Designing the RhoCoCo Retro Home COlor COmputer hardware

From RevSpace
Revision as of 18:16, 18 June 2018 by Mahjongg (talk | contribs) (June 6, 2017 drawn schematic of first version in KiCAD)
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 not how it will look.
Status Initializing
Contact Mahjongg
Last Update 2018-06-18

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), probably BASIC (if possible BBC BASIC)

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

I thought about creating PAL color video instead of VGA, 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, at the same time, do virtual I/O handling, and sound generating.

Also these tech-demo's create a quite a low resolution video signal, which doesn't satisfy me.

So I think that is not the way to go. Problem is that the color encoders (Chips used to convert RGB or YUV data to composite color video) used in the Spectrum and later systems (such as LM1889 and MC1377 chips) 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 needed 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 the Z80 code 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.

April 30, 2017 added most wiring, except for SRAM

The SRAM chip is unfortunately still missing, Benadski wasn't there so I couldn't ask him about it. Stickers were cut out, plasticized, and stuck on the Z80 and ATMega32A (but not on the missing SRAM chip) and wired with DuPont wires, using color codes, like A0 = Black A1 = brown A2 = red etc. most wiring is done, its now waiting for the SRAM chip so I can finish wiring. After that I intend to in circuit program the ATMega32A. An USB serial device has also been added to the design.

May 2, 2017 added SRAM chip, finished wiring

Now I only need to double check the wiring, which is much more intense than I thought, seeing the pictures of the original, probably because I use DuPont wires. It doesn't seem very reliable. Now I have to figure out how to program the ATMega32A. First task is probably installing the latest Arduino IDE.

May 9, 2017 Programmed the ATMega32A and started testing

Installed the Arduino IDE, and found it didn't offer programming a bare ATMega32A. Found a source called "Mightycore" that offered programming options for ATmega32A's. Managed to get the programming code "S221116_Z80_Breadboard.ino" compiled after selecting the ATMega32, (had to remove the ATMega32A from the breadboard for programming) and managed to get the USBbus programmer working. Finally the code was uploaded to the Mega32A, and I saw a lot of code space was still free.

Installed a driver for the USB serial adapter, and got it to work, first with the built in monitor, later I installed PUTTY, and configured it for 9600 baud etc, and it worked... Partly.

I got all the messages from the ATMega running the code, upto the message:

"IOS: Z80 is running from now."

then, nothing.... :-( so the z80 uBIOS doesn't run, probably some wiring error still. Although it seems to finish running the first and second boot parts, with help from the Z80 for the second part. Next time debugging, and probably building it up on perfboard for better reliability and the possibility to remove the main chips from sockets, or even to add a programmer interface, for easier programming, although the ability to just take the ATMEGA32 out of its socket will also help a lot, as taking it out of the breadboard is now a pain, with all the Dupont wires crisscrossing over it. Here is a picture of it on breadboard.

Z80AVR BREADBOARD.JPG

As can be seen, its very hard to take out any parts, for example the ATMega32 for (re-)programming, and all these loose wires that loop through the air make for a noisy and unreliable system. So I will start putting it on a hand wired perfboard, at this stage designing a PCB isn't a good idea, as I will interactively, step by step, expand the design from the base design to a version that will be able to create a video signal. This will probably mean many intermediate steps and a hand wired perfboard is the easiest solution. I will also buy a programmer (a MINIPRO TL866) so I can easily program the ATMega32, and it will also service to program EPROM's and OTP's.

May 23, 2017 Started building perfboard version

Took a piece of perfboard, and mounted two 40 pin sockets for Z80 and ATMega32 a 32 PIN socket for 128K SRAM, a 14 pin socket for the 74HC00, and added two 20 pin sockets in between ATMega32 and SRAM for future expansions I have in mind (one 8-bit latch with 3-state outputs between databus and upper 8 address lines (including A17), and one 74HCT590 8-bit counter with 3-state outputs for the lower 8 address lines). Also added all resistors, capacitors diodes and LED's, as well as the two buttons. Next time I will start the wiring, starting with the GND, and then +5V wiring. After that I will probably draw my own schematic, so I can also add wiring to the two 20 pin expansion sockets (although these won't be used yet at this stage).

June 6, 2017 drawn schematic of first version in KiCAD

I decided that for this project I would switch from my old and beloved, Ultiboard to the new and more universally adapted KiCAD. So I installed KiCAD, and learned to use it. This is my own drawing in KiCAD of the "4 chip $4 Z80 computer" that will become the basis of RhOCoCo, its extended with (for the moment non functioning) address generation logic consisting of an 8-bit counter, and an 8-bit latch: File:RHOCOCO REV 1.1.pdf

RHOCOCO picture REV 1.1.png

The 8-bit latch for the higher 8 address lines, and the 8-bit counter for the lower 8 address lines will form the infra structure that will enable the ATMega32 access to all of the RAM for storing code into the RAM, and do Z80/ATMega32 memory sharing of video RAM later, also for memory mapped keyboard I/O (spectrum/TRS-80 style). In the first testing phase the data and address busses of the counter and latch will be wired up on the bread board, but won't be controlled, and the IC's will not be inserted into their sockets, so the same bootstrap method can still be used as the 4-chip $4 computer uses, later if the breadboard works, the address lines from the ATMega32 to the Z-80 bus will be removed, freeing up 9 GPIO pins for new functions (PC2 to PC7 and PD2 to PD4) and my own RAM access system will replace it, using a few of these GPIO's but still leaving some others for other uses. If that bootstrap system works I will add an 8-bit latch and video shift register to the data-bus so that a (monochrome) video stream can be generated, which can switch between a foreground and a background color using a dual 4-bit multiplexer. each 4-bits will come from another 8-bit latch. so in theory each 8 consecutive pixels can have either a foreground or a background color, the resulting 4-bit video data will generate sixteen foreground or background colours, as two levels each of R, G, and B signals. This color data will go to the VGA plug together with h-sync and v-sync data from the ATMega32.

June 14, 2017 added some ground wiring and stickers

Designed stickers for the 74HC590, and 74HC574 chips, in mirrored form to paste to the back of the bread board, replaced the 14-pin socket to a 16-pin socket for the 74HC590, and added GROUND and VCC wiring to the bread board. Next time I should bring some wire wrap wire for the wiring of address, data and control wires. It will be lots of work to wire this board up. Hopefully it will be worth it, and be much more reliable than the breadboard.

June 14 to July 12 wired up my prototype board

Well, I't took a long while, but I'm now nearly finished with wiring up my prototype board, here are a few (bad) pictures of the board so far, and the wiring on the back. PTDC0071.JPG

PTDC0073.JPG

Colors of wires are:

Thick Red, +5V

Thick Blue, or uninsulated, GND

Red, Databus

Yellow, lower 8 address lines

Green, Higher 8 address lines

Blue, control signals


May 23, 2018, gave up the version with an ATMega, and switched to using a Parallax Propeller (P8X32A) instead

I realized that with all the functionality I wanted to implement, while maybe I could do most of it with an ATMega chip, it wouldn't be fun, and I expected it would become a hassle to implement video and sound, the way I wanted. And that was the main reason the project stalled for almost half a year.

I needed a better, easier, solution.

I had dabbled a bit previously with a unique chip, (the P832A AKA Parallax Propeller) which I suspected could be exactly what I needed. With its unique concept of using eight 32-bit cores, (called "cogs") that can each be programmed individually with either a high-level object-based language called SPIN, or with its own assembler language, and with each core having control of four 8-bit I/O ports.

I knew, have seen examples, that you can implement a VGA video driver with just a few COGs, and there exists code to emulate many types of hardware, with one or just a few COGs.

There are even complete, (but simple) systems with an emulated (Z80) CPU. Main problem with such systems is that the propeller has limited RAM (just 32K).

A problem with replacing the ATMega with a Propeller, in combination with a Z80, is that the propeller runs on 3.3Volt, not on 5V, and the Z80 runs only on 5V. I have to find a solution that doesn't require a massive amount of level shifting. unfortunately no 3.3V z80 CPU seems to exist (except the eZ80, but i'm not inclined to use that monstrosity).

Anyway, for the moment I ignored the problem, and made a conceptual drawing of RHOCOCCO where I replaced the ATMega CPU with a Propeller, here is the new schematic: File:RHOCOCO with propeller.pdf.

This is just a first concept, I think I need to simplify it a lot, also to free Propeller pins for things like audio output, VGA output, (directly from the propeller chip) and much more. perhaps i should separate the Z80 and its RAM into a module (sub-sheet) of its own. I think that I need to get rid of the TTL logic, and invent a simpler mechanism to interact with the Z80. I need to be able to:

Fill in a very small section of boot code (256 bytes) to the first page of RAM
React to I/O reads and writes (while halting the Z80)
read out a somewhat larger part (10K or so) of RAM somewhere else in memory (read out the video frame buffer) efficiently (quickly) while not disturbing, or by halting the Z80.

Via Z80 I/O and specially written routines, I should be able to access all of the Z80's RAM, so I can upload code. As a basis the rhococco should be a bit like a sinclair spectrum, TRS-80 or MSX.

28 may, 2018 found boot method

I found a way to write boot code into the Z80's RAM, using a propeller chip here: http://www.shaels.net/index.php/mini80/mini80-general/119-mini8o-overview With the schematic here: File:Mini80b.pdf

it works like this:

   Pull Z80 reset line low.
   Generate enough clock pulse to allow Z80 core to fully reset then set reset line high.
   Set the tri-state buffer enable pin high to tri-state Z80 read and write lines (/RD, /WT).
   Provide clock pulses to the Z80 until the Z80 indicates a read operation.
   Place the desire data on to the data buss, then pulse the RAM /WT pin low to write the memory location, Z80 provides address and RAM chip select.
   Place the 8 bit Z80 op-code NOP (0) on the data buss.
   Provide clock pulses to the Z80 until the Z80 indicates the read operation completed (/RD = high).
   Repeat steps 4..7 until the required boot code is copied to RAM, each cycle the Z80 will increment its memory address starting at address zero.
   Pull Z80 reset line low.
   Generate enough clock pulse to allow Z80 core to fully reset then set reset line high.
   Set the tri-state buffer enable pin low to enable Z80 read and write lines (/RD, /WT).
   Set the Propeller chip counter to clock the CPU at required frequency.

This simple CP/M system proclaims it uses undervolted Z80's, running them at much lower clockspeeds than they are rated at at 5V. He claims they should be able to run at 20/33th of their rated speed, or 6.9MHz for a 16MHz rated Z80.

The above method only uses a few propeller I/O signals, namely: D0 to D7 (with a voltage divider, see below) /Reset for Z80 Clock for Z80 /WR (overriding the /WR signal from the Z80, by using a wire between Z80 and /WR to RAM) /RD

I think it should be possible to power the Z80's at 5V, and use a simple resistor divider to lower voltages between Z80 and Prop to 3V3, while providing the full prop ViH voltage to the Z80. I think these dividers are only necessary for signal the prop reads, like data and /RD /WR and /IORQ. I think 2K2, and 3K3 will suffice.

catching I/O requests

To catch and react to I/O requests, the simple CP/M system reads the lower 8 address lines using a 74HC165 multiplexer. The basic system to catch an I/O request is:

When a port read or port write operation is requested by the Z80 the Propeller chip stops the Z80 master clock.
The 74HC165 parallel to serial register is used to read the 8 bit port address from the Z80 address buss. 
If the Z80 requests a port write operation the 8 bit data value is read directly by the Propeller chip from the Z80 data buss.
The Propeller chip uses the supplied port address and executes the required code to complete the request.
If the Z80 performed a port read operation the resultant data is placed on the Z80 data buss and and the Z80 is clocked until the /RD line is set high by the Z80.
If the Z80 performed a port write operation the Z80 is clocked until the /WT line is set high by the Z80.
Finally the Propeller chip starts the Z80 master clock and goes back to waiting for an I/O port operation.

the mechanism to read all 8 lower address lines is minimalist, but still uses a bit more Propeller ports than I like, maybe this can be simplified, especially as having 256 I/O locations is overkill.

reading out Z80 video framebuffer memory, to display it

A relevant change compared to the original design of the simple CP/M system is that I insist that I must support a video framebuffer in the Z80 memory map. Only this will allow the fast video updating that is necessary for engaging video gameplay, (although it must be said that it should be possible to use an I/O driven video sub-processor system like the TMS9914 based systems (like MSX) use. after studying a few of the major Z80 based home computers that use a frame-buffer in their memory map, but their seems to be no trend on where in memory the frame buffer is located, and how large it must be. I have opted for an 8K location in the second quart of the memory map, leaving 16K for "ROM" space, followed by 8K of video framebuffer, followed by 8+32 = 40K of RAM space. This supports a system that resembles a spectrum. 8K is enough for 1024 8x8 characters, and 1024 characters is enough for 25 lines of 40 characters, or 12 lines of 80 characters or 16 lines of 64 characters (as a TRS-80 uses). all in full bit-mapped (high-res) mode.

so on top of the above boot and I/O interface structures, I will need hardware to scan (read) through an 8K (&H1FFF) section from &H4000 to &H5FFF from the RAM chip, so a 13-bit address range (8192 Bytes). with 3 address lines fixed (with weak pullup/pulldown resistors). Either a 13-bit counter, or a 8-bit counter, with a 5-bit latch. Actually, the original idea was to use an 8-bit counter and an 8-bit latch, so we can put the video framebuffer anywhere in the 64K memory space, and use any size we want. We don't need to put the Z80 in tri-state mode, as we can just use the same trick the spectrum uses, with isolation resistors in the address lines (and other lines we need to drive to read from the RAM).

Adding a keyboard

There are several methods possible, primarily you could do it spectrum style, first you catch an I/O request that asks for keyboard data, then with the Z80 stopped, you scan a few addresses, and read out keyboard data from an 8x8 (64 key) keyboard matrix, then put that data on the databus, and clock the keyboard data into the Z80's I/O read instruction.

An altogether other solution would be to implement a PS/2 keyboard interface, and interface that to the Z80 using I/O requests.

I tend to prefer the first method, as more "pure" way to do it, without using things that are already becoming hard to get now (PS/2 keyboards) and will become impossible to get in the future.

Adding sound

the simplest method is catching I/O requests that want to output sound, and use the propellers sound output method (PWM) to output it directly to an DAC. Another method is to emulate a PSG, such as the AY-3-8910, interfaced using I/O request handling.