Designing the RhoCoCo Retro Home COlor COmputer hardware

From RevSpace
Revision as of 12:05, 28 April 2017 by Mahjongg (talk | contribs) (April 25 Started building up the prototype)
Jump to navigation Jump to search
Project Rhococo Retro Home COlor COmputer
Rhococco concept art.png
A brand new 8-bit homecomputer with modern parts. Above picture is just an artist impression, its probably no how it will look.
Status Initializing
Contact Mahjongg
Last Update 2017-04-28

Less is more, less complexity, more fun is the driving force behind the Rhococo Retro Home COlor Computer. It will be a remake home-computer inspired on, but not compatible with, the Sinclair spectrum, Initially I considered not basing it on a Z80, but on an ARM7TDMI based simple micro-controller, (probably an STR710FZ2) running at 66MHz with 256 + 16 KB internal fast Flash and with 64K internal fast RAM and a separate external 32K VRAM. But early 2017 I changed my mind, as you can read below.

The idea behind it is bringing back a new homecomputer as it was popular in the 80's, but build with modern components.

It will be capable of 320x200 VGA full high resolution graphics 16 colour display (Mode "D" timings, 70Hz, Horizontal Sync = 31.778 KHz, pixel clock 25.175 MHz). Or perhaps PAL color, I'm not sure yet.

To be able to keep the design simple, but still able to be drive a VGA monitor, I chose to support only the lowest VGA resolution of 320 x 200 with 16 colours. It means we only need to have, (and manipulate) a 256000 bit (32K) frame buffer. Three bytes will be shifted to the Red, Green an Blue colour inputs, and one to the intensity input, giving sixteen colours per pixel. Preferably the "glue logic" for it will consist of standard logic, but if necessary I will consider a small FPGA.

the Rhococo will support a simple SD-Card interface as storage, and will use a keyboard similar to the ZX81+34, but with more keys,and a more conventional keyboard layout.

For sound I consider a PWM output.

It will be a "turn on and use" system, meaning that the "OS", and a programming language will permanently reside in ROM, ready the moment you turn the Rhococo on (Meaning it will be based on some kind of interpretative language).


For the moment (quarter 4 2015) the Rhococo has been stalled, as I have problems getting the ZX81+34 ZX81 clone to work. Now working on version two.

April 18, 2017 Changed my mind, will try to build a Z80 based more "home computer like design", with a CRTC, and not software driven

After a year or so contemplating this idea of a new homecomputer, I came to the conclusion that an ARM based system with software VGA generation might be too complex for a the simple system I have in mind. I will make a NEW homecomputer design with components that can be bought in 2017 (and the next few decades). It will be based on a Z80 compatible CPU as it is one of the few 8-bit CPU's that is still relatively easy to get, and it was so popular in the 80's that there is a plethora of software available for them. One thing I don't want is to use an FPGA for it, as these are still relatively expensive and difficult to program for. This does cause a problem, as most old homecomputers either used some kind of programmable logic (Sinclairs ULA logic) or were based around a CRTC like the MC6845 which are no longer available, or they used a VDC (video display controller) like the TMS9918 (MSX an many others) which are also no longer available. My preference would have been using a CRTC, but as I said I can find no CRTC's for sale anymore, I could build one with standard logic (like the TRS-80 did) but that's too RETRO even for me, (uses far too much components). Instead I'm wondering if I can replace the CRTC with an simple AT-mega (Arduino) microcomputer. For a 320 x 200 display you would need 320 / 8 = 40 8-pixel wide rows and 200 lines, which means you need 40 * 200 = 8000 address locations, this is about 8191 or 2 ^ 13, meaning you need 13 address lines to address these 8191 (or hex 0x1FFF) locations. and a couple of other signals like HSYNC and VSYNC and video clock. An Arduino (nano) uses an ATmega328, and doesn't really have that many GPO (output) ports, but that can be solved with a few 8-bit latches. I'm planning to do this in little steps, so first I'm planning to connect 8K Byte SRAM (or an EPROM for testing) to an Arduino nano, plus a shift register to clock out a video stream, to try to generate a 320 x 200 (monochrome) VGA signal, using a Arduino nano as a CRTC surrogate. Then continue from there.

April 23, 2017 Found some inspiration on what is possible with an ATMega328

I have looked (googled) a bit around if others had tried to combine a Z80 with an Arduino (ATMega328 chip which from now on I will call he AVR) and found this https://hackaday.io/project/19000-a-4-4ics-z80-homemade-computer-on-breadboard which isn't exactly what I want but seems to prove you can control a Z80 from an AVR, and do such things as catching I/O requests, and take over the Z80 bus to "fake" data being read from "ROM" (faked by the AVR) so you can feed some boot code to the Z80 which then uses I/O reads to get more data from the AVR to load in RAM. This is a nice idea, but you need quite some GPIO's to catch which address the Z80 reads from so you can feed it the right bytes. However, I considered that you can also completely take over the Z80's data and address busses, and use the AVR to load data into the RAM and use this method filling RAM with Z80 bootable content, (when adding an AVR controlled 16-bit counter for the address bus) then boot the Z80 from RAM. These ideas and others make that I can foresee that many other technical tricks can be pulled, like creating VGA color video this way. In any case I think that the ability to use the AVR as a virtual Z80 peripheral is very promising.

I also looked at other small Z80 systems, but they all are quite primitive IMHO or use things like bit banging to access I/O devices like serial ports, PS/2 keyboards and SD-cards, which is in my view a wrong approach as it uses Z80 CPU cycles too much, for things that a AVR could do more easily with virtual I/O.

The fact that you can use just a Z80, a 64K SRAM chip and an AVR chip to create a $4 CP/M capable machine is exhilarating, but I have set my goal on a color capable SBC that can be used with most (VGA) monitors, and has a built in keyboard, can run BASIC and has a clear architecture, and is cheap to reproduce.

For example I think it would be possible for the AVR to stop the Z80 (take over the bus) use the AVR to read some data from the RAM, then store it in the video shift register(s) one or more for each RGB and intensity shift register, and in this way create a 16 color video stream, you can use the very same 16-bit shift register you use for storing data in RAM for reading out sequential bytes from RAM to create video .

The very same AVR chip can also do many other things like creating PWM audio, (emulating a sound chip) reading keyboard data, and loading/storing files from an SD-card, and also creating a serial I/O channel, and I2C for I/O expansion, the possibilities seem endless. The bootable image data the system loads can be stored a simple serial EEPROM.

Ik denk dat ik eerst maar eens de $4 4-chip Z80 homemade computer ga nabouwen, en daarmee ga experimenteren. This is its schematic: File:Z80 with AVR schematic.pdf

April 25 Started building up the prototype

Luckily RevSpace has breadboards, so I could start building the prototype. I thought the Hackaday design used the AVR chip used in the Arduino, the ATMega328, so I could replace it with an Arduino nano, but not so, it uses an ATMega32A, thankfully Bernadsky donated one to me, so I could start. He will also buy the 128K Byte SRAM 32-pin DIP chips for me from Farnell using the RevSpace account we have, that saves me from buying one through my work.

I have set up the breadboards, with the example from the pictures and video's of the Hackaday site. Added a Z80, an Atmega32A, and the 74HC00 and several buttons and LED's, capacitors and diodes, and connected up several GND, VCC and other connections. Next week I will continue. By then I will have made stickers for on the 3 main chips, so its easier to connect up buses and such. P.S. Stickers are ready. 26/4/2017.

Some thoughts

Thought about creating PAL color video, there are "tech demo's" creating PAL color video, that means the AVR code also generates color-bursts, and phase shifted color information, using nothing but an AVR, but I don't think I can practically integrate such a design with my idea of using an AVR to read video data out of Z80 RAM-space, and also do virtual I/O handling.

Also these tech-demo's create a quite low resolution video signal.

So I think that is not the way to go. Problems is the color encoders (Chips used to convert RGB or YUV data to composite color video) used in the Spectrum and later systems are no longer sold. and RGB monitors are also gone the way of the Dodo. So for the moment keeping to the VGA video seems the only obvious solution.

So the basis should be that the AVR takes out video data from Z80 RAM and converts it to a pixel stream. Do do so, and to simplify filling that RAM from the AVR (while freeing up some much neeeded GPIO's) I suppose I need to implement an 8-bit counter, for the lowest 8-adress lines, complemented with an 8-bit latch for the highest 8-address lines, both with three state outputs to the address bus. So I can fill 256 sequential RAM locations from any of 256 address blocks, but also read 256 bytes out from video-ram into the AVR from any of the video RAM blocks, and one byte at the time keep feeding a video shift register with it, where the output of the video pixels go to a multiplexer so that 4-bit RGBY information is switched between a foreground and a background color. The two nibbles of which can be changed simultaneously with storing a byte in the video shift register.

For keyboard I/O I'm thinking of an 8x8 keyboard array accessed (Spectrum style) with a single 8-bit data-bus driver for the 8 columns, while 8-rows are driven from 8 address lines, and read out with a virtual I/O command at the end of a video screen cycle.

Also virtual I/O could be used to control a virtual programmable sound generator on the AVR which outputs sound on a PWM output of the AVR. Using the RAM access shift register/latch combo can/should replace the 6 GPIO lines now used to store 512 bytes of boot code in RAM, and should free up a few GPIO lines, which are quite dire and we do need some. also we probably need code space which is now used to contain Z80 code, I suppose we could off-load to an external I2C/SPI EEPROM or possibly to an SD-Card (in a later stage). Which also makes using much larger Z80 images possible.