The Cody Computer
codycomputer.org
codycomputer.org
it's a real 6502 assisted by a RP2040
I think the only thing that really holds the original Propeller back in such projects is that while the Propeller is fast, it's going to take a few cycles to interface the 6502 bus whatever you do. The Propeller runs at 20 MIPS per cog, which can easily bit-bang the bus when the 6502's running at 1 megahertz or so. But if the 6502 is running at 16 megahertz then it's not going to be able to keep up without some external decoding logic and throwing in a wait state via the 6502 RDY pin.
The newer Propeller 2 would have no such constraints, but it's also a more complex chip that you can't get in a 40-pin DIP.
A small board could sacrifice some IO pins and still get it to 40 pins. Or, at least, 64 like a 68000.
160x200 video is a mistake however. Those pixels are twice as wide as they are tall, in NTSC signaling to be perfectly fair. And to be a bit more fair, using that resolution can mean eliminating color "dot crawl" common to devices outputting a composite color video signal, which this little computer appears to do.
Now I have written quite a bit of video related code for the Propeller 1 chip featured in this project. It is possible to compromise and double the video resolution to 320x200 and still maintain that crisp look seen in the product photos.
The secret is to avoid the color signal interlacing, and or output s-video, which is separated Luma and chroma signals similar to the C64 output signal. Additionally, one can get these little S-video to composite adapters that work pretty well on a non s-video capable display, though the Propeller can offer either video signal just for the asking, and the same video circuit is used for both.
With NTSC, anything over 160 pixels in the active video area, which is the signal inside the borders seen in the product photos on the project page, tends to leave fringing between high contrast pixels. Contrast being say, red and blue, which are far apart on the color wheel. This is caused by the low resolution of the NTSC color signal itself being superimposed onto the monochrome Luma signal in the composite, single RCA jack output case.
What I did for my video drivers, which can be found on the Parallax site with usually an MIT license, was to simply not interlace the color signal. The spec calls for the color timing to be such that every other scan line is out of phase relative to the prior scan line. This allows for 320 pixel color resolution with the cost being the fringing at high contrast pixel transitions.
If the driver simply does not do that, the result is a bit less sharp color, but also no shimmering in the text. That works pretty well with composite on most displays.
And when S-video is used, doing the interlace simply improves on the non interlaced color, making it sharper.
A propeller chip video generation is almost entirely software driven, which means one can do just about anything with the output signal. It is really a fun device.
In my opinion, a 40x25 text display with 7 bits per character, rather than the 4 bits seen on the CODY, would be a whole lot easier to read.
The good news is anyone can do that due to how the Propeller is a software driven video device.
All that said, the project author may have intended a specific look and feel, and if that is the case, the project looks like a home run!
> All that said, the project author may have intended a specific look and feel, and if that is the case, the project looks like a home run!
I’m assuming that. The C64 palette is a good indication.
Period authenticity, color palette, and pin count, among other reasons:
The idea was to make something that really felt like an old 8-bit you could build, and composite video output was a big part of that.
The NTSC colors were also a lot closer to the "feel" I wanted the computer to have, and unlike VGA output on the Propeller, you don't have to increase the number of pins to increase the number of output colors; the color information is conveyed by the phase of the NTSC signal. On the Propeller you can get a rather large NTSC (or PAL) palette with a 3-pin DAC, but with VGA, you'd want a six-pin DAC plus H and V signals for VGA (and likely not find color matches as close to the C64 palette anyway).
You also need to take into account the timing limitations for "racing the beam" and generating the video on the fly as the Propeller firmware is doing internally; TV scan rates are comparatively slow and give you more time to assemble a line of pixels.
Lastly, as far as HDMI or DisplayPort, that was well out of scope for what I was trying to do, and likely out of range of what the Propeller could bit-bang even with its shift register hardware. I know people have done something similar with DVI output from the Pi Pico, but I'm still not sure that even the Pico could do as much as the Propeller is doing here overall, and probably not as cleanly.
One of the things about engineering, or really anything, is that's more often than not a matter of finding the least bad option given competing constraints; in this case what I thought was the best technical fit was also the one that fit the 1980s aesthetic.
> fit the 1980s aesthetic.
Can't blame you for that - the 80's is where I grew up and that feel is unbeatable (even though I liked the higher-end gear from DEC and IBM as well).
DVI is streamed just like analog video is. One can stream a frame buffer, or not, just like analog.
The Propeller has hardware assisted video signal generation. It is a lot of fun to program and one can basically duplicate a lot of old computers video signals.
One advantage NTSC has over VGA is when using a component video capable television. The Luma "Y" output can drive an HDTV in monochrome all the way up to 1080i using one single pin!
The Propeller chip used in this project may not be capable of 1080i, but it can do 720i.
The P2 chip can do 1080p and more via VGA.
Sounds like a perfect target for a port of the Sierra AGI interpreter!
One was simplicity for the user. When this was all just an idea, I often compared it to a "Commodore Junior" in terms of functionality, and I wanted to keep it simple to learn from and have fun with. I thought something like the C64 or Plus/4's multicolor graphics mode would be the best compromise in terms of letting you make graphics/games but also having readable text output. A lot of old C64 games did just fine with 4x8 multicolor text, and even the VIC-20 did passably well with some of the 40-column extensions people wrote for it.
Another was simplicity from the standpoint of designing the thing. I actually looked into trying to mimic most of the VIC-II's functionality, including being able to mix low-res and high-res on the same line. I just couldn't convince myself there would be enough cycles to pull that off, or at least I'm not sharp enough to manage the feat, particularly with sprites also involved. You could do it with more cogs (Propeller cores) but since the Propeller is handling so many jobs (kind of like the TED on the Plus/4 series), there were constraints there as well. From there I went back to thinking about separate high-res and low-res modes, but that circles back to the above point about complexity.
Yet another reason was that Cody actually liked the multicolor graphics modes (and I do realize how that sounds). When I played around with different video graphics he got really big eyes and a smile watching multicolor tests on the TV. He also really enjoyed YouTube videos of Commodore Plus/4 games done in the multicolor mode it had when I was reading up on the TED. If it got his attention I found a way to work it in, and I also think a really smart Pomeranian isn't necessarily that much different from a really young boy in terms of researching your audience for this kind of thing.
(True story: At one point when I was showing Cody the Propeller breadboard I used for experimenting, he started slapping the RCA jack with his paw with a curious look like it was going to do something. I think he saw me plug that into the cable so many times that he concluded the RCA jack is what made it run or something.)
I think your project is great, and I am thankful I made the final comment I did, because you did aim for specifics and appear to have nailed them.
Great work! I am likely to build one.
I know the developer of that chip personally and will make him aware of your project. He will likely think it is really neat.
Another true story:
I stepped away from electronics and microcontrollers, until a friend sent me the datasheet. I ordered one immediately and had a blast! Got caught right back up. Met the developer, who said I* was who he made the chip for. We have since had a running conversation about this stuff and a lot of fun.
*That being anyone looking to get into this stuff no matter what age, or experience level.
The idea was to offer more capabilities to existing Propeller users as much as it was attracting new users for whom the first chipboard not make sense.
The newer design being named a "2" can be confusing!
They are similar, yet very different devices.
This project uses the original, which in my opinion, was the perfect choice.
The device offers great retro level video just about any way you want it, except digital. VGA, NTSC, PAL, s-video, others... You can drive TTL displays, such as a CGA, EGA, Monochrome. And on composite, you can crank horizontal resolution way up to do, 80bcolumn plus text.
People have made various Basic dialects, there is a quite capable Forth, and of course SPIN is fun and easy. Feels retro to me.
One has to go looking, but there are a lot of games too.
The problem is that the Propeller community ended up being a lot smaller than, say, the Arduino community, so learning materials aren't nearly as available outside of Parallax's publications or the forums. That said, I think that if you took a group of kids and gave them Propellers compared to a similar group with Arduinos, the Propeller group would understand a lot more about why things work the way they do.
And the P2 chip can put all that to bed due to it literally supporting almost every computing model and can even do multiple language programs that run all at the same time!
I have written programs that are SPIN, C, assembly and BASIC. Compile, run, and there it is! All running together, concurrently.
One can write parallel algorithms, concurrent ones, or just do sequential compute too.
Yes, the design is unique, but what one learns can be applied broadly.
One does wish more would work as easily and be performant, but that is a minor league problem.
My ability to use just about anything else is now very significantly improved.
The thing is a playground, but also at the same time more effective than one might expect at first glance.
Video options are improved too. There is a color engine capable of mapping colors into color spaces. Say you want green and yellow and you want to display those on the following video signals:
Ntsc, Pal, VGA, Component Video (YCbCr), HDMI, Composite, S-video
The thing can do that, even outputting them all at the same time!
640x480 on the HDMI without tricks and refresh rate games. (24p)
Full HDTV and above on the analog component and VGA, and the usual interlaced or non for Composite. 240i 480p.
Has a CORDIC math engine able to crank out trig, powers, roots, shared among all cores. Drop arguments, pick up some 50 ish cycles later. Amazingly, it is pipelined such that all cores can do that non stop and it all gets done.
Interrupts have been changed into events, with a time being one event, pin state changes, all sorts of fun things. Three level deep priority system too.
Let see, what else...
Oh, hardware locks for managing concurrent or parallel access to common memory.
Oh, this is big:
Every pin has a "smart pin" state machine that can do stuff like trigger an interrupt when a given state criteria is met.
Each PIN can be an ADC or DAC, and the input precision is up to 12 bits with builtin filtering, or you can get the raw stream to do better of you want to.
Outputs are high quality too.
Want an on board 20Mhz scope coupled with 100Mhz complex signal generator?
The P2 does it.
I can go on and on.
Have fun!
I really got a lot out of these chips. Hopefully you do too.
As one of the other commenters mentioned, keyboard switches don't come cheap. Your best bet would be to look at some of the sources for Cherry MX clones, though for my build I was able to find a US-based source for Cherry MX switches relatively cheaply. It also helps that you don't need nearly as many as for a full, traditional keyboard.
Another cost to consider is the cost of the PCBs. All of our boards (including the prototypes that didn't go anywhere) were done by Aisler and were a bit more expensive than Chinese board houses, but they always came through and I was too lazy to shop around. Per board the cost isn't bad, but consider that you're buying boards in groups of three, and then you have at least two PCBs (the main board and the keyboard).
It's also going to depend on where you live and what kind of import duties you might get hit with.
You might be surprised at the knock-on effects of that.
You're not going to be able to drop in the PS/2 driver from the OBEX that easily. The Propeller has 8 cogs. Right now one manages the 6502 bus, one manages the SID emulation, one manages the NTSC video generation, four are in use for scanline rendering, and one is used to implement two separate UARTs via coroutines. So you have no free cogs, so unless you can wedge your own PS/2 driver into the UART or SID code somehow, you have nowhere for it to run.
Also, the Cody Computer has its own ROM in 65C02 assembly, and that has its own I/O routines written around the idea that it's scanning the keyboard using the 65C22 VIA. You could change some of the ROM so that it would read the PS/2 input from the Propeller (assuming you could solve the above problem), and most of the programs in Cody BASIC would work as long as you consistently translate the data. However, assembly language programs that directly scan the keyboard matrix would be completely incompatible.
The joystick ports are also scanned as part of the keyboard matrix, so you'd have to keep that separate, ditch the joysticks, or something else. That means that you don't really have the option of deleting that much code, which poses another problem because the Cody Computer's (emulated) 8-kilobyte ROM is already full from the BASIC interpreter, runtime routines, and default character set. You can also move that around and expand the boundary, but again, that introduces yet more changes so it would be harder for people to share programs, particularly low-level ones. It also reduces the sense of it really being a retro 8-bit computer.
If the Cherry MX switches are too expensive, you've got better options:
1. Buy some knockoff switches off Amazon, Alibaba, or whatever; I'm seeing 32-packs of Cherry clones for $10 to $15, tops.
2. Get a piece of junk mechanical keyboard that's really only good for scrap and try to desolder and salvage 32 of the switches.
3. Redesign the KiCad file for the keyboard to take tact switches. That said, if you're going to buy a board, an additional $10 or so for switches isn't that bad. (The very first keyboard we did actually had more keys, but all of them were tact switches; it was a neat keyboard but it wasn't a joy to type on.)
But for the Propeller itself, there's actually a driver for PS/2 keyboards and mice written by Kwabena Agyeman. It's up on the OBEX (https://obex.parallax.com/obex/combo-ps2-keyboard-and-mouse-...) which is a good place to look for Propeller-related code. I've never used that driver personally, but that's where I would start.