Differences

This shows you the differences between two versions of the page.

--- pinouts [2021/05/13 23:04] – [Smart Keyboard (Clavier Tip Tap)] 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.
   * 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:
-  * What is the max capacity? Since we have 2 bits (ROM_CSB1 and ROM_CSB2), can we fully control them individually and address 3 different spaces of 22bit each?
+  * 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?
-  * 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.
 ==== Battery backup cartridge ====
@@ Line 81: / Line 80: @@
 ===== 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 sends a byte, RTS goes low first, then it waits for CTS to be up. Then RTS goes up and sends its byte. Finally CTS goes low again.
+A controller is activated (both for transmission and reception) by setting its CTS pin high. Controllers can request attention from the console when they have data to send using their RTS line.
-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 corresponding CTS high
+  * 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 last byte from the UART
+  * 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 =====