Q68 support thread

[XorA]

I have VROOM on microdrive, but I will need to make a MDV image, convert to MDI can run on the Q68 from a FAT partition.

Maybe you could try VROOM on the Q68, or I will get to it later on.

I'm nearly sure, that I have had Vroom (I have had buyed this game!) running from Floppy. Just searched my old QL disks, but unfortunately I currently cannot find my Games disk (I had nearly all games on one disk). Must look through my old (carton) QL boxes, when I find time. Fortunately I have a working USB-floppy drive, which works in QPC.

It is available on floppy from RWAP!

[ql_freak]

And also you can run it off any device if you use a hex editor to change mdv1_ to the device of your choice in the exe file!

Yup, I think this is, what I have had done cause I'm nearly sure, that I started Vroom from floppy. When it runs on Q68, this means it is really highly compatible to the BBQL. As far as I can remember, I couldn't run it anymore with Minerva on my Goldcard QL (which I haven't used for about 20 years).

[XorA]

And also you can run it off any device if you use a hex editor to change mdv1_ to the device of your choice in the exe file!

Yup, I think this is, what I have had done cause I'm nearly sure, that I started Vroom from floppy. When it runs on Q68, this means it is really highly compatible to the BBQL. As far as I can remember, I couldn't run it anymore with Minerva on my Goldcard QL (which I haven't used for about 20 years).

For some reason it seems to fail somewhere between 1M and 2M of memory on a BBQL (testing on sQLux and qlay2). So that might be why it fails with GC!

[ql_freak]

(and I'm not even talking about the Pointer Interface which is included in SMSQ_E but has to be loaded separately with Minerva, though I believe it supports higher resolutions too but only in 4 or 8 colour mode)

This is correct, I have had it running on my PC with 1024x768, but only in 4 colors. Unfortunately I cannot remember how to start uQLx on my former Windows PC with WSL2 :-( But I know it's installed and working.

[ql_freak]

For some reason it seems to fail somewhere between 1M and 2M of memory on a BBQL (testing on sQLux and qlay2). So that might be why it fails with GC!

Ah! Good point!

[ql_freak]

SD Card Format from SD Association not really suitable for C68

I have tried the newest version from https://www.sdcard.org/downloads/format ... s-download and the one delivered on the SD card (on the FAT partition) of Q68. Both always format the whole SD card, even if I have partitioned the card before with Disk Management (from Computer Management) of Windows 10. As I have accidentally deleted one of the original SD cards, I created it newly. I did it successfully with Disk Management from Windows :-) I have partitioned the FAT32 (WIN1) partition with 3537 MBytes (can't remember the size for the FAT partition), formatted both partitions with Disk Management (default cluster size) and then restored the QL files from a ZIP-file created with 7-Zip from my second QC68 card (afaik when restoring from a ZIP-file even the modification dates of directories are restored).

[Derek_Stewart]

Hi Peter,

I am sorry that you are having problems with the Q68 SD Card partitioning.

The SDHC Card sent with the Q68 is a 4Gb Capacity, where I create 1 FAT32 partition 3.7Gb in size and 1 FAT16 partition, 1 200Mb

The FAT16 partition has a maximum size of 255Mb

I created the SD Card partitioning system on a Linux machine with GPARTED. The SD Card Association software is supplied for people who use Windows, this will be dependant on the Windows version and setup.

I assumed that most people will more QWA or QUBide files to store files, which is why the FAT32 partition is the majority of the capacity of the SD Card and 200Mb is more than enough for transfer of file to the Q68 fropm the FATA16 partition.

The supplied SD Card is an example of how to produce the disk system for the Q68, an alternative setup would be:

FAT32: 2Gb
FAT1: 255Mb
FAT2: 255Mb
FAT3: 255Mb
FAT4: 255Mb

Also maybe CARD 2 slot should be used for more FAT drives and have all the QWA files on CARD 1.

The QWA/QUB/FAT drives can be defined and changed at runtime or in the SMSQ/E config blocks.

This is all explained in the Q68 documentation located on the FAT1 drive of the supplied SD Card.

The Date Stamp issue in restoring the contents of a archive file is usual to restore the contents of the archive to the date of creation of archive. This can be changed in the options of the archiver.

[XorA]

FAT32: 2Gb
FAT1: 255Mb
FAT2: 255Mb
FAT3: 255Mb
FAT4: 255Mb

That would be invalid partiton layout, only 4 partitions allowed in a dos partition label. Any more than that need to be partitions inside partitions!

[Derek_Stewart]

FAT32: 2Gb
FAT1: 255Mb
FAT2: 255Mb
FAT3: 255Mb
FAT4: 255Mb

That would be invalid partiton layout, only 4 partitions allowed in a dos partition label. Any more than that need to be partitions inside partitions!

Sorry, should be - SD Card1:
FAT32: 2Gb
FAT1: 255Mb
FAT2: 255Mb
FAT3: 255Mb

FAT4 could be created on the SD Card, and available for loading with the FAT_DRIVE command, by unloading one of the other FAT images

[ql_freak]

Hi Derek,

I am sorry that you are having problems with the Q68 SD Card partitioning.

There are no problems with the SD cards, they are working perfectly. I just accidentially deleted (formatted) one of them and have to recreate it.

I created the SD Card partitioning system on a Linux machine with GPARTED. The SD Card Association software is supplied for people who use Windows, this will be dependant on the Windows version and setup.

The problem is the SD Card Association software, which seems not to be capable to format (partition) a card with a large VFAT32 partition and a small FAT partition. But the Disk Management of Windows 10 can do it:

Start->Windows Administrative Tools->Computer Management than under Storage in left column Disk Management. When formatting I have used Default for the Allocation unit size.

The Date Stamp issue in restoring the contents of a archive file is usual to restore the contents of the archive to the date of creation of archive. This can be changed in the options of the archiver.

The problem is, that when you create a directory (includes copying a directory tree) on windows, the modification timestamp of directories will be set to the current date/time (files get the original modification timestamp when copying directory trees). If you first zip the directory tree and restore all from the zip file (I have had used 7-Zip), the modification dates even of directories are restored. I did this for the FAT partition (of the original SD card) and all directories have the same modification timestamp as on the original C68 SD card :-).

Regards

Peter