My current QL accelerator project

[XorA]

My emulator is based on Mushashi and boots Minerva fine.

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

Sqlay3/sq68ux

[Will James]

Well that hasn't had the effect I was hoping for, it hasn't sorted it but at least I know I am turning the interrupts off
correctly now and I can rule that out.

Strangely, when I read and print the contents of the interrupt register directly after setting it to 0x1F
and before the emulator begins, I read back apparently random numbers each time I run it; 0x40, 0xC0, 0x60, 0xC0 and 0x60

Peter was suggesting that there might be a problem with the timing of reading and writing to registers... although I don't
know what I could do about that as I have already had to rewrite the Verilog state engine to make it exactly 68008 timing in
order to get it reading RAM reliably, I don't think there is much more I could do there...

[tofro]

Well that hasn't had the effect I was hoping for, it hasn't sorted it but at least I know I am turning the interrupts off
correctly now and I can rule that out.

Strangely, when I read and print the contents of the interrupt register directly after setting it to 0x1F
and before the emulator begins, I read back apparently random numbers each time I run it; 0x40, 0xC0, 0x60, 0xC0 and 0x60

Peter was suggesting that there might be a problem with the timing of reading and writing to registers... although I don't
know what I could do about that as I have already had to rewrite the Verilog state engine to make it exactly 68008 timing in
order to get it reading RAM reliably, I don't think there is much more I could do there...

The values written to the interrupt control register can, in true Sinclair fashion, not be read back - reading returns something different, namely the

- interrupt status of the gap, IPC, transmit, frame, external interrupts in 0-4 (even if masked)
- clock state of the RTC in bit 5 (toggled with 32kHz)
- Microdrive motor state in bit 6 (0 if any drive is spinning)
- bit 7 is toggled with the baud rate clock

The toggling bits would clearly explain the "randomness" you see.

[Will James]

Ha! That'll be why they keep a copy in the system variables for setting and clearing the register
in the JS ROM.
It all makes sense now.

L2B88 move.b sv_pcint(a6),d7 ;interrupt register setting
ori.b #pc.intrg,d7 ;clear gap interrupt
andi.b #$DF,d7 ;disable gap interrupts
move.b d7,pc_intr-pc_mctrl(a3) ;write to hardware port, then
move.b sv_pcint(a6),pc_intr-pc_mctrl(a3) ;restore previous setting
movem.l (a7)+,d0-d6/a0-a4
bra L03B6 ;restore trap level registers and rte

[Peter]

Peter was suggesting that there might be a problem with the timing of reading and writing to registers... although I don't
know what I could do about that as I have already had to rewrite the Verilog state engine to make it exactly 68008 timing in
order to get it reading RAM reliably, I don't think there is much more I could do there...

E.g. I was thinking of timings like "AS/DS negated to data out invalid" during your emulated write cycles. The 68008 would provide a minimum of 40 ns here, and nobody knows exactly how much of that is required for the ULAs. Maybe you could check these and some other basic timings in comparision to the 68008 data sheet. Also it should be checked whether the bus accesses, even if they are perfect by themselves, arrive in faster succession than a real 68008.

Also, please have a look at the signal quality with a scope. I don't remember which logic drivers you're using, but as a rule of thumb: "The faster the rise/fall times, the worse."

[Will James]

Peter, some good points there, I have heard people mentioning on here that modern fast logic chips can cause problems with timing etc.
with the QL. I've had a few ideas about what's going on with the interrupts which I'm going to implement now that I understand how the
interrupt register works using sv_pcint from the system variables to store the current settings. If that doesn't improve things I have to start poking
around with a scope, which I'm not looking forward to. I also need to get some sort of 68000 assembler sorted on my PC so I can assemble
some test programs and see if keys are working, so far I've been doing all the testing from the Pi side in C.

[Will James]

Well Interrupts are now working how I expected.

Which means reading and writing to the Interrupt register
is definitely working. The problem was just my lack of understanding of QL and Musashi interrupt handling worked.
I also worked out what all the black space is in the TXN signal - as QL PiStorm only actually hardware writes to IO and screen
and only hardware Reads from IO, we only get r/w TXN high when the JS ROM is writing to the screen or reading or writing IO.

Now to work out -
1) Why I'm still not getting keypresses even thought register read and writes seem to be working, at least for interrupts and the screen.
2) Why Minerva actually crashes big time during it's RAM test while JS runs perfectly. Possibly reset or exception handling by Masushi...

PS - thanks for everybody's help yesterday.

[XorA]

If I remember my issues in emulation, Minerva actually requires that the memory wraps round at 24 bits. If it doesn't it goes wrong (TM).

[Will James]

Hi XorA

I'm doing this as the first line in my m68k_write_memory_8() and m68k_read_memory_8()

address = address & 0x03FFFF;

Do you think that would cause the problem?

Tried 0x0FFFFF instead but it still crashes...

[XorA]

Hi XorA

I'm doing this as the first line in my m68k_write_memory_8() and m68k_read_memory_8()

address = address & 0x03FFFF;

Do you think that would cause the problem?

Tried 0x0FFFFF instead but it still crashes...

No that should be suitable!