The Q68 design has not changed. Only the operating system has changed.
My badly photograph shows Minerva booting up correctly. I was also able to read the QUBide file from the QL-SD v1
I was referring to Dilwyn's photograph which only showed 'Q68 extension ROM' without version and no message from the SD-card driver, which suggest that something keeps hanging.
I remember that later versions of the Q68 could have faster SD access due to a change in the microcode, or am I mistaken?
The Q68 design has not changed. Only the operating system has changed.
My badly photograph shows Minerva booting up correctly. I was also able to read the QUBide file from the QL-SD v1
I was referring to Dilwyn's photograph which only showed 'Q68 extension ROM' without version and no message from the SD-card driver, which suggest that something keeps hanging.
I remember that later versions of the Q68 could have faster SD access due to a change in the microcode, or am I mistaken?
Hi Jan,
There was a few updates since 2017, which now the Q68 FPGA code is at v1.05, which I do not know the exact details of the changes.
The SMSQ/E sources do document the faster card operation to a degree (e.g. dv3_q68_win_card_xxxx_asm, dv3_q68_win_init_asm, extras_new_Q68_SDcard_speedup_txt). Explains there is a BASIC extension not in the manual which can tell if your firmware can support SD card speedup to 40MHz. On my Q68 at least PRINT CARD_SPEEDUP returns 0, explaining that the firmware in mine can't support it. Does this mean the Q68 doesn't even try to operate at the faster speed? I know mine fails to start in SMSQ/E if the speedup is configured on.
The Q68 design has not changed. Only the operating system has changed.
My badly photograph shows Minerva booting up correctly. I was also able to read the QUBide file from the QL-SD v1
I was referring to Dilwyn's photograph which only showed 'Q68 extension ROM' without version and no message from the SD-card driver, which suggest that something keeps hanging.
I remember that later versions of the Q68 could have faster SD access due to a change in the microcode, or am I mistaken?
The Minerva4Q68 startup stops at random points before it gets to the F1/F2 keypress. Sometimes, only one or two letters of the message appears.
dilwyn wrote: ↑Sun Jun 11, 2023 8:12 pm
The Minerva4Q68 startup stops at random points before it gets to the F1/F2 keypress. Sometimes, only one or two letters of the message appears.
This suggests that the keyboard driver interrupt keeps hanging in a loop.
Can you try the following:
(if you have the LRESPR'able version, add 32 to 50656 and to 80*1024. As a check, the original word at this location should read 26264 for extension ROM v1.2).
This stops the interrupt routine from looping if the keyboard status bit keeps signalling 'new keystroke'. The latter will probably indicate a hardware issue between the Q68 and the keyboard so it may not fix the problem but will allow the startup message to be displayed.
Do you have the keyboard connected via a splitter combined with a mouse?
Patching neither the Q68_ROM.SYS nor the _rext version fixed the issue, but there is now a consistency in how far it gets. Every time now it stops after displaying the Minerva logo. If left for a few minutes, it disintegrates into random patterned screens.
Keyboard and mouse attached via Derek's PS/2 splitter cable.
Have tried with the keyboard plugged directly into the Q68 (no splitter cable), just the keyboard plugged into the splitter (no mouse), and reversed keyboard and mouse (in which case the startup stops just after the ROM check and CLOCK messages before it gets to the booting from ser message).
dilwyn wrote: ↑Sun Jun 11, 2023 11:08 pm
Patching neither the Q68_ROM.SYS nor the _rext version fixed the issue, but there is now a consistency in how far it gets. Every time now it stops after displaying the Minerva logo. If left for a few minutes, it disintegrates into random patterned screens.
Looking at the source code of SMSQ/E it appears that in v3.36 the keyboard handling code has been changed to use external interrupts in addition to polled interrupts. This might explain why Minerva hangs on your Q68; it only uses polled interrupts to read the keyboard and when an updated version of the hardware generates an external interrupt there won't be a handler to serve it, so it returns without clearing the interrupt and keeps looping forever.
Since Minerva appears to crash already before you've got a chance to press F1 or F2, there might also be some problems with hardware initialisation. The problem is that external ROM's initialisation code only gets called after Minerva has initialised the hardware and the machine is already in user mode and with interrupts enabled, so when the Q68 has already asserted the external interrupt the machine will lock up before the extension ROM even has a chance to respond to it. To fix this, the hardware initialisation code from SMSQ/E has to be backported to Minerva. Not a big deal I expect, but this requires a careful look at the SMSQ/E source code.
I'm sorry to have bothered you, but it appears that not all Q68's have been created equal...
