The blog has moved (a little bit)

When I first transitioned my personal blog to the Area 73 name, the only reasonable domain name available was “area73.us”. At the time I was fine with it; it is short and easy to remember. However, it recently came to my attention that the “area73.org” and “area73.net” names have become available as well. Of course I immediately purchased them both, and how I am happy to report that this blog officially lives at area73.org! In fact, you can access it at any of the three domains, though they will all redirect to area73.org.

For the time being I have no plans to decommission the original area73.us, so any page links out in the wild will continue to work. However I still suggest updating your bookmarks to use the new canonical site name.

Now if only area73.com would become available…

JRC-1 Has Officially Arrived!

I’m happy to report that the JRC-1 boards arrived a few days ago, and exactly as I predicted I had a build up and running by Christmas. Here it is, in all of its black solder mask glory:

JRC-1 as of 2021-12-23

I guess the third time’s a charm, because this is my third full build, and the board booted up with no hardware issues. It’s currently running at 4 MHz; it should run faster but I have not tried yet.

The board is not perfect; there are a couple minor problems with the layout. The footprints for the DS1813s (the reset and NMI controllers) are reversed, and the footprints for the expansion slots don’t fit the slot connectors I have. Neither problem is critical and both have easy workarounds, so at this point I am considering this design final. All of the the hardware design files (KiCad project and CPLD Verilog project), as well as the latest firmware code, are in the JRC-1 GitHub repository.

With the board up and running I am turning my attention to the firmware. Currently I’m working on cleaning up the code so that I can start the major work. Next up is getting the SD card driver working, and then work on JR/OS. That’s where the real fun begins!

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.

Expansion Bus Woes

When I first start planning the JRC-1, my main goal was to produce a simple base design with which I could experiment with more advanced features down the road. Something akin to the original IBM PC, except with a 65816. Meeting that goal meant I needed some sort of expansion bus.

The Design

Before I started any design work I ran my original plans by the folks at the 6502 forums. There are a lot of very smart people there who have experience with these things, and I trust their advice. The recommendation was that I not bring the system buses out of the slots. Instead, I should create an expansion bus behind a 6522 VIA.

After a few iterations I settled on a bus design. My bus looked very similar to the typical bus you might find on a RAM or ROM chip. It has six address lines, eight data lines, a R/W signal, a slot enable, and an I/O strobe. A pulse on the I/O strobe signals the card to perform a transaction. This design was chosen to interface to as many available peripheral chips as possible with minimal additional logic. It also fits on a single VIA, so I could test the design on COLE-1+.

The Experiment

At this point I need to mention that the deal-breaker application for any expansion bus is that I can create a video card for it. Sp. I adapted the TIVI code that I wrote for the TinyFPGA board to run on my ULX3S and hooked it up to COLE-1+. The results were….less than encouraging.

The whole setup was terribly unreliable. Sustained writes would frequently result in missed or duplicated bus transactions and thus garbled frame buffer data. Hooking up a scope did not reveal anything wrong at the signal level. The signals were very clean, and there was very little ringing or cross-talk. Manually slowing things down in code did not help at all, either.

I have spent many hours in the past week trying to fix this issue without success. My working theory is that the relatively high rise/fall times on the strobe line may be problematic. At 50 ns it might very well be causing metastability issues inside the FPGA. Given enough time I could probably make this work, but my frustration level has reached maximum.

Moving Forward

After a lot of thought I’ve come to realization that my expansion bus is turning into the kind of project-killing feature that doomed COLE-2. The irony here is that I was trying to avoid this exact issue by having expansion slots in the first place!

If I want JRC-1 to actually be finished and built, then I need to move past this. Instead of trying to come up with the perfect design on my first try, I’m just going to build what I really want, and if it is unstable, or fails outright, then I learn from that and design a better version.

And so I have decided to go with an ISA-style bus that provides access to buffered versions of the main board buses. This should work fine for at least a couple of MHz, and anecdotal evidence from folks using RC2014 and ISA backplanes suggests I may be able to hit 8 MHz without too much trouble. The only way to tell for sure is to build the dang thing and see what happens!

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.

Introducing JRC-1…and COLE-1+

Apologies for the long silence on the blog; I’ve had work and health issues that ate up a considerable amount of time during the first half of the year. Fortunately that’s all over and I am returning to my many projects.

JRC-1

First, I’d like to introduce the JRC-1, or Josh’s Retro Computer 1. This is a direct successor to COLE-2, with the aim of actually bringing the design to completion. Along those lines I ditched some of the more complex features of COLE-2, including built-in video and the game/joystick ports. Instead, it has an expansion bus with three slots that can be used to add features down the road.

Unlike its predecessor, JRC-1 is a 5V design. I had previously moved to 3.3V in order to gain access to larger RAMs, but it added complexity, as some parts of the design still needed to be 5V.

At the moment JRC-1 is still in the early planning stage. Once I am confident my design can be implemented I will begin work on the schematic and PC board. I am planning to skip the home prototyping stage for this project, and instead go directly to a manufactured PCB.

COLE-1+

As part of planning out JRC-1 I have been testing some design ideas by using my original COLE-1 board. However, that board is a bit problematic: it has power instability issues, and the footprint for the 6850 is wrong and required an ugly hack.

Since having a good test bed for my design ideas is important, I decided to spend a few hours fixing up the COLE-1 design a bit:

  • The 6850 now has the correct footprint
  • Added a large electrolytic capacitor to help smooth out the power supply
  • Replaced all of the discrete logic with a single 22V10D GAL. This also allowed me to tighten up the address decoding to make all but the bottom 1K of the ROM available.
  • Swapped out the CPU for a 65C816, because it was very easy to do so.
  • Removed the dedicated 1.8432 MHz crystal for the 6850. Instead, the CPU and the 6850 now share a 3.6864 MHz crystal.
  • Reduced the serial port speed to 57.6k bps, due to the use of a double-speed clock crystal.
  • Made the board layout more compact, and made all ICs align vertically.
  • Added some silkscreen to label the pins on the expansion headers.

In the interest of time I used the FreeRouting autorouter to route the board. It actually did a pretty decent job, and I only needed to make a few tweaks to some via locations. I may give it a try for JRC-1 down the road just to see how well it works on a larger design.

The final result of this work is officially the COLE-1+, as the feature set is almost identical to COLE-1. Boards are already on order from JLCPCB; I should have them in about a week. Hopefully I didn’t mess up anything this time around!

(Nope! It seems I left off a pullup resistor for the 6850’s IRQ line. Sigh. Fortunately this will be a very simple and relatively clean fix during assembly.)

XGS on the Raspberry Pi 400

About a week and half ago I became the owner of Raspberry Pi 400, a small computer built around a Raspberry Pi 4. The kit I purchased came with a USB-C power adapter and a basic USB mouse; all I needed to supply was a monitor.

Naturally, the first thing I did after setting it up was get XGS running on it:

This was not quite as simple compiling XGS and running it, so let’s go over what changed, why it changed, and how to build XGS on the Pi after the changes.

Open GL Support on the Raspberry Pi

On older Pi models (1, 2, 3, and the Zero) the OpenGL support was provided through a proprietary firmware blob, and exposed through a set of custom GL libraries in /opt/vc/lib. Since 2017 XGS supported use of these libraries by specifying -DBCMHOST=true when running cmake.

As of the Pi 4 (and, by extension, the Pi 400) this proprietary firmware driver is no longer supported. Instead, there are now open source drivers supporting the Pi 3 and 4. They are fully integrated into Mesa now, so it is no longer necessary to link against proprietary libraries.

As a result of these changes I have decided to remove the BCMHOST option in XGS. Instead, XGS relies on SDL to pick the right driver; this will be KMSDRM when running from the console, or X11 when running from the desktop.

Note that this change has probably broken support for the Pi 1 or 2. Those models are sufficiently outdated now that I don’t feel the need to continue supporting them.

Building XGS

As of this writing Raspberry Pi OS does not ship a version of SDL with the KMSDRM driver enabled. So, before building XGS, you’ll need to build and install your own build of SDL. Fortunately this is very easy:

sudo apt-get remove -y --force-yes libsdl2-dev
sudo apt-get install libgbm-dev libdrm-dev
tar -xzvf SDL2-2.0.12.tar.gz
cd SDL2-2.0.12
./configure --host=arm-raspberry-linux-gnueabihf \
--disable-pulseaudio \
--disable-esd \
--disable-video-rpi \
--enable-video-kmsdrm
make -j4
sudo make install

You should also run raspi-config, navigate to Advanced Options -> GL Driver, and make sure you have the KMS driver selected. You’ll need to reboot after making this change.

With SDL built and the KMS driver enabled you can now build XGS:

cd xgs
mkdir build
cd build
cmake ..
make -j4

The resulting binary can be run from the desktop or direct from the console. It will open in a window when run from the desktop, and full-screen when run from the console.

The only problem I have noticed is that the video is a bit choppy when running from the console. It’s most noticeable when watching the sliding apple on the “Check startup device” screen. It does not happen when running from the desktop, so it is somehow related to the KMSDRM driver.

Raspberry Pi & the Future of XGS

XGS has certainly had a fragmented development history. I originally started it in 1996, but by 1997 development had already stalled. Five years later, in 2002, I briefly resumed work on it, but I also started a small business around that time and XGS ended up on a (virtual) shelf for nearly 15 years.

Fast forward to 2016, when I got the XGS itch again. I rewrote the code in C++ to make it easier to understand, removed non-SDL graphics support, and added a basic GUI.

By 2017 I had moved away from the project again despite making good progress. I briefly considered creating a retro emulated GS based around the Raspberry Pi (think of the C64 Mini) but that project never really got off of the ground, and by that point I was already spending the bulk of my time on other projects.

And so here we are in 2020. I’m currently between hardware projects (well sort of; more on that in another post) and I’m feeling the need to spend at least some of my free time on a software project. So, I am jumping back into XGS, with the intent of improving the Raspberry Pi support. My first task will be to create an ARM-optimized version of the M65816 emulation core. I’ve been wanting to learn ARM assembly, and this will be a great way to do that.

Stay tuned!

Moving on from COLE-2

Over the last few days I have been thinking a lot about COLE-2’s future, and I kept asking myself if it is worth taking this project all the way to a final build. After much debate I finally admitted to myself that it’s not.

This project is a stepping stone, part of a long-term plan to build my dream 65816 computer. Think of it as the Apple IIGS upgrade I wish Apple had produced 30 years ago. Each design iterates on the previous one until my goal is reached. Since COLE-2 is not the end goal, once I build it it will end up in the same drawer as COLE-1 when I start my next design. Thus I’ve decided not to pursue further work on this hardware design.

As a stepping stone I think this project has done very well for me. I learned how to design a 65816 system, how to program GALs and CPLDs, and even some FPGA skills. Now it’s time for me to take the next step towards my final goal.

The Joys of Programmable Logic

My next design will be built around the ULX3S, an FPGA development board based on the Lattice ECP5. Compared to the iCE40 I used for COLE-2’s video controller the ECP5 is a beast; it sports over 84,000 LUTs compared to the paltry 7,680 on the iCE40. With that level of resources available I can build the entire system inside the FPGA itself.

Nothing is 100% finalized yet, but my plan is to connect a 65816 directly to the FPGA. The FPGA will provide the CPU with all necessary resources, such as RAM, ROM, and I/O. Future iterations may even replace the CPU with a soft core inside the FPGA, which could let it reach speeds that a physical 65816 simply can’t achieve.

The beauty of this design is that I can iterate on it without changing the hardware at all. In theory this design can be anything once it’s built, even a IIGS-compatible build, just by changing the FPGA’s code. I think that level of freedom will keep me occupied for a very long time!

As a bonus this new design will be quite small. This will make it very easy for me to push it aside when I want to use my workbench for other projects for a while.

I don’t have a name for this project yet, other than “not COLE-3”. I’ll be thinking of names as I wait for my ULX3S to arrive, which should be before the end of the month. I’ll announce the name at that point.

Taming my home office, vintage hardware, and a quick COLE-2 update

This post is far less technical than my usual posts, but since I haven’t blogged in nearly 8 months I decided it was time to post something.

So, what have I been up to? Well, like most people, I’ve just been trying to adjust to pandemic life. I’ve been working from home since late March, and that is slated to continue until at least January. Working from home has been great in some ways (I’m saving a ton on gas and lunches), but it’s also been tough in others (distracting cats, lack of sunlight, and general malaise with my lunch choices at home). For the first couple of months it was very draining on me, but now I have adjusted and things are going much better.

Home Office Reorganization

Since I am home so much I took the opportunity to get some work done on projects around the house. One of those projects was a massive reorganization of my home office/workshop, which has been in dire need of it for many years now.

Starting conditions

My home office is not very big; it’s just a spare bedroom and is roughly 8′ x 12′. One one short wall is my actual desk, plus an old end table that pretty much is just a table for my workstation. The other short wall had some very overburdened shelves holding all my technical books, plus a self-standing equipment rack, like you may find in a data center. One of the longer walls is mostly a set of double doors, and the other has my work bench. Every inch of wall space was used, and the remaining area did not leave a lot of room to work comfortably.

New Shelving

The first thing I did was recycle about half of the books, as they were all 15-20 years out of date. The remaining books went onto some brand new shelves I installed above my desk. The old shelves then came down, and I installed two Muscle Rack shelving units along that entire wall.

The equipment rack has not had any actual rack-mountable equipment in it for at least a decade; all that remained was our MythTV/Minecraft server, the cable modem, the wifi router, a cable box, and an HD-PVR. All of that went to the new racks, and the old equipment rack went to the basement.

The end result is that I now have a ton of storage space for all my parts and equipment, and my office feels much more comfortable. I still have some work to do as far as organizing what is on the racks, but it is ten times better than before.

Vintage Hardware Collection

As you might have guessed from my SBC projects I’m a fan of vintage hardware. I am particularly found of hardware from the 1970s and 80s. Over the last 20-25 years I’ve put together a nice collection, but it has been packed away in closets. My dream has been to get it all out, cleaned up, and put on display.

With my office organized I decided to gather everything into my office and display it on my new racks. While it’s not the display I dreamed of, it’s a start. As of right now my collection consists of:

  • A ColecoVision, sans power adapter. Untested since I can’t power it up.
  • A TI-99/4A, with the speech synthesizer add-on
  • A TurboExpress handheld
  • A late-model Commodore 64, but no floppy drive
  • A ROM 03 Apple IIGS, with a 3.5″ and a 5.25″ drive, but no monitor
  • A Macintosh IIfx (won’t turn on)
  • A Macintosh Quadra 660AV (also won’t turn on)
  • A Macintosh Quadra 630
  • A Macintosh SE/30
  • An SGI Indigo. Turns on, but no video
  • A Sun SPARCstation IPX. Turns on, but no video
  • A Sun SPARCstation 20. Turns on, but no video
  • A pizza box form factor NeXT workstation. Turns on, but no video

I plan to do some future blog posts about my collection, including repair work and efforts to make them more compatible with the modern world, such as adding SD card adapters where possible.

COLE-2

I’d like to end this post with a quick update on COLE-2. I have gotten some work in on this project over the summer, and my focus has been on finalizing the hardware so I can concentrate on the software. I’ll post more about those efforts soon.

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!