• Please review our updated Terms and Rules here

completed hardware for my homebrew 8-bit

C

carangil

Experienced Member
Joined
Jun 3, 2009
Messages
285
Location
Oakland, CA
Over the last 13 months or so, I've been working sporatically on a homebrew 8-bit build. I finally got all my hardware to play nice with each other. I need to put it in a box and put up picture online, but these are the current specs:

  1. 20 mhz AVR atmega 644 cpu (20 mips, 64k flash, 4k ram)
  2. 128k external sram in two banks of 64k
  3. vga output, 64 colors at 256x240 or 512x240
  4. sd card (tested with 1gb card, theroetical to 4gb, no sdhc support)
  5. rs232 tested at 115kbps
  6. 8-bit pcm audio, ~ 10khz
  7. ps/2 keyboard

It took forever to get things to play nice. Some keyboards didn't work Typing glitched the screen. Sound garbled the keyboard. Reading the sd card blanks the screen. Ugh. Technically reading the sd card still blanks 10 pixel rows of the screen: If I'm playing music from the card (like for the background of a game or something), I can live with 10 lines being blank. It is much better then the zx81's tape loader!

The AVR has the limitation of not running instructions from RAM. Flash only. But it also has self-programming ability, and you can delete and reprogram single pages as needed. There are some loaders that reflash the whole thing from ram/sdcard, and even though you can do this 10's of thousands of times, I don't want to wear the chip excessively. So for the OS, I'm thinking:

  • all critical (disk, sprite graphics, comm) in native code flash
  • VM interpreter for user programs. Runs them from ram.
  • User programs could install a small native-code routines in an unused pages of flash memory. The OS will track what routines are installed and where.
  • I hope that over time, the need to install native-code pages will diminish (as I figure out what common things need to be done fast), and many new programs can be written without wearing the flash at all.
 
Any reason for the 644, and not, say, the 162 or 128, which allow direct addressing of external RAM?

If you prefer von Neumann architecture, there are plenty MCU choices for that as well.
 
I chose the AVR for a few reasons:

  • I definitely wanted an MCU as opposed to a raw microprocessor, since boot flash and a modest bit of ram give a working base system immediately.
  • Huge community, lots of libraries and 'arduino' things I can run on here.
  • The AVR competitor (PIC) are typically 4 clocks per instruction. AVR can go 1 instruction per clock for most of the simple ones. Apart from that, PIC and AVR have similar limitations (harvard arch, etc)


I chose the 644 over the 128 for a few reasons:

  • '644 runs at 20Mhz officially; the external bus ones do not
  • I have complete control over the bus. For instance, the external AVR memory bus latches the low part of the address, then outputs the high part while read/writing. Instead I latch the high part when switching pages; when staying in the same page I merely output the low part of the address followed by read of the data bus. I can read 1 byte from external ram in 2 clocks; it takes 3 clocks when using the official memory interface AND I can run at 20 mhz instead of 16. I kind of think the AVR external memory bus was sort of half thought through.
  • I am bit-banging the VGA signal by updating the address lines and dumping the video through a DAC. Cpu doesn't really read the data; it just scans through it, sort of like a zx80. The maximum rate is once per 2 clocks, so 10Mhz pixel clock. This gives 256 pixels across. This type of fast scan isn't possible when using the real external memory interface. Also, the port I'm using for the address bus has a few hardware functions. I can actually have the timer hardware toggle a pin faster than I can write addresses, resulting in the address changing twice as often as I'm writing to it. Think of it as I'm only writing even addresses that are on the bus for 2 clocks cycles, but every other clock cycle the LSB bit flips automatically. You get all the odd addresses for free. As a result I can output a pixel clock of 20Mhz, giving me 512 pixels across.

Someday I'll probably do another microcomputer project, and then I can use a more proper cpu. Any recommendations?
 
Fun stuff! I've been really intrigued by the idea of a VM-oriented system lately (been reading about Smalltalk and the Alto) - I'd be interested to hear about how your project to get the native code down to a minimum goes.
 
carangil said:
Someday I'll probably do another microcomputer project, and then I can use a more proper cpu. Any recommendations?
Click to expand...

I wouldn't necessarily call any CPU improper. But, 65816. I'm biased, I just like the 6502, but would recommend the '816 over that for you. Otherwise, TMS9900, for obscurity's sake.
 
Depends. Both ARM and PC32 are good choices. PIC32 is basically the MIPS R4000 re-done as an MCU--and I think there's a port of LInux for it. ARM comes in so many flavors, it'd be difficult to list them all--but I really like the ST Micro STM32 ARN Cortex chips cheap and lots of choices. TI makes some cute development kits for their MSP430 CPUs--I think you can still get the wristwatch one. Most of the PIC32s run at 80MHz (that's 32-bit) and the STM32s run at 72MHz.

If you want to go off the beaten path a bit, you can try some of the Cypress PSoC chips--an ARM MCU with a CPLD integrated into it. They used to be hugely expensive (ca. $10 each), but prices have come down considerably.

If you want to go way off the beaten path, try a Parallax Propeller chip.

Almost too many choices. One of the VCF members here did an XT emulator in a souped-up 8052.
 
I did consider the propeller before I picked the 644. My issues with the propeller, was it seemed too much of it was done for me. There's a library for vga out. It has 32k of ram. That's already 'ok' for the kind of machine I wanted to make. But with the atmega, I had to expand my ram, figure out the vga patterns, figure out how to read the sd card without blacking the screen, etc. It's quite a challenge.

The AVR32 might be the next logical step, since it's a 32-bit microcontroller, runs at higher speeds (60 mhz), and has an external ram bus. But its also surface mount, and the x-bus versions start at like 144 pins. The I could do the 48 pin surface mount version (with like a schmartboard or something), take advantage of its ability to run code from its internal sram, and just bit-bang my own memory for data/graphics like I do with the atmega.

But first things first, I need to write the OS for the thing I have now. I've start re-orging my code into a new project file. So far both the keyboard and the serial port are 'chardevice' and the sd card will be the next device class, blockdevice. I can even set the baud rate of the serial port with an 'ioctl.' I feel like I'm writing my own unix or something.
 
Before I started, I was open to a lot of different ideas, but there were a few criteria that steered my initial decisions:

I wanted to make a 'true computer.' I've played with single board computers where you plug into a serial port, stuff like that. I wanted to just plug in a standard ps/2 keyboard, plug in a VGA monitor, turn it on, have it act like a computer.

mcu over mpu: Mcu has integrated flash and small amount of RAM, getting the minimal base system working very easily. most (probably all modern ones) have rs232 built in, so your base system is the chip , a clock, and a max232. Just a matter of choosing a chip. I wanted something with lots of examples and support, and good performance. It basically came down to AVR vs PIC. AVR has faster performance for the same clock, so I went with that. This project http://www.lucidscience.com/pro-vga%20video%20generator-1.aspx and this one http://belogic.com/uzebox/ show me what kind of stuff the AVR is capable of, and I came to the conclusion that to do the same with a PIC would take a PIC32. I wanted to keep 8-bit if possible.

memory: I originally wanted 64k, but I happened to have a 128k chip. I have the last pin tied to ground for about a week before I decided I couldn't just not use half the chip. I didn't want to use 3 8-bit ports (hi addr, lowaddr, data), so I decided to have an 8 bit address bus, and 8 bit data bus, and latch the high part of the address. Most reads/writes are sequential in nature (drawing a sprite, scanning a line of vga, etc), so there's almost no penalty for the latch, except in the case of completely random access.

sdcard: This was an easy choice. Large storage space (1gb is huge to a 8-bit machine), serial protocol with no minimum clock speed, removable. Considered CF card or laptop PATA drive: too complicated, too many wires. SATA is serial, but minimum speed is too slow. Considered serial eeprom: not removable. USB key: serial, but too complicated for AVR, also too fast a minimum speed. SDCARD can be removed and put in a PC for easy transfer of lots of files.

VGA: I didn't want to deal with a composite screen (tv), didn't want to use a custom LCD or be limited to a simple text-only serial LCD. Choose bit-bang VGA, alternative was to use a vga driver module, but it was more costly and 'less interesting.' That, and both the Lucid Science and the Veronica project showed how well it can work. ( http://quinndunki.com/blondihacks/?p=1154 )

ps/2 keyboard: ubiquitous, easy protocol, usb is just too heavy. most usb keybord also talk ps/2 anyway.

audio: originally I wanted to use a real DAC. I tried PWM w/ smoothing capacitor and it sounded fine, so I abandoned the DAC. I actually have a test program that reads the serial port at 115kbps (comes out to 11.5 khz) and puts in the in pwm buffer. On my linux PC if I cat a wave file, it plays great!
 
You must log in or register to reply here.
Back
Top