Connecting a uC (PIC) to the QL

[martyn_hill]

Hi there!

You are correct. We used to have to rely on a fast transistor to drive DSMC# High upon recognising it's own address and thus 'steal' it from the 8301. Today's modern CPLDs are both fast enough and provide enough current drive to achieve the same effect before the 8301 detects DS#.

That said, you should NOT wait until DS# becomes active (low) before driving DSMC# - instead just decode the address lines without gating on DS#.

I suspect that Daniele was simply warning that your CPLD IO on Pin #43 should only ever go either Tri-state or High - never an active Low output.

[fuasn]

I suspect that Daniele was simply warning that your CPLD IO on Pin #43 should only ever go either Tri-state or High - never an active Low output.

ah ! yes, that makes sense. thank you !

[martyn_hill]

Hi again fuasn!

Just wanted to add a small additional consideration that is sometimes overlooked and, in any case becomes relevant dependent upon which address lines you are decoding...

The 68k will also issue what looks like a valid memory access during its ACKnowledge to an Interrupt. You should aim to differentiate such a memory cycle and not activate your address decode upon this condition. The simplest way is to also decode the 68k Function Code signals, which will set FC0..2 active and disable your address decode (including NOT disabling the 8301 with DSMC#) in this condition.

As it happens, it's enough to look at just FC0 and FC1 - if both Active, you are looking at an Interrupt acknowledge cycle...

Good luck!

[fuasn]

hi martyn_hill,

okay thank you, never heard of that, do you maybe have some pointer for more info ? does it also include DS(L) asserted ?
would mean i need to wire FC0 & FC1 then to the CPLD (and sacrifice 2 of the "free" pins). i got some CUPL inspiration from a memory-expansion project in this forum and that didn't include FC0 & FC1, but maybe because that decodes only non-relevant addresses for that behavior.

[martyn_hill]

Hi fuasn!

So your main source of info would be the MC68000 User Manual (not the 'PRM' programmers manual, as that's just from the SW angle) but you'll also find a similar description posted by Nasta some years ago on this Forum when he was answering some questions about custom memory expansions.

If I find it first, I'll write again with the specific post link.

EDIT: You'd do worse than to read this post from Guru Nasta...
viewtopic.php?p=42949#p42949

Look for his detailed description on Sat Sep 04, 2021 11:41 pm under the sub-heading: "2) Potential signal conflict during interrupt acknowledge."

Good luck!

[fuasn]

thx a lot ! will read..

... hm, that sounds very thrilling, but i have problems understanding why the extension should be in the address spaces mentioned

-- until some unlucky person designs a peripheral that sits up at the address $FFFF5, which may generate /DTACK faster (so problems might occur). What is more insidious is that a typical peripheral will have ROM at the start of a 16k boundary within the expansion area at $C0000 and above, in this case it would be $F8000, and quite probably some bits that control some hardware that is not memory, but say, a floppy controller, in the highest address of it's 16k slot. In this case this may end up being $FFFxx, and xx could well be $F5. In other words, the highest addresses are likely to be used for some type of hardware control, and in this case it is not uncommon that even the actual reading of data from such addresses (regardless of the contents) may have effects in the real world ...

shouldn't the end of the add-on peripherals address space be $E0000-1 ? especially that

in this case it would be $F8000

. isn't that already the add-on rom area ?
i mean i don't have problems wiring FC0 & FC1 to the CPLD, but i don't understand it tbh

[fuasn]

btw i think im also wiring the colors the csync & vsync and that VPAL to the "next" connector, but i dont think i need them on this extension.

[martyn_hill]

Hi again fuasn!

... hm, that sounds very thrilling, but i have problems understanding why the extension should be in the address spaces mentioned

shouldn't the end of the add-on peripherals address space be $E0000-1 ? especially that

in this case it would be $F8000

. isn't that already the add-on rom area ?

Whilst Sinclair/TT originally documented that the 128KB at 0xC0000 (768KB) of the 68008 1MB memory map should be reserved for peripheral/IO cards, with add-on ROMs occupying the final 128KB from 0xE0000 (896KB) onwards, there is no hardware limitation forcing one to to stick to that and, as long as you disable the 8301 from detecting memory accesses in your chosen area (by pulling DSMC# High), you are free to use any of it for your own purposes - at least as far as the hardware is concerned. In fact, the standard that got adopted in the end was for each peripheral/IO card to interleave it's own ROM & IO within a 16KB block and for that range to span everything above 768KB (in conjunction with the SP0..3 lines to provide up to 16x 16KB regions.)

Minerva, for example, will check EVERY 16KB boundary above RAMTOP for a ROM identifier (until it finds repetition/mirroring.)

i mean i don't have problems wiring FC0 & FC1 to the CPLD, but i don't understand it tbh

Don't worry about it - it only really matters if either of the following 2 conditions hold:
1. You have chosen to use and explicitly/fully decode the address space to include those last 16bytes (don't worry why it's 16bytes for now), or
2. You have chosen to ignore some of the address lines to simplify your decoding logic, effectively resulting in a 'mirror' of your chosen address space re-appearing in those final 16bytes.

If neither of the above 2 conditions hold for your design, then you can safely ignore this 'edge-case' of needing to detect the Interupt-ACK memory access cycle and explicitly exclude it from your address decoding logic.

[M68008]

I suspect that Daniele was simply warning that your CPLD IO on Pin #43 should only ever go either Tri-state or High - never an active Low output.

Exactly. Mainly pointing this out as DSMCL ends with L (for active-low), but it should never be set to Low. Confusing, at least to me.

[Peter]

Exactly. Mainly pointing this out as DSMCL ends with L (for active-low), but it should never be set to Low. Confusing, at least to me.

For the external bus, this signal can be thought as "DSMCDIS" for "Data Strobe Master Chip Disable", which would then be high-active. But only highside driven.