PAL color video with Atmel controllers

October 2, 2007

It looks like i'm close to the goal set out a few days ago. Time to make a new goal!

Having a PAL-system is nice, but it would be great if i can actually DO something with it. If i want to enter information into the system, i'd need some way of sending it to the controller. The first choice would be RS232, and sending stuff from a PC through a serial cable.
So, why not use the same peripherals as with my scrolling led matrix: an RS232 with an optional PS/2-to-RS232 interface to turn this into a Teletext/TextTV system.

First things first: the keyboard interface.
I've looked up the PS/2 interface from my scroller project and moved the connections to other ports. I've used the ATTiny13 as my keyboard controller. It has a massive 1kB flash in which i can store a decoding program, as well as a serial output routine. I even have 1 unused pin..

This has got to be the smallest PS/2 interface ever: it fits on a 22x17 mm pcb, including the PS/2 connector! The program was written for a Tiny2313, using the USART for sending the keyboard ASCII-codes out, so this has to be rewritten since the Tiny13 doesn't have a USART.

I'm still debating over what protocol i should use. I could go for a software generated I涎, but when connecting it to the bus system (together with the planned I涎 EEPROM) it needs to be configured as a slave device. No problem on this end, because the Tiny13 also has 64 bytes of SRAM at its disposal for keystroke buffering (minus a few bytes for stack). The problem is at the other end, where the main microcontroller will be very busy updating the PAL screen, and also has to poll the I涎 bus to see if there are any keystrokes buffered.

The other option is to use PB2 to signal "data in buffer" by pulling it low. This requires an extra I/O port on the master controller - also something i don't like.. i may find myself out of I/O lines later on in the project.

Hmm... one final option: don't use a seperate microcontroller for PS/2 decoding and buffering, but let the main controller do it.
Well, i guess this has both disadvantages in one little package (with a nice ribbon around it): decoding takes time, and it requires not one, but 2 extra I/O lines, since the inputs are not compatible with any other protocol. They will need their own dedicated I/O ports.

I'll go for option #1. That way, i can let the main controller choose how many buffered characters it will digest each time it gets around to calling the Tiny13, which will be 50 times per second (during vertical retrace). Also, it does not require extra I/O lines and i preserve as many as possible.

October 4, 2007

I've successfully tested my modified keyboard controller yesterday and repositioned the ports, so i have a PWM output available on PORT B.1 to connect a speaker. The speaker is optional and will make clicks or short beeps when pressing a key. I could also have the main controller send command codes to initiate an error beep. All in good time.. first finish my keyboard controller by adding code to understand the controlcodes like SHIFT, ALT, CAPSLOCK, etc...

I've also updated my existing Mega88 code to include a blinking cursor a la C64. I brought the screen resolution back to 32x24 characters, taking up 768 bytes of SRAM, leaving 256 bytes for variables. Some space has already been taken up by cursor position and the blinking counter but it leaves more SRAM for data. It also helps keeping the program smaller, because the X and Y position on the screen can now be calculated more easily.

The software I涎 has also been included into the project, but i may use the hardware I涎 since i specificly kept the SDA and SCL pins unused so far.

October 6, 2007

How difficult can it be to have 2 devices communicate through I涎? I've been working on it since last night, but the two Atmels just don't seem to like each other. I've written 2 routines: the main micro (the ATMega88) runs at 16MHz, and the keyboard microcontroller (the ATTiny13) runs at 9.6MHz internal RC oscillator and both have their own routines. I found out it can be rather difficult to track down signal problems if you don't have an oscilloscope handy but i managed to get some signals going. Turned out to be a timing problem, since the Mega88 runs a lot faster than the Tiny13. In addition, it takes more instructions to read from the I涎 bus than to write to it the ATTiny just wasn't fast enough.

October 14, 2007

It's been a busy week! But i spent some time on this project over the weekend and i have rewritten the software to use the hardware I涎 interface instead. So far, the signal does arrive at the Tiny13 intact, but i'm not certain it responds in time for the Mega88 to pick up the ACK signal. I will have to schedule some extra time next weekend to fix this problem once and for all.

October 19, 2007

With the help of Atmels Application Note AVR302 i managed to connect the 2 micros using the I涎 protocol. I first tested it at 200kHz only, since the Tiny13 runs at only 9.6MHz and wasn't able to keep up at certain times with the 400kHz fullspeed. I've optimized the code a bit still, and got it to run fine at fullspeed: it now runs on 400kHz full I涎 speed!
This means i can access my external EEPROM at full speed too when i add it to the project later, which in turn will double efficiency when it comes to executing whatever is stored in the EEPROM.

The initial test has it send code $41 (an ASCII 'A' character) on every request, so my screen fills up quickly with A's before crashing, when it overwrites the stack RAM.
Reading a byte from the keyboard controller takes up 1 scanline (the black line in the bottom border, roughly 64盜 wide) but the actual handling of the byte is much faster, since i'm now using the hardware I涎 and transfers occur while the microcontroller can do other tasks.

Character set