I have started to collect information about the tape format associated with Panasonic JR200, and the CJR format used in Panasonic emulators.
I will here produce what I have figured out so far, so this is not a comprehensive deciphering of CJR files. The information below is compiled mostly with a view to creating files that could be readable with emulators or with the machine itself. I have had some success in generating audio wave files from CJR, which will be a later topic.
Only a typical file will be discussed here, such as that could be outputted in JR-BASIC with the SAVE command.
The CJR format appears to be a comprehensive representation of the data in a file saved on a tape. Consider an audio recording of a file saved on a real Panasonic. Examining the audio file reveals that it has bytes encoded into a waveform. The CJR file contains all these bytes. Note that it does not represent the waveform. Also, it is not a full tape format, as each separate file has its own CJR file. (Such as the BASIC loader, loading screens and game data.)
The data in a CJR file is organized into blocks. In principle, the blocks have a similar structure, but they also differ. Each block begins by values 2 and 42, and except the final block, they are ended with a checksum. The checksum is particular to each block, an 8-bit value that is reached by adding all previous values together, including the 2 and 42. (Being 8-bit, the value will of course "roll over" after 255.)
I have chosen to call the first block the Identifier, the subsequent parts as Data blocks, followed by a Tail.
The Identifier:
- 2
- 42
- 0 (Block number. The ID block is #0)
- 26 (Length of data, fixed in a normal ID)
- 255
- 255
- Ascii (Filename, 16 characters)
- Ascii
- Ascii
- Ascii
- Ascii
- Ascii
- Ascii
- Ascii
- Ascii
- Ascii
- Ascii
- Ascii
- Ascii
- Ascii
- Ascii
- Ascii
- 0 (0=BASIC 1=BINARY)
- Baud Rate (0=2400 1=600)
- 255
- 255
- 255
- 255
- 255
- 255
- 255
- 255
- Checksum (8-bit number, all previous values added)
A Data Block (one or more):
- 2
- 42
- Block # (Block number, starting from #1)
- Length (Length of data. 0 means full 256 bytes)
- HI (Word: Block start address.)
- LO
- Binary data (Up to 256 bytes of binary data)
- ...
- ...
- ...
LAST. Checksum. All values in this block added together.
The Tail (After all data blocks):
- 2
- 42
- 255
- 255
- HI (Word: End address)
- LO
About the ID
The File identifier is quite straightforward. The 16 character filename, the two following values and the eight 255's make up the 26 bytes indicated by the length.
Data Block handling
Very short files, such as BASIC loaders for games can sometimes be less than 256 bytes, so they only have the Identifier, one Data Block and a Tail.
Files that exceed 256 bytes in length have multiple Data Blocks. In this case the Block length is denoted by a 0 (Really 256), meaning that there will be further blocks. The last block will then have a different length. Suppose you have saved a file that is 320 bytes long. The first Block length will be 0, whereas the second (and final) Data Block will be 64 bytes long.
The Block number will be incremented for each block. The Identifier is the block number 0, so the first actual Data Block has a value of 1.
The start address in each Data Block shows where the data "belongs". For example, a BASIC file has a start address of $0801. The start address in each data block is normally incremented by $100 (256), so a normal BASIC file would have $0901 as the next Block start address and so on.
Each Data Block has its own checksum, which is reset for each block. The Tail, as can be seen, does not have a checksum.
It is also possible to load files into a different start address on the Panasonic. A character set could be loaded directly over the normal character set or the user defined graphics memory area.
Wrapping it up
The end address in the Tail is the memory address after the file. So if 255 bytes are loaded to a start address of $D000, the end address in the Tail is $D100.
Edit
As has been commented, apparently the 24th byte in the header/identifier block indicates the baud rate of the subsequent data blocks. I suspected it to have some meaning! This and other information on the tape format is available on a Japanese language web page. The byte is not $64 or 64 though, but simply 0 or 1 for 2400 and 600 bauds respectively.
Isn't byte 24 of the header block the speed of the following blocks? According to the Japanese page 0 = 2400 baud, $64 = 600 baud.
ReplyDeleteMy attempt at a bin2cjr converter can be downloaded here. Works with the emulator at least: http://www.kameli.net/~marq/jr200/bin2cjr.c
ReplyDelete