Matt Sarnoff's Amethyst

Hardware
1

Using an AVR microcontroller to generate NTSC video is nothing new; there are a zillion examples out there going back at least to 2004. (Edit: whoops, make that 2003.) But Matt Sarnoff has recently been working on a system he calls the Amethyst which seems like a pretty nice example of the genre: with an ATmega1284, a couple of multiplexers and a couple of shift registers he generates quite pleasing 160×200 graphics in 215 colours. And the AVR at the same time generates sound, scans a keyboard, and runs programs in Forth to do stuff with all of this I/O. (There’s also an FT320X thrown in so you don’t need a USB serial cable to talk to the AVR’s serial port.)

Now a good part of this isn’t all that retro (it’s a relatively modern CPU with a fair whack of C code running it), but still, it’s 8-bit and NTSC, with some pretty neat ideas and design, and at least a hint of Woz-like minimalism.

4 Likes
2

Very nice, and certainly fills a retro-shaped hole for many, I’m sure.

Video is a perennial difficulty, I think - you can see that in many threads on the 6502 forums. There are many ways to go, involving different tradeoffs and expressing different values.

My first machine, the Compukit, produced very basic character video but used only TTL. My second, Acorn’s Beeb, used both the 6845 display controller and a semicustom chip. Oh, and a teletext chip too! That’s a lot of transistors, only three chips, but rather complex chips. And even then, no sprites, no collision detection, no decent colours.

3

Well, the way I see it there are really two basic options these days.

One is to build up a traditional-style actual video circuit yourself. This could be based around a display controller such as the MC6845 or just consed up from 7400 logic the way Woz did it with the Apple II. Either way, you’re going to have to deal with getting your timings right, and that can be quite a bit of work.

The other is just to grab a modern chip and a video library for it: this could be a microcontroller such as an Amtel AVR or a Propeller, or an FPGA. There your only real issue is interfacing it to your CPU and memory, which is relatively simple in comparison to the first option. And these sometimes do provide sprites and the like as well.

(The Amethyst, despite being driven by an AVR, is really the first option rather than the second, since he designed the shift-register side and wrote the video library himself. Basically, he replaced the traditional hardware with the same thing done as software on a fast modern MCU.)

4

Retro computers were essentially video circuits that had a few spare cycles to dedicate to actual processing. Most of the 8-bit machines were effectively slaves to their video processing system, as the video processing dominated a large chunk of the overall design of system. That screen refresh rate was a very harsh task master, and the memory bandwidth on such small machines could be substantial.

5

I wonder if the design can be converted into a simple serial terminal, it looks like it has real keys compared to some UK computers.

6

No problem at all: the AVR has an async serial interface built-in. In this design it’s connected to an FT320X serial/USB converter, so that you can simply plug the microcomputer it into a PC via USB and see it come up as a serial device. It would be trivial to disconnect that and use TTL-level serial right off the board, or put a level converter on that to get proper RS-232 levels.

If you needed some of the RS-232 control pins as well (DTR, RTS, maybe DCD) you’d need to find another digital I/O pin or two somewhere. Maybe borrow them from the game controller ports.

Actually, while I’m not really a fan of using an AVR as the main CPU, the more I look at this design the more I like it. It does a great job for what it is, even if it’s not how I would build an SBC.

7

Is the power from the USB, looking at the photo?
Well I guess we will not be running CP/M on this.

8

Yes. You can use just a USB charger if you’re not connecting the serial port to a computer.

Well, no, but there are a lot of computers using retro CPUs and even retro computers themselves that you won’t be running CP/M on, because they use a 6502 or 6800-series processor instead of an 8080-compatible.

In fact, given that the CPU here is Amtel AVR, you won’t be running much assembly-level historical software on it at all. It does have a Forth interpreter (including editor, etc.) built in, though, and there’s a fair amount of Forth code out there in the retro-hacker community (The 6502.org Forum has an entire section dedicated to Forth, which is fairly active.)

There’s also no built-in mass storage beyond the microcontroller’s built-in 128 KB of flash memory (essentially, the “ROM” of the system). I assume his editor does let you save your own Forth screens to this (each screen probably being a 1 KB/so block) and let you run code directly from the Flash.

The system does have an SPI interface with four select lines and physical ports (the two .1" female headers on the back labeled “port 0/1” and the “game controller” ports on the side, which are actually just generic SPI), so it would be quite easy to attach an SD card reader/writer to the system. And of course, being AVR, there are already libraries out the wazoo for reading/writing files on the standard FAT filesystems used by SD cards.

All of the above is just what I gathered from the video and the schematic, along with reasonable guesses as to how the system design works based on that, so take it all with a grain of salt. It would be cool if someone wanted to do a more detailed analysis, or perhaps even breadboard up one of these systems. (I’ve got a couple of ATmega1284Ps myself, and even an diode-matrix keyboard salvaged from a TRS-80 Model III, but no '157s or '166s.)

Except for the CPU itself, I must admit I’m rather getting to like this little system. And it’s definitely giving me some design ideas for my Apple 1 clone.

9

It’s very nice!

I have done video from the ATmega in the past - I was originally going to use it on my Ruby6502 project, however my 320x240 pixel composite video display required some 65-70% of all CPU cycles to generate, so ultimately I did something else as that slowed down other functions I was using the ATmega for (serial and SD card)

It’s also worth nothing that a UK chap did a Forth based ‘Arduino’ type system a few years back too with PAL or NTSC video output - just monochrome though - his keyboard was a somewhat novel design too:

-Gordon

2 Likes
10

Back in 2003 I designed a terminal for truck drivers using an ATMega chip. One limitation was that it couldn’t programs its own Flash memory but needed an external device for that. It did have 4KB of EEPROM you could save data to. At that time the chip was $30 and I ended up redesigning it with an FPGA, 8MB SDRAM, 256KB Flash and a CPLD which added up to $15 (as seen in this picture). Now the Flash could be used for mass storage.

In the Amethyst you can have a serial connection to a PC via the USB power port and the PC can reprogram the Flash. So with the help of a suitable program on the PC it could use the internal Flash for mass storage as well. But if you have that PC anyway you might as well save things to the PC’s disks instead.

1 Like
11

That limitation has long been removed from ATMega chips. The Arduino ecosystem is based around AVR MPUs being able to program themselves. Part of the flash is (optionally) reserved for a “bootloader” that can talk over the serial port and take programming instructions; there are fairly standard and well-known protocols for this.

The Amethyst is almost certainly reprogramming its own flash to do things like save a Forth source code screen or compiled words.

12

Thanks for the information! Even with the Harvard architecture I didn’t see any good reason back then to not allow internal programming. I see that this was only the case for the ATMega103 (which was the only one available in 2001 when I built the first prototype) and by 2002 there were a bunch of other models, all of which allowed self-programming.