65816

An Updated Roadmap for JR/OS

The origins of JR/OS date back to my ill-fated COLE-2 project. I had originally envisioned it as being a simple single-tasking OS that could run on a variety of hardware. There would be a BIOS layer that interfaced to the hardware, with the actual operating system interfacing to the BIOS. JR/OS would not provide much functionality other than device and file system management.

Over the last year it has become apparent that there will probably never will be a plethora of 65816-based systems. It’s just not as popular a target for hobbyists compared to the 6502. I decided that the only systems I should worry about supporting are my own. Thus the BIOS/OS separation fell away to become just JR/OS.

Freed from the constraints of having to run on a variety of differing hardware, a more ambitious goal for JR/OS began to crystallize. JR/OS will be a full multitasking OS with memory protection, virtual memory, and a POSIX user space environment. It goes without saying that this is a much bigger project than my original plans. However, I think the journey will be fun and educational even if it doesn’t get to its destination.

To maximize my chance of success I am going to do this in phases. The idea is to make JR/OS usable for user space programs as quickly as possible. I will then add functionality in manageable chunks. Each phase will add tangible functionality, which should hopefully keep me motivated to keep moving to the next phase.

Required Features

Before I delve into the phases of this road map i want to go over some requirements I have. These are in addition to the core OS features such as multitasking and memory protection:

  1. The system must be usable at power-on even without booting from storage. This means booting into a ROM-based BASIC interpreter.
  2. The BASIC interpreter must support storage (LOAD, SAVE, OPEN, etc).
  3. If storage is detected at boot time the system must attempt to boot from it.
  4. The system monitor must always be available.

If it is not obvious I am basing my design on the Apple II (or more accurately the IIGS). This should not be surprising, given my stated desire to create a modern evolution of the IIGS.

With these requirements out of the way let’s take a look at how I’m planning to build all this.

Phase 1: User space environment

The first phase is the easiest, and the one on which I will be starting work this week. In this phase I will get the user space environment fleshed out enough that it’s possible to write functional applications.

For me to consider this phase “done” the user space must provide the following minimum features:

  1. Full console I/O
  2. Memory management (allocate and deallocate memory)
  3. Device access (serial ports, SPI devices, SD cards)

Much, if not most, of this is already implemented in some form, but there are some gaps to plug. The largest of these is that memory allocation needs to be wrapped in some sort of standard library. This is because memory management will eventually move to user space, and I want the change to be transparent.

Phase 2: File system support

The next step will be to implement a file system. The ability to load and save files is critical for writing any truly usable software. Since the hardware only supports SD cards it makes sense to use FAT32 as my file system. The current JR/OS code already has some support for this: FAT32 partitions are detected and enumerated at boot time.

It is in this phase that I’ll also be adding the ability to automatically boot from storage. If no boot media is found then the built-in BASIC will be launched.

Phase 3: Preemptive multitasking

This is where things will start getting really interesting. In this phase JR/OS will gain support for multiple processes and preemptive multitasking, but without virtual memory or memory protection. In this sense it will resemble GNO/ME.

It is also in this phase that JR/OS will implement multiple user IDs and multiple privilege levels. Theoretically at this point JR/OS could support multiple simultaneous users by spawning a console on the second serial port. However, I am not actively planning on implementing this at this point.

One thing I will need to iron out in this phase is how to support the system monitor going forward. Currently the monitor is basically a user application running with root privileges. It uses the JR/OS direct page and stack, and directly accesses some JR/OS internals. The monitor will need converted to a regular application here and divorced as much as possible from JR/OS itself.

Phase 4: Virtual memory support

This phase will begin once JRC-2 hardware is available, as it will require a PMMU. In this phase I will move memory management into the user space runtime. JR/OS will continue to manage its own memory allocations, but only provide VM support for user space.

Phases 5+: ???

Beyond phase 4 my road map is currently undefined. A major part of these phases will likely be making fleshing out POSIX support in user space.

I may add networking support here, though it would probably be limited to a PPP link. I don’t even know where to begin building an Ethernet card.

Another very lofty goal that would fit in here somewhere is to implement a IIGS-compatibility mode in JR/OS. This is purely a pie-in-the-sky idea right now. I have barely scratched the surface of how this might be accomplished.

Final Thoughts

As I mentioned at the start, this is a very ambitious road map. I can’t even begin to estimate how long it will take, especially considering my unpredictable periods of burnout. Only time will tell…

JRC-1, One Year Later

JRC-1

It has been just over one year since I assembled my first build of JRC-1. It’s also been that long since my last significant post here, but despite the radio silence I have been making steady progress and I’d like to share that now.

Firmware Updates

First, and most importantly, the firmware has seen a lot of improvement. This includes:

  • I made the ROM code 16-bit clean. Much of the ROM code originated on my COLE-1 board, which was a plain 65C02, and had been updated just enough to work on the 65816. Now, everything except low-level driver code runs in 16-bit mode by default.
  • I implemented a device manager and registered the built-in hardware as devices.
  • There is now a functioning SD card driver for reading and writing blocks.
  • Implemented the initial scaffolding of a DOS, including scanning devices at startup and reading DOS-style partition tables.
  • Created a built-in mini assembler reminiscent of the Apple IIGS mini assembler. There is still work to be done here but it is already usable for writing small programs.
  • I created an Apple IIGS-style memory manager to manage allocation of memory to both the OS and user space programs
  • The code base got a fair amount of reorganization as the amount of code continues to grow. This includes not only physical file layout but also changes to how the various layers of the operating system (core OS, device drivers, DOS, and the system monitor) interoperate.
  • Added a Makefile target for the memSIM2 ROM emulator. This USB device emulates the physical EEPROM and allows me to upload new code directly to the board (including a reset afterward) with no fuss. Testing a new ROM image can now be done in just seconds.

Hardware Updates

There have only been two hardware changes in the last year:

  • I installed a bodge wire from the 65SPI’s external clock input to PB7 on the VIA. SD cards (at least the one I am using) cannot reliably be initialized without starting with a slower SPI clock. The bodge allows the VIA to be programmed to provide a slow initialization clock for SD card initialization; once the card is initialized it switches back to the faster, PHI2-based clock.
  • I installed a 16 MHz crystal in the board, bringing the system clock up to 8 MHz. The board has been rock-solid at this speed for several months now. This is already better than I expected, and it’s possible I might be able to squeeze out another 1-2 MHz down the road.

Next Steps

My top priority right now is to finish the mini assembler, as having the ability to easily write code directly on the system makes testing ideas much easier. I am hoping to have this completed by the new year.

After the mini assembler I have a number of subprojects that need attention:

  • Building out the scaffolding for supporting task switching (multiple processes).
  • Fleshing out the user space environment so that actual user space programs can be written
  • Implementing a FAT32 driver
  • Developing a BASIC interpreter application. This will require the user space environment to be usable.

I also have an updated road map for the future of JR/OS as a whole. I had originally had that here, but this post was getting rather long, so look for another new post very shortly.

A Quick JRC-1 Update

Well folks, today the JRC-1 project reached a major milestone: the design is complete, and parts and PC boards have been ordered!

KiCad 3-D rendering of the final board design.

I should to have everything in my hands in about a week, and with some luck, a working assembled board a few days after that.

Ordering PC boards is always a bit nerve wracking for me. One can never be 100% sure that a board is going to work until you get them back from the fab house and try assembling one. In addition, the final JRC-1 board comes in at 200×120 mm, which is considerably larger (and more expensive) than any of my previous designs. Still, I am very relieved to have finally hit this milestone, and assuming no major problems arise with the design I can shift my focus to creating the BIOS and operating system.

Over the next few days I will be copying most of the information from my private JRC-1 planning document over to the JRC-1 home page. This will include information such as the memory layout, component information, and details on the expansion slots and user port. Stay tuned.

COLE-1+ is alive

I’m happy to report that the first build of COLE-1+ is up and running! JLCPCB created some beautiful boards and delivered them almost exactly a week after I put in my order. Here’s a photo of the assembled board:

There were only two fixes I had to make to the board after delivery. One is to add the missing pullup resistor on the ACIA IRQ line that I mentioned in my previous post; the other was a bodge wire to bring the A11 address line to the GAL. With those two fixes the board works exactly as expected.

Not only does this board run its original firmware just fine, it also runs a slightly modified version of the COLE2 firmware, and this is the firmware version I am going to use going forward. My plan is to make this a universal BIOS for all of my future 65816 builds. This will allow me to continue development on the firmware while I plan out and design JRC-1.

In the end I am very happy with this build. I may do a re-spin of it down the road to correct the two errors I had to correct, and possibly add a power switch, just so that I can turn the unit off to pull the EEPROM without having to disconnect the USB serial cable. But, for now I’m going to concentrate on the firmware and on the JRC-1 design.

New Year’s Update

Happy New Year to everyone reading this much belated status update! I apologize for the radio silence, but I took a break from this project over the summer. I came back to it en force in late November, taking advantage of my holiday time off to really sink my teeth into it again. Quite a few things changed, so let’s dive right into it.

It’s Alive….Alive!

My first goal when coming back to the project was to get the new build booting to a serial console. To make this easier I threw together a bus analyzer using a Raspberry Pi and some MCP23017 I2C I/O expanders that I had in my parts bin. With two of them, plus some Python code, I was able to have the RPi monitor the CPU buses while pulsing the system clock. This severely cut down the time it took for me to find the various wiring mistakes, and it was useful enough that I hope to someday create a more permanent version of it for future builds.

At this point I had a booting system, but it was not very stable. I partly solved this by switching (no pun intended) to a better bench power supply. The big change, though, was getting rid of all of the discrete logic, which brings us to…

The COLE System Controller

The CSC is the core of the system and is responsible for managing the system buses. It’s implemented on a Xilinx XC9572XL CPLD, and it’s responsible for:

  • Bank address latching
  • High address line generation (A16-A18)
  • Chip selection for RAM, ROM, and I/O
  • IRQ aggregation

In the previous build, the bank address was latched by a 74ACT73, which remained open (transparent) during Φ2 low, but closed and latched the bank address on the Φ2 rising edge. This is the design recommended by WDC in their application notes for the 65816.

When I first implemented this design in the CSC it made the system even more unstable. However, by switching my design to latch the bank address on the Φ2 rising edge the system suddenly became rock solid I don’t know the reason for this, but since it works I am going to leave it as-is. The only real downside to this design is that my address decoding is not as fast as it could be, and thus I would need faster RAM and ROM for any given clock speed.

TIVI

With the system booting reliably I next turned my attention to getting video into a working state again. The new video controller is called the TIVI, or (TI)ny (V)ideo (I)nterface, and is implemented on a TinyFPGA.

The TinyFPGA is a wonderful and inexpensive piece of hardware, but it does suffer from one major problem: a lack of user-accessible I/O pins. There are far too few pins available to connect it to any sort of external RAM. Fortunately, the TinyFPGA has 16 KB of on-chip dual-port block RAM. which is just enough for text and basic graphics.

Since the video RAM is on-chip the TIVI chip operates like many old-school CRTC chips, and provides registers for reading and writing video RAM. This isn’t as bad as it sounds; through the use of an auto-incrementing address register the CPU can read/write contiguous chunks of video RAM at full speed.

The output from the TIVI is an analog VGA signal with a resolution of 640×400 pixels, at a refresh rate of 85 Hz. I chose this mode because it uses a 31.5 MHz pixel clock, which the TinyFPGA’s PLL can synthesize exactly. Standard 640×480, by contrast, uses a 25.175 MHz clock, but the closest value the PLL can generate is 25 MHz. While it’s close, and it sort of works with my LCD monitor, it is technically out of spec.

Due to the small amount of available VRAM the TIVI can’t output an actual 640×400 image. The current design implements two video modes:

  • 80×25 text, with 8 background and 16 foreground colors, hardware blink, a programmable hardware cursor, and a programmable font.
  • 160×100 graphics in 6-bit color.

The text mode uses an 8×16 font stored in the high 4K of VRAM. The BIOS loads the font from ROM at startup, and when switching from graphics mode back to text mode.

Down the road I would like to try adding hardware scrolling, at least for text mode. I may also add a higher res mode such as 320×200, but this is not a priority for me.

The Speed Force

In this new build the TIVI generates the system clock by dividing its 63 MHz master clock by a programmable divisor. The default value is 24, which produces a system clock of 63/((24+1)*2) = 63/50 = 1.26 MHz. I chose this value because breadboard builds aren’t the best for grounding and noise, and 1.26 MHz is an easily attainable target in these conditions.

With the TIVI chip now accessible by the CPU I was able to twiddle the divisor after boot and see how fast I could push the system. So far I have had good success running with a divisor as low as 4, which equates to a system clock of 6.3 MHz! This exceeds my original design goal by a whopping 20%. It may be able to run a bit faster, but the next lower divisor produces 7.87 MHz, which instantly freezes the system.

The COLE Input Controller

The CIC is an ATmega 328p that handles all user input, including the keyboard, the mouse, and both game pads. It connects to the rest of the system via SPI. It’s similar to the 8042 keyboard controller in IBM PCs; it handles the low-level communications with devices, freeing the CPU for other tasks. It also manages the system’s RESET and NMI signals. This includes the initial power-on reset function previously handled by a dedicated IC.

Unlike my previous build the CIC does not do PS/2 scan code conversions, nor does it manage the LEDs automatically. Instead, raw PS/2 scan codes are fed to the CPU, which is now responsible for key mapping and LED management. It does, however, watch for some special key sequence and act upon them. Pressing Ctrl-Alt-Delete will reset the system, and Ctrl-Alt-Break will toggle the NMI line. Since the CIC handles these directly they are guaranteed to work even when the rest of the system is non-responsive.

The SPI/65B

My original build used two 6522 VIAs. One was dedicated to receiving data from the CIC, plus a bit-banged SPI implementation. The second VIA was reserved solely to the user port. There were a couple of problems with this design, however.

First, there was no way to send data to the CIC. This meant the BIOS couldn’t change key repeat rates, mouse resolution, or the keyboard LED states.

Second, the bit-banged SPI was really slow, and very CPU intensive.

Fortunately for me I stumbled upon André Fachat’s SPI/65B project, a VHDL rewrite of Daryl Rictor’s 65SPI hardware SPI controller. Daryl’s original design is wonderful, but it is written in ABEL, which is no longer supported by the Xilinx tools. André rewrote Daryl’s implementation in VHDL, with a few bug fixes and enhancements.

I was able to upload André’s design to an extra CPLD, and after a few minor tweaks I finally had working hardware SPI. This has now replaced one of the VIAs in my build, leaving just the user port VIA.

For maximum compatibility the SPI interface is running at 5V via a small level shifter. The CPLD itself is 5V tolerant, so the level shifting is only necessary on the output signals.

Now What?

With the final hardware design finally coming together, it’s almost time to start work on a PC board design. I would like get the first (and hopefully only) PCB design done and built by this spring.

There’s a lot of hard work ahead, but I’m looking forward to it!

COLE-2 Status Update

Progress for the past few days has been slower than I’d like, but hey, progress is progress right?

Hardware Updates

I’ve finally ironed out the remaining bugs in the hardware interface with the propeller. Previously I had thought things were stable, but when I attempted to read back the frame buffer in my scroll code I would get corrupted data, frequent crashes, and hard lockups. I spent two long nights trying to figure out what was wrong with my code; turns out it was a couple of hardware issue…

Bus Buffer Timing

The first problem was with the propeller’s data bus buffer, a 74LVC245 used for converting the 5V signals from the rest of the system down to 3.3V. When the propeller isn’t being accessed this buffer was being held in a high-Z state by a signal called /PROPBE generated by one of my GALs. I suspect that this signal, which was generated from the output of a second GAL, introduced enough extra lag that the buffer was not shutting off fast enough. Putting that signal back under direct propeller control solved the random crashes and data corruption, but not the lockups.

Clock instability

The second problem was with the /STP signal used for clock stretching. This signal had been giving me problems since day one due to voltage level differences. The obvious solution of using an ACT series part for the flip-flop did NOT work; despite the data sheet claiming the 74ACT74 is TTL-level compatible it would not recognize 3.3V on the /PRE input. So, I had the signal hooked up with a pull-up to 5V and was relying on the propeller to pull it low. As it turns out, this only sort of worked, and it was enough to cause the CPU clock to randomly start and stop at weird times, violating the timing specs and causing random lockups. I finally gave up and just tossed a 74HCT04 inverter in front of that signal, since I had a few on-hand, and voila! No more lockups.

The system is now rock-solid as far as I’ve been able to tell. I’ve had it running for more than 48 hours with zero issues. I may even swap out the crystal and see if I can push it up to 4 MHz; previously this made the system horrendously unstable, but with the /STP issue fixed it may finally work.

Video

With the hardware issues sorted out I was finally able to get a basic console driver working, including scrolling. To celebrate I prettied up the boot screen:

The console code is still in that “hacky but at least it works” state. Some of this is due to the fact that I have been dragging my feet on implementing a real driver architecture in my BIOS. Fixing that is high on my priority list for ROM enhancements.

Another thing the console driver is sorely lacking is a robust set of control codes. I briefly considered implementing VT-100 for compatibility with the old serial console, but VT-100 is pretty complex and way overkill for my needs (and it would require a decimal parser in the console driver…yuck). Instead I’ve decided to go more Apple II-style using control characters. Right now the only thing implemented is Ctrl-A + byte to change the text attribute byte.

Sound

Not much to report here. I would like to code up a boot sound soon, but I have zero experience with the SID. I am hoping to find some code I can borrow for that.

Keyboard

Absolutely no progress here. I did briefly work on hooking up the PS/2 connection directly through the VIA, but abandoned it; I just didn’t want the VIA doing that much polling during interrupts. So, I’m back to my original plan of using an ATmega to handle the user input devices.

SPI

After much internal debate I think I’m going to offload SPI onto the ATmega instead of the propeller. The driving force here is that my current propeller interface just doesn’t really provide for a clean way to implement SPI. The shortage of I/O pins contributed as well.

The new plan is to designate the ATmega as the I/O coprocessor; it will handle SPI in addition to the keyboard, mouse, and game controllers. I have not yet decided HOW to do this, as this means the ATmega<->VIA interface will need to be bidirectional. I do have some ideas though.

Next Steps

This week’s number one priority is to get the ATmega interface up and running. Once that’s done I will implement the keyboard code and then finally be free of the serial console for now.

Time permitting I’d also like to finally start tackling the mess that is the BIOS. In fact I may make another post this week just talking about the BIOS design, as I’m finding that these posts help me think through my issues.

As always thanks for reading! 😉

COLE-2 has video!

I said I’d post an update (with a picture) when I got the VGA console working, so here it is:

COLE-2 booting on VGA for the first time

It’s very preliminary; the screen does not scroll yet, and input is still coming from the serial port (there’s no keyboard port yet), but it does work.

One thing that is rather apparent in the above screen shot is that the weird issues with some of the punctuation symbols. I’ll dig into that after I get scrolling working.

Hardware Changes

The image above was taken using my updated hardware design that I talked about in my last post, which uses clock stretching in lieu of the 65816 RDY pin to pause the CPU during propeller accesses. The previous design rarely lasted more than a few minutes without random serial port garbage, and always crashed after a few hours at most. This new design has so far gone nearly 48 hours glitch-free, and probably would have gone longer had I not powered it down for a ROM update.

Next Steps

With basic video output working my next task is to make the console scrolling work so that it’s truly usable. After that I’ll be getting the keyboard port implemented, which I’m still planning to do using a small ATmega ‘328. It’s going to connect through the VIA so it should be a lot less work than it was getting the propeller implemented.

Stay tuned for another update later this week.

Propeller Fun

As I mentioned in my previous post I am using a Parallax Propeller in my COLE-2 SBC project. The propeller is a neat little chip. I won’t go into a whole lot of details about it here, since that is well-covered elsewhere, but the basics are that it’s an 8-core (or “cog”) processor running at 80 MHz, and is very hobbyist-friendly. It’s a bit of an odd duck from a programming point of view, but once you get used to it you can do some amazing things with it. There are literally hundreds of open source modules available implementing all sorts of software-designed peripherals so you can do a lot while writing little to no code of you own, if you so choose.

What initially drew me to the propeller is its ability to generate video signals, both composite (NTSC or PAL) and analog VGA. It’s able to do this thanks to some custom hardware included in each cog that facilitates the generation of the proper timing and the shifting out of pixel data based on that timing. You can do this with as little as one cog, although multiple cogs working together will allow you to get higher resolutions and/or better color depth. The only limitations are that is is limited to 6-bit RRGGBB color, and there is only 32 KB of shared RAM (called “hub RAM”) available for holding your frame buffer and other shared data.

Once you have the propeller integrated into your design, however, you might as well put all eight cogs to use; the only cost incurred is adding the extra driver code and maybe some I/O pins (more on that later). With that in mind I decided to see how much I could pack into that single chip.

The Bus Interface

To start with I need a way to interface the propeller to the rest of the system. Many projects just do this over a serial link; the chip can bit-bang serial at modest bit rates, and I could easily have attached it to the second port of the UART. But serial can be a real bottleneck for graphics modes, so I wanted some sort of parallel interface. In an ideal world I would let the chip pretend to be a 32 KB RAM chip, but this would eat up every single available I/O pin and would probably be overkill for the modest graphics modes the chip is capable of producing. So, I decided to borrow from the 1970s-era TMS9918, which did all configuration and VRAM access through just two addressable registers. This means I only need 1 address input instead of 15.

To implement this I connected the propeller to 14 signals bus: D0-D7, Φ2, /IOSEL2 (from my address decoder GAL), RWB, RDY, and /IRQ. The RDY line would be held low to halt the CPU while the propeller responds to a bus request, since it’s not fast enough to keep up with the CPU at full speed. All of these signals would be fed through a pair of 74LVC245 buffers, because the propeller is a 3.3V part but the rest of my system is 5V. So far so good, or so I thought…

RDY and Waiting

As it turns out using RDY with the 65816 is not quite as straightforward as I had hoped, due to the way it multiplexes the bank address onto the data bus. The bank address is emitted during the first half of the CPU cycle, when Φ2 is low. The data bus is connected to a 74ACT573 latch, which is kept open (transparent) during Φ2 low, but which closes and captures the bank address when Φ2 goes high.

Normally this setup works fine, and in fact it’s the exact design recommended by WDC. The problem comes in when you start trying to use RDY. When RDY is pulled low, the CPU halts as soon as Φ2 transitions from high to low. The actual Φ2 clock, however, does not stop. If RDY is kept low long enough for Φ2 to go high again, the bank address latch will capture some random data bus data as the bank address, and when the CPU finally resumes it will likely access the wrong memory address.

For my test implementation I solved this by using some extra lines on a GAL to construct a latch enable signal that such that the latch remains closed as long as RDY is low. Unfortunately this seems to have made the system slightly unstable, even when the propeller is not being accessed (during which times it’s not even on the bus, as its data bus buffer is disabled until /IOSEL2 goes low while Φ2 is high.) My GALs are fast (7 ns parts), but it’s possible the extra delay is the causing the strange behavior.

For my next attempt I am going to try a different approach: halting the CPU’s Φ2 clock during the high phase using a circuit like this:

Clock generation circuit with wait stating, by BigDumbDinosaur (http://forum.6502.org/viewtopic.php?f=4&t=5229)

My current clock generator is the top half of that circuit, which means I already have the second half of the flip-flop available to use to add the bottom half; I just need to do the wiring. Once that’s done the propeller will pull /STP low instead of RDY, and my bank address latch will go back to being directly qualified by Φ2. I am hoping this will result in a stable system.

As a bonus I am hoping this new setup will solve another issue I have so far ignored; when first powering on, the propeller takes a few seconds to boot, during which it is not properly asserting RDY. This causes boots to randomly fail. With the new setup /STP will be low during this time so the CPU will not even try to boot until the propeller is up and running.

The Software

Writing the PASM code to implement the 65xx bus interface turned out to be much easier than I was expecting; I was able to hack out a working proof-of-concept implementation in a few hours. It isn’t even a lot of code; the basic code forming the main loop is just this:

mainloop    waitpeq Pin_PHI2, Pin_CS_PHI2       'Wait for /CS to go low with PHI2 high
            andn    outa, Pin_RDY               'Pull RDY low
            mov     _in, ina                    'Capture the input port
            and     _in, Pin_RS WZ,NR           'Check RS bit (0 = vram, 1 = registers)
            and     _in, Pin_RWB                'Mask RWB bit for later
    if_e    jmp     #:vram
            tjz     _in, #write_register
            jmp     #read_register
:vram       tjz     _in, #write_vram
            jmp     #read_vram

'' Common code for all ops; unhalts the CPU, waits for /CS to go high and then loops

finish_request
            or      outa, Pin_RDY               'Unpause the CPU
            waitpeq Pin_CS, Pin_CS              'Wait for /CS to go high again
            andn    dira, Pins_Data             'Set data bus pins to high-Z (input state)
            jmp     #mainloop                   'Rinse and repeat

In the end I had a working setup in which reading the propeller on either I/O port would return a constantly incrementing byte, which I could also change by writing to either port. This allowed me to verify that the bus interface was working properly.

With the test code working I’ve started adding useful functionality. So far I’ve gotten the VRAM read and write working, and I’ve been able to successfully fill the screen with characters using assembly code running on the main CPU.

Video

At the moment the video output is being driven by the “80×25 C0DF” driver from the waitvid.2048 repository. It generates 80×25 text using a 9×16 font; each character has an attribute byte associated with it that points to a 256-entry color palette. Each color entry in turn consists of a foreground/background color pair and a blink bit. The driver also supports two independent hardware cursors that can be a block or an underline, with or without blinking. The video buffer, color palette, and the font are all in hub RAM, so in theory they could all be made changeable by the main CPU.

I would like to offer the ability to switch to an alternate video driver (either a limited resolution bitmap, or perhaps a tiled driver with sprites), but as of yet I have not worked out how to accomplish this.

Sound

Since I have video the most natural choice for another thing to add is audio. As it turns out someone has written a Propeller module called SIDcog that emulates the C64 SID chip. It takes only a single cog to run, uses very little hub RAM (just a couple dozen bytes for registers) and only two I/O pins.

The SIDcog module is very simple to use; you tell it what pins to use for left/right audio, and it returns a pointer to a block of emulated SID registers in hub memory. Reading or writing those locations will affect the emulated SID just like it would a real one. So, in theory, once I’ve finished implementing the write_register function in my bus interface I will be able to play sound.

SPI

An SPI cog is the last piece I plan to add, since at that point I will be almost out of I/O pins. The propeller will handle the actual SPI transfers and signal the main CPU via interrupt once the transfer is complete. To allow reading or writing of entire SDcard blocks I plan to implement a small 512-byte buffer. I am not yet sure how this will be implemented at the bus interface side but I have some ideas.

Future Work

At the moment I’m hard at work getting the bus interface fully implemented. My focus is on getting the video registers implemented enough that I can try redirecting the console output to VGA. Expect another post (with pictures) once that VGA boot screen is working!

COLE-2 is born

NOTE: I’m going to experiment with turning on commenting, starting with this post. We’ll see how it goes.

The nice thing about creating things as a hobby is that you can switch to a new thing whenever you get bored or frustrated with the current thing. That is exactly what happened to me a few months ago: I started getting frustrated with the limited features I had available on COLE-1, so I decided to just jump ahead and start the next iteration. The result is this:

That ugly mess of wires is actually a functional 2 MHz 65816-based SBC, called, not surprisingly, COLE-2.

Hardware Overview

COLE-2 will be a substantial upgrade from its predecessor:

  • 6 MHz 65C816 CPU (largely limited by EEPROM speeds)
  • 1 MB of RAM
  • 256 KB of ROM w/ full system monitor, OS, and 16-bit BASIC
  • Glue logic moved to two 22V10 GALs
  • 28L92 Dual UART providing two DB-9 serial ports
  • 80 MHz Parallax Propeller for analog VGA video, stereo audio, and SPI
  • ATmega328p for PS/2 keyboard/mouse and two NES-compatible game ports
  • Dual 65C22 Versatile Interface Adapters
  • SD card reader
  • A user port
  • A single expansion slot

When I started this project my goal was to produce another headless SBC similar to COLE-1, but with an expansion slot that would act as a platform for developing my custom CPLD-based video system. However it became apparent that I was trying to take too big of a leap there, and so I decided to add basic on-board video as an interim step.

My current prototype is scaled down from the final specs, since it’s implemented on solderless breadboards. It only runs at 2 MHz, and has only 512 KB of RAM, 32 KB of ROM, one VIA, and no ATmega. Much of this is just due to lack of space on the breadboard; as you can see I’m already spilling out onto additional boards, and all those long wire runs take their toll on stability, especially at higher speeds. My plan is to squeeze the ATmega in there somewhere to get a working keyboard port, and then move on to designing the PCB and building a full prototype.

In my next post I will dive into how I integrated the Propeller into my design.