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

Hi Nataliapc,

Yes,I did use a makeTZX tool to extract the game data of Laser Squad, and also the extra levels from the Spectrum version, they were encoded on tape the exact same way (disk version with extra Spectrum levels is available on my website). I'll check my TSX file tomorrow, but this looks a bit too small for the loader, IIRC.

The version 0.6 of makeTSX is available. It includes several new features:

1. Option to do hex / ASCII dump [-c]

2. When generating a ".TSX" file automatically are generated also the following blocks at the beginning of the file:

-- Block # 30 with info about the version of makeTSX that has extracted this file.

-- Block # 32 with an empty info block in order that user can modify it to identify the Tape.

-- Block # 35 with the MSXLOAD key to indicate the load instruction of the Tape (RUN / CLOAD / BLOAD), provided the first data block be a standard MSX header.

3. Listing the blocks of a ".TSX" file now shows the start / finish / execution addresses of data blocks # 4B in case of having previously an MSX header that identifies it as binary.

You can found this new version here:

http://www.zonadepruebas.com/download/file.php?id=5200

Thank you very much to NataliaPC for her efforts creating the MakeTSX Program. ;-)

Hello,

I have forgotten to mention that we have now a FTP repository where we put all the ".TSX" File that are being created.

host: opencomputer.ddns.net
user: msx
pass: msxtsx
port: 21

Gracias & saludetes. ;-)

The 0.8beta version of the makeTSX is available and includes the following improvements:

- Normalization of the audio before the detection process (can be disabled with -dn).
- Record the WAV once normalized (wav_normalized.wav) to see the result (-outn).
- Record the WAV after applying the wav_envelopped.wav to see the result (-oute).
- Autodetection of baudrate in blocks # 4B (no longer detects only 1200 and 2400).
- Improved detection of Blocks # 20 (Silences) and their integration with other blocks to optimize the total number of blocks.
- Improved Detection of Blocks # 4B.
- Detection of Blocks # 10 (colloquially known as Turbo blocks in the MSX world).
- Detection of Blocks # 12 (Pure tone) but pending improvement.

You can download the Program here:

- Windows -> http://www.zonadepruebas.com/download/file.php?id=5253

- Linux 32 bit -> http://www.zonadepruebas.com/download/file.php?id=5251

- Linux 64 bit -> http://www.zonadepruebas.com/download/file.php?id=5252

The great advance is the recognition of the "TURBO BLOCKS" ;-)

We also have an FTP in which you can upload the versions of ".TSX" files that you are creating (you have to upload them to the "UpLoads" folder). The FTP access data are as follows:

Host: opencomputer.ddns.net
User: anonymous
Pass:
Port: 21

As a teenager, I originated the UEF file format in my ElectrEm emulator. I've also implemented support for a whole bunch of other tape formats over the years. If I can be of any help:

TZX is a poorly-designed file format — most of the elementary chunks have completely distinct ways of encoding their length. So you need to implement a large number of things correctly before anything works reliably; more recent revisions have become very duplicative and given off a vibe of being the repository for whatever the authors are playing with that week. Even in the Spectrum world, there is a vocal movement towards PZX as a format that doesn't have most of the multitude of deficiencies of TZX (cf. the PZX description, and particularly the threads linked to underneath 'Why new format?'*).

From a keep-it-simple point of view, if adopting another format then I'd strongly advocate CSW or, possibly, the Commodore-style TAP as completely natural fits. CSW just stores the time between every zero crossing with byte stream compression. Commodore TAP stores the time between every upward zero crossing (i.e. from low to high, but not vice versa). CSW is preferable because TAP doesn't record the relative widths of the high and low periods of any complete wave. On Commodore hardware you're signalled only upon a rising crossing so the difference is immaterial there.

Since a CSW chunk has been added to recent revisions of TZX, implementing CSW support is unavoidable even if you stick with TZX. Honestly, without any legacy collections about, I'd strongly advocate just picking CSW.

Acorn computers use a different stream of bytes but at the bit level use exactly the same Kansas City standard as the MSX. Since it can contain a raw Kansas City bitstream at an arbitrary baud rate, or just a collection of pulses if necessary, arbitrarily spaced, a UEF can already exactly describe any MSX tape. Unlike TZX, blocks are entirely uniform, so there's no TZX-esque initial coding cost or multitude of potential sources of regression.

* Thread one, thread two, thread three.