".TSX" --> ".TZX" Format in MSX

Cool. I took the quick opportunity to try a couple of these with my emulator; as it turns out I was parsing custom info blocks incorrectly* and TSXs see to be full of them, so nothing would load. One constant update later and everything seems to be loading. At original tape speed as and when they don't use the ROM routines, but that's correct.

So as usual you can grab that here if OpenMSX isn't your thing for some reason.

It might be an interesting thing to try to figure out which loaders are commonly used in the hope of being able to accelerate them, but I suspect they're probably just going to be very much like the Spectrum set?

EDIT: the emulator also correctly determines the correct loading command fairly easily; even if that can't be added to OpenMSX for whatever reason, maybe it could be stored as custom information rather than shoved mercilessly into the filename?

* the spec is extremely inconsistent in where it uses hexadecimal and where it doesn't; within the custom info block documentation alone it cites lengths of both 10 and 0x10, including using the unadorned value '10' within the description of length where, throughout the rest of the document, it random switches between decimal and hexadecimal. For the record, it means 0x10.

It's had support for a while... as long as there were no custom info blocks, because it parsed those incorrectly. So as far as the repository goes, I guess it really didn't have support.

The tape hardware is fully emulated and is the default manner by which TSX, CAS and CSW load. The underlying file format is indistinguishable to any functioning part of the emulator.

Optionally there is also a BIOS trap, which will catch TAPION and TAPIN and perform them instantly. Those parse the tape at its pulse level — again, no knowledge of the underlying tape image format is obtainable within the emulation — so CASes and any parts of TSX or CSW that are ordinary BIOS-format data, however encoded, and which are loaded by calls into the BIOS will load immediately if the user prefers it.

Of TSXs, some like Cyberun load instantly, others like 007: Licence to Kill get as far as their title screen via BIOS calls then run their own code, so segue into ordinary tape-speed loading. The emulator is careful in the BIOS traps to leave things in the state they would have been had the BIOS acted normally, so it's not a problem if some segments jump into the ROM and others don't.

That same BIOS-format parser is applied at launch time to determine the correct loading command — it's picked based on the type of the first file on the cassette. Since the first thing effectively must be ROM loadable, that works for all tape images.

You can't implement TSX fully without implementing CSW anyway, so I thought I'd just offer it directly too. It costs nothing, and it's used by some of the machines other than the MSX so it isn't dead code. Actually, so is the TSX support: in its TZX form it can feed the ZX80/81 and in its CDT form the Amstrad CPC.

Re: level of TSX support, this is where to look. Anything that's a `get_` will actually parse the contents of that type of block. Anything that's an `ignore_` will ignore the contents.

I was imagining some sort of fingerprinting of the code around whichever instruction is reading the tape port to try to identify the type of loader and, if identified, doing much the same thing as my TAPIN trap. But I don't know, it's probably a bit fringe.

Cool. At the minute I'm using virtually none of the metadata, either from TSX or from any of the other formats the emulator deals with. But I don't see any downside to allowing a file to override whatever the analyser picks, so I'll try to come up with a consistent way to handle that given the diversity of underlying file formats.

Right, so originally I decided to trust the 'Length:' box, scrolled to the top of the document and saw that the length of the header is specified as '10' and that means decimal. But if I'd just scrolled down to chunk 11 I'd have seen that the length box oscillates randomly between hexadecimal and decimal too. I guess they've gone back and bolted that box on later to try to ameliorate for the mess of chunk lengths but probably in multiple sittings, or via the input of multiple authors?

Will do!

Thanks to you @Tolvatar and all the people interested in the TSX Format. ;-)

Thanks for encouraging us and for your support ! ;-)

Saludetes. ;-)

Wich problem have you with ID15?

Maybe try an on the fly conversion from block #15 to block #13 could be interesting.
I don't propose a straight conversion... but the use of this approach could be a solution: convert block #15 in something better to manage.
I'm just brainstorming.