The Parallax Propeller Project Board (#32810) is big enough to fit all the chips. Maybe I’ll make a wire-wrapped Propeddle for those who are too impatient to wait for the next version of the PCB?
When I was at the Maker Faire in San Mateo in May 2012, I met Vince Briel of brielcomputers.com. It was the high point of the day and made the Maker Faire even more memorable than it already was. When I introduced myself, he immediately knew who I was. He knew about Propeddle project and he told me what he was working on: a replica for the OSI 600 “Superboard II”.
I had to admit that I’d never heard of such a thing, but now I know that the Superboard II was the base for the Ohio Scientific Challenger computers. I’ve seen those before but never worked with them. Ohio Scientific was present at the legendary 1977 West Coast Computer Faire where the “big three” (TRS-80, the Apple-II and Commodore PET) were also announced. While the oldcomputers.net page, linked above, dates the OSI in 1978, this report by David Ahl mentions the Challenger being demonstrated at the show where the other computers were merely announced.
Vince told me at the Maker Faire how he had the 6502 connected to a Propeller to emulate video, and we discussed my PETSCII driver for Propeddle for a while. We talked about using the RDY line to hold the 6502 while the Propeller was working, and how it wasn’t needed for Propeddle. We also talked about connecting the Propeller to 5V system and I told him Propeddle uses the WDC 65C02S which is able to work on 3.3V like the Propeller.
A few months ago, Vince and I started exchanging emails about the OSI, and I started learning about the system. It’s actually a fairly simple 6502 system with RAM, ROM, video, a keyboard and a 6850 ACIA. It doesn’t use any interrupts, the keyboard is basically a switch matrix with an address decoder. The ROM has an early version of Microsoft Basic.
The video hardware on the OSI is a bit weird. It uses a 256-character font in monochrome without inverse video, and the memory is organized as 32×32 characters (1KB total). However, the characters are so wide that on a CRT monitor the leftmost and rightmost characters are invisible, so the editor only uses 25 columns and 25 rows. Vince asked me for help to implement that in his video driver so I did. And things went on from there.
The 6502 has to access memory inside the Propeller to display video, and I contributed some code to do this. Vince then proceeded to add more code to let the 6502 access the ROM too. I designed a schematic to map a number of areas in the upper 32K of the 6502′s address range into the Propeller as “virtual memory” so that the ROM could be stored in a contiguous area of hub memory. That way it takes fewer instructions to decode memory operations. I also modified the PS/2 keyboard driver for the Propeller that Chip Gracey (of Parallax) wrote, so that it can be used to emulate the polled keyboard of the OSI.
By this time, Vince decided that this project (which he had been working on for a while) is now finally in a stage where he’s confident that he can finish it. You can see the work in progress on his discussion list here.
It’s been an absolute honor and pleasure to work with Vince, on a project that’s almost (but not quite) completely unlike Propeddle
I hope to see him again at the next Bay Area Maker Faire in May 2013. He promised he’ll bring his prototype and I can’t wait to see it and play with it. I taught Vince some things that I know from the Propeddle project, and I learned some important things that I will use for the continuation of Propeddle. It will definitely be possible to make an OSI emulator with Propeddle, but it will not be the same as “the Briel thing”.
It’s been quiet for a while again in the land of Propeddle, so here’s a short update.
A while ago, I wrote an in-depth article about Propeller programming in C, and because of this, I was invited by Parallax to write some documentation for the PropGCC official website. I agreed that I would contribute some articles, but first I want to get Propeddle in a more finalized state, so I can sell it as a kit, and hopefully give a presentation at the Propeller Expo next May.
I’ve been rewriting the software in C and inline assembler for a while, and currently the code for the control cog is code-complete, and I’m ready to start debugging it with my Logic Analyzer.
Unfortunately, however, I’m hitting a major snag. Although it compiles without warnings or errors, the machine language that gets generated by the assembler is wrong: the Gnu Assembler (GAS) for the Propeller apparently still has some major issues that apparently don’t affect the C compiler, but generates fixups that are miscalculated for all instructions with immediate source arguments except JMP/JMPRET.
I had a long look at the Gnu Assembler code today and learned a lot about the architecture of binutils (of which GAS is a part). But the longer I look at it, the more I wonder why it works at all.
The Propeller uses hub memory and cog memory. All data and program code is initially stored in the hub, and gets downloaded to the cogs to get executed. In the hub, every byte is addressable, but the cogs use 32-bit addressing (every address represents a 32-bit word). When an instruction in the code refers to another item, the reference might refer to the location where that item is stored in the hub, or the location in the cog where the item was copied when execution started.
When using the Spin language, a reference or pointer to an item always refers to the hub. In assembler, all references and pointers refer to cog memory, except hub instructions. So it makes sense for GAS to store cog addresses into those instructions, and that’s what it does in most cases, but it gets it wrong:
I’m going to try a workaround for this (basically by putting the assembly code in a separate module) but I’m probably going to be working on fixing this problem in the Binutils too.
[Update: The problems in GAS are now fixed, thanks Eric Smith (maintainer of Propeller-GAS)]
It’s been a while since I had time to work on the project, so I figured you deserve an update.
Here’s the short version of my to-do list:
I’m excited to announced that I am today’s Featured Engineer on the EEWeb.com website.
The interview was submitted in February so the last paragraph is slightly out of date: You can now in fact buy the Propeddle kit although I don’t have an official web shop at this time. Send an email to jac-at-goudsm-dot-it for more information.
I created an account on Github. From now on, that’s where you can find the latest source code and schematics.
To those who bought a kit at the Parallax Expo:
I’ve been off the Internet all weekend so I had no way to work on the documentation, and there was just not enough time to get it done today once I got back on the grid.
I truly appreciate your patience and your trust, it inspires me to keep working on the software, the hardware and the documentation. I assure you, I’m working as hard on it as I can, but unfortunately I have other obligations to my work and my family too. Thank you for understanding.
What follows is an abbreviated version of the build instructions, without pictures for now. I will post a full version with pictures as soon as I can. Use the rightmost board in my Twitter profile background picture for reference if you wish.
I know some of the soldering points on the circuit board are pretty close together and the solder islands aren’t very big. If soldering is not your thing, or if you aren’t confident that you can solder it together yourself without causing short circuits, contact me I’ll solder it together for you for a small charge plus shipping cost.
If your Propeddle doesn’t work after you put it together, contact me too (tip: use a flatbed scanner to send me a picture of both sides)! I’ll help you make it run, or I we can arrange for you to send it to me to fix it for you (depending on what’s wrong with it). You will have to pay the shipping cost, though.
PS I will post code here tomorrow. The code is now online on Github.
This article explains how the Propeddle electronics work in detail. Some generic knowledge of digital electronics, the Propeller and the 6502 are assumed, but even if you’re not familiar with the intricate details, you should still be able to follow this.