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.