Port Map And Signals Descriptions

[Dave]

The Sandy SuperQBoard had a 16K driver image and TK2. The TK2 can be relocated.

I could just put this card in slot 6 or 8. On 16M/4G range CPUs I would move the select bytes up a few so each card has 128K or something like that. A14..17 instead of A11..14. That would open up some cool expansion options.

[Popopo]

So great to collect all that information about how works the signaling and devices allocation

How signals works (and their bounds) is pretty important in order to design future devs, for port expansions or even inside.

Moreover it is very helpful for mods and deep changes in the QL board.
With this thread many considerations to keep in mind, it saves me a lot of time in the Devs, reducing mistakes and the most important, giving stability and safe use to the users that port their main integrates to the new board.

To be sure about the priorities for the system before to go ahead...
When the system turns on, the CPU try to read addr 0h (ROM), and all the other ICs (ULAs) keep how? "awaiting/sleeping" mode?
Could They try to call a CPU IRQ at any time even when the CPU didn't started?

I guess all they will wait for CPU first instructions, but I am not so sure about ZX8301 since it may try to read the RAM (that the CPU initialize) to know what to painT on the screen.

At the end, all is about how to manipulate the system in order to integrate devices on it. Many devices goes by the expansion ports (I include the ROM port on it)
And the way to do it by controlling the signals functions and what/when/why generate it.

[tofro]

To be sure about the priorities for the system before to go ahead...
When the system turns on, the CPU try to read addr 0h (ROM), and all the other ICs (ULAs) keep how? "awaiting/sleeping" mode?
Could They try to call a CPU IRQ at any time even when the CPU didn't started?

Peripherals don't "call an IRQ" - They simply set the IPL lines. All 68k CPUs start with an IPL of 7 in supervisor mode, thus everything but the NMI (which can only be triggered by the IPC in a standard QL and would lead to a crash anyways) is ignored during initialization.

I guess all they will wait for CPU first instructions, but I am not so sure about ZX8301 since it may try to read the RAM (that the CPU initialize) to know what to pain on the screen.

QL peripherals have no "initiative" of their own - They cannot "wait". If they're not instructed by the CPU to do something they won't (with the exception of the video circuitry). The 8301 will start scanning and shifting out the video memory as soon it's switched on (and generate VBL interrupts, which are ignored by the CPU until it decides not to), and that creates the random screen pattern after a reset - because the CPU hasn't yet initialized the frame buffer.

[Popopo]

Thanks tofro

Peripherals don't "call an IRQ" - They simply set the IPL lines. All 68k CPUs start with an IPL of 7 in supervisor mode, thus everything but the NMI (which can only be triggered by the IPC in a standard QL and would lead to a crash anyways) is ignored during initialization.

Then, only the NMI that is provoked by IPC would take the control back.
In case the CPU crash, I need the CPU to come back to my bootloader routine... OK. It requires to measure the time to when it happen (to do everything I need, before that event).

(with the exception of the video circuitry). The 8301 will start scanning and shifting out the video memory as soon it's switched on (and generate VBL interrupts, which are ignored by the CPU until it decides not to), and that creates the random screen pattern after a reset - because the CPU hasn't yet initialized the frame buffer.

That's what I supposed. Since I am not going to access to the QL RAM, I guess nothing is going to disturb the CPU. Somehow I misunderstood in previous messages (when talking about DSMCL and others) that line avoid CPU to access to the buffered RAM, so that may somehow stop CPU from what it was doing (worried about, not asserting it).

That is a good news. It implies that I could get (maybe) 1 second to do everything I need before to return the control to the CPU.

I guess... it is also time to think about to get a logic analyzer for study and working with QL to synchronize signals for devs. The OpenSource of Agustin B (Dr. Gusman) seems more than enough for this matter.

[tofro]

Thanks tofro

Peripherals don't "call an IRQ" - They simply set the IPL lines. All 68k CPUs start with an IPL of 7 in supervisor mode, thus everything but the NMI (which can only be triggered by the IPC in a standard QL and would lead to a crash anyways) is ignored during initialization.

Then, only the NMI that is provoked by IPC would take the control back.

Not sure what you mean with "take control back". The CPU is always in control. It can be made to wait until the video circuitry is done generating a frame (that's done by the 8301 by simply not generating a DS for frame buffer memory access until it's done, so it simply simulates "very slow memory" in the frame buffer area). But if your external circuitry generates a DSML faster than the 8301, you're both telling the 8301 "I got that, don't worry" and the CPU "you can read now". In my understanding, you simply cannot tell the 8301 that it shouldn't bother for that address and the CPU to wait until you got your data ready.

In case the CPU crash, I need the CPU to come back to my bootloader routine... OK. It requires to measure the time to when it happen (to do everything I need, before that event).

The IPC will only generate an NMI if you press <CTRL>-<ALT><7>

[Pr0f]

So technically speaking the 68008 is using aysnchronous access - requiring a device to respond on DTACK pin when it's ready to send or receive data, the DS pin from the CPU initiates the request. If your external hardware raises DSMCL when the address matches one you are providing an override for - the 8301 will never assert dtack - so your device must respond instead and provide it. As there is no BERR circuit on the QL to timeout after some number of clock periods - it will wait indefinitely if you don't assert DTACK.

Just to be clear- assert means to make active, in the case of DS and DTACK - these are both active low.

[Nasta]

...
To be sure about the priorities for the system before to go ahead...
When the system turns on, the CPU try to read addr 0h (ROM), and all the other ICs (ULAs) keep how? "awaiting/sleeping" mode?
Could They try to call a CPU IRQ at any time even when the CPU didn't started?
I guess all they will wait for CPU first instructions, but I am not so sure about ZX8301 since it may try to read the RAM (that the CPU initialize) to know what to painT on the screen.
And the way to do it by controlling the signals functions and what/when/why generate it.

A short explanation is certainly possible but all of this is clearly described in the 68008 user manual (easily found on the net). The QL is a fairly simple machine and all the signals except power, video and DSMCL are basically copies of the CPU signals.
Also, for how interrupts work, see the 'Hardware programmable timers' thread. On the QL you are limited to using either EXTINTL which ties into interrupt level 2 through the 8302, or directly using the IPL1L line, which is again interrupt level 2.
Otherwise you _could_ use interrupt level 7 (aka NMI) but doing so through the IPC also has it's considerable problems.
BTW, interrupts are not supposed to come before the relevant data structures are initialized, sometimes this has to be catered for by hardware, especially when NMI is used.

[Nasta]

So technically speaking the 68008 is using aysnchronous access - requiring a device to respond on DTACK pin when it's ready to send or receive data, the DS pin from the CPU initiates the request. If your external hardware raises DSMCL when the address matches one you are providing an override for - the 8301 will never assert dtack - so your device must respond instead and provide it. As there is no BERR circuit on the QL to timeout after some number of clock periods - it will wait indefinitely if you don't assert DTACK.

Just to be clear- assert means to make active, in the case of DS and DTACK - these are both active low.

When the QL motherboard devices are disabled by pulling DSMCL high, it also disables DTACK generation, so in fact all functions have to be handled by external hardware.

[Nasta]

Not sure what you mean with "take control back". The CPU is always in control. It can be made to wait until the video circuitry is done generating a frame (that's done by the 8301 by simply not generating a DS

That would be DTACKL, not DS. I know the author of the post knows it, just correcting for posterity