Monday, January 12, 2009
X08 banking specification
The X08 banking system is a new method of banking which nominally allows 32K of ROM and 8K of RAM. Because the cartridge must contain an operating system in addition to the user code, not all of the ROM and RAM will be available.
From a hardware standpoint, ROM is stored at addresses $00000000-$00007FFF and RAM is stored from $40000000-$400001FFF. As noted above, the first part of RAM and ROM will be used by the operating system. The emulator wouldn't have to worry about the OS RAM and ROM requirements, though it may be helpful to provide a 'trap' if a RAM address is written illegally. I'm not sure the best way to indicate what RAM areas should be considered legal and illegal, though.
Because the X08 controller is microprocessor based, it allows some features in addition to its rather generous RAM allocation. Most notably:
The X08 banking specification is in some regards trickier than others, because the main controller is itself another microcontroller which can be in a number of different states at the start of each memory cycle. Much of this will usually be transparent to the person writing code for it, but to minimize the likelihood that code will work beautifully in emulation and then fail in weird and bizarre ways on actual hardware, an emulator should try to mimic these behaviors as closely as possible.
The following is a list of cartridge states. Note that at the end of each cycle, the cartridge may be outputting a byte of data or may be floating the bus. If the processor attempts a read while the bus is floating, the data bus contents should be randomized (on real hardware they may be unpredictable). If the processor attempts a write while the bus is being driven, that should probably cause a fatal error except in "inject" state. Note also that except when the processor is in busy state, any bus cycle which uses the same data as the previous one will be ignored.
As noted above, the system address space is divided into eight 1K blocks. The functions of each block are as follows:
Each of the three User Banks may be independently programmed to use any of the following modes:
Key bank-switch addresses:
Note that any access to a bank-switch address will cause the following cart-space address to be performed in Simple-Fetch state.
From a hardware standpoint, ROM is stored at addresses $00000000-$00007FFF and RAM is stored from $40000000-$400001FFF. As noted above, the first part of RAM and ROM will be used by the operating system. The emulator wouldn't have to worry about the OS RAM and ROM requirements, though it may be helpful to provide a 'trap' if a RAM address is written illegally. I'm not sure the best way to indicate what RAM areas should be considered legal and illegal, though.
Because the X08 controller is microprocessor based, it allows some features in addition to its rather generous RAM allocation. Most notably:
- It allows the 6502 address space to be subdivided into four 1K zones which can be moved on byte boundaries anywhere within RAM or ROM address space.
- It provides high-speed block copy operations; future versions of the specification may allow other special operatons as well. The cartridge will clock out NOPs while such an operation is in progress, and then clock out a JMP to the instruction following the instruction that triggered it; thus, while such an operation will take time, the user need not worry about waiting for it to complete.
The X08 banking specification is in some regards trickier than others, because the main controller is itself another microcontroller which can be in a number of different states at the start of each memory cycle. Much of this will usually be transparent to the person writing code for it, but to minimize the likelihood that code will work beautifully in emulation and then fail in weird and bizarre ways on actual hardware, an emulator should try to mimic these behaviors as closely as possible.
The following is a list of cartridge states. Note that at the end of each cycle, the cartridge may be outputting a byte of data or may be floating the bus. If the processor attempts a read while the bus is floating, the data bus contents should be randomized (on real hardware they may be unpredictable). If the processor attempts a write while the bus is being driven, that should probably cause a fatal error except in "inject" state. Note also that except when the processor is in busy state, any bus cycle which uses the same data as the previous one will be ignored.
- Normal State
- This is the most common state of the system. Each address is categorized into a 1K block, and then processed appropriately. A more detailed description appears below. This state may progress into many of the other states, based upon the address accessed.
- Simple-Fetch State
- If an access is not in cartridge space, it will be ignored. Otherwise the system will assume that the address is a normal read with the same memory-bank offset as the previous read. This has two main consequences:
- The first byte of the instruction which follows a bank switch will be fetched from the page that was selected before the bank switch occurred.
- If an instruction which triggers a bank-switch appears as the last byte of a bank, the first byte of the following instruction will be accessed from the byte following the end of the bank from which the instruction had been fetched. If the banks point to consecutive regions of memory, this will be as expected. If not, it may cause weird behavior.
In any case, the system will revert to Normal State following a Simple-Fetch access. - The first byte of the instruction which follows a bank switch will be fetched from the page that was selected before the bank switch occurred.
- Simple-fetch-and-handle-write State
- Because certain write operation trigger actions which cannot be undone by simply writing new data, the system will latch the address and data bus on each cycle until it sees a change in the address bus other than at bits 8 and 9. The system will then process a simple read, and then process the write. Note that indexed writes may safely cross page boundaries, but not bank boundaries. This state reverts to Normal State.
- Enter-Busy-State State
- The system will wait for a change in the address bus other than at bits 8-9, and then examine bit 12. If bit 12 is set, the system will drive $EA (NOP) onto the bus and queue up $4Cxxxx for injection state (where xxxx is the fetched address). The system will then perform a function based upon the previous access (said function will probably set busy_cycles, since the purpose of this state is to handle operations that will take multiple 6507 cycles to complete).
- Busy State
- The cartridge will keep floating the bus or driving it with a constant value until a specified number of cycles have elapsed. This state takes priority over all others, and it is recommended that an emulator use a "busy_cycles" counter; if it's non-zero, decrement the counter and perhaps check for bus contention (an attempted write while the cartridge is driving the bus) but otherwise do nothing. Busy State may progress to either Normal State or Injection State.
- Injection State
- Each time the address bus changes and the new address is in cartridge space, output a byte from the "injection queue". The injection queue allows up to four bytes to be loaded provided the last is not zero. The suggested implementation is to store all the bytes in a 32-bit unsigned integer. After each address change, if the address is in cartridge space, output the least significant byte and shift the integer 8 bits to the right. Once all data are shifted, the system will progress to Normal State.
As noted above, the system address space is divided into eight 1K blocks. The functions of each block are as follows:
| ADDRESS | Function |
| $0000-$03FF | Some key registers at $007x, $02xx, and $03xx, as described below. |
| $0400-$07FF | One page for each bank--Select mode for a bank based upon LSB of address |
| $0800-$0BFF | One page for each bank--Add LSB of address to bank pointer |
| $0C00-$0FFF | One page for each bank--Subtract LSB of address from bank pointer |
| $1000-$13FF | User Bank 0 |
| $1000-$13FF | user Bank 1 |
| $1000-$13FF | User Bank 2 |
| $1000-$13FF | User Bank 3 |
Each of the three User Banks may be independently programmed to use any of the following modes:
- RAM/ROM read
- Read a specified address from RAM or ROM, in typical ordinary fashion
- RAM write
- Writes a specified address to RAM. Note that indexed writes are acceptable, even if they cross page boundaries within a bank. Reads will return arbitrary data, and a read which is followed by any address other than a page wrap will "accidentally" store arbitrary data. RAM writes will use the Simple-Fetch-and-Handle-Write state.
- Tethered read
- Like a normal read, except that the base address of bank 0 is added to the address for the current bank.
- Tethered write
- Like a normal write, except that the base address of bank 0 is added to the address for the current bank.
- Set Function Pointer
- Performs a RAM/ROM read, but also sets the 'Function Pointer' to the address accessed (in RAM or ROM).
- Byte Copy
- Storing a byte to a bank in Byte Copy mode will perform a block copy from the Function Pointer to the destination address. The number of bytes copied will be the value stored, plus one. This will use the Enter-Busy-State state; the system will be busy for approximately 2+(bytes/8) cycles. Reading a byte in a copy-mode bank may cause unpredictable behavior.
- Word Copy
- Word Copy mode is similar to Byte Copy mode, except that (1) the specified value is the number of 16-bit words to copy, minus one (instead of bytes), and (2) both source and destination addresses must be even. Words are copied at the same loop rate as bytes (so 2+(words/8) cycles).
- Longword Copy
- Longword Copy mode is similar to Byte Copy mode, except that (1) the specified value is the number of 32-bit longwords to copy, minus one (instead of bytes), and (2) both source and destination addresses must be multiples of four. Words are copied at the same loop rate as bytes (so 2+(longwords/8) cycles).
- Indirect Read
- A byte is read from RAM at the specified address, and the upper 7 bits are used to select an entry in a table of 128 16-bit addresses pointed to by the Function Pointer. The value at that address in RAM is then fetched and given to the 6507. If the original byte read was odd, the address in the table will be incremented. Code may be executed from a bank in this mode (indeed, that's the whole purpose!) provided that it does not perform any writes to the cartridge nor perform any bank switches.
Key bank-switch addresses:
- $0070 -- Set LSB of Function Pointer
- $0071 -- Set MSB of Function Pointer
- $007x -- (x>=4) Writing 'dd' acts like an access of $0xdd.
- $040x-$071x -- Set bank 0-3 to point to page 0-31 of RAM without affecting mode
- $042x-$073x -- Select specified mode for bank 0-3:
- Read
- Write
- Tethered read
- Tethered write
- Set Function Pointer
- Byte copy
- Word copy
- Longword copy
- Indirect read
- Read
- $044x-$075x -- Set bank 0-3 to point to specified RAM address and select read mode
- $0460-$076x -- Set bank 0-3 to point to specified RAM address and select write mode
- $0480-$07FF -- Set bank 0-3 to point to specified ROM address.
Note that any access to a bank-switch address will cause the following cart-space address to be performed in Simple-Fetch state.
