A noob's guide to QL machine code

[RalfR]

Thank you Dilwyn. This is useful, as I like to keep EXEC programs always in their native format.

[bwinkel67]

I use Q-emuLator on a classic 68K/PPC Mac (i.e. pre-2000s). On those, the QL file header information is kept in the resource fork QFHD and seems to only be 10 bytes in length. With the move to Unix BSD, I don't think file is split into two parts anymore so I don't know how its stored on a modern Mac.

[M68008]

I think I will personally adopt the XTcc trailer method for storing executables programmes on non-QL filesystem.

I thought that XTcc was only used by cross-compilers, but not sure.

Q-emuLator doesn't currently understand XTcc. While it could, it is already inspecting the start of files and also looking at the end of each would not be ideal.
The Q-emuLator header (also supported by QPC and other tools) can store some additional metadata. It's rarely used, but for example Eye-Q stores some extra header information when saving images.

[M68008]

I use Q-emuLator on a classic 68K/PPC Mac (i.e. pre-2000s). On those, the QL file header information is kept in the resource fork QFHD and seems to only be 10 bytes in length. With the move to Unix BSD, I don't think file is split into two parts anymore so I don't know how its stored on a modern Mac.

The OS X version uses the same header mechanism as the Windows version. There was also a last 68K update that can read both the resource fork and the modern in-file header.

[M68008]

Taking things a little step further, here's a short SuperBASIC program to remove the native file format header from QemuLator files (and probably other emulator native files which use this format, but that's untested).

Thank you Dilwyn. To avoid confusion (or rather to add to it?? ), I'd like to comment that this should not be needed in normal use as tools should automatically remove extra headers when appropriate.

There are two types of file systems, QDOS-aware ones (e.g. WIN containers, MDV images, QDOS floppy disks, QDOS ZIP files) and non-QDOS-aware (e.g. PC file system).
The rules to avoid issues are very simple:
1) If a tool or emulator is used to move a file from QDOS-aware to non-QDOS-aware, then the same program should be used to go in the other direction.
2) Only access QDOS zip files by running the QDOS zip/unzip programs on a QSOS-compatible OS, both when expanding them and creating them. This is the main one that trips up people new to the QL, especially as they may not be aware that there is a separate version, where to find it and how to use it.

If these guidelines are not followed and a file ends with a wrong extra header, Q-emuLator includes utilities to fix the files from a QDOS system. However, it may be a chicken and egg problem, as those programs are executables that need to be transferred in the correct way, so a SuperBASIC version is useful! (Q-emuLator never creates a file header for SuperBASIC source code, text files and any other files that don't need to store extra QDOS metadata like the executable dataspace size.)

[XorA]

2) Only access QDOS zip files by running the QDOS zip/unzip programs on a QSOS-compatible OS, both when expanding them and creating them. This is the main one that trips up people new to the QL, especially as they may not be aware that there is a separate version, where to find it and how to use it.

I wrote https://github.com/xxoraa/qem-unzip to address this point! It adds Q-Emulator headers to files based on info in the zip!

[M68008]

2) Only access QDOS zip files by running the QDOS zip/unzip programs on a QSOS-compatible OS, both when expanding them and creating them. This is the main one that trips up people new to the QL, especially as they may not be aware that there is a separate version, where to find it and how to use it.

I wrote https://github.com/xxoraa/qem-unzip to address this point! It adds Q-Emulator headers to files based on info in the zip!

Nice! I didn't know about it.

[Derek_Stewart]

In the other message thread concerning the Qliberator self modifying code, I have been trying to understand what is, modifying code and how to write it.

Is there any Assembley language tutorials with regards to this?

[pjw]

In the other message thread concerning the Qliberator self modifying code, I have been trying to understand what is, modifying code and how to write it.
<>

I once had the problem of running out of spare registers so rather than doing what youre supposed to, ie:

Code: Select all

        move.w  ut.cstr,a2
        jsr     a2

I came up with this naughty trick:

Code: Select all

init
        lea.l   str_comp,a2         ;hard-wire in some vectors
        move.w  ut.cstr,2(a2)
        ..
        ..

str_comp
        jsr     0

Thats an example of self-modifying code.

Since this only happened during the intialisation of the toolkit the code
was still re-entrant, because however many times the code would be
initialised the result would be the same. However, it would not be ROMable,
because you cant change code in ROM (without re-proramming the chip).

[Derek_Stewart]

Does this work for other vectors?

e.g. opw.con or mem.achp