Changes between Initial Version and Version 1 of microserial

Timestamp:

Oct 29, 2010, 4:58:43 PM (13 years ago)

Author:

pulkomandy

Comment:

--

microserial

@@ +1 @@
+= Introduction =
+The Amstrad CPC is a great computer, but it lacks a serial port.
+Why should it have one ? The serial port can be used as an easy mean to transfer file, do remote debugging, or use a more modern computer as a mass storage device.
+
+There were commercially available interface, most of them using a z80 PIO or anoter USART device. More recently, the CPCBooster gained some attention and was used by some demosceners.
+
+However, the old interfaces are hard to find, and so are the chips used to build newer ones. The CPCBooster is big and bulky, and it has some annoying bugs leading to the firmware commiting suicide.
+
+This project is about making a new design. Everything will be open sourced so everyone can help and improve.
+
+= Specifications =
+Here is what th card should be able to do :
+ * Use only 2 addresses in the computer I/O space, as there is already quite a lot of things there
+ * Serial port with either polling mode or interrupt generation
+ * Timer with interrupt generation
+ * Firmware upgrade from serial port, with a 'write enable' jumper to avoid problems
+ * on board LED
+
+= The hardware =
+The card is built around an attiny2313. This chip provide the serial port, the timer, and handles part of the communication on the z80 bus. It is however, too slow to handle everything. The I/O decoding is done externally with diodes and NOR gates.
+
+there will be two versions of the card : one witha MAX232 outputting serial data on an RS232 standard port (DB9 connector, 12/-12V signalling). The other version will use an FT232BM chip and provide an USB port on-board for easy connection with a PC. It will behave as a serial port so there is no structural difference, however this version of the card can't be used to plug a serial device to a CPC, nor to connect two CPCs in a small network.
+
+= The firmware =
+This is the most tricky part of this system.
+
+When the CPC makes a request to the card, the microcontroller is interrupted and must answer on the bus really quick. We have 3 z80 cycles to react. With a 20MHz crystal on board, this means we have 15 clock cycles to handle the request. As it is handled as an interrupt, we have 10 cycles used up in interrupt handling and only 5 left for our own code !
+
+This has the following consequences on the code :
+ * there is no time to save registers and restore them in the interrupt handler. So it must keep its wn register that no other part of the code will use. This means all code must be written in AVR assembly.
+ * there is no time to do complex computations, the interrupt must just read or write a value. Everything else is done later.
+
+As there are only 128 bytes of RAM in the microcontroller, we must be careful about variables. Having a table of registers stored in RAM is out of the question. So, the best solution is to expose directly the hardware registers ofthe ATTiny. This means you can mess with the I/O ports and create bus conflicts by wrong programming !
+It also means you can read the attiny doc and knowhowto program the card immediately. And it also allows touse all the attiny power from the z80without having to alter the firmware each time youwant something different.
+
+== Interrupt forwarding ==
+When there is an interrupt on the attiny, it will be able to trigger an interrupt on the z80 side for proper handling. There is an interrupt mask register and interrupt status so everything else can be handled by the z80. Only exception is the INT0 and INT1 interrupts as these are used for handling the z80 bus communication. don't try to disable them or the card will not answer you anymore.
+As reading and writing to the board alter the interrupt state, a backup of the interrupt status may be needed, so the CPC can know which interrupt hapenned.
+
+= Software =
+As the firmware will provide low-level stuff only, the software will have to do more work. For serial this is not too much : one reg for sending and receiving data, one for setting the baudrate and one or two for setting up interrupts. As there is no hardware flow control, a buffer may be needed, this would rather be done in hardware, even if the buffer is small. This is particularly important in polling mode if we want to use high baudrates.
+
+The software will be provided as a ROM to put on your ramcard or similar device ; a floppy version may be done but I'm not sure that's useful. As it will be opensource everyone will be welcome to improve the ROM and add newfunctions to it.
+
+The ROM will include at least :
+ * GETBYTE and PUTBYTE for serial
+ * SERSPEED
+ * Timer functions (to be determined)
+ * SERMODE (polling or interrupt)
+ * LED for using the debug led
+ * maybe other things
+
+At init it will :
+ * set the card to sane values
+ * test if the card isinfirmware upgrade mode and displayawarning message if so (in this case the board will not react to normal commands)
+ * show a nice welcome message