Memory Module for the Atari 2600 and 7800: Protocol

For consistancy across games, I recommend that the Memory Module be connected to the controller port that corresponds with the player whose data is to be accessed. If this doesn't apply (high score lists, two player simultaneous games, etc), then I recommend the left controller port be used for the Module. This is basicly the same rule that seems to be used by PlayStation games to decide where to find the right memory card. It also allows the player the option of using the Module's controller emulation.

Before initiating communication, the controller port will function normally as if only a regular controller is attached, or nothing is there. The process of initiating communication will not damage any of the standard controllers. The steps are:

1. Ground controller lines 1 through 4 (joystick directional lines).
2. Wait at least 10ms. Notes:
• The required delay will be shorter if no PlayStation controller is connected, so delay for 10ms or test with a controller.
• 4ms might be long enough.
3. Change controller lines 3 and 4 back to inputs.
4. Wait at least 1ms.
5. Check the state of lines 3 and 4. If they are both grounded, a device using this protocol is attached.
6. Bring the clock line, controller line 2, high. (This will cause lines 3 and 4 to return to a high state within 12us.)
7. Wait at least 12us or until lines 3 and 4 are high.
8. Bring the clock line low.
9. Wait at least 24us.
10. Send a device ID (0x10 for the memory module) to use over the synchonous serial lines.
11. Wait at least 2ms.
12. Check the !slave selected line (controller line 4).
• If the line is high, the device is not present or did not respond. Go back to setp 1.
• If the line is low, the device is selected. No other device will respond to commands until this line returns to a high state.

The uses for the controller lines with the serial protocol:

Communication is done using half duplex synchronous serial. 8 data bits are sent followed by a ninth bit for odd parity. Slave devices check and generate the parity value, so its use is not optional. Data is sent LSB and LSb (Byte & bit) first. Data is read on the falling edge of the clock and output on the rising edge. The clock must not exceed 1MHz.

The device ID sent in step 10 is sent using this method of communication. When a device recognizes its ID, it will bring the !slave selected line low. While it remains low, no other devices will respond, but they will wait for the !slave selected line to return to a high state before allowing step 1 to occur again. Once selected, communication continues in whatever way the device specifies.

In the case of the memory module, communication follows this pattern:

1. A command is sent from console.
2. Paramters for the command, if any, are sent.
3. A result code is sent to the console. If it is an error, the device will expect another command (step 1) next.
4. For write commands:
   1. The data to write is sent.
   2. A result code is sent to the console. If it is an error, the device will expect another command (step 1) next.
5. Any return data is sent to the console.

Whenever the slave selected line is low, a device claims to be in use. Other devices will not respond until the line returns to a high state. Send the deselect command (0xFF) to a device to make this happen. Within 32us of the !slave select line going high, devices will be able to respond to attempts to initiate communication.

Asynchronous serial is also supported for use with a computer. The data format is 8-N-1 (8 data bits, no parity, and 1 stop bit) at 19.2kbps with CTS flow control (RTS is not used). Because parity checking is not used, it is up to the computer software to detect and respond to errors. I would have left parity checking enabled, but I couldn't get the software to function properly and came across a bug in the serial support of the 2.4.19 Linux kernel. If these problems are resolved, I may reenable parity checking for asynchronous serial connections.

To summon the device:

1. Signal the computer is ready by raising the DTR line.
2. Send any character (optional) or send the device ID code (0x10).
3. Recive a character. This should be the device ID code. It is possible that the data will be trash for the first attempt.
4. If the character sent in step 2 does not match the response of step 3, go back to step 2, or stop if the device ID is for an unsupported device.

Storage is divided into blocks, the atomic storage unit for this device. There are 64 blocks, each 128 bytes long. Blocks are allocated to files, which may be several blocks long and may be non-contiguous. Games provide a 15-bit value which functions as a file name and is used to find allocated blocks. A game can allocate multiple blocks and access each block through an index. The index starts with zero. Each increment of the index addresses the next allocated block in chronological order of allocation. Deallocating a block will cause the index of any following block(s) to decrease.

The directory information that details the usage of the serial EEPROM is stored on the EEPROM of the microcontroller. Each entry is 16-bits long. The upper bit is set if the corresponding block is not a head block (the first block for a game). The remaining 15 bits of a head block's entry is the game ID, which works like a file name. Other blocks are organized differently. In the lower byte, the first 7 bits store the absolute index of the next block in the file, and the MSb is set when this block is the end of the file. In the upper byte, the first 7 bits are the absolute index of the previous block in the file, and the MSb is always set because the block isn't a head block. This scheme requires a linear dierctory search to find the second block (bad), but allows a large game ID space (good) and allows files to grow until all the space is used (also good).

The memory module contains a 160 byte volitile RAM buffer that is accessible through the interface. All EEPROM data must go through the memory buffer. Data can only be read from the EEPROM into the buffer and only data in the buffer can be written to the EEPROM. Data in the buffer may be changed without EEPROM access. The data will be presevered between times when the module is summoned so long as power is maintained. As a result, the buffer can be used for temporary storage. The contents on power-up are undefined.

PlayStation controller interface

The memory module can send data from an attached PlayStation controller over an asynchronous serial connection. To use this feature, begin communication with the module as detailed above, then send 0x78 as a command code. No return code is sent. The module will continously send controller data until it is reset. Before the module can succeed in reading data from the controller, DTR must be dropped.

If no data is read from the controller, the module will send 0. If any data is read, the module will send 1 followed by 8 bytes. The first byte is the controller ID code. The third and fourth bytes are the button flags. The fifth through eighth bytes are the analog stick positions. This data is in the order the controller sends it and is documented in a few spots on the web. The module sends everything but the analog stick positions with the bits mirrored (bit 0 from the controller is sent as bit 7, bit 1 is sent as bit 6, etc).