good use of machine-pin sockets there!
but what happened to that poor d-sub connector: burning? dremel? a dremel that caught fire?

An accident with the soldering iron, while trying to remove R27 without damaging the board, its just some melted plastic, this is a prototype after all, its not there to win beauty contests, and accidents happen.

Well I managed an important step forward, I am able to generate a VGA text video signal!
This was a necessary step because without some form of built in text terminal it would be hard to develop and debug software, both for the P8X32A (propeller) co-processor, as for the Z80 main CPU. no hardware modifications were necessary, just a modified VGA.SPIN driver, and a simple .SPIN terminal routine.

A much better tile based high-resolution video driver will come later.

Another important step will be gaining file access from the SD-card. For that I need to first get the I2C I/O expander chip (PCF8574A) working, then implement a rudimentary SD-card driver.

Its the default font built into the P8X32A, its 16 x 16 pixels, so yes it looks good.

P.S. Its using half the 32K ROM space of the propeller, so 16K byte.
by the way, I found out that the real VGA resolution used is 640 x 480, this means the text screen only is 15 lines, not 16 as was documented, and the actual pixel width used is 512 pixels, at least in this 32 x 15 VGA text driver.

AFAIK Prop2 is still not out, I don't expect it to do HDMI, so yes, I'm using a Prop1, and as it will mainly be used as a video generator I can use most of its 32K for a video framebuffer. The Z80 will have its own main video memory, and typically it will be something like 10K.
When Prop2 comes out I consider it for an upgraded Rhococo.

The current video driver is just a modified standard VGA video text mode driver, just for software development.

So yes its VGA, which is already a big step up from just generating a composite video signal.

most modern monitors still accept VGA, and there are literally millions of VGA capable monitors still in use, so not having HDMI isn't much of a compromise. I expect that (second hand) VGA capable monitors will be easily be available for another few decades, not so much TV's with a composite input...

I have gotten the I2C PCF8574A IO-expander chip, ( the IO expander that drives the SD-card interface ) working (I can now write to, and read from the expanded I/O ports) and I have also solved a nasty resetting problem.

when you inserted an SD-card into the SD-card slot the system would reset due to the in-rushing-current generated by suddenly loading the card across the 3V3 supply. I changed the decoupling capacitor (C13, 100nF) to a 470uF 6V3 elco, and that solved the resets, the rush-in current is now delivered by this elco, and so the 3V3 supply doesn't "dip" anymore, solving the brownout resets.

I changed the schematics, and PCB layout to revision 2.1 with this change in C13, from a 2/10" cap to a 6.3mm round 2mm pitch elco.

I discovered that for a good interface between the I2C IO-EXPANDER driver code, and the simple SD-card FAT16 driver code I have, both need to use propeller assembler, NOT (interpreted) SPIN code, so at this quite early stage I need to learn enough Propeller assembly code to write this code, and as its fully summer, with tropical temperatures during day and night, I'm not too busy with this hobby of mine, so don't expect that I take this hurdle quickly.

Also, I'm busy trying to arrange a GitHub account so I can publish some of my earlier work (primarily my ZX81 clone).

If you know Z80 assembler, learning PASM (Propeller Assembler) should not be that difficult.

Things to get used to:

There is no indirect addressing. You have to use self-modifying code. There are instructions specifically for changing the source or the destination address of an instruction. Remember to have at least one other instruction between modifying an instruction and executing it.

There is no distinction between registers and cog ram.

Cog ram is quite limited, it is not difficult to overflow it with code and data.

Awesome project !
Do you have a github repository for those wanting to reproduce, participate and improve your RhoCoCo design ?
(Kicad schematics, PCB layout, Propeller firmware ...).
I have recently implemented a few retro computer designs as a learning base of digital electronics :

I thought it would be interesting to analyse your design more closely and it would be much easier if I could start with your last pcb layout revision.
Thank you for sharing your knowledge with the maker community !

Last edited by amoraru on Mon Sep 09, 2019 6:28 pm, edited 1 time in total.

No, not yet, but Ill consider it, in fact my Rhococo project has stalled a bit because the bit-banging software needed to get SD card reading has me stumped a bit, and in fact I am now devoting my time to finishing my ZX81+35 project (designing the keyboard PCB) so for the moment Rhococo is stalled a bit.

I could use some help to restart the project, especially with the propeller code needed for SD-card reading (bit banging the SPI code over the I/O expander), as my strong points is not software development, but rather ideas and hardware.

perhaps the idea to begin by installing SD-card reading code wasn't the right idea, it was inspired by computers that loaded code like a BASIC interpreter from tape (SHARP MZ80 series) so the basis of the computer was just a monitor with tape loading code, as a simple way to bring up all the basic capabilities of my rhococo.

I had hoped I could use the ability to load in code from an SD-card as a starting point in testing the ability to upload and start Z80 code, and to develop the ability to write Z80 keyboard drivers and I/O handlers. So without that ability I would have had to circumvent that idea, and use a more direct method to upload (some) code to the Z80, to see if my hardware design would work.

But if you are unconcerned that there might still be undiscovered hardware issues, i'm not agains the idea of sharing my as yet unfinished hardware.....

In fact I already decided that the best way forward would be to release what I have early and often.
in Fact that is what I do on my Revspace wiki project pages at https://revspace.nl/Projects you can read almost day to day progress reports about my projects, only the wiki is unsuitable to release files, as its restricted to open-office, pictures and .PDF files, not to CAD files and gerber files etc. For that I will need to use GitHub.

watch this space for news....

p.s. Yes, the list you mentioned are also some projects I was following with interest, except for the dual propeller game system, which was new to me, thanks for the link..

I could use some help to restart the project, especially with the propeller code needed for SD-card reading ... perhaps the idea to begin by installing SD-card reading code wasn't the right idea, it was inspired by computers that loaded code like a BASIC interpreter from tape ... I had hoped I could use the ability to load in code from an SD-card as a starting point in testing the ability to upload and start Z80 code...

It can certainly be done.

Since almost the beginning my PropAltair 8080 simulator on the Propeller loaded the CP/M operating system from SD card and then started the 8080 emulation to run it. Or it loaded Microsoft's 4K and 8K BASICs. The code to do that was written in Spin and I just used some Spin object I found that bit banged the SD card to read a few block into RAM.

At that time I had no FAT file system on those SD cards. So this was very simple to do and did not waste any Propeller memory space with a FAT drivers. I just used dd to write the CP/M image to them from Linux. They were CP/M formatted SD cards! It was a magic moment when CP/M first booted and displayed it's prompt on a two line LCD. I had a CP/M system with 24K RAM on the Prop to work in, no external RAM chip required. All very simple.

Later when I started on the ZiCog Z80 emulator I was talked into using FAT on the SD so that people could simply copy CP/M to a file from Windows. And then cam the need for an external RAM as all that code had used the Prop space and people wanted a 64K (or more) system.

Later I regretted going that way. Using FAT on a CP/M system seemed morally wrong! All that complexity of external RAM and caching it in the Prop got overly big and complex.

If I were doing it today I would not worry about FAT on SD. Windows users can put whatever is reqired onto the SD with Etcher.

On the other hand, I perhaps would not use SD at all. Using a 32GB SD card to do nothing but hold a 64K CP/M image seems all wrong.

I was talked into using FAT on the SD so that people could simply copy CP/M to a file from Windows. And then cam the need for an external RAM as all that code had used the Prop space and people wanted a 64K (or more) system.

If only reading files from a FAT formatted SD Card there should be no need for anything beyond whatever buffer is needed to read a single sector and I believe that could be reduced to just enough RAM to hold a single file entry if one interleaves filename matching with the SPI reads. I have done it with a PICAXE microcontroller which has only 1KB of RAM.

To simplify writing one can require an existing file of suitable size to already be on SD Card and then just overwrite that file's sectors. That side-steps having to update the FAT or directory entries. Alternatively one can quick-format the card on the fly and put the saved data into a single file.

Now you remind me. There was no FAT in the ZiCog Z80 emulator code. It just found the CP/M image from a know position on the SD card. Which happened to be the position of the first file one writes to a newly formatted FAT disk.

Still ZiCog got too fat. Just emulating all the hundreds of Z80 instructions, which CP/M software never uses, started to eat a lot of Prop HUB RAM, till an external RAM was required to run anything under CP/M. And performance suffered as a result. I got disillusioned with the whole thing.

It was much more fun when I could fire up CP/M under PropAltair with nothing but a Prop chip and an SD card and have 24K HUB RAM space for CP/M to use.

Last edited by Heater on Tue Sep 10, 2019 10:36 am, edited 1 time in total.

In the case of the RhoCoCo, its used as a means to easily plug in files into the system.
As of now, only to test the ability to run and debug the ability to execute Z80 code, later it will be used as the normal storage capability of the home computer, as a replacement for cassettes, or floppies. Its like the old SHARP MZ systems, which only had a debug monitor, an a cassette loader.

using a (simple) FAT filing system makes it possible to store files on it from another computer.

I don't want to use SPIN code, for it as that would mean I need one COG for running the SPIN code interpreter, so all "system code" should be written in spin assembler.

I wonder where the invention of FAT comes from, before acquiring (they didn't write it) DOS I don't think Microsoft used any kind of filing system for their BASIC interpreters, they were all cassette based anyway. Apple used their own filing system, as did Tandy, and the PET had no real filing system, and used IEEE488 to communicate with a storage device.

I remember that FAT existed for some stand alone Microsoft BASIC interpreter, before it was ported to QDOS, which was a 16-bit CP/M clone, and that QDOS was bought and turned into PC-DOS by Microsoft.

Awesome project !
Do you have a github repository for those wanting to reproduce, participate and improve your RhoCoCo design ?
(Kicad schematics, PCB layout, Propeller firmware ...).
I have recently implemented a few retro computer designs as a learning base of digital electronics :

I thought it would be interesting to analyse your design more closely and it would be much easier if I could start with your last pcb layout revision.
Thank you for sharing your knowledge with the maker community !