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

Never hear of that. Could you put some examples?

That's exactly what I said, and the microcode version does; it provides the template for producing a 0, the template for producing a 1, then the template for producing bits from a byte. Except that I also included parity, because some micros use it.

Simplifying everything to nibbles, pseudo code for my proposal is something like:

Program {
    Program() {
    }

    Program(Program zero_program, Program one_program) : zero_program(zero_program), one_program(one_program) {
    }

    void step(byte) {
        void output_bit(value) {
            parity ^= value;
            if(value) one_program.perform(); else zero_program.perform();
        }

        switch(next_nibble()) {
            case 0: // output 0
                zero_program.perform();
            break;
            case 1: // output 1
                one_program.perform();
            break;
            case 2: // output and reset parity
                output_bit(parity); // the reset comes for free!
            break;
            case 3: // output bit n
                bit = next_nibble();
                output_bit((byte >> bit)&1);
            break;
            case 4: // wait
                triple = next_triplet(); // i.e. next three nibbles, compiled in little-endian format
                add_wait(triple);
            break;
            case 5: // toggle parity
                parity ^= 1;
            break;
            case 6: // toggle output
                add_crossing();
            break;
        }
    }

    void perform(byte) {
        pointer = 0;
        while(pointer < end) step(byte);
    }
};

void perform_data_block() {
    zero_program = read_program();
    one_program = read_program();
    byte_program = read_program(zero_program, one_program);

    while(bytes) {
        byte_program.perform(read_byte());
    }
}

void perform_repetition_block() {
    repeats = read_int();
    program = read_program();

    while(repeats--) program();
}

void perform_tape() {
    while(not end of file) {
        block_header = get_block_header();
        parity = 0;
        if(is data block)
            perform_data_block();
        else
            perform_repetition_block();
    }
}

I don't see how making the byte and bit formats declarative rather than programmatic would actually simplify in this case.

Off the top of my head, I am aware of the tape encodings and tape hardware of the:

• Spectrum (/Amstrad/Enterprise/etc);
• ZX80/81;
• Electron/BBC;
• Commodores;
• Oric; and
• MSX

That would cover everything that any of those machines can read with perfect fidelity.

EDIT2: to be absolutely explicit:

• a data block would cover most if not all byte-oriented streams;
• a series of changes that could not be encoded into a data block could be stored as a repetition block with a repetition count of 1;
• lead-in tone could be encoded into a repetition block with a repetition count of several thousand;
• limited range on WAIT isn't problematic: just put multiple of them in a row. If you're encoding a long gap between files, use a repetition block to avoid having to spell each out individually.

You're all smart people. I'm sure you realised that already. The main additional block I might consider would be sequence-of-bits, where a 0 program and a 1 program are specified, then n bits. No byte program, no requirement for a multiple-of-eight number of bits.

The audio is intended for human ears, so MP3 would be smarter. But as a corollary, it's not intended for the computer to process or control, so one might argue it is out of scope — we're trying to preserve only the digital signal.

As well as your example, there are at least two albums off the top of my head that include ZX Spectrum software on them (including last year's OK Computer reissue), and some games that just had music on side two (Confuzion springs to mind, but it's not the only one).

Would be nice if this could be part of the image format, embedded in effect. That way emulators can also emulate that part of it. On the other hand, it would bloat the files significantly, and be too large for a real MSX still to process. So you would need some kind of tool to strip such data if you want to load the file on a real MSX.
Another way would be to add some metadata to the file to indicate there should be an external MP3 file (or files?), and when it should be used. This could be ignored when loading the file on a real MSX. The problem with this is that such external files are easily lost, but that is probably no different then giving users the ability to strip the MP3 from the file.

I think that is important maintain the format in a raw and uncompressed way for easiest read/manipulation in old and/or low performance platforms.

The prediction method is cool but IMHO add an unnecessary complexity layer to the format. File size is not a critical factor due low program lengths and high mass storage sizes, even in old 8 bits computers.

Anyway the prediction+compression could be a format optional feature. But maybe this will force us to to create conversion tools to use the raw/no compressed format in the devices that not support it and leave the prediction+compression for storage/distribution purposes.

Right now I'm interested to discuss about microcode and how to represent the definitions of bits (using pulses) and bytes (using bits, start/stop bits, parity, etc...) in a flexible and configurable way.

I would like to hear too the opinion about all this (compression/raw, microcode, ...) of emulator owners/maintainers.

Hi TomH, my intention wasn't undervalue your proposal, just to known other owner/maintainers opinions...

So, for a uncompressed file format I understand that you propose the use of a pulse based format (like CSW as you say), right?