Minerva4Q68

[janbredenbeek]

I have loaded Q68 v1.02 FPGA code onto a Batch 4 Q68, and copied a Q68_ROM.SYS, with integrated Toolkit 2, to a freshly formatted SD Card with a FAT32 partition.
The Q68 boots up to Minerva and links Toolkit 2, faster than my monitor startup.
The system seems to work in 512x256, 1024x768, also loads the Extended Environment. All seems to work.
One question regarding the mouse, vent though there is no mouse driver, would moving the mouse cause any interrupts on the operating system?

It does when the mouse interrupt is not disabled, but I have added code to Minerva's ss_init section that should disable it before any interrupts are enabled.

I just need to test loading Minerva from SMSQ/E, and assemble the ROM on the Q68. Which be straight forward, using existing programming from the Minerva4Q68 repository distribution.

After the upgrade from v1.00 to v1.05 I got random crashes when loading Minerva from the FAT partition, which led to the discovery of the bug in the FAT driver. It seems to be connected to the 40MHz SDHC clock option (which I had disabled in the SMSQ/E configuration). SMSQ/E versions before 3.37 appear to be safe.
I think this is a bug in the FAT driver and not related to the freezes Dilwyn experienced with v1.05 (I got the same problem with 1.02, which also supports 40MHz SDHC clock).

What happens when you upgrade the firmware again to v1.05, do the freezes re-appear?

[Derek_Stewart]

Hi Jan

I will try restoring the v1.05 on a spare Q68 I have.

The point about the mouse interrupt, was just a thought on other hardware that looked to have same problem.

[janbredenbeek]

After the upgrade from v1.00 to v1.05 I got random crashes when loading Minerva from the FAT partition, which led to the discovery of the bug in the FAT driver. It seems to be connected to the 40MHz SDHC clock option (which I had disabled in the SMSQ/E configuration). SMSQ/E versions before 3.37 appear to be safe.
I think this is a bug in the FAT driver and not related to the freezes Dilwyn experienced with v1.05 (I got the same problem with 1.02, which also supports 40MHz SDHC clock).

I've mailed Wolfgang about this; there is a workaround for this bug: POKE $17d20,0 stops the corruption by disabling 16-bit SDHC access. This location is set to 255 on newer firmware versions supporting 16-bit SDHC access, which is on by default and not affected by the 40MHz setting.