The Sinclair QL Forum

Wonder if all this could be related to the problems I had with Jan's Minerva for Q68, where I never did manage to get it up and running on my 1.05 Q68.

Hi,

All the Q68 computers bought from the last batch, with a ID number starting Q68-04-xx have the new FPGA code programmed in.

The FPGA version an be checked by powering the Q68 without a SD Card in slot 1.

If anyone wants their Q68 updated, I will do so free of charge, just pay for the return postage, contact me by PM to arrange this.

Understood, thank you Derek.

Hi Peter,

Peter wrote: Tue Jan 16, 2024 9:50 am They surfaced when Martyn tests his QLNET driver. Unfortunately they are so rare that I can not even reproduce them myself.
I can't say if there is a connection to your problem or not - I simply have no time to dig into https://github.com/janbredenbeek/Minerva4Q68/issues/1 at this time.
Maybe Derek can find out by the delivery date whether your board is affected?

In v1.6, I've added a 'sf q68_reset' instruction which should reset the Q68 hardware. This seems to cause an immediate lock-up on Mark's Q68 (on my Q68 it seems to do nothing, even when POKEd from BASIC). He could fix it by adding a 2-second delay afterwards, however his Q68 locked up later on (after pressing F1/F2).

I've searched SMSQ/E's source code but could not find any occurrence of such an instruction, so I'm considering to remove it again from Minerva.

Is there any difference between a 'clr.b' and 'sf' instruction in the Q68? The 68000 documentation states that on the 68000/8 both instructions always read the memory location before writing.

Hi Jan,

I have read through the issues on Github, I am not sure if the problem is the Q68 FPGA code or if there is a problem with the Minerva operating system.

Till I was notified that there wad a problem with Q68 FPGA code greater than v1.2, I had no real problems, but then again I only use SMSQ/E on the Q68.

Since I have more time to use the Q68 now, I will have a look at the Minerva OS, I want use the Q68 to assemble the code rather than cross assembled.

janbredenbeek wrote: Tue Jan 16, 2024 2:48 pm In v1.6, I've added a 'sf q68_reset' instruction which should reset the Q68 hardware. This seems to cause an immediate lock-up on Mark's Q68 (on my Q68 it seems to do nothing, even when POKEd from BASIC). He could fix it by adding a 2-second delay afterwards, however his Q68 locked up later on (after pressing F1/F2).

OK, Peter notified me that I got this reset thing wrong... The Q68 can be reset by writing a magic word $BAD0 into hardware register $1C024. POKEing this from BASIC works on SMSQ/E but not from Minerva, because Minerva pokes individual bytes to allow (long) words to be written into odd locations.

Resetting the Q68 in this way reboots the operating system but leaves the RAM intact, so it should only be used by the Minerva boot loader (LRESPRed from SMSQ/E) or CTRL-ALT-SHIFT-TAB key combination. It doesn't disable the Ethernet interrupt, but that will be catered for by the hardware initialisation code in Minerva itself.

I will release a new version of Minerva4Q68 this week, but as there have been reports about firmware version 1.05 freezing before v1.6, this will probably not fix these issues. It's work in progress...

janbredenbeek wrote: Tue Jan 16, 2024 10:26 pm Resetting the Q68 in this way reboots the operating system but leaves the RAM intact, so it should only be used by the Minerva boot loader (LRESPRed from SMSQ/E) or CTRL-ALT-SHIFT-TAB key combination.

The hardware reset by magic word access to $1C024 resets both the CPU and all peripherals except the CP2200.
It is does not require a bootloader, unless the operation system code in emulated ROM had been corrupted.
It is legitimate - and actually working - to reset a Q68 with Minerva by a word-write of $BAD0 to $1C024 without any bootloader.

janbredenbeek wrote: Tue Jan 16, 2024 10:26 pm It doesn't disable the Ethernet interrupt, but that will be catered for by the hardware initialisation code in Minerva itself.

No, this reset also disables the ethernet interrupt.
It just does not reset the CP2200 chip, simply because the Q68 FPGA has no external reset output.
That leaves it up the ethernet driver to initialize the CP2200 properly, which it should do anyway.

To me, the extra bootloader mainly seems a workaround for not having native access to FAT32 when developing/changing Minerva itself. If there is interest, I can write a little tool that allows to update Q68_ROM.SYS on FAT32 from the QL side instead.

Peter wrote: Wed Jan 17, 2024 9:21 am The hardware reset by magic word access to $1C024 resets both the CPU and all peripherals except the CP2200.

I am curious whether this does preserve the 68000 registers or not. If not, it won't be possible to do a full hardware reset with CALL 390 because it expects a magic word in register A5 and boot options in D1. At present, it does a RESET instruction (which sends a reset signal to the hardware but doesn't reset the 68000 itself) followed by a jump to the initial PC vector location. Does the CPU in the Q68 do something similar on a RESET instruction?

To me, the extra bootloader mainly seems a workaround for not having native access to FAT32 when developing/changing Minerva itself. If there is interest, I can write a little tool that allows to update Q68_ROM.SYS on FAT32 from the QL side instead.

Well, for me the boot loader is just convenient as it eliminates the need for a separate SD card with a FAT32 partition, and running the risk of it getting fragmented with each new build (even Windows command line's COPY is not safe). I use a second FAT16 partition for the builds and just boot it from SMSQ/E.
(If you want to boot Minerva from the same card you boot SMSQ/E from, you can use CARD_RENF to rename the Q68_ROM.SYS file but this only works from SMSQ/E as the Minerva SD card driver doesn't support this command, at present. So the ability to update Q68_ROM.SYS from the Q68 would made that easier).

janbredenbeek wrote: Wed Jan 17, 2024 1:59 pm

Peter wrote: Wed Jan 17, 2024 9:21 am The hardware reset by magic word access to $1C024 resets both the CPU and all peripherals except the CP2200.

I am curious whether this does preserve the 68000 registers or not. If not, it won't be possible to do a full hardware reset with CALL 390 because it expects a magic word in register A5 and boot options in D1. At present, it does a RESET instruction (which sends a reset signal to the hardware but doesn't reset the 68000 itself) followed by a jump to the initial PC vector location. Does the CPU in the Q68 do something similar on a RESET instruction?

Okay, forget that question... I've tested it by replacing the RESET at $190 with MOVE.W $BAD0,$1C024 and CALL 390 works, so the registers appear to be preserved.

Now I need to find out why (re)booting Minerva with SHIFT-F1 sometimes gets you 28MB of RAM instead of 128K, which it cannot handle and crashes sooner or later...

janbredenbeek wrote: Fri Jan 19, 2024 1:56 pm

janbredenbeek wrote: Wed Jan 17, 2024 1:59 pm

Peter wrote: Wed Jan 17, 2024 9:21 am The hardware reset by magic word access to $1C024 resets both the CPU and all peripherals except the CP2200.

I am curious whether this does preserve the 68000 registers or not. If not, it won't be possible to do a full hardware reset with CALL 390 because it expects a magic word in register A5 and boot options in D1. At present, it does a RESET instruction (which sends a reset signal to the hardware but doesn't reset the 68000 itself) followed by a jump to the initial PC vector location. Does the CPU in the Q68 do something similar on a RESET instruction?

Okay, forget that question... I've tested it by replacing the RESET at $190 with MOVE.W $BAD0,$1C024 and CALL 390 works, so the registers appear to be preserved.

Now I need to find out why (re)booting Minerva with SHIFT-F1 sometimes gets you 28MB of RAM instead of 128K, which it cannot handle and crashes sooner or later...

Random numbers in d1 register?