Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revisionLast revisionBoth sides next revision | ||
pinouts [2021/03/12 20:26] – [V.Smile cartridges] pulkomandy | pinouts [2021/09/23 22:56] – [Flow control] Document it a bit more clearly pulkomandy | ||
---|---|---|---|
Line 21: | Line 21: | ||
* Sense is connected to VDD to indicate that a cart is inserted. It is connected to the RESET pin, so inserting a cartridge will power the console off. | * Sense is connected to VDD to indicate that a cart is inserted. It is connected to the RESET pin, so inserting a cartridge will power the console off. | ||
* Card detect is connected to VDD to indicate that a cart with ROM is inserted (?) maybe it allows booting from cartridge instead of internal ROM (tbc) | * Card detect is connected to VDD to indicate that a cart with ROM is inserted (?) maybe it allows booting from cartridge instead of internal ROM (tbc) | ||
- | * ROM CSB1, ROM CSB2 and RAM CSB allow to select which bank of the cartridge is accessed. Typically cartridges use only ROM CSB1, but larger cartridges (example: alphabet adventure) need two ROM banks. ROM_CSB2 may also be used for battery-backed SRAM. | + | * ROM CSB1, ROM CSB2 and RAM CSB allow to select which bank of the cartridge is accessed. Typically cartridges use only ROM CSB1, but larger cartridges (example: alphabet adventure) need two ROM banks. ROM_CSB2 may also be used for battery-backed SRAM. The two pins are controlled independently as GPIO from the CPU, so all 4 combinations are possible. However, 11 will be used when the internal ROM is accessed, so it's better to have the cartridge idle in that case. |
To be confirmed: | To be confirmed: | ||
- | | + | * What is RAM_CSB? It is not connected on the only cart known to use SRAM. The name of the pin comes from schematics of the console but it just shows that it is connected to the SPG200C without any other info. SPCE1600 datasheet shows it would be usable for external RAM, where in the address space would it be mapped in that case? |
- | | + | |
==== Battery backup cartridge ==== | ==== Battery backup cartridge ==== | ||
Line 38: | Line 37: | ||
The blob is flash (as usual) and the chip on the right is RAM: BSI - [[https:// | The blob is flash (as usual) and the chip on the right is RAM: BSI - [[https:// | ||
- | FIXME The pin labelled RAM_CSB in the pinout above is in fact not used by this cartridge (but ROM_CSB2 is) | + | The pin labelled RAM_CSB in the pinout above is in fact not used by this cartridge (but ROM_CSB2 is) |
+ | |||
+ | ==== Dual ROM cartridges ==== | ||
+ | |||
+ | At least the following games have two blobs on ROM_CSB1 and ROM_CSB2: | ||
+ | |||
+ | * The little mermaid | ||
+ | * Smart keyboard | ||
+ | * Alphabet adventure | ||
===== Nitro Vision / Genius TV progress cartridges ===== | ===== Nitro Vision / Genius TV progress cartridges ===== | ||
Line 68: | Line 75: | ||
- RTS (from controller) | - RTS (from controller) | ||
+ | {{ : | ||
+ | {{ :: | ||
===== Flow control ===== | ===== Flow control ===== | ||
- | When the console sends a byte, first CTS goes high, then the console sends the bits on the Tx line. When done, CTS goes low again. | + | The CPU has a single UART that is used to communicate with both controllers. This requires flow control to make sure the two controllers don't try to communicate at the same time. |
- | When the controller | + | A controller |
- | If there are multiple bytes to send, RTS remains down until the start of the last byte. | + | The general way to handle this is as follows, starting from an idle state with all CTS low and no pending data transfers |
+ | |||
+ | * If a controller has its RTS pin low, select it by setting | ||
+ | * The controller will start transmitting data, receive that from the Rx register until "Rx ready" is cleared | ||
+ | * If needed, send a reply to the controller | ||
+ | * Make sure the reply is completely sent ("Tx buffer empty" in status register) | ||
+ | * Wait until RTS goes high (the controller has nothing to send anymore) | ||
+ | * Put CTS low again | ||
+ | * Wait a little (in case the controller was sending something just as you set CTS low) and read a possible | ||
+ | * You are back to idle state | ||
+ | |||
+ | It is possible to send something to a controller even if it was not requesting RTS: | ||
+ | |||
+ | * Select the controller by setting the corresponding CTS high | ||
+ | * Send data to the controller | ||
+ | * Make sure the reply is completely sent ("Tx buffer empty" in status register) | ||
+ | * Check that RTS did not become low | ||
+ | * Put CTS high again | ||
+ | * Back to idle state | ||
+ | |||
+ | The controller keeps RTS down as long as it has more bytes to send. | ||
===== Messages from the controller ===== | ===== Messages from the controller ===== | ||
Line 159: | Line 188: | ||
* Down: 70 8F | * Down: 70 8F | ||
* Up: 70 87 | * Up: 70 87 | ||
+ | |||
+ | Boot sequence: | ||
+ | |||
+ | * Keyboard sends 52 52 52 | ||
+ | * Console sends 0x02 0x02 0xE6 0xD6 0x60 | ||
+ | * Keyboard sends language code | ||
+ | * Console: 0x70 | ||
+ | * Keyboard: 0xBA | ||
+ | |||
+ | The language codes: | ||
+ | |||
+ | * 0x40: US | ||
+ | * 0x41: UK | ||
+ | * 0x42: French | ||
+ | * 0x44: German | ||
===== Commands from the console ===== | ===== Commands from the console ===== | ||