Designing the RhoCoCo Retro Home COlor COmputer hardware
Project Rhococo Retro HOme COlor COmputer | |
---|---|
![]() | |
A brand new 8-bit homecomputer with modern parts. Above picture is just an artist impression, its probably not at all how it will look, although the keyboard is new representative. | |
Status | In progress |
Contact | Mahjongg |
Last Update | 2018-07-25 |
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"
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.
I think that the first thing I should do is to replicate the $4 4-chip homebrew computer, and experiment with it. 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 about PAL versus other video output modes
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.
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
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.
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, that 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.
In the past I had dabbled a bit 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 RHOCOCO 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 rhococo 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. found it 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 signals 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 bus. 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 bus 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, it seems there is no trend on where in memory the frame buffer is located, and how large it must be. I have opted to follow the Spectrum, 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 with an 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) (note that I have found a simpler solution later).
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) which will become impossible to get in the future. It will also look more like a home computer, less like a PC, and you can give it its own styling.
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.
19 June, 2018 Started working on a new schematic
Because I think the schematic will be too big for a "flat file" (single sheet) schematic, even on an A3 sheet, I have now split the schematic into two sheets. A main sheet (with the propeller chip), and (for now) one sub sheet, containing the Z80 8-bit CPU, and the (128K) RAM chip, both running on a separate +5V supply. Z80 and propeller share the data-bus, using a resistor divider, (on each data-line) which divides 5V data signals to about 3V for the 3V3 powered, and not 5V tolerant Propeller chip, while 3V3 ViH propeller data reaches the Z80 essentially unmitigated (and so satisfies its ViH levels). when the propeller needs to set up addresses to the RAM chip, or wants to read which I/O address the Z80 tries to access, interface logic takes care of that, which logic is 5V tolerant, and also acts like logic level translators. A third sheet can be used which has the keyboard logic.
When the design nears completion, I can think about trying to capture the whole design in a single sheet, but in this initial stage, I want to keep it simple.
July 20, 2018 four sheets schematic
updated first on July 4, then on July 18, 2018. The first (main) sheet is here: File:RHOCOCO MAIN PROPELLER.pdf its the main sheet with the propeller chip and VGA output, and a sub-sheet for the Z80 and its RAM, and now also keyboard I/O The second (sub) sheet is here: File:RHOCOCO Z80CPU with RAM.pdf its the sub-sheet with the Z80 and its RAM running at 5V, the 74HCT574 is used to latch the lower 8 address lines when an I/O request is pending, and can be read while converting the data to 3V3 levels. The third sheet File:RHOCOCO KEYBOARD with Joystick.pdf contains keyboard I/O and joystick interface, note that three new keys can be added (compared to a spectrum), plus the joystick can be copied as cursor keys, plus a few more keys compared to a spectrum.
The keyboard interface, also supports a joystick.
The fourth sheet covers a separate PCB, its compatible with a spectrum, but slightly extended with cursor keys, and a CTRL button, which duplicates as the fire button. this is the schematic:
July 9, 2018 Had a new idea on how to read out (video) RAM
Originally I wanted to externally generate A0 to A15 with a set of latches, but while I was thinking about implementing Z80 interrupts, I got an idea. What if an interrupt caused the Z80 to read out an area of RAM, its possible to periodically trigger a routine that reads out (video buffer) RAM, and puts its contents on the data-bus with an IO-write, so that the propeller could pick it up. and copy it to its own framebuffer. when we use such a routine there is no need for external address drivers, we simply let the Z80 do the work. The ZX80/81 does something similar, but uses a mechanism to force a NOP on the data-bus, in our case that doesn't seem the best way to do this, (it conflicts with the data-bus voltage divider) but we do need to invent a mechanism that synchronizes the RAM read action to the propeller, so the propeller knows when to read the data from the data-bus.
Perhaps the best way would be to convert the read data to a series of OUT instructions, as we already have a mechanism in place for that. It means we simplify the hardware to a minimum, and instead use software.... we also avoid things like wait states, and BUSREQUESTS and other complications that would slow the procedure down. I like it.... Lets keep this SIMPLE! (bus requests are still needed for the booting (initial RAM load) system.
Also, the simplest way to catch the low address byte for the I/O request is to simply use IORQ going low to trigger the address latch. we need to invert the clock signal because we want to latch the address on the start of the IO request, so we can use the address later during the propellers IO handling.
July 11, 2018 I have drawn new schematics with the insights from 9 July
I updated the two .PDF's, (ie: RHOCOCO MAIN PROP.pdf and : RHOCOCO Z80CPU with RAM.pdf ) and the above schematics. Refresh the page if you don't see a VGA connector on the main sheet. The new main sheet now has VGA and sound (PWM) output and an EEPROM, the two address latches were removed as they are no longer needed (because we will use the NMI triggered memory to IOWR copy routines.) The Z80 + RAM (and now keyboard) sheet has also been revised. The simple boot method is supported, and address lines A0 to A7 are latched on any IO request, and can be read-out by the Propeller to distinguish between various IO request types. The same keyboard matrix system is used as a spectrum, (drawn on a new sub-sub-sheet) and an IO-READ to a keyboard read location can be captured, and the keyboard-scan data can then be pushed onto the Z80 data-bus to finish the IO-READ instruction.
Corrections and hints (filling in the blanks) toward a first version
SRAM is not a 628128 but a (DIP-32) AS6C1008, and has to run at a somewhat lower voltage (4.5V) as its ViH = 0.7 x VCC, or 3.5V for 5V. 4.5V would be fine as 4.5V would mean that ViH becomes 3.15V. Use a simple diode to lower VCC for the RAM. The ram can function between 2.7 and 5.5V. its VoH is 2.2V minimal, which is just enough for a Z80 at a load of 1mA meaning for a 2.2V a resistance to ground of R=V/I of 2.2/0.001 = 2K2, so the resistance dividers which are now 470 Ohm plus 680 Ohm = 1150 Ohm, should be doubled to 1K and 1K5 (2K5 total). The RD# WR# and WREQ# signals must be routed directly to the RAM, NOT through the resistor divider! to overrule them with the propeller chips another solution must be found. Probably we don't need to take precautions to connect these signals directly to the propeller, maybe all we need are a few 1K series resistors between the Z80 and RAM , but not a resistor divider.
For the keyboard I/O we can use a 74HCT365 hex 3-state driver, we only ever need D0 to D4 and maybe use D5 for joystick switches, so a hex driver is enough, and nice and small. Don't use a whole 74HCT04 for a task that can be solved with a single 2N7000 FET, and a pullup resistor. Remember, use HCT logic, as its ViH is guaranteed 2.0V, not 0.7 x VCC as HC logic.
power input will be a model-B usb (no SMT soldering needed), and yes, I plan for all parts to use pin-though-hole technology. 3V3 will be provided using a TO220 based cheap LDO. The main PCB will be dual sided, connecting to a single sided keyboard PCB, to keep the price low. Taking hints from my ZX81 clone (10x10 cm dual sided PCB)
The keyboard wil be based on the somewhat larger, but similar keys I used on my ZX-81 clone, as they support keycaps. I have also used these keys on my SNES joypad, but used round keypads there, not the square ones I intend to use here. These buttons seem to be somewhat standard, so should be available for some time to come.
I wanted an SD-card interface, and at first sight it looked as if this would not be possible, but it is! note that the EEPROM is on an I2C (compatible) bus, so I can add an I/O expander for the necessary I/O for an SD_CARD, with bit banged SPI code. it might not be a very fast solution, but will still be convenient. Other I/O expansion might also be possible the same way.
The Z80 bus system can be connected to an edge connector, giving I/O and memory expansion possibilities, more-so if I also connect I2C pins, or leftover pins for the I/O expander, and connect pins like CS2 of the RAM so an external memory can overrule the RAM. other signals to route out are INT# and BUSREQ# in and out, with an 470R resistor in between, so the Z80 can be externally overruled by another CPU.
an internal speaker is also possible, with a small speaker driver, and sound output through a 3.5mm stereo/mono jack with a switch (to disable the internal speaker when a jack is plugged in).
serial programmer (and console I/O for debugging) will be supported with a pinheader to which an USB serial dongle can be connected, for those who wish to do some programming of the Propeller.
the EEPROM will be socketed, just like every other IC, so EEPROM's can also be pre-loaded.
To support 128K (or more) Ram, there must be routines in place in each 64K half, which makes switching the RAM "on the fly" possible, also note that code must exist to copy the stack from one half to the other without crashing the system. so that code can be executed in the other half without problems. and that jumps to a subroutine in the second half would be possible, with a clean return to the first half afterwards. the second ram bank could also be used for double buffered video. such code (assisting routines) must be stored in both haves at boot time, as adding them afterwards won't be possible without support code being present already.
Video output routines must also be present, in various forms, from simple terminal I/O routine, to monochrome and colour memory mapping routines, console output must also be redirect able to the serial port. keyboard I/O must also be supported.
Because of my previous (bad) experiences with trying to build a prototype on breadboard, or perfboard, I have decided that this time I will design a (prototype) PCB, it might cost me some money but spares me time and frustration.
July 18, 2018 updated schematics, added keyboard I/O with joystick interface sheet
Drew the schematic with most of the remaining details, added a keyboard and joystick interface, and an expansion port to the Z80, added sound output, and an SD-card interface, added power input connector, and a 3V3 regulator, added a USB to serial input connector for optionally programming the propeller, and debugging, and did various corrections. The (now three) new .PDF's were added, as well as new drawings. Please refresh the page if you don't see an expansion connector on the Z80 with RAM sheet. Also, corrected names and filenames where Rhococo was spelled wrong, including the introduction picture.
About the keyboard
I have decided to use MCDTS-2 12 x 12mm keys with KTSC-21 (square white) key-tops for the keyboard. As all MCDTS-2 keys are sold in sets of 15, I have decided to use 45 keys, (5 more than the 40 keys an original spectrum uses). Inclusive the key-tops the price for the keys will be around € 17 (exclusive of the PCB they will be mounted on). The keys will have 12 x 12mm square tops with a flat surface, that can easily be labeled. They will be spaced out on a somewhat larger grid, with 3 or 4 mm room between the key-tops. The cursor keys will probably be arranged in a diamond shape (with keys rotated 45 degrees). Finished the keyboard schematic, added it to the .pdf schematics, above.
rendered a picture of how it would look, with keycaps removed:
About the expansion port pinout
Initially I choose to more or less copy the pinout of the ZX81 expansion port, but I do realize that there is no need to follow an existing layout. I should choose a layout that is easy to wire up. I realized that my ZX81+34 design has its expansion port not in the back, but more like a Sinclair QL on the left, and not on an edge connector, but on a dual row angled pin-header, which is a very good solution for mechanical and electrical stability. I also realized that I will more or less copy the same setup as the ZX81+34 design, with the expansion port on the extreme left next to the Z80 top left, the SRAM to the right of it, then the propeller to the right of the SRAM.
Power, VGA, and audio out connectors go on top, and the SD-card slot, and the DB-09 Joystick connector goes on the right hand side. Possibly I will add a simple power switch top right hand side too, meaning the power connector will move to the right hand side. it makes sense to do it like that.
That means that the most logical pinout for the expansion port would be to simply copy the pinout of the Z80. With the connections to it (between Z80, and expansion port), all routed horizontally on the same (top) side of the PCB, so that the other (bottom) side can be used for vertical connections (mainly GND and VCC).
So with the next iteration I will change the expansion port pinout to exactly follow the Z80 pinout. Obviously I will add extra signals like 3V3, SRAM disable, bank select and I2C signals as well.
As the pin-header is self aligning, there will be no need for the kind of "key slot" that an edge connector would use.
Created a (3D) preview of Rhococo
I was curious if Rhococo would fit on the same minimal 10 x 10 cm PCB that I managed to fit my ZX81 clone on. So I decided to quickly design a 3D preview to check, the preliminary conclusion is that I think it will fit! The first version lacked the various resistors, and caps, and the 3V3 regulator, but my guesstimate was that it would fit. On July 24, 2018, I added (almost) all remaining components on this preview, and as you can see they fit (which doesn't mean the PCB can be routed, we will have to see about that).
Here are a few preview pictures, seen from the front, and the back:
Created a new set of schematic diagrams
This new set of three sheets replaces the older separate sheets, and has the latest corrections, for example a new expansion header, (replacement for the old edge connector) closely following the Z80 CPU, adding a power switch, replaced all hierarchical ports for the easier to use global ports, replaced resistors with SIP resistor networks, and a lot of other small corrections and changes, towards a version that is functionally complete, and has all the footpads needed. Consider this version 1.0. File:FULL RHOCOCO.pdf
Sheet 1 of 3: Main sheet. P16 to P23 of the propeller are used for the VGA output signals. So the propeller chip is capable of producing 64 colors per pixel, 8 times as many as a spectrum. Audio output is supported, as well as an SD-card (through the use of an I2C I/O expander).
Sheet 2 of 3: The Z80 (running at 5V) with its 128K (two banks of 64K) RAM, and a latch that can capture the lower 8-address-lines during an I/O (write or read) operation, during the I/O operation the propeller can read out the data, and then the 8 address lines for an I/O write, or can read out the addresses, then put 8-bit data on the Z80 data bus for an I/O read operation. To the top right is the Rhococo specific expansion port.