Changes between Initial Version and Version 1 of microserial

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



  • microserial

    v1 v1  
     1= Introduction =
     2The Amstrad CPC is a great computer, but it lacks a serial port.
     3Why 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.
     5There 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.
     7However, 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.
     9This project is about making a new design. Everything will be open sourced so everyone can help and improve.
     11= Specifications =
     12Here is what th card should be able to do :
     13 * Use only 2 addresses in the computer I/O space, as there is already quite a lot of things there
     14 * Serial port with either polling mode or interrupt generation
     15 * Timer with interrupt generation
     16 * Firmware upgrade from serial port, with a 'write enable' jumper to avoid problems
     17 * on board LED
     19= The hardware =
     20The 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.
     22there 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.
     24= The firmware =
     25This is the most tricky part of this system.
     27When 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 !
     29This has the following consequences on the code :
     30 * 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.
     31 * there is no time to do complex computations, the interrupt must just read or write a value. Everything else is done later.
     33As 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 !
     34It 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.
     36== Interrupt forwarding ==
     37When 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.
     38As 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.
     40= Software =
     41As 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.
     43The 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.
     45The ROM will include at least :
     46 * GETBYTE and PUTBYTE for serial
     47 * SERSPEED
     48 * Timer functions (to be determined)
     49 * SERMODE (polling or interrupt)
     50 * LED for using the debug led
     51 * maybe other things
     53At init it will :
     54 * set the card to sane values
     55 * test if the card isinfirmware upgrade mode and displayawarning message if so (in this case the board will not react to normal commands)
     56 * show a nice welcome message