I think it was a typo, A18 and A19 are ignored by the QL motherboard and are only used by peripherals.Popopo wrote: Sat Aug 23, 2025 6:53 pm BTW, to the HAL goes A6,A16 & A17. I don't see A18 nor A19, I must check a better look how they are bound to it.
Port Map And Signals Descriptions
Re: Port Map And Signals Descriptions
Re: Port Map And Signals Descriptions
Thanks!
I will try but I cannot promise it (very interesting puzzle)
So I guess zx8301 has a default signal value at powering the QL on. Otherwise it create a lot of doubts about how Ramtest (like Minerva and others) works to check RAM or, does it work (ramtests) once this ULA starts?
That is what I thought.
OKM68008 wrote: Sat Aug 23, 2025 7:04 pm The transistor would be on the external peripheral. The transistor you see on the motherboard does something else, I would ignore it for now.
I will try but I cannot promise it (very interesting puzzle)ZX8302 doesn't need it too?M68008 wrote: Sat Aug 23, 2025 7:04 pm The ZX8301 generates ROMOEH to enable the onboard ROM, mainly based on A16 and A17 I guess.
So I guess zx8301 has a default signal value at powering the QL on. Otherwise it create a lot of doubts about how Ramtest (like Minerva and others) works to check RAM or, does it work (ramtests) once this ULA starts?
Re: Port Map And Signals Descriptions
In the issue 5 QL - so no HAL - the ZX8301 acted as both video generator and address decoder - so it would produce the ROMOEH signal - this means the A17 and A16 are both low, bottom 64K is addressed, it would share one register address for video and a few addresses in the ZX8302 in the next block of 64K - QL I/O starts at 18000h - so this is with A17 Low and A16 High, then the top 128K with A17 high - is the RAM - 2 banks of 64K, of which the lower bank has the capability of 2 screens of 32K for video.
What the HAL does is to better decode the I/O so that ZX8302 which controls most of the I/O does not sit on the contended database shared with video data being produced.
This is all covered in the technical guide - but that is quite 'dry' as a manual goes.
What the HAL does is to better decode the I/O so that ZX8302 which controls most of the I/O does not sit on the contended database shared with video data being produced.
This is all covered in the technical guide - but that is quite 'dry' as a manual goes.
Re: Port Map And Signals Descriptions
Yes. To clarify/correct myself, the circuit to pull DSMCL high is implemented physically on the expansion. It's a line in my equations. I had to invert it because the area that's valid external is much larger with a 24 or 32-address line CPU than a 68008.
One of the things I regret is that people have always misused the SP0..3 lines. Sinclair's intention was not communicated clearly so it was used poorly by even high status members of the hardware dev community.
The intention of S0..3 was to be tied to GND on the J1 connector, and each incremental slot would be 0001 0010 0011 0100 and etc. These four bytes could be simply compared to A11..14 to tell a card which slot it was in.
Expansion_select = A18 & A19 & !A17
Card_select = Expansion select & (SP0..3 = A11..14)
Cards were not supposed to map themselves into areas. They were supposed to accept the area physically indicated by the socket. Sinclair did not envision that people would use through-connectors at inception. They presumed that multiple expansions would have their own connector.
Personally, I'd move the SP0..3 lines up the address bus a bit to give each expansion card a larger allocation.
I was told this by David Karlin personally in 1986 or so. Alan Miles, Bruce Gordon and Arnie Gardner were present. He had just left Sinclair Research a few weeks before and was looking around for something to do while he looked for a position that fitted his station.
I relayed this nugget to Nasta several years ago and he flatly told me I was mistaken. Sooooo, I guess it's up for debate. Discuss!
One of the things I regret is that people have always misused the SP0..3 lines. Sinclair's intention was not communicated clearly so it was used poorly by even high status members of the hardware dev community.
The intention of S0..3 was to be tied to GND on the J1 connector, and each incremental slot would be 0001 0010 0011 0100 and etc. These four bytes could be simply compared to A11..14 to tell a card which slot it was in.
Expansion_select = A18 & A19 & !A17
Card_select = Expansion select & (SP0..3 = A11..14)
Cards were not supposed to map themselves into areas. They were supposed to accept the area physically indicated by the socket. Sinclair did not envision that people would use through-connectors at inception. They presumed that multiple expansions would have their own connector.
Personally, I'd move the SP0..3 lines up the address bus a bit to give each expansion card a larger allocation.
I was told this by David Karlin personally in 1986 or so. Alan Miles, Bruce Gordon and Arnie Gardner were present. He had just left Sinclair Research a few weeks before and was looking around for something to do while he looked for a position that fitted his station.
I relayed this nugget to Nasta several years ago and he flatly told me I was mistaken. Sooooo, I guess it's up for debate. Discuss!
Re: Port Map And Signals Descriptions
Even the technica guide contradicts itself - with saying that there were to be 16 'slots' of 16K each for I/O and supporting ROMS, but also spoke of a 128K area for ROM for toolkits etc.
To be honest it's a mute point now, but you could still use a similar concept even on an expanded machine.
To be honest it's a mute point now, but you could still use a similar concept even on an expanded machine.
Re: Port Map And Signals Descriptions
I just found my original notes from then. He said they intended for people to use a 74HC85 to directly compare A11.14 against SP0..3, and add that to A19 & A18 & !A17. 74HC85 are still available and cheap, in DIP, SOIC and TSSOP.
My noted circuit is 74HC21 dual 4 input AND gate and a 74HC04 gate.
The 74HC04 inverts A17 creating !A17 = 1 with a propagation delay of 8 ns.
A19, A18 = 1
SP_match = 1 with an 18ns propagation delay
These four 1's go to the 4 input AND gate deriving a slot specific select signal on the output with a 9ns delay. This gives you a determination in typically 35 ns. Using LVC replacements this can be cut to 12-15ns. Using an ATF150X CPLD or similar achieves 10ns or even 7ns depending on speed grade.
In a 7.5 MHz QL we have a valid address available at 125ns. DSL asserts at 187ns. A zero wait cycle has DTACKL asserted by 312ns (the uptick of S2) so we should have our cycle complete and stable on the data bus by then with DTACKL valid.
Real world, that's a comfortable 180ns to decode and complete a zero wait state cycle.
On a 16 MHz system that drops to 90ns. On a 25 MHz system 54ns. 30 Mhz you got 45ns. With these timings if you don't finish in time that's fine. The CPU will just keep repeating S2 until DTACKL is latched and S3 can begin.
(Not aimed at any specific person or anyone here. Just a "please keep this in mind when making things other people will copy or use.)
Mini-rant after watching someone release hardware that worked on their system but caused data loss in others' machine that had a certain bit of common hardware in them:
When designing expansion cards, always map out the time budget and the propagation delay tree, stacked correctly. When you build hardware use your tools to confirm real hardware meets the calculated delays. If it doesn't, recalculate your delays with the real world data. You're designing expansion hardware that goes into vintage computers that people consider very precious. I would hope you have at least a multimeter, oscilloscope and TTL logic analyzer. The logic analyzer, should you decide to run out and get one, should sample at 4-5x the highest frequency you want to accurately see. So on a 7.5 MHz computer, if you use all 8 or 16 channels it should still maintain at least a 30 MHz sample rate. If it doesn't, reduce the number of captured channels until it is fast enough. For example the LA2016 can sample 100MHz@3CH, 50MHz@6CH 32MHz@9CH, 16MHz@16CH. So you can use up to 9 channels to get good quality captures from a 7.5 MHz machine. Yes, it works at slower speeds but the relative relationships of signal changes (the thing you're looking for) become more aliased the lower the sample rate to frequency ratio.
With easy and cheap availability of PCB services to any hobbyist, we do have to remind people that other people's computers are precious. It may be a hobby to you but some people have a lot invested in their systems.
My noted circuit is 74HC21 dual 4 input AND gate and a 74HC04 gate.
The 74HC04 inverts A17 creating !A17 = 1 with a propagation delay of 8 ns.
A19, A18 = 1
SP_match = 1 with an 18ns propagation delay
These four 1's go to the 4 input AND gate deriving a slot specific select signal on the output with a 9ns delay. This gives you a determination in typically 35 ns. Using LVC replacements this can be cut to 12-15ns. Using an ATF150X CPLD or similar achieves 10ns or even 7ns depending on speed grade.
In a 7.5 MHz QL we have a valid address available at 125ns. DSL asserts at 187ns. A zero wait cycle has DTACKL asserted by 312ns (the uptick of S2) so we should have our cycle complete and stable on the data bus by then with DTACKL valid.
Real world, that's a comfortable 180ns to decode and complete a zero wait state cycle.
On a 16 MHz system that drops to 90ns. On a 25 MHz system 54ns. 30 Mhz you got 45ns. With these timings if you don't finish in time that's fine. The CPU will just keep repeating S2 until DTACKL is latched and S3 can begin.
(Not aimed at any specific person or anyone here. Just a "please keep this in mind when making things other people will copy or use.)
Mini-rant after watching someone release hardware that worked on their system but caused data loss in others' machine that had a certain bit of common hardware in them:
When designing expansion cards, always map out the time budget and the propagation delay tree, stacked correctly. When you build hardware use your tools to confirm real hardware meets the calculated delays. If it doesn't, recalculate your delays with the real world data. You're designing expansion hardware that goes into vintage computers that people consider very precious. I would hope you have at least a multimeter, oscilloscope and TTL logic analyzer. The logic analyzer, should you decide to run out and get one, should sample at 4-5x the highest frequency you want to accurately see. So on a 7.5 MHz computer, if you use all 8 or 16 channels it should still maintain at least a 30 MHz sample rate. If it doesn't, reduce the number of captured channels until it is fast enough. For example the LA2016 can sample 100MHz@3CH, 50MHz@6CH 32MHz@9CH, 16MHz@16CH. So you can use up to 9 channels to get good quality captures from a 7.5 MHz machine. Yes, it works at slower speeds but the relative relationships of signal changes (the thing you're looking for) become more aliased the lower the sample rate to frequency ratio.
With easy and cheap availability of PCB services to any hobbyist, we do have to remind people that other people's computers are precious. It may be a hobby to you but some people have a lot invested in their systems.
Re: Port Map And Signals Descriptions
OK, so (I know, hard to believe) I am going to try and keep this short.
8301 is the main decoder in the QL an decodes ROM, RAM and IO.
ROMOEH is a high active line from the 8301 to the ROM sockets and also appears on the expansion connector J1. It is a direct output, do NOT tie it to another output or a fixed logic level, you can fry the 8301. You can use it to select a ROM mounted on a board plugged into the J1 connector as long as the ROM sockets on the motherboard have nothing in them.
IO is mostly located inside the 8302, which is selected by the 8301 signal PCENL (PC=peripheral chip=8302) going low. This signal only appears on the motherboard.
The 8301 has no A18 and A19 input lines, they only go from the CPU to J1. This is known as partial (as opposed to full) decoding. Because it has no idea about the states of A18 and A19, the same decoding will be seen at $00000..$3FFFF, $40000..$7FFFF, $80000..$BFFFF, $C0000..$FFFFF, once for each of the 4 possible combinations of A18 and A19, This means everything is seen 4 times within the address map, i.e. there are 4 'aliases' of every device.
On an unexpanded QL, that's it.
Now we come to the DSMCL signal. MC='master chip'=8301. This is the DSL _INPUT_ to the 8301, which is connected to the DSL pin on the J1 through a resistor, and it also appears on the bus.
The DSL signal (as far as the QL is concerned) indicates a data transfer is happening on the bus, this implies a stable address is present on A0..A19, to be decoded by devices external to the CPU.
The resistor between DSL (driven by the CPU) and DSMCL (observed by the 8301) is there so that an external decoder present on J1 can over-ride the built-in decoder in the 8301 by pulling DSMCL high if an address of interest is present on J1, thereby preventing the 8301 from even seeing there is decoding to do. The resistor prevents DSL trying to drive low while an external device is driving high - because the external device is connected after the resistor, it will 'win' because the resistor makes the DSL signal weaker, and of course protects the DSL signal pin on the CPU from potentially frying by limiting current.
In short: Pulling DSMCL high will disable everything on the motherboard by preventing the 8301 from even knowing there is something supposed to be going on on the bus, hence no decoding and no selecting anything.
Simply, if something on J1 wishes to use any address that appears on J1, it has to pull DSMCL high when that address appears on A0..A19. Since the address lines are stable before DSL goes low indicating that this is so, suitably fast logic (time between address lines being stable and DSL going low is quite short) can pull DSMCL high before DSL goes low and all internal decoding on the motherboard will be disabled. Again, yes, that includes ANY address, including the ROM (slot).
So, if an external ROM address decoder is implemented, if it pulls DSMCL high, the internal ROM will be disabled and an external one can be selected using the said decoder output.
8301 is the main decoder in the QL an decodes ROM, RAM and IO.
ROMOEH is a high active line from the 8301 to the ROM sockets and also appears on the expansion connector J1. It is a direct output, do NOT tie it to another output or a fixed logic level, you can fry the 8301. You can use it to select a ROM mounted on a board plugged into the J1 connector as long as the ROM sockets on the motherboard have nothing in them.
IO is mostly located inside the 8302, which is selected by the 8301 signal PCENL (PC=peripheral chip=8302) going low. This signal only appears on the motherboard.
The 8301 has no A18 and A19 input lines, they only go from the CPU to J1. This is known as partial (as opposed to full) decoding. Because it has no idea about the states of A18 and A19, the same decoding will be seen at $00000..$3FFFF, $40000..$7FFFF, $80000..$BFFFF, $C0000..$FFFFF, once for each of the 4 possible combinations of A18 and A19, This means everything is seen 4 times within the address map, i.e. there are 4 'aliases' of every device.
On an unexpanded QL, that's it.
Now we come to the DSMCL signal. MC='master chip'=8301. This is the DSL _INPUT_ to the 8301, which is connected to the DSL pin on the J1 through a resistor, and it also appears on the bus.
The DSL signal (as far as the QL is concerned) indicates a data transfer is happening on the bus, this implies a stable address is present on A0..A19, to be decoded by devices external to the CPU.
The resistor between DSL (driven by the CPU) and DSMCL (observed by the 8301) is there so that an external decoder present on J1 can over-ride the built-in decoder in the 8301 by pulling DSMCL high if an address of interest is present on J1, thereby preventing the 8301 from even seeing there is decoding to do. The resistor prevents DSL trying to drive low while an external device is driving high - because the external device is connected after the resistor, it will 'win' because the resistor makes the DSL signal weaker, and of course protects the DSL signal pin on the CPU from potentially frying by limiting current.
In short: Pulling DSMCL high will disable everything on the motherboard by preventing the 8301 from even knowing there is something supposed to be going on on the bus, hence no decoding and no selecting anything.
Simply, if something on J1 wishes to use any address that appears on J1, it has to pull DSMCL high when that address appears on A0..A19. Since the address lines are stable before DSL goes low indicating that this is so, suitably fast logic (time between address lines being stable and DSL going low is quite short) can pull DSMCL high before DSL goes low and all internal decoding on the motherboard will be disabled. Again, yes, that includes ANY address, including the ROM (slot).
So, if an external ROM address decoder is implemented, if it pulls DSMCL high, the internal ROM will be disabled and an external one can be selected using the said decoder output.
Re: Port Map And Signals Descriptions
Not mistakenDave wrote: Sat Aug 23, 2025 9:10 pm
One of the things I regret is that people have always misused the SP0..3 lines. Sinclair's intention was not communicated clearly so it was used poorly by even high status members of the hardware dev community.
The intention of S0..3 was to be tied to GND on the J1 connector, and each incremental slot would be 0001 0010 0011 0100 and etc. These four bytes could be simply compared to A11..14 to tell a card which slot it was in.
Expansion_select = A18 & A19 & !A17
Card_select = Expansion select & (SP0..3 = A11..14)
Cards were not supposed to map themselves into areas. They were supposed to accept the area physically indicated by the socket. Sinclair did not envision that people would use through-connectors at inception. They presumed that multiple expansions would have their own connector.
Personally, I'd move the SP0..3 lines up the address bus a bit to give each expansion card a larger allocation.
I was told this by David Karlin personally in 1986 or so. Alan Miles, Bruce Gordon and Arnie Gardner were present. He had just left Sinclair Research a few weeks before and was looking around for something to do while he looked for a position that fitted his station.
I relayed this nugget to Nasta several years ago and he flatly told me I was mistaken. Sooooo, I guess it's up for debate. Discuss!
this is correct and was indeed intended that way but it can only reliably be implemented on systems where the expansions all have through-connectors (though there might be limitations even then). The point was that each card takes the SP0..3 lines in from J1 and then adds the number of 16k slots it needs and outputs them on the through connector.SP0..3 are compared to A14, A15, A16 and A17 (lower order lines may be omitted as needed if more than 1 16k slot is needed) while A18 and A19 are high.
What I objected to is that the idea is great in theory as long as each peripheral only takes one 16k slot, and more importantly, proper integrity of all other other signals in such a long bus system is really there, which is challenging to put it mildly.
Alternatively one could use a backplane system and then permanently assign SP0..3 codes to each slot, but the problem then remains if any peripheral needs to use more than 1 slot, you can't plug those into just any available slot or conflicts may happen, and it would be difficult to explain to an average user how to decide what can go where without the risk of problems ranging from 'it does not work' all the way to 'it killed my QL and/or expansion card'.
I should know, I actually made that backplane as one of my very first QL projects, it had 7 slots, and the system had 768k RAM, taking up the first 8 slots for the extra 128k over the specified 640k total RAM (I was very happy when the system saw the extra RAM over 640k even on a JM ROM!), so SP3..0 started at 1000. 7 out of the remaining 8 were present on the backplane, one was internally used on the board that drove it (and had other stuff on it). I was very disappointed when the JM ROM did not detect any peripherals at all above $C0000m though so nothing worked in those slots.
I should also know as the original prototype Qubide circuit used the address comparator mechanism (but not the 'add 1 to SP0..3 on the through port'). However, the various limitations to where the Qubide could be mapped, imposed by other expansions that were available, ended up keeping the comparator on the production version, but now the address lines were compared to the state of mapping jumpers. This made it possible to locate the Qubide in the ROM slot (disabling it from J1
), or indeed at $10000 or $14000 that are additional slots made available with Minerva (unless TC and later GC and SGC were used, which imposed their own limits), or any of the slots starting at $C0000 and up.As Prof said, once more than 512k of expansion RAM became desirable, this became a moot point as the RAM was mapped into (at least some) of the 16k slots for add-on peripherals - it had nowhere else to go. Later on, GC and SGC and then Aurora made it even more moot.
Honestly, J1 needed extra ground lines interspersed along the length of it more than the SP lines, especially as none of the early ROMS (up to JS if I remember correctly) tested for the presence of a peripheral in any other slot but $C0000.
Re: Port Map And Signals Descriptions
I have done this with my 8-way backplane. I just solve the problem by documenting it, so it's a feature.
For cards that exceed their associated address range, use the highest available slot. It is critical that multi-slot cards are placed in a slot that aligns with their address range needs:
- For 2-slot cards: Place in a slot number that is a multiple of 2 (i.e., slot MOD 2 = 0).
A custom backplane from [company name] with configurable solder bridges is available if custom top-slot numbering is required.
- For 4-slot cards: Place in a slot number that is a multiple of 4 (i.e., slot MOD 4 = 0).
Re: Port Map And Signals Descriptions
I'll just point out that I think the Sandy SuperQ Mouse board had 32k, so would possibly conflict on a backplane in what Nasta has just outlined. At least to get all 8 slots (disregarding 9 to 16 for the ROM card).
I assumed that wasn't a problem as Sinclair document it as being possible, if not desirable by them.
In fact Sinclair's planned Xchange on ROM deviates from this at somewhere around 180k (figure given in a Thor review in QL World as to why it wasn't done on the Thor).
A backplane of 16 Care cartridges maybe be possible :D
I assumed that wasn't a problem as Sinclair document it as being possible, if not desirable by them.
In fact Sinclair's planned Xchange on ROM deviates from this at somewhere around 180k (figure given in a Thor review in QL World as to why it wasn't done on the Thor).
A backplane of 16 Care cartridges maybe be possible :D
Last edited by Wicksy on Tue Aug 26, 2025 5:12 am, edited 3 times in total.