The Sinclair QL Forum

The plot thickens, I see that that IC24 IPC sends it interrupt to IC38 HAL16L8 mystery chip... which is also connected to !VPA so it could be using the 68000 slow peripheral timing for IO registers. I hadn't considered this 'till just now... with all my ROM and RAM tests I never witnessed !VPA in action... this looks like a whole new can of worms for me to investigate this weekend.
A small change to the FSM for bus access seems to have got Minerva 1.98 to boot and a slight delay Kludge in the read and write access routines when accessing $18020 & $18021 has got the keyboard doing something at last, just not quite what it is supposed to be doing; - it's reading garbage even when I'm not pressing any keys

I think the problem I had with Minerva not getting through its RAM test may have been due to fast instructions to the hardware starting a new transaction before the !DTACK had gone high and it
might have pung through the next access thinking !DTACK had been asserted. I added a term in the state engine to stop the state engine returning to state 0 before !DTACK had de-asserted. This is not in the Motorola Read-Write cycle Flowchart but I found this hidden away in The Motorola M68000 Family Programmer’s Reference Manual;

"The processor samples DTACK on every cycle start to determine if the bus is ready."

And:

"DTACK must be de-asserted (high) before the processor begins a new bus cycle."

So I figure it will be ok. It has got Minerva booting anyway.

Time to go and watch a bit of Doctor Who - I'm up to "The Hand of Fear" with Tom Baker. It's so good. Back on to slow VPA peripheral cycles in the morning.

Morning Mark!

More great progress - well done!

Ok, so that apparent VPA bus cycle is not really a bus cycle, but a workaround for not having a dedicated 'Auto Vector' Interrupt Acknowledge signal.

All interrupts on the QL are thus hardwired to generate the Auto Vector approach to interrupts. In effect, it's like a DTACK, effectively ending the interrupt acknowledge cycle in place of DTACK for normal memory accesses.

It is important that it arrives BEFORE any DTACK in that interrupt ack cycle, otherwise the m68k assumes a vector is present on the DBus and uses that to slink-off somewhere in memory to find the interrupt service routine...

Make sense?

@Martyn - Ah, so your saying the QL doesn't use the M6800 Peripheral Interface for register but uses VPA and generates VMA for Interrupt cycles. I will have to check this is not confusing my state machine logic...

Cheers

Will

Precisely, Will

It's not so much VPA generating VMA, but VPA signal being used for more than one purpose. You need to look at the state of the 3 Function code lines FC0-FC2, although the QL pulls a trick there and only uses 2 of these (FC1 and FC0) to generate the VPA signal using a NAND gate.

So whenever there is an interrupt to process - (from the IPL lines) - the processor responds with an Interrupt Acknowledge cycle, by placing the relevant status on the FC lines (FC0-FC2 all 1's) , the interrupt level it's servicing on the Address lines - A1-A3, and then checking to see if either VPA or DTACK are asserted to determine whether to use autovector or a user supplied vector.