Jupiter ACE Tape Format
Thanks to Ricardo Lopes for this image.
1 byte file type 0 for Dictionary 32* for bytes
10 bytes filename padded with spaces
2 bytes length of file
2 bytes start address. This is 15441 for a dictionary
2 bytes current word. Unused for bytes file
2 bytes value of system var CURRENT [Address hex 3C31, dec 15409]. Unused* for bytes file
2 bytes value of system var CONTEXT [Address hex 3C33, dec 15411]. Unused* for bytes file
2 bytes value of system var VOCLNK [Address hex 3C35, dec 15413]. Unused* for bytes file
2 bytes value of system var STKBOT [Address hex 3C37, dec 15415]. Unused* for bytes file
* File type for bytes file may be any non zero value.
* Unused bytes are filled with spaces.
Emulating the Tape saving tone
Observations from Kevin Palser whilst implementing the tone output for an emulator:
• Unlike the beeper output, the Z80 IN instructions have no effect
• The ROM uses OUTs at port 0x8FE to make the tone go high and port 0xFE to go low
• Consecutive low tone operations are ignored if their was no high operations between them (* see note)
• Based on End Mark part of samples from a real Jupiter ACE, the amplitude stays at the max high/low level for about 0.00065 of second before decaying to the neutral level over about 0.0006 of a second
* note: This was based on two observations of the real recording:
1. the cassette saving ROM routine starts with an OUT to port 0xFE (i.e. low) but the tone output starts with a high amplitude, hence this initial OUT is ignored
2. the End Marks after the header bytes and after data have the same amplitude shape. However, during the End Marks after the header bytes there are two consecutive OUTs to port 0xFE (i.e. low) with the second about midway in the low amplitude. Whilst the first starts the low amplitude, the second OUT does not stop the low amplitude decaying back to neutral the same as the End Marks after the data bytes, which has no second consecutive OUT to port 0xFE.
