Difference between revisions of "Designing the RhoCoCo Retro Home COlor COmputer hardware"

From RevSpace
Jump to navigation Jump to search
(May 23, 2018, gave up the version with an ATMega, and switched to using a Parallax Propeller (P8X32A) instead)
(May 23, 2018, gave up the version with an ATMega, and switched to using a Parallax Propeller (P8X32A) instead)
Line 137: Line 137:
  
 
== May 23, 2018, gave up the version with an ATMega, and switched to using a Parallax Propeller (P8X32A) instead ==
 
== 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 problem to implement video and sound, the way I wanted. And that was the main reason the project stalled for almost half a year.  
+
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 had dabbled a bit previously with a unique chip, which I suspected would be a better, and easier solution.
+
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.  
 
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.  
  

Revision as of 00:10, 23 May 2018

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-05-23

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, but the solution could be to use a CMOS based Z80, that can also run on 3.3V.

Anyway, I 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