Jupiter Ace - Tape i/o and .TAP file format
	-------------------------------------------

	based on the FAQ <http://users.aol.com/autismuk/ace/faq.htm>
	worked on by kio
	2005-11-14


Port $FE is the tape and buzzer output port. 
Port $FE is also the Keyboard Input port. (Where is the tape input bit? kio.) (?)


Most of the work on this was done by Simon Owen. si@obobo.demon.co.uk

The tape file format is almost identical to that of the Sinclair Spectrum. Tapes were initially read in using the registered version of the "Z80" Spectrum Emulator. These were then provided as data files, as "header" and "data" blocks.

A .TAP file consists of these header and data blocks concatenated together, each block seperated by a 2 byte word giving the size of the block. (Low,High order). This does not include the the size word itself - e.g. the next block size word is found at <address>+<size>+2.

A simple program to construct .TAP files from Header & Data blocks is available from the software library. Information on the snapshot format .ACE is also available from me.


From Si's mail on converting the "Five Ace Programs" ...

>>>
The tape wasn't in very good condition and I had to sample both sides at different volumes and frequencies (using the READSB utility that comes with Z80). I did 6 samples, converted the 8 headers and files to data blocks and compared them all to filter out ones that have errors.

The baud rate is compatible with standard Spectrum tapes so I wrote a small program on the Spectrum emulator to read each block into memory. The tape format is the same: 'tone leader, header data,tone leader, data block', but the second tone leader is too short to be caught by the standard ROM, which requires 256 'edges' before it will accept a block and also has a 1 second delay after it toggles the border from cyan to red between edges). I ended up patching the Spectrum ROM image to reduce the delay from 1 second to zero, and also reduced the required number of required 'edges' to be found from 256 to 100.

Another problem is that there is no gap between the header data and the second tone leader so I couldn't work out the length of the header data. Reading a bigger block resulted in the second tone leader being read as header data! It appears that headers are 26 bytes long (maybe 25).

The first byte in the header appears to be some sort of type byte or flag and is always zero. The next 10 bytes are the filename, padded out with spaces. The following 2 bytes appear to contain the length of the main data block, although for some reason I always seem to read 1 byte more! To read the data block I call the ROM routine with a big length and wait for it to get cut short by reaching the end of the data. I then subtract the starting address from the position reached (still in IX on return) to work out the length. Maybe this is what's causing the extra byte... the last byte might be junk.
<<<


Paul Robson (autismuk@aol.com) has created a program 'TAPH' which converts a 22khz Mono Sample of a Ace program (such as produced by the Windows 95 'Sound Recorder' program) into a .TAP file, which was successfully used to read in the 'Boldfield Computing' programs. This program was based on the program of the same name by 'Technomancer' (but is a complete rewrite !)