Bringing up Rhococo (first boot, and firmware development)
|Project Bringing up Rhococo|
|This tells the story of how the firmware and software was developed that gives rhococo its functionality|
This page describes the initial bringing up (designing and installing firmware and software) that will give Rhococo its functionality.
First we have to install the tools we need. For programming the propeller we have to install the propeller IDE, https://developer.parallax.com/propelleride/ . Fortunately I have already installed the latest version, when doing some initial research, and I have it working with my propeller based game development system, I bought some ten years ago, when thinking about building my own home computer was still a pipe dream.
- 1 May 1, 2019 First attempts at sending a propeller program to Rhococo
- 2 May 2, 2019 Found out why nReset "floats"
- 3 May 3, 2019 updated schematic and Layout
- 4 May 4, 2019 programming the propeller works ITS ALIVE!
- 5 May 22, 2019 trying to get a standard VGA driver (32 x 16 text driver) to work
- 6 May 28, 2019 VGA driver works!
- 7 June 5, 2019 Thinking about video modes
May 1, 2019 First attempts at sending a propeller program to Rhococo
I tried to send a modified version of LEDblink to Rhococo but failed (my debug LED is on A0, just like the Hydra). I was not sure my USB-serial adapter was compatible, and I used an oscilloscope to check, but that wasn't it, the adapter, which is intended for small Arduino compatibles without a built in serial programming port, seemed okay, and DTR was toggled by the programming software. Only for some unclear reason the nRESET input on the propeller stayed low. The USB dongle had a 100nF cap in its DTR line, but that could not be it. I removed the 2N3904 transistor, but nRESET kept being stuck low. All the schematics I could find about the programming interface seemed to imply that the nRESET pin had a built in pullup, so I hadn't implement an external one, but it seemed that without one nRESET didn't go high. So I added a 10K pullup, and now nRESET goes high, but without a new 2N3904 I have to wait till next week to try again.
May 2, 2019 Found out why nReset "floats"
its because I have tied the brownout input (BOEn) high, this turns off the built in 5K pullup. BOEn should be tied low instead.
May 3, 2019 updated schematic and Layout
new version is revision 2.0 (after version 1.9) it has BOEn tied low, and other recent updates, such as bleeder resistors, an 5mm pitch caps. schematic is here: File:RHOCOCO rev2.0.pdf
May 4, 2019 programming the propeller works ITS ALIVE!
I managed to get BlinkLEDRhococo.spin to upload, and program into the Rhococos EEPROM, and the blinking program starts when turning on the USB supply.
May 22, 2019 trying to get a standard VGA driver (32 x 16 text driver) to work
I'm trying to convert VGA.SPIN so that it works with RhoCoCo. It works on a Hydra game development system, but Hydra isn't hardware compatible with rhococo, so I have to change a few things. I managed to make it work with a 5MHz crystal, instead of the Hydra's 10MHz crystal, but Rhococo also has its VGA hardware on a different set of pins, namely gpio-0 to gpio-7, while Hydra seems to have in on gpio-16 to gpio-23 (hydra documentation is vague). These are the three .SPIN files, each using a COG that demonstrate the VGA text mode driver already modified for a 5MHz xtal: File:Vga text demo spin.pdf, File:Vga text spin.pdf, File:Vga spin.pdf
I'm also figuring out the version of the propeller IDE for Linux, which isn't the same as the Windows version described in the Hydra documentation.
The progress is painfully slow, but I am convinced that i'm close to success.
This will just be a placeholder VGA driver, so I have a textmode display for my Z80 uploading debug work.
May 28, 2019 VGA driver works!
Here is a picture of the VGA monitor displaying a picture directly produced by the RhoCoCo.
With this video terminal it will be much easier to develop firmware such as the Z80 RAM upload code, and IORQ handlers.
June 5, 2019 Thinking about video modes
This TV driver is text only, but I'm thinking about some modifications that will turn it into a high-resolution graphics driver.
one idea is using two sets of 256 programmable fonts, and assigning one glyph of the font per character position.
The text screen (horizontal x vertical number of glyphs) for this (VGA Text) driver is by nature 32 x 16, so you can display 32 x 16 = 512 glyphs on one screen. so if you had two font-sets of 256 glyphs you could have one glyph for every position on the screen. The propeller chip itself has a massive high resolution 16K ROM containing 256 character definitions of a 16 pixels wide by 32 pixels tall characters. 16 pixels = 2 bytes X 32 x 256 = 16484 or 16K. The Propeller has 32K hub RAM, meaning that theoretically you could store other such font sets in hub RAM, but that leaves no hub RAM at all left over, so storing two such fonts is not a useful proposal, and also having a 32K video framebuffer in Z80 RAM isn't practical either.
Still this method of generating high resolution screens has some practical advantages, so I don want to give up on the idea immediately.
VGA Text claims to have a practical horizontal screen resolution of 16 x 32 = 512 pixels and a vertical resolution of 32 x 16, also 512 lines. So it seems the actual resolution generated is 512 x 512.
However a VGA monitor I connected claims the actual VGA resolution of the generated video signal is 640 x 480 @ 60Hz, so it seems the vertical resolution is cropped, and indeed I only count 15 lines of text, not 16. 480 / 32 = 15.
And 640 - 512 = 128 pixels, probably 64 pixels left and 64 pixels right of the visible area are "black".
so the generated resolution is 640 x 480 and the "pixels resolution" is (or seems to be) 512 x 480.
perhaps with 15 lines instead of 16 its possible to store enough glyphs in hub RAM with some RAM space left over. In theory we need 2 byte x 32 x 32 = 2048 or 2K per line, so 15 x 2K or 30K (30720 bytes), leaving only 2K left over.
What I would prefer is using something like a spectrum with 8x8 glyphs, and a 256 x 192 pixel resolution, and a on a 32 x 24 tile screen. 768 glyphs would be needed, so it fits in a ten bit number, 8 bits + two more bits.
It is clear this needs more study, especially I need to study the VGA TILE drivers, and see how they work.
perhaps its better to let this be, and first concentrate on loading up and running some Z80 code.