It’s been a while since I worked on Orwell. I need to get back into doing my Usborne book reviews, especially since I finally found the last book I was missing on eBay and that should be on it’s way.
A recent off topic post on 6502.org mentioned the upcoming Star Wars films. Personally I don’t hold up much hope for them to be honest (if the last ‘new’ Star Wars films were anything to go by) and mentioned that the original is still the best, especially my own special version of course.
I started thinking it would be very nice to be able to play that on Orwell. Unfortunately, with it’s 38 character wide display, that wasn’t going to work too well since my Asciimation is 67 characters wide. To make it work I would need to update the display.
It turns out that a chap called Grant Searle has built, on top of existing work around AVR video output, a video unit and a serial/keyboard controller that will output 80 column text as well as provide a simple graphics mode using an ATmega 328 chip. This is the same microcontroller used in the Arduino.
Theoretically I can take this and just use the video part as a new display module for Orwell. It wouldn’t take much of a hardware change and then I just need to add new software routines to replace the existing ones and finally add support for graphics.
Currently, you will remember, I am using the Batsocks Telemate as my video output device. This also uses an ATmega microcontroller. That is being driven via the serial port (which on Orwell does double duty as a serial port and display driver.
Grant’s video module supports multiple ways to drive it, 8 bit, 4 bit or 2 bit (I2C) interfacing. On Orwell I should have enough bits free on the VIA I am using to do the keyboard scanning and beeper to drive the 4 bit interface. First though I need to get the interface built and working. That turned out to be a bit of a mission!
First up the hardware. This is very simple. I don’t have on hand any 74HCT166 chips though so those are now ordered from RS and should arrive tomorrow I hope. In the meantime I looked at getting the software working.
Grant has provided the source code and the assembled hex file for his interface which is very handy. All you need to do is burn the hex code into the ATmega328 and burn the appropriate fuses. Now burning the microcontroller is easy if you have a programmer. I don’t. You can however use an Arduino to act as one. The code to do this is even included in the IDE as a sample.
First you install the ArduinoISP sketch to the Arduino board you are going to use as your programmer. You then use another tool, called avrdude.exe, to use that Arduino to burn another ATmega chip with the code for the video display. The Arduino IDE already includes the tool in the \hardware\tools\avr\bin folder.
To be able to use the tool I added \hardware\tools\avr\bin and \hardware\tools\avr\etc to my PATH environment variable so I could call it from the command line. The \etc directory is needed since that contains a file called avrdude.conf that the tool requires.
The Arduino with the ArduinoISP sketch running is connected to a breadboard with the device that needs to be programmed. That device needs minimal external components, mainly the clock crystal and capacitors. It helps to wire in the three indicator LEDs to the ArduinoISP board too so you can see that it’s alive, downloading or has an error. I also had to use the 10uF capacitor reset hack to make things work.
Ratehr than just downloading the hex file Grant supplies I wanted to see how the code works and assemble it myself. To do that you can install the free AVRStudio6 software from Atmel. With that installed I was able assemble Grant’s source code to produce the hex files myself.
Now to get the file on the ATmega328 you need to connect up the ArduinoISP as described on this page and then use avrdude.exe to download it to the chip. Avrdude has a fair few command line parameters you need to use but when you look at them one by one isn’t not too difficult. The documentation for the arguments is here. You can do it all from the command line but I found it easier to configure an external tool in the AVRStudio IDE. This IDE is using the Microsoft Visual Studio IDE isolated shell which means if you know Visual Studio AVRStudio should be quite familiar.
I added an external tool for calling avrdude.exe to download the main code and set the fuses on the microcontroller. You should note on Grant’s page that the fuse setup is particular for his video controller.
The arguments I used for the tool are:
-p m328p -P com3 -c arduino -b 19200 -U flash:w:”$(ProjectDir)Debug\$(ItemFileName).hex”:i -U lfuse:w:0xe6:m -U hfuse:w:0xd9:m -U efuse:w:0x07:m -u
- -p m328P sets the device type.
- -P com3 sets the serial port the Arduino is connected to.
- -c arduino sets the programmer type.
- -b sets the baud rate.
- -U means a memory operation.
- flash means burn to the main flash ROM memory.
- w means read the specified file and write it to the specified device memory.
- “$(ProjectDir)Debug\$(ItemFileName).hex” is the path and directory to the hex file.
- i means the file is in Intel hex format.
The further -U commands are to write the fuses, lfuse, hfuse and efuse.
If you want to know about fuse bits this tutorial explains it well. The fuse values are specified in hex and there is an online fuse calculator tool available here.
One little quirk I found was the fuse generator tool was give me back a value of 0xff for the efuse. If you try using that value you will get an error in AVRStudio when you run the avrdude tool:
avrdude.exe: reading input file "0xff" avrdude.exe: writing efuse (1 bytes):
Writing | ***failed; ################################################## | 100% 0.16s
avrdude.exe: 1 bytes of efuse written avrdude.exe: verifying efuse memory against 0xff: avrdude.exe: load data efuse data from input file 0xff: avrdude.exe: input file 0xff contains 1 bytes avrdude.exe: reading on-chip efuse data:
Reading | ################################################## | 100% 0.02s
avrdude.exe: verifying ... avrdude.exe: verification error, first mismatch at byte 0x0000 0xff != 0x07
It took me awhile of looking to work that one out. It turns out that on the 328P chip only the bottom three bits of the efuse flag can be used. You can write to it fine but when you read it back the top 5 bits will always read back as 0. So we try to write 0xff and we get back 0x07 since only the bottom three bits have been changed. The bits have been changed, it’s just the avrdude tool complaining since the verify failed. But if you want to get rid of the error the solution is to write 0x07 to the fuse.
Once all that is done I was able to modify, assemble then burn the code to the ATmega chip. Phew!
To test that everything works you need to then control the chip. On Grant’s page he used yet another ATmega as a keyboard/serial port controller. However another chap called Dave Curran has written some code that uses an Arduino to drive the video board. That is all described on his blog here.
He provides the Arduino library code and several example of driving the video board. It is a simple matter to upload the appropriate sketch to the Arduino then use that to control the video board.
Now, at this point you’re probably totally confused. I was. It’s bloody ATmegas all over the place! But this should help:
Right, what we have here as my bench test setup is as follows. The top Arduino is my ArduinoISP acting as a programmer. Beneath that on the breadboard is where you plug in the ATmega328 chip to program with the video driver code.
Once programmed that then moves to the left of the breadboard which is the video board hardware section. Missing to the far left is the shift register chip. The yellow and black wires go to the video-in on the tiny LCD monitor I am using as a display.
The bottom Arduino is being used to drive the video hardware via a four bit interface (with two control lines) via the rainbow ribbon cable. That Arduino has one of Dave’s example sketches loaded on it.
Once my 74HCT166s arrive I should be able to finish breadboarding the video board then just fire it up to see if it works. Assuming it all works I can then take just the video section, build it up on Veroboard and connect it to Orwell to see if I can drive it that way. That will require a minimal hardware mod, basically adding a new header to break out the appropriate pins on the existing VIA. I have just enough data lines free on Port B, B3..B6, and should be able to use CB1 and CB2 as the control lines I hope. I already have a 6 pin header going to the Batsocks. I can rewire that and add another 2 pin header for power. As it is now the video processor will be on it’s own, small board so it can be easily changed at a later date.
That will free up the serial port for just serial use (loading and saving). Theoretically, apart from some configuration changes, I only need to change one routine in the Orwell code to work with the new video display. Graphics can be added later.
I will see if anything works when the final missing chip arrives!