The Sinclair QL Forum

Hi all!

I wonder if there is any DOC with the expansion ports maps. I mean pinout & signal descriptions.
The service manual isn't enough for me, since it doesn't tell if the signals are in/out or bi. Of course I don't mean ADDR or DATA signals.

It would save a good time for development (considering that I forget everything every week after).

For example:
I wanted to start my test with some devs connecting them to the ROM expansion and Expansion Port (J1) and it has its own ROM on it, so I need to disable internal QL ROM, I thought it was ROMOEH to disable the internal QL ROM, but I was wrong (thanks to Alvaro to point me at that matter).

That is just an example, so I would love to have a fast consulting document to check out the pinouts and signal purposes.

Also reading some old threads from Noel Llopis, where some people explained how parts of the System starts. That also would be very very helpful to integrate Devs into QL System. In that thread somebody (perhaps Nasta) explained that ZX8302 doesn't start to work till Minerva ROM has check firstly the RAM, this order in booting is another point would help a lot.

Thank you very much!.

There is no way to disable the internal ROMs from the expansion port (or any port, for that matter), other than unplugging it. You might confuse that with the ZX Spectrum that has that capability.

tofro wrote: Sat Aug 23, 2025 1:28 pm There is no way to disable the internal ROMs from the expansion port (or any port, for that matter), other than unplugging it. You might confuse that with the ZX Spectrum that has that capability.

????
Sorry tofro, perhaps I explained myself not good enough.
There are ways, otherwise you would need to open your QL every time you insert for example... a Gold Card, or QIMSI or SGC... QBIDE... whatever.
They have their own ROMs (and some of those) disable internal QL ROM (somehow).

Each system at this time (structure) has some signals to enable or disable a ROM, usually they are ROMOE or ROMEH or similar. that allows to activate or de-activate other ROMs in the system.
In fact, what confuses me a lot are not standard names for those signals.

Or perhaps just I didn't understood at all how it really works. So please to explain it if you don't mind

If you see QL Expansion port you can notice there are ROMOEH and DSMCL (last one works de-activating ULAs that activates the inner ROM, I was told), those lines does that work in this case. Just I didn't found proper DOC.

Thanks

Edit:
I add an example about the structured information that I am looking for but not only for that signal. Sometimes I can figure it out by myself, but it requires a lot of reading in many different sources. An always there is a risk to take wrong a signal that could damage the QL.
So in order to integrate properly my devs, I would like to save time and have a DOC that explain the purpose of those signals and how they works.

I suppose the gold card uses the bus arbitration signals to completely disable the CPU.

From memory: DSMCL is connected to the CPU DS through a resistor, so it goes low to signal to the ZX8301 that there is a bus access to the onboard RAM or ROM by the CPU. Peripherals can prevent this (and provide data to the CPU themselves instead) by using a transistor to switch DSMCL to high.

There was a series on interfacing to the QL in QL World magazine, see for example the February 1987 issue: https://archive.org/details/ql-world/QL ... 0/mode/2up

M68008 wrote: Sat Aug 23, 2025 4:58 pm I suppose the gold card uses the bus arbitration signals to completely disable the CPU.

From memory: DSMCL is connected to the CPU DS through a resistor, so it goes low to signal to the ZX8301 that there is a bus access to the onboard RAM or ROM by the CPU. Peripherals can prevent this (and provide data to the CPU themselves instead) by using a transistor to switch DSMCL to high.

There was a series on interfacing to the QL in QL World magazine, see for example the February 1987 issue: https://archive.org/details/ql-world/QL ... 0/mode/2up

Thank you very much for the link, very useful.
CPU has direct access to the ROM, no need to ask to the ULAs since they are in the other side of the bus (ADDR and DATA).
So DSMCL is controled by ULAs or by the CPU? I see in Iss5 is the CPU who activate the transistor that put the signal DSMCL to high or low (I guess), but still fighting with the concepts to see it clearly.
By now I am a sea of doubts

What is clear now is that I need to write my own Doc with all the information about the system signals and working in order to make it easier for me in a couple of weeks to remember what, where, when and why
And to share it for others.

The KILLH signal is logically A18 AND A19. It indicated an external bus cycle. When KILLH is asserted it sets DSMCL continuous High (negated). This prevents the 8301 from being active on the bus, read or write.

The DSL signal remains operational on the expansion port, which allows the CPU to properly access external devices or memory.

On Issue 6/7 this signal comes from IC18. On Issue 5, from IC38.

Hope this helps.

Thanks boths!
It helps Dave... I am taking notes and spreading the glue for all the pieces of the puzzle

Dave wrote: Sat Aug 23, 2025 6:36 pm The KILLH signal is logically A18 AND A19. It indicated an external bus cycle. When KILLH is asserted it sets DSMCL continuous High (negated). This prevents the 8301 from being active on the bus, read or write.

So, DSMCL is not a signal that generate 8301, checking the schem from Iss5 I thought it was the CPU with VAP' signal that activate the transistor to put High or Low the signal DSMCL.
I will need more time to be able to implement my own ROM into the expansion port. Not so easy as I thought.
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.

Dave wrote: Sat Aug 23, 2025 6:36 pm The DSL signal remains operational on the expansion port, which allows the CPU to properly access external devices or memory.

Devices or memory? the whole rank, right? I mean 000h to 4000h (ROM area)

Dave wrote: Sat Aug 23, 2025 6:36 pm On Issue 6/7 this signal comes from IC18. On Issue 5, from IC38.

In Iss5... I must misunderstand the schem, perhaps you can explain it to me better...
And I thought from there (CPU) comes the control over the signal DSMCL, let me show you... The CPU control the base of the transistor to put high or low the signal. I have not the equations (or logic schem) for the HAL to know how it works internally, but by comparision it seemed to me that was the CPU.
Sure if tomorrow I check the CPU datasheet I will discover it is an Input Pin (signal) so that cannot be the CPU but by the schems... that is what I thought.

The addresses within a standard QL are all controlled through the ZX8301 or with the ZX8301 and HAL chip (issue 6 onwards) - the DSMCL (data strobe master chip low), signal is basically a copy of the DS signal from the CPU, but via a resistor - if you tie this line high when your device needs to overide, then the CPU can't address the ZX8301/HAL and your device can respond instead. This is basically the trick all expansion cards use. Note that the interals of the QL are completely unaware of what's going on with A18 and A19 address lines - only the CPU knows, so anything outside the 256K of the original QL is normally just seen as repeats of the internal hardware - hence why DSCML is needed.

Popopo wrote: Sat Aug 23, 2025 6:30 pm CPU has direct access to the ROM, no need to ask to the ULAs since they are in the other side of the bus (ADDR and DATA).
So DSMCL is controled by ULAs or by the CPU? I see in Iss5 is the CPU who activate the transistor that put the signal DSMCL to high or low (I guess), but still fighting with the concepts to see it clearly.

DSMCL is an input to the ZX8301.
The transistor would be on the external peripheral. The transistor you see on the motherboard does something else, I would ignore it for now.
The ZX8301 generates ROMOEH to enable the onboard ROM, mainly based on A16 and A17 I guess.

Pr0f wrote: Sat Aug 23, 2025 6:54 pm The addresses within a standard QL are all controlled through the ZX8301 or with the ZX8301 and HAL chip (issue 6 onwards) - the DSMCL (data strobe master chip low), signal is basically a copy of the DS signal from the CPU, but via a resistor - if you tie this line high when your device needs to overide, then the CPU can't address the ZX8301/HAL and your device can respond instead. This is basically the trick all expansion cards use. Note that the interals of the QL are completely unaware of what's going on with A18 and A19 address lines - only the CPU knows, so anything outside the 256K of the original QL is normally just seen as repeats of the internal hardware - hence why DSCML is needed.

I didn't understand it pretty well:
The QL has 128K, so why to try to access to the next 128K?
I understand the CPU & ULAs needs a mechanism to access to the RAM without conflict, but CPU doesn't need to share the access to the ROM area.
A18,A19... don't go to the HAL, they are A6, A16 & A17 (based in the schem)... The last of your point is what is the most interesting point, but I couldn't understand it properly yet.