The Sinclair QL Forum

Will James wrote: Sat Jul 12, 2025 8:43 pm I know writing to the screen register is working as I can change between mode 4 and mode 8 and turn the screen off. This means my read and write mapping is ok.

But it does not necessarily mean all timings (and delays between accesses) are okay for all registers involved.
I think your problem at the moment is probably not interrupt related.
As a first step, I would create a little ROM at $C000 with the correct header, which pokes something to the screen. Just to see if execution arrives there. If it does, you could poll the keyboard yourself with MT.IPCOM (TRAP#1 with D0=$11) and see if you receive something. MT.IPCOM already works at this early stage, and does not need interrupts.

Will James wrote: Sat Jul 12, 2025 9:36 pm Funny you should mention Minerva, as I get a perfect boot up to the F1 F2 screen with a JS ROM, but Minerva goes a bit wonky, I think it has a very different RAM test procedure...

Minerva is also more demanding in terms of correctness of the CPU emulation.
I would not take for granted that Musashi has no bugs that are triggered by Minerva.

The fact the 8049 can control both interrupt lines seems to be a hangover from the development days - interrupt level 7 (NMI) is basically set by pressing CTRL ALT 7 on the QL keyboard - this triggers code in the 8049 for it to reset itself and at the same time trigger the NMI on the QL - the usual affect of this is disaster - a hung or crashed QL - because the behavior from each side has not been written to take account of the other side.

HERMES replacements for the 8049 made the key sequence 4 characters long so less likely to happen, plus I believe it no longer generates the Interrupts if you have bent out the legs to use them for general purpose I/O.

SuperHermes does have an interrupt, but it's a flying lead or built in to Aurora board that creates an external interrupt input to the ZX8302 chip - this was to allow for support of the PS/2 and faster Serial 3 built in to the SuperHermes,

From the QL side - you can think of the ZX8302 as the interrupt controller - since it handles the various interrupt sources and can mask them off - the Vsynch interrupt, the external interrupt, the microdrive, serial output, the QL network, the IPC communications - it's all through this chip. If anything is off with the interrupts - this is the first place to look

Peter wrote:

Will James wrote: Sat Jul 12, 2025 9:36 pm Funny you should mention Minerva, as I get a perfect boot up to the F1 F2 screen with a JS ROM, but Minerva goes a bit wonky, I think it has a very different RAM test procedure...

Minerva is also more demanding in terms of correctness of the CPU emulation.
I would not take for granted that Musashi has no bugs that are triggered by Minerva.

My emulator is based on Mushashi and boots Minerva fine.

XorA wrote: Sun Jul 13, 2025 10:35 am My emulator is based on Mushashi and boots Minerva fine.

That's good. Which of your emulators use Musashi, as you are maintaining several?

I very definitely have a problem with interrupts. For some reason !IPL1 is constantly low, even before I run the emulator.


The logic analyser is showing IPL0/2 always high, which is correct, but IPL1 is constantly low.
IPL_ZERO should be high most of the time except when an interrupt request is happening on IPL0/2 and IPL1.

Because !IPL1 is always low IPL_ZERO is constantly low too. The yellow trace is TXN ie. a Read or Write transaction in progress.
The first 2 yellow blips are me trying to mask all interrupts and clear any pending interrupts before the main
execution loop of the emulator. The solid yellow is JS booting up. For a single moment IPL1 goes High ie. no interrupts
and IPL_ZERO also follows but IPL1 immediately goes low again.

I'm not convinced I am properly masking the QL interrupts or clearing pending interrupts as I am not 100% sure
what the addresses are or what they need to be set too. There is so much conflicting information and GTP has
got my head in a spin over this inventing new addresses at the drop of a hat.

I'm thinking this could be cause by the delay before booting up. On a real 68000 it would begin immediately and
would set stuff up. Maybe loads of interrupts are happening before the emulator starts running...

I'm also a bit confused by the 3 blank sections of TXN, but I guess this could just be a artefact of the Interrupts
being in such a mess.

Will James wrote: Sun Jul 13, 2025 4:23 pm
The first 2 yellow blips are me trying to mask all interrupts and clear any pending interrupts before the main
execution loop of the emulator. The solid yellow is JS booting up. For a single moment IPL1 goes High ie. no interrupts
and IPL_ZERO also follows but IPL1 immediately goes low again.

Exactly how are you trying to mask and clear the interrupts?

like this...

ps_write_8(0x18021, 0xFF); // Mask off all interrupt sources
ps_read_8(0x18021); // clear any pending interrupts by reading interrupt register?

I'm pretty sure it isn't right.

Will James wrote: Sun Jul 13, 2025 5:25 pm like this...

ps_write_8(0x18021, 0xFF); // Mask off all interrupt sources
ps_read_8(0x18021); // clear any pending interrupts by reading interrupt register?

I'm pretty sure it isn't right.

To clear all interrupts, you need to write the lower 4 bits with 1 (for gap=0, interface=1, transmit=2, frame=3, external=4). Reading only will not clear anything.

To mask all interrupts, you need to write a zero to the upper three bits (for gap=5, interface = 6, transmit = 7). The frame interrupt (50Hz) apparently can't be masked, but is, I think, edge-triggered.

Thus
ps_write _8(0x18021,$1f)
should do what you want. Note if you don't clear interrupt bits, they will keep on triggering constantly.

Thank you, I try it right away.