I've been working on the Cody Computer off and on for a couple of years in one way or another but finally decided to post some build-in-progress news and pictures; there are a couple of postings I've made on the site regarding particular 65C02-related questions but nothing in detail regarding the build. Eventually the idea is to end up with an open-source and (relatively) easy-to-build homage to the 8 bits that I grew up with as a small child, although one that you can actually solder together chip-by-chip, 3D print a case and cartridges for, and so on.

The electronic design is in many ways a spiritual successor to the Propeller-based 65C02 projects posted a few years back, and most of my initial inspiration came from Jac Goudsmit's Propeddle project. Clock generation (1 MHz), address decoding, and so forth are all performed from within a very tight cycle-counted loop running on one of the Propeller's cores, taking special care to ensure that any accesses to the Propeller's hub memory are aligned with the hub window (else from the rest of the circuit's perspective the clock signal will be inconsistent, throwing off counters in the 65C22 and so on).

Video generation (and eventually sound generation) all occur within other cores on the Propeller, with the final goal being something like a stripped-down C64 or Atari 800-style system, albeit one with a single 160x200 fat-pixel video mode. I/O occurs through a 65C22 that both scans a minimalist keyboard and allows interfacing with an SPI bus, the latter of which is also used to read from a custom cartridge design sporting either an SPI EEPROM or SPI FRAM chip. Operationally the Propeller serves the same purpose as something like the TED chip did in the Commodore Plus/4 series, and then some, although the overall spirit of the machine is definitely more C64 than Plus/4 at this juncture.

The current keyboard scanning logic uses a 4051 along with the 65C22 in a manner almost identical to that of the Oric (and documented in Garth Wilson's circuit potpourri page), although with a keyboard layout. The prototype keyboard pictured below is just using regular tact switches soldered to a PCB and connected to 3D-printed "keycaps" with decals; some of that's going to change for the final build, but it was enough to get me to a "TV Typewriter"-like level with the board. I'm still working on the keyboard design to a significant extent, and my wife has helped me get our 3D printer dialed in sufficiently that I might be able to print the keycap legends directly on the keycaps in a pseudo-double-shot-keycap fashion (though it will mean simplifying the keycap legends significantly, something more like a toy typewriter than a C64, but I can still have ATASCII or PETSCII-style symbols readily available via escape codes rather than special key combinations).

I've attached some pictures of the evolution of the design over the years as it's been something I'd work on when time permits. Many of them also include the computer's namesake, Cody, who was my near-constant companion on the project and inspired most of my key design decisions based on the number of smiles, tail wags, or happy little huffs for each alternative I showed him. He passed away all too soon recently at the age of 14, and it's been quite different working on this without his company; I'm quite sure it would have languished on a shelf collecting dust if not for how excited and happy he always seemed to get when he was sitting beside me working on electronics, and while he got to see so much of the work that went into it, I'll forever regret that I'll never get to sit beside him and show him its conclusion.

There's still obviously a lot to do before it's finished, but given the amount of information I've gleaned from this forum, I thought sharing the progress so far might give someone else an idea or inspiration in the same way that so many of your posts have given me. There are still some portions of the design that I need to cinch down with respect to I/O and so forth, at which point I need to design and send off for a board with that as well. Most of the remaining "hard work" is going to be on the software side, as most of what I've written thus far have been one-off programs to verify particular functionality or test out some ideas rather than writing anything along the lines of a Commodore-style kernel much less a BASIC interpreter; similarly, there's a lot left on the Propeller side in terms of refactoring the video generation code and writing the remaining audio and I/O code for what are effectively other virtual peripherals.

Some photos are attached; I'll update with posts as time permits and progress dictates.

Thanks for the details and photos! Sorry to hear you lost your companion.

I thought I'd post an update regarding progress through August and September.

The keyboard is coming along rather nicely. Instead of the tact switch "keyboard" in the previous post, I now have a keyboard using Cherry MX blues with 3D-printed keycaps. The legends are actually printed into the keycaps in a different color. The actual process is similar to posts you'll find online where people print keycaps/buttons upside-down with the first couple of layers using different colors, but we had problems getting our printer consistently dialed in such that the legends wouldn't get blurry; instead what we do is print the very top of each keycap in black, switch out the filament to print some interior layers in white, then switch back out to black to print the remainder of the keycap. The keycaps themselves were designed in OpenSCAD with the legends designed in Inkscape and imported into OpenSCAD as part of rendering the individual keycap portions for printing.

I've also had quite a bit of luck on the software side insofar as the beginnings of a Tiny Basic implementation are starting to take shape. I initially started by cleaning up the TV Typewriter-style terminal program I already had in place, then started adding some subroutines to parse an input string buffer into tokens for various commands, strings, 16-bit integers, and so on. I started to get worried about the overall size of a tokenized BASIC since there's so much overhead in terms of the code for encoding and decoding tokens and briefly sketched out the beginnings of a direct interpreter more like Tiny Basic (but with subroutine-threaded code rather than a virtual machine implementation). However, in the end I continued with the tokenized approach. Right now the tokenization seems solid and I'm able to add and remove lines by line number, so the next steps will be trying to tidy up what I have a bit and consolidate my progress; after that it'll be time to start actually writing the code for command and expression evaluation.

I am planning to make some particular excursions from the Tiny Basic "standard", such as there is one, for support of strings and arrays. My current thought is to allow a DIM statement that would let you effectively allocate n+1 bytes (for a null-terminated string) or n words (for an integer array), storing the pointer in the provided variable; array dereferencing, use of $ to indicate a string value, etc., would provide additional information at evaluation time to treat the value as a pointer of the specified type rather than a word. This obviously removes the bounds-checking and similar guarantees typical of BASIC, so you can cause a lot of mayhem in short order if you aren't careful. On the other hand, it seems to me to be a reasonable tradeoff for expanding the system's capabilities without unduly complicating the interpreter, and it's likely no less error-prone than something like Forth or BCPL.

Right now the code that I do have clocks in at under 2 kilobytes when assembled; that includes the "Cody Basic" so far, along with the supporting code I've dragged in for the on-screen terminal, support code for bulk memory operations (heavily borrowed from Bruce Clark's memory routines), and so on. As noted above, no code has been written yet for expression evaluation and so on, and I haven't included my SPI routines yet either. I do not expect to squeeze the remainder in such that I can fit the entirety in 4k, though that may at least be in part to my own ignorance; a better 6502 developer with an eye for space optimization could probably do better.

Wow, that keyboard is impressive.

Very good job!

How are you handling the voltage differences between the Prop and the CPU? Are you running the CPU at 3v3?
Any schematics?

_________________
Cat; the other white meat.

I've got to say, I love those little cartridges! They actually remind me a bit of Fujitsu's bubble memory carts for the FM-8.

These obviously don't work the same as more traditional ROM cartridges do, but one probably could get clever and still add additional devices (sound chips were a popular addition on MSX carts) using some sort of SPI addressing scheme or something like that.

_________________
Curt J. Sampson - github.com/0cjs

@cbmeeks:

Thanks! Your inference that I'm running at 3.3 volts was correct; considering the entire machine is running at 1 MHz, the remaining ICs on the board are 3V-friendly, and that the only expansions I plan to have will be via the SPI (and potentially I2C) connections, I didn't think it made much sense to go with 5 volts.

No schematics as of yet, I do have some stuff in KiCad but the only part that's in anything approximating a final form is the keyboard schematic and PCB that I sent off to get some boards made. When this is actually at a finished stage, I plan to put up KiCad schematics for the entirety of the Cody Computer, along with the sources for Cody Basic and the OpenSCAD and STL files to be able to print all the hardware. What I'd really like to do is document it in a (free) ebook along the lines of Grossblatt's "The 8088 Project Book" but written in the style of 1980s computer books for children, complete with a little Pomeranian caricature named Cody living throughout the pages and pointing out important details as you go through it. On the other hand, I actually have to get this thing done first, but that's the end goal.

@cjs:

Also thanks! I spent quite a bit of time trying to come up with a decent design for them, particularly the enclosure/packaging; I got my first computer (Commodore 64) when I was just three, and as you might imagine I had a lot more software on cartridge than on disk at that age, so I wanted to have a more modern and compact form of those cartridges. It basically came down to SD cards, CF cards, or something custom, and within the choice of something custom, some kind of I2C or SPI based memory, and what kind. SD cards didn't seem like a good fit, CF cards don't exactly have a friendly connector, and when little Cody was around, for whatever reason, he would wag and get really excited when I'd talk about SPI, and he sniffed/wagged for the Fujitsu ferroelectric RAM ICs more than any of the other stuff I played around with, so that's what I settled on. That said, I did make the prototype batch of cartridges with a pin-compatible and protocol-compatible (for my purposes) EEPROM rated for upward of a million writes, as I didn't want to get unduly boxed in if the FeRAM stops being available in DIP form.

You're quite right about the SPI subsystem being useful for expansion, and in fact that's my intention; one expansion port will have a pinout for the cartridges themselves, and the same SPI lines and remaining SPI /selects will go to a different expansion connector so you can plug other devices in. Finalizing the SPI portion has been one of my focuses recently and I'm actually going to post a subsequent update about that.

January update:

I've gotten Cody Basic (the Tiny Basic-like dialect I mentioned above) more or less completely finished; along with a few kernel-like routines for things like keyboard scanning and SPI operations, it clocks in around 6 kilobytes in size.

Along with the typical Tiny Basic commands, it also supports strings and arrays, albeit in a very nonstandard way even by Tiny Basic standards. Arrays consisting of signed 16-bit integers can be allocated from the heap using a "DIM X(n)" style syntax (note the parentheses) whereas arrays consisting of unsigned bytes can be allocated from the heap using a "DIM X[n]" syntax (note the brackets). Either form of the command populates the variable with the address in the heap, effectively acting as an untyped pointer; deferencing with brackets treats it as a byte array, dereferencing with parentheses treats it as a word array, and dereferencing with a trailing $ treats it as a null-terminated string. When strings are used as an rvalue in LET statements, this is noted by the interpreter to ensure that the lvalue is also being treated as a string; in such situations, the contents of the string on the right are copied into the memory on the left.

The array and string implementation is obviously less type-safe and memory-safe than operations under something more traditional BASIC implementations, but I'm happy with the tradeoffs involved. In many respects, Cody Basic should be viewed as a tokenized, BCPL-inspired or C-inspired dialect of Tiny Basic. Some relatively simple type checks occur during LET statements, and reads and writes involving string or array types are checked against the heap bounds under most circumstances, but it still does require a degree of consideration not typical to most BASIC dialects outside of PEEK/POKE operations.

It also supports DATA statements that build on the above operations. Once an array is allocated, you can use its address in the form of a RESTORE statement, which sets a variable in the BASIC interpreter. Subsequent DATA operations populate the contents of the array and increment the internally-held pointer; DATA statements can either contain strings (which are copied into newly-allocated memory from the heap and the pointer stored in the array) or integers (which are directly copied into the array). As with most other operations impacting the heap, these operations also undergo bounds-checking to minimize the chance of things going completely awry.

I've also gotten SPI operations more or less working, though I've really only tested them using mode 0 SPI operations. The operations exist at a low level in the kernel but are exposed via the SPISHIFT command in Cody Basic. The SPISHIFT operation takes an SPI "port" number (decoded in the circuitry), an SPI mode number, a length in bytes, and a variable; the variable is interpreted as a pointer to an array of bytes, and each byte is shifted out to the specified device and replaced in the array with the byte clocked in. As a simple test, I'm able to directly control an MCP23S17 for the obligatory display of blinkenlights.

As mentioned/discussed above, the SPI operations also form the basis for data storage and retrieval using the cartridges depicted above. This is where it gets particularly exciting as while the storage is solid-state, the inspiration behind how it works borrows more from old cassette drives and in particular the stringy-floppy drives. The theory of operation is that each cartridge can be viewed as a sequence of 256-byte pages/blocks, reflective of the internal operation of most serial EEPROM-like devices. This page number (essentially the high bytes of the address) can be viewed as a more accurate equivalent to old tape drives that used a mechanical counter to reference the start and stop of programs stored on tape. Kernel and Cody Basic operations use this concept to permit the storage and retrieval of files via the SEEK, HEAD, LOAD, and SAVE commands.

For example, to save the current file on the first page of the first device, one would issue "SEEK 0, 0" to specify page 0 on device 0, followed by "SAVE" to save the current program; the new position can be read via the "HEAD" command, indicating the next "safe" position on the cartridge. A similar sequence of operations but using the "LOAD" command will retrieve a program from the cartridge. Beyond that, there's not a lot of checks in terms of ensuring that the file is valid, that you're not overwriting an existing program, or anything of that sort, though I do write some sentinel values along with the data, and I may elect to build on that to add some minimal level of safety in terms of load and save operations. For now, though, you'd better have a good memory or write stuff down on an index card.

Photos are attached, hopefully in a meaningful sequence. Also, if it's preferred to not post so many images, let me know and I can refrain from doing so, or link them off the site; I'm not sure what the moderators, if any, would prefer, and at this point this is turning more into my own personal build diary anyway.

EDIT: It looks like I should've added them in reverse order; they'll make more sense if you read the photos from bottom to top, unfortunately.

I like it! Especially the two types of array. Thanks for the progress report. (And for the photos. You can, I think, visit each photo using the drop-down and then the 'place inline' button, to put them into a more controllable order. Or, as you say, add them in reverse order. But it's no big deal.)