Q68 support thread

[Derek_Stewart]

Hi,

There was an update to the Q68 FPGA to allow handling of the PS/2 to USB converter. You need an update.

If you want to send the Q68 back to me, I will update the FPGA codre

[Pr0f]

Hi,

There was an update to the Q68 FPGA to allow handling of the PS/2 to USB converter. You need an update.

If you want to send the Q68 back to me, I will update the FPGA codre

I think I will be ok - as the Belkin is actually emulating an extended mouse to the Q68, so it doesn't have any issues. It means I have my choice of keyboards and mice - USB - wired or wireless or PS/2 - as long as both the console devices are the same interface - either both USB or both PS/2

[Peter]

Maybe I should forget about the copyright issue with the Black Box PS/2 to USB adapter and try and reverse engineer the adapter.

Quite a large effort and even if you succeed hardware-wise, I don't think you'd be able to read the firmware.
And for what? PS/2 (or combo) mice and keyboards are still very easy to get.
There are few users who need USB for an important reason. Let them buy the adaptor if they dislike PS/2 so much.

Frankly spoken, I think it is far more important to have the Q68 available again.

[Peter]

Follow on question - the message about the mouse shoots off the screen so quick when the Q68 boots - I can't see what mouse it detected - is there a way to ascertain which mouse type it detected, is this stored anywhere in a sysvar? Any quick way to test the mouse on Q68 for scroll wheel support?

Bit 4 of Mouse Status Register at $1C168:
0 -> Standard mouse
1 -> Intellimouse/Wheelmouse

[Derek_Stewart]

Quite a large effort and even if you succeed hardware-wise, I don't think you'd be able to read the firmware.
And for what? PS/2 (or combo) mice and keyboards are still very easy to get.
There are few users who need USB for an important reason. Let them buy the adaptor if they dislike PS/2 so much.

Yes you correct, this was the reason for not selling the Black Box PS/2-USB adapter, I find PS/2 is good enough.

Frankly spoken, I think it is far more important to have the Q68 available again.

I have 30 Q68 PCBs, 10 built and tested running SMSQ/E v3.38.

The new Q68 case, which is shown in another thread, which has a split case design, nearly the same size as the previous case. The End Panels are entirely Andodised, only difference is there is no white lettering on the rear panel.

The I2C connector is located on the rear panel, accessed by a 4 pin JST 2mm connector, a JST to 9 pin D connector wil be supplied. This is to make compatibilty to the Minerva MK2 I2C devices.

The QL NET connection was goig to be located on the side of the case, but I do fancy drilling 60 x 6mm holes, so the comprimise is to have a JST socket on the rear panel, with an extension cable with twin QL Network Connectors.

The Q68 should be shipping in 5-6 weeks for cased orders, orders of PCB only, can be shipped next week.

[Pr0f]

A big thank you to Peter and Derek who were as always very helpful in sorting my problem. It's nice to have the setup running, I will be able to cable up all my various machines now, and not have a big clutter of keyboards and mice.

[ql_freak]

According to this post SDHC cards up to 32 GBytes are supported. My 32 GByte card has 30435 MBytes (according to disk management of Windows 10). I want to create the first primary partition with 30435-255 = 30180 MBytes (which will be formatted with FAT32) and the rest as second partition with 255 MByte as FAT16 for the FAT device.

Will this be OK or are there better options to partition the card? (I'm an absolutely beginner with Q68 and do not know modern things like e.g. Prowess).

I also want to install Minerva on another card. Can I use the high resolution QL modes with Minerva (DISP_MODE 4; At least this resolution works on UQLX with Minerva)?

[Derek_Stewart]

Hi Peter,

The Q68 SDHC Card system, uses a 4 partition scheme, where the first partition must be a FAT32 partition, the other 3 partition can be FAT16 of a maximum size of 255Mb.

The FAT32 partition for storing QWA files, which are sometimes called QXL.WIN files and Qubide files, the FAT16 partition(s) can hold any type of data file.

The filenames are restricted to 8+3 filenames (8 title characters, 3 extension).

The SDHC card supplied with the Q68 is 4Gb capacity, which has 1 FAT32 Partition, and 1 FAT16 partition.

The FAT32 partition holds QWA files:

QLWA.WIN - Q68 applications
QLE.WIN - latest QL/E file
BP.WIN - Black Phoenix
Q68_SMSQ.WIN - SMSQ/E operating system

The FAT16 partition holds all the Q68 and App.ication documentation.

The SDHC Card is a demonstration of how to use the Q68 and how to write boot files.

Prowess is included on the WIN1 drive.

Minerva can run on the Q68, but only in 512x256 mode, the DISP_MODE commands are only used in SMSQ/E.

SMSQ/E is the recommended operating system, Minerva is not as well developed.

[ql_freak]

Hi Derek,

The Q68 SDHC Card system, uses a 4 partition scheme, where the first partition must be a FAT32 partition, the other 3 partition can be FAT16 of a maximum size of 255Mb.

Than my partitioning seems to be OK. Only the first partition must be FAT32. As the second partition (FAT16) can only have a size up to 255 MBytes, the FAT32 will use the rest (i.e. 30180 MBytes in my case).

The FAT32 partition for storing QWA files, which are sometimes called QXL.WIN files and Qubide files, the FAT16 partition(s) can hold any type of data file.

If I'm using a .SYS file (e.g. a ROM Image) and one QWA file for the applications and data, is it correct that the QWA file must have the size to fill the rest of the FAT32 partition (assuming I only want WIN1_ and no WIN2_, WIN3_, ...)?

Or is there a size limit for a QWA file?
 

Prowess is included on the WIN1 drive.

I have noticed that on the delivered SD card. I assume Prowess is responsible, that the move Icon can now be dragged and the window is moved showing it's contents?

Minerva can run on the Q68, but only in 512x256 mode, the DISP_MODE commands are only used in SMSQ/E.

I will have a look on that in the future (unfortunately I currently do not have time for it). I think it should be possible to use at least the 4 color modes in higher resolutions than 512x256, as it works perfectly with UQLX. Minerva (IMHO) was the first ROM supporting screens at another address than the original QL screen and and (IMHO) was the first ROM which supports SD.LINEL documented in Technical Guide (18.9 Screen Driver Data Block Definition). Therefore it was the first ROM (long before SMS2/SMSQ) which doesn't suspend jobs in (partly) overlayed windows, when they want to write to that window (with additional software).

SMSQ/E is the recommended operating system, Minerva is not as well developed.

I know, but one reason to buy a Q68 is the possibility to use other ROMs, which is not possible with QPC2. Albeit I have Minerva (and other systems) on UQLX on Windows with WSL2 it has serious problems, e.g. does not support IO.OPEN with D3.L = 3 (overwrite) :-( (In fact not so problematic, as an original QL with microdrives and without TK2 also doesn't support overwrite and so many programs like MasterSpy delete the original file before writing it back.)

Regards

Peter

[XorA]

I will have a look on that in the future (unfortunately I currently do not have time for it). I think it should be possible to use at least the 4 color modes in higher resolutions than 512x256, as it works perfectly with UQLX.

uqlx installs a virtual driver in Xscreen.c/init_xscreen() function to handle the bigger than QL screen modes!