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

Page 10/11
3 | 4 | 5 | 6 | 7 | 8 | 9 | | 11

By TomH

Master (215)

TomH's picture

12-07-2018, 04:43

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.

By nataliapc

Resident (51)

nataliapc's picture

12-07-2018, 18:22

Great news, CLK support!!
So, have you emulated the PPI Tape I/O?

TomH wrote:

...At original tape speed as and when they don't use the ROM routines, but that's correct.

...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?

Yes, as you say, the spectrum (turbo) blocks #10 and #11 can be accelerated but we don't know the speed tolerance of each turbo loader program in every game.

TomH wrote:

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?

You can use the Custom info block "TSX.LOAD" included in all our TSX files.
You can see them using ZXBlockEditor, or in our webpage expanding de "Blocks show/hide" option.

TomH wrote:

...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.

Yes, I had the same problem xDDD
At TZX Specs we can see '10' for Identification string lenght but is '0x10' instead...

Thanks again for the support and if you need talk about, don't doubt contact me :D

By TomH

Master (215)

TomH's picture

12-07-2018, 19:50

nataliapc wrote:

Great news, CLK support!!
So, have you emulated the PPI Tape I/O?

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.

nataliapc wrote:

Yes, as you say, the spectrum (turbo) blocks #10 and #11 can be accelerated but we don't know the speed tolerance of each turbo loader program in every game.

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.

nataliapc wrote:

You can use the Custom info block "TSX.LOAD" included in all our TSX files.
You can see them using ZXBlockEditor, or in our webpage expanding de "Blocks show/hide" option.

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.

nataliapc wrote:

Yes, I had the same problem xDDD
At TZX Specs we can see '10' for Identification string lenght but is '0x10' instead...

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?

nataliapc wrote:

Thanks again for the support and if you need talk about, don't doubt contact me :D

Will do!

By nataliapc

Resident (51)

nataliapc's picture

13-07-2018, 11:50

TomH wrote:

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.

If you are interested in, you can follow the next steps:

  1. Get the CAS and TSX of the same game with spectrum blocks (turbo)
  2. Convert the CAS to TSX using my php script 'cas2tsx.php'
  3. Locate the loader binary block in both files and export them using ZXBlockEditor
  4. Use a binary compare program with both files.
  5. You can see now the original load routine in the block from the TSX and the patched one using BIOS from the CAS file.

By manolito74

Paladin (928)

manolito74's picture

13-07-2018, 22:38

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

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

Saludetes. ;-)

By CASDuino

Resident (54)

CASDuino's picture

14-07-2018, 13:31

Totally off topic as the TSX format doesn't make use of TZX ID15 but if anyone has any knowledge of working with Arduinos we are still looking for help to add ID15 to TZXDuino.

By nataliapc

Resident (51)

nataliapc's picture

15-07-2018, 18:19

Wich problem have you with ID15?

By CASDuino

Resident (54)

CASDuino's picture

15-07-2018, 22:17

At the moment we have not been able to code ID15 at all on TZXDuino. TBH we're not even sure if it's possible. Some fresh eyes may see a solution where we do not have one.

By nataliapc

Resident (51)

nataliapc's picture

16-07-2018, 01:31

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.

By TomH

Master (215)

TomH's picture

16-07-2018, 15:16

CASDuino wrote:

At the moment we have not been able to code ID15 at all on TZXDuino. TBH we're not even sure if it's possible. Some fresh eyes may see a solution where we do not have one.

What's the specific issue? Bandwidth, or something else?

Page 10/11
3 | 4 | 5 | 6 | 7 | 8 | 9 | | 11
My MSX profile