An impression of the board, using a header for RGB connection
I've expanded my simple schematic of the Mega88-system to include the PS/2 keyboard controller (the ATTiny13 in the topleft)
and an optional EEPROM program memory (the 24C64 in the topright).
Also added to this schematic is a joystick-port compatible with Commodore 64 joysticks.
The 2 unconnected pins of the subminiature DB9 connector (pins 5 & 9) are reserved for paddles, and could later on be connected to the ADC6 and ADC7 extra pins of the ATMega88-TQFP package.
Pins 2 and 3 of the Tiny13 (inputs PB3 & PB4) are to be connected to the PS/2 connector as described earlier
with optional capacitors to VCC to lengthen the periods a little and reduce errors due to static (i found 220pF caps to be adequate).
I left PD0 and PD1 intentionally unconnected for use as RS232 interface (RXD and TXD are located on these pins).
PB5 outputs the dot-clock and should be left unconnected if the dotclock signal is not required.
PB1, PB2, PB3, as well as PD2 can be used for general I/O.
November 5, 2007
A difficult task is now waiting for me: to enhance my keyboard interface software to handle all special keys.
But before starting on that, i think i should already look out for the next goal;
although writing key handling code could take a while, it won't be as unpredictable as the last goal and i'm expecting to finish it within a few weeks
(i won't write it all at once, i'll stick to cursor keys, home and backspace for now).
I think the next goal should be something fun, like a simple game.
Something that can be run on a small text-mode microcontroller.
How about a game that has never been done before with a controller (*cough*): Tetris!
I had been thinking about Pong, but the problem is: how can i make it beatable, without making it stupid looking?
.. anyway.. Tetris it is!
I've also tackled a bug in the PAL interrupt causing the scanlines to randomly jump 1 or 2 pixels to the left and right.
This was creating an annoying visible effect and i had known for a while it was caused by the fact that an interrupt on an AVR controller occurs at the end of an instruction.
And, of cource, sometimes the PAL SYNC interrupt occurs smack in the middle of an instruction.
When the Atmel then waits for the instruction to end, the timing is off by 2 or even more clockcycles, depending on the instruction & interrupt timing.
To solve it, i added a second timing interrupt that would just wait long enough for the main SYNC interrupt to start.
Then when the SYNC interrupt returns, the first interrupt handling will continue and timing doesn't really matter much at that point.
