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.

Hi All

Does anyone know how the IPC detects that the Read register ($18020) has been read in order to put the next data bit on D7?
Also, is there a PALASM source file for IC38 HAL16L8 anywhere even if it's reverse engineered?

Cheers

Will

This is the routine for sending bits in the original IPC:

; send 4bit data to ZX8302, ent A.msb=data
0762: BF 04 MOV R7,#04 Load loop counter for 4 bits to send
0764: AE MOV R6,A
0765: 0A IN A,P2
0766: 53 80 ANL A,#80 loop until comdata=H These 2 lines loop around until the comdata line goes high
0768: 96 65 JNZ #0765
076A: FE MOV A,R6
076B: 90 MOVX @R0,A
076C: F2 72 JB7 #0772 If bit 7 is high - jump to send 1 bit
076E: 9A 7F ANL P2,#7F This is where we send a 0 bit (comdata)
0770: E4 74 JMP $774
0772: 8A 80 ORL P2,#80 This is where we send a 1 bit (comdata)
0774: 90 MOVX @R0,A
0775: E7 RL A Shift along
0776: AE MOV R6,A
0777: 8A 80 ORL P2,#80 Ending with a 1
0779: EF 65 DJNZ R7,#0765 And loop back until 4 bits done - for 8 bits this routine is simply called twice
077B: 93 RETR

With regard to the HAL code - https://dilwyn.theqlforum.com/docs/hardware/HALic38.txt

Pah! I've been desperately trying to get this working before I go off to Spain for the summer, but it looks like I'm going to have to come back to it in September... thanks to everyone who has helped me with top QL hardware information. This has been a lot harder than I first imagined, the IPC/ZX8302 communication stuff is so weird, but I will get there if it's the last thing I do (unless someone else gets there first). Have a great summer all.

Will James wrote: Mon Jul 21, 2025 11:37 pm Pah! I've been desperately trying to get this working before I go off to Spain for the summer, but it looks like I'm going to have to come back to it in September... thanks to everyone who has helped me with top QL hardware information. This has been a lot harder than I first imagined, the IPC/ZX8302 communication stuff is so weird, but I will get there if it's the last thing I do (unless someone else gets there first). Have a great summer all.

I bet during your trip you'll think of it. That's how it usually works for me :-/

Hi,

I have created a folder with a video of what QLPiStorm is doing during boot and the included the Logic Analyser trace file
in case any brainy bods out there fancy taking a look. It's all explained in the readme.txt file.
There are a few photos and the current Verilog and C files.

It's here; https://drive.google.com/drive/folders/ ... sp=sharing

Have a great summer all.