The Sinclair QL Forum

Posted: **Mon Jul 23, 2018 7:01 am**

In the past week I have been asked by a couple of people about which SD / CF solution they should get for a QL, so I thought a topic was the best way of tackling this.

My reply to the original enquiry was:

There are several options:
a) Use a HxC floppy disk emulator connected to a standard disk interface.
b) A vDriveQL (which connects via the QL microdrive port)
c) A QL-SD which plugs into one of the QL's internal ROM sockets and then the card reader can replace a microdrive unit.
d) A Qubide interface with CF to SD card adaptor
e) The Tetroid Trump Card + CF card clone (TDI)

Each have their various merits and pitfalls:
1) The HxC needs you to convert a floppy disk image to HFE format - the format used by the HxC, using a PC. Unfortunately, there is not much software available for the QL as floppy disk images. There is some new "FlashFloppy" firmware which may possibly allow the QL to overcome this by allowing direct access to the images (not confirmed).

Speed of the HxC is limited to floppy disk speed and the size of the storage is limited to a 720K disk image (or 1440K disk image if you have a Gold Card / Super Gold Card); although you can store multiple disk images on the same SD card and switch between them using a built in mini display and buttons on the unit (to select flp1_ and flp2_ ).

2) A vDriveQL emulates microdrive cartridges - it loads programs at the same speed as a microdrive cartridge, and you are limited to the size of a microdrive cartridge image (128K). You can however store several microdrive images on the SD card and attach up to 8 at a time to the QL and use them as mdv1_ and mdv2_ to mdv8_ if you want).

Again very little QL software is currently available as microdrive images. q-emulator can also write files to/from microdrive images (and floppy disk images).

3) The QL-SD, QubIDE and Tetroid TDI all use the same format. This is basically a large single hard disk container. There is some Windows software which allows you to extract downloaded QL software from the Sinclair QL Homepage (for example) and copy them into the container on the SD or CF card. The software has few instructions and I have not used it but others have. As a hard disk solution, this is much better for newer software which can be configured to run from various locations, but you will have problems with older software or software which uses the same filenames and cannot be easily re-configured to boot from a different location.

4) The latest driver for the QL-SD, does offer some more flexibility, in that you can use it to access a QXL.WIN format instead of the QubIDE hard disk format. QXL.WIN is the hard disk container used by several QL emulators and the QPC, so emulators can write directly into that container for getting files onto the QL.

Can anyone add to this - and maybe we can create this on the FAQ section>

Posted: **Mon Jul 23, 2018 8:11 am**

Possibly the new firmware - FlashFloppy - can bypass the HFE format and read images directly.
But I not tried this.
(Based on anticipation, that the physical format of QL disk is simillar to PC and only the logical format is different.)

Posted: **Mon Jul 23, 2018 8:23 am**

You might want to add that all image file solutions (vDrive, HxE) are size-limited to floppy (or mdv) sizes, although you can have more than one image on the media.

QL-SD and QubIDE derivatives support a hard-disk-like usage, while vDrive and HxE are a bit less convenient - You will often need to switch media on the fly (even if that is made quite simple by both solutions, it is still a bit inconvenient), but getting older (non-harddisk-aware) software to run might be simpler on the vDrive and HxE.

For QL-SD, it actually depends on the chosen driver which image format is used - Marcel's new driver uses the QXL.WIN format, which in my opinion is much more convenient to use with PC emulators than the QubIDE format used by the original driver and the CF card solutions.

Also, I seem to recall that QubIDE (QubATA) and original QL-SD formats were byte-reversed (so, not directly exchangeable without first converting)

Tobias

Posted: **Mon Jul 23, 2018 10:27 am**

So with a HxC you can directly access the FS on the SD card.

QL is one of the few systems without a driver for this functionality.

Posted: **Mon Jul 23, 2018 10:51 am**

I need to try out flashfloppy. I found the HxC very fussy and overly complicated.

Posted: **Mon Jul 23, 2018 11:33 am**

Thanks - I have expanded on the pros and cons a bit further above - more information is of course welcome - how about the Q68, Q40 and Q60 ?

Posted: **Mon Jul 23, 2018 12:26 pm**

RWAP wrote:Thanks - I have expanded on the pros and cons a bit further above - more information is of course welcome - how about the Q68, Q40 and Q60 ?

QXL cards (obviously, it's in the name, after all) support QXL.WIN containers.

Starting from 3.32, SMSQ/E for the Qx0 supports QXL.WIN containers on FAT32 as well, although I'm yet to try that myself. Using a IDE-to-SD adapter, you should be able to exchange cards directly between Qx0/Q68/QL-SD

Q68 SD handling is virtually identical to QL-SD with Marcel's new driver. QXL.WIN containers can be exchanged between all the systems that use them.

So, if you have multiple computer types running SMSQ/E (except the *GoldCard QL using QubIDE or derivates), QXL.WIN containers are very much recommended. They can be filled on a standard PC easily using QPC2, and are completely interchangeable between platforms that support them.

On the other hand, Wolfgang has built support for QubIDE partitions into Q68 and (I think) Qx0 SMSQ/E. So, actually, lots of things are possible.

Tobias

Posted: **Tue Sep 18, 2018 8:27 am**

Hi all,

I told you already when I joined this forum that I have 2 QLs (one that I bought end 1984 - when they first arrived in France - with a JM ROM, and the second - for spare, when Sinclair sold out the last ones - with a JS ROM.

To the first one I soon added a Sandy SuperQboard - later upgraded to support a mouse - and TK2 ROM, 512Kb RAM, floppy interface and parallel printer interface. The second one remained boxed.

Lately, for my second QL I bought a Tetroid extension adding to it TK2, 768Kb RAM, a floppy interface and a 8Gb CF card.

By the way, I have a question (for those who may know) : what is the use of the (undocumented) "JTAG" connector in the middle of the board

To have it work, it was actually not so simple - but I managed :

The Starter Kit provided by Alain Haoui was very helpful to me as a good example of how to initialize and partition the CF, but his setup program creates only two small partitions. I still do not know exactly how I will use this huge mass store, anyway here is my first (modifiable) personal partition plan for the whole space :

First partition named "GIRL" will be of 60Mb with 8 sect/block, dedicated in principle to WIN1 channel. Needing 60Kb of RAM space for the FAT.

Followed by eight partitions of same size and organization called "BOY2" to "BOY9", swappable in principle to WIN2 channel using an additional 60Kb of RAM space for their FAT.

In the remaining CF card space, I will create 20 bigger partitions, that may be used occasionally (for what ?), swappable to WIN3 channel.

Partitions 10 to 19 will be called "CAT0" to "CAT9" and will be of 240Mb with 32 sect/block, thus needing when WIN3 is used, 60Kb more of RAM for their FAT.

Partitions 20 to 29 will be called "DOG0" to "DOG9" and will be of 433Mb with 32 sect/block, thus using up to 110Kb of RAM for their FAT.

This provides for all 8Gb but 7 "tracks".

With this in mind, I rewrote completely the setup_bas program and did it more in the spirit of SuperBasic : defining procedures !

Commented listing :

Code: Select all

32500 dev$ = "flp1_"
32501 PROG_USE dev$
32502 DATA_USE WIN1_

32503 DEFine PROCedure NO_BOY
32504    WIN_DRIVE 2
32505 REMark I may add things here
32506 END DEFine
32507 DEFine PROCedure NO_ANIMAL
32508    WIN_DRIVE 3
32509 REMark I may add things here 
32510 END DEFine

Procedure UP_GIRL does for the moment exactly the same things as in the original setup (but it may change) :

32511 DEFine PROCedure UP_GIRL
32512    CLS #2
32513    PRINT "QubATA version " & WIN_VER$
32514    WIN_DISK #2,"SHOW"
32515    WIN_DISK #2,"DETAILS",1
32516    WIN_DRIVE -1
32517    WIN_DISK "INIT",1

32518    WIN_FORMAT 11,5
32519    WIN_DISK #2,"CREATE",1,1,60
32520    WIN_DRIVE 1,1,1
32521    FORMAT "WIN1_GIRL"
32522    DIR #2,WIN1_
32523    WIN_CTRL 1,14

32524       MAKE_DIR WIN1_SYS
32525       MAKE_DIR WIN1_BIN
32526       MAKE_DIR WIN1_ETC
32527       MAKE_DIR WIN1_PRG
32528       MAKE_DIR WIN1_PRG_C68
32529       MAKE_DIR WIN1_PRG_QMAC
32530       MAKE_DIR WIN1_PRG_PSION
32531       MAKE_DIR WIN1_TMP
32532       MAKE_DIR WIN1_WORK
32533       MAKE_DIR WIN1_GAMES
32535       MAKE_DIR WIN1_QubATA
32536       COPY dev$ & "setup_bas" TO WIN1_QubATA_setup_bas
32537       COPY dev$ & "unzip_exe" TO WIN1_ETC_unzip
32538       COPY dev$ & "starter1_zip" TO WIN1_QubATA_starter1_zip
32539       EW WIN1_ETC_unzip ; "-d WIN1_ WIN1_QubATA_starter1_zip"
32540       DIR #2,WIN1_

32541    WIN_FORMAT 0
32542    PRINT #2, "DONE !"
32543    WIN_DISK #2,"SUMMARY",1

32544 END DEFine

Procedure UP_BOYS creates and formats the eight BOYn partitions :

32545 DEFine PROCedure UP_BOYS
32546    CLS #2
32547    WIN_FORMAT 11,5
32548    FOR I = 2 TO 9
32549       WIN_DISK #2,"CREATE",1,I,60
32550       WIN_DRIVE 2,1,I
32551       FORMAT "WIN2_BOY" & CHR$(I+48)
32552       DIR #2,WIN2_
32553       WIN_CTRL 2,14
32554       WIN_DRIVE -1
32555    END FOR I
32556    WIN_FORMAT 0
32557    PRINT #2,"DONE !"
32558    WIN_DISK #2,"SUMMARY",1
32559 END DEFine

Procedure UP_CATS creates and formats the ten CATn partitions :

32560 DEFine PROCedure UP_CATS
32561    CLS #2
32562    WIN_FORMAT 11,7
32563    FOR I = 10 TO 19
32564       WIN_DISK #2,"CREATE",1,I,240
32565       WIN_DRIVE 2,1,I
32566       FORMAT "WIN2_CAT" & CHR$(I+38)
32567       DIR #2,WIN2_
32568       WIN_CTRL 2,14
32569       WIN_DRIVE -1
32570    END FOR I
32571    WIN_FORMAT 0
32572    PRINT #2,"DONE !"
32573    WIN_DISK #2,"SUMMARY",1
32574 END DEFine

Procedure UP_DOGS creates and formats the ten DOGn partitions :

32575 DEFine PROCedure UP_DOGS
32576    CLS #2
32577    WIN_FORMAT 11,7
32578    FOR I = 20 TO 29
32579       WIN_DISK #2,"CREATE",1,I,433
32580       WIN_DRIVE 2,1,I
32581       FORMAT "WIN2_DOG" & CHR$(I+28)
32582       DIR #2,WIN2_
32583       WIN_CTRL 2,14
32584       WIN_DRIVE -1
32585    END FOR I
32586    WIN_FORMAT 0
32587    PRINT #2,"DONE !"
32588    WIN_DISK #2,"SUMMARY",1
32589 END DEFine

Procedure UP_ALL does the total setup :

32590 DEFine PROCedure UP_ALL
32591    UP_GIRL
32592    UP_BOYS
32593    UP_CATS
32594    UP_DOGS
32595 END_DEFine

When all the partitions exist, here are procedures to link a BOYn to WIN2
 
32596 DEFine PROCedure BOY( N )
32597    CLS #2
32598    WIN_DRIVE 2
32599    WIN_DRIVE 2,1,N
32600 END DEFine

And a CATn or a DOGn to WIN3

32601 DEFine PROCedure CAT( N )
32602    CLS #2
32603    WIN_DRIVE 3
32604    WIN_DRIVE 3,1,N+10
32605 END DEFine

32606 DEFine PROCedure DOG( N )
32607    CLS #2
32608    WIN_DRIVE 3
32609    WIN_DRIVE 3,1,N+20
32610 END DEFine

At the beginning of the listing, I added two procedures I forgot, just to unlink any partition linked to WIN2 or WIN3 and retrieve the RAM space of their FAT. It is safer to use these instead of the QubATA commands.

When you want to remake the partitions you need to "kill" the old ones. For the moment, this is done "group-wise", but I may "complexify" !

32611 DEFine PROCedure KILL_BOYS
32612    WIN_DRIVE -1 : WIN_FORMAT 1
32613    FOR I = 2 TO 9
32614       WIN_DISK#2,"REMOVE",1,I
32615    END FOR I
32616    WIN_FORMAT 0 : WIN_DRIVE 1,1,1
32617 END DEFine

32618 DEFine PROCedure KILL_CATS
32619   WIN_DRIVE -1 : WIN_FORMAT 1
32620    FOR I = 10 TO 19
32621       WIN_DISK#2,"REMOVE",1,I
32622    END FOR I
32623    WIN_FORMAT 0 : WIN_DRIVE 1,1,1
32624 END DEFine

32625 DEFine PROCedure KILL_DOGS
32626    WIN_DRIVE -1 : WIN_FORMAT 1
32627    FOR I = 20 TO 29
32628       WIN_DISK#2,"REMOVE",1,I
32629    END FOR I
32630    WIN_FORMAT 0 : WIN_DRIVE 1,1,1
32631 END DEFine

Yes ! what follows is cruel (:o)

32632 DEFine PROCedure KILL_ANIMALS
32633    KILL_DOGS
32634    KILL_CATS
32635 END DEFine

And indeed, you may never kill GIRL !

32636 DEFine PROCedure KILL_ALL_EXCEPT_GIRL
32637    KILL_ANIMALS
32638    KILL_BOYS
32639 END_DEFine

If you really want to blow the World, then call simply UP_GIRL ; it will suicide her (with INIT command), but she will immediately resuscitate.

Final notes : the line numbers I put are suited for merging this file to an existing boot of a floppy. And these tools do not do error checking, either I will add them later, or I will decide that they will be used so scarcely that error checking is not needed. As I intend also to modify the file for booting from WIN1, I may add more secure versions to it.

May the FORTH be with you.

Bye Paul

Posted: **Tue Sep 18, 2018 1:40 pm**

Hi Paul

Nice set-up!

You asked "what is the use of the (undocumented) "JTAG" connector in the middle of the board"

As I understand it, the CPLD (or FPGA) that Tetroid has designed at the heart of his expansion card can be re-programmed 'in-place' via the JTAG connection and a suitable programmer/cable. It spares you from having to remove the device and fit it in to a separate programmer in order to re-program the 'firmware.'

Its only likely to be of use to you should Tetroid release updated firmware for the device - perhaps to address any bugs that might come to light in the future (e.g. like Marcel has devised for his updated QL-SD interface). It's not of immediate value to the end-user as the firmware of the programmable device is inherently tied-to the design of the rest of the interface.

Just to be clear, 'firmware' here is used rather loosely and has nothing to do with the 68k code contained in the ROM that is accessed by the QL itself.

Perhaps more value will be gained by playing with the hardware as it is today - you've got some very nice equipment, after all!

M.

Posted: **Wed Sep 19, 2018 3:36 pm**

tofro wrote:Also, I seem to recall that QubIDE (QubATA) and original QL-SD formats were byte-reversed (so, not directly exchangeable without first converting)

The formats are not byte-reversed! But the IDE bus must be read correctly, i.e. with big-endian 68K hardware QubIDE was designed for. As long as one uses 68K hardware: No difference at all!

The confusion comes from some people attaching QubIDE media to x86 PC IDE hardware instead of 68K hardware. PC IDE hardware can not directly read a QubIDE harddisk correctly, because it is uses unsuitable x86 little-endian format on the 16 bit IDE bus.

In other words: Not the formats are byte-reversed, but PC IDE hardware is different from the QL IDE hardware.

The Sinclair QL Forum

Overview of QL SD / CF Solutions

Overview of QL SD / CF Solutions

Re: Overview of QL SD / CF Solutions

Re: Overview of QL SD / CF Solutions

Re: Overview of QL SD / CF Solutions

Re: Overview of QL SD / CF Solutions

Re: Overview of QL SD / CF Solutions

Re: Overview of QL SD / CF Solutions

Re: Overview of QL SD / CF Solutions

Re: Overview of QL SD / CF Solutions

Re: Overview of QL SD / CF Solutions