Catching up: homebrew retro computer projects (Z80 and 68010)

Another catchup post, about my homebrew retro-computer projects. This started in 2016 when I made an extremely rudimentary, completely lacking in I/O capability, but extremely educational Z80 computer. I uploaded a video about it on youtube, while it was still on the breadboard stage, which demonstrated very clearly how the Z80 computer fetches and executes instructions by single-stepping the clock and inspecting the state of the data and address busses, as well as some important processor control signals at each step. Later I uploaded a short followup video to let it execute the program with a free-running clock. I also did a talk with the same demonstration at fosscomm 2016 with the final PCB version of this computer, but unfortunately there is no video of the event.

rudimentary Z80 8-bit computer

The next step was to make an improved homebrew computer, with proper I/O capabilities, which would be actually usable as a computer instead of just an educational demonstration. Initially I started designing an improved 8-bit computer based again on the Z80 processor, but soon I scrapped those plans and designed a 16-bit computer based on the Motorola 68000 processor instead.

The first video I uploaded about the 68k computer project was actually an attempt to familiarize myself with the processor by performing a similar single-stepping experiment again. This time I thought it would be fun to use a switches and LEDs panel similar to the old PDP or Altair interfaces to feed the processor with opcodes during the bus cycles. The video is somewhat long-winded, but I think if you skip the boring introduction, it’s also very educational, showing how to assemble a test program by hand, and how to coerce the 68k to single-step bus cycles while still keeping a continuously running clock, which is required for this processor to maintain its internal state.

I also uploaded a short followup progress report video shortly thereafter, with the computer constructed on a proper PCB, which shows the serial I/O interface and a bug in my initial design.

The computer works in this simple state, and I’m able to upload cross-compiled C programs through the serial port, and run them. It was a lot of fun reaching this stage, but then I got too lazy and didn’t even upload a proper demonstration video for that, or continue improving it for some time now.

homebrew 16bit motorola 68010 computer.

To make it more interesting, I made a test program for my 68k computer which calculates a koch snowflake fractal, and sends graphics commands to the serial terminal to draw it. Here’s a screenshot of xterm, which supports the vt330/vt340 ReGIS graphics commands.

My 68010 computer drew its first fractal

Advertisements

Catching up: SEGA Mega Drive (Genesis) PAL/NTSC mod

Continuing with the 2017 catchup, another retro venture was acquiring a SEGA Mega Drive for the first time to hack, play some retro games, and watch mega drive demos. None of my software hacks are interesting enough to post at this point, but I did like a hardware mod I did, to add a switch to the back of the unit, that flips the megadrive between PAL (europe) and NTSC (US) modes. This was necessary, because some games and demos only work in one of the two modes, while some NTSC games work on PAL consoles like mine, but run way too slow.

If you want to see the details, head over to my regular website, where I uploaded a complete writeup of the PAL/NTSC hack.

SEGA MegaDrive PAL/NTSC hack

Catching up: Amiga hardware hacks of 2017

So since I’m not really posting anything on this blog regularly. I decided to do a few catching up posts from time to time, with any cool stuff I did since last I posted here. First up, my amiga hardware hacks.

I bought an Amiga 500 in 2017, something that I meant to do for a long time now, to play with it, hack it, and see what makes it tick. So I ended up doing a couple of hardware hacks for it, to improve what I thought needed improving to make it more enjoyable to use and hack on.

First thing I did was make a “trapdoor” RAM expansion using 30pin SIMMs. 512k RAM expansions (to bring the total RAM to 1MB) was so ubiquitous back in the A500’s hayday that not having one would be crippling.

RAM expansion board

Next up, I wanted to set up a convenient hacking environment on the amiga itself, which is extremely annoying with my single floppy drive. Most people on the A500 used to use an external floppy for this purpose, but I decided to skip that and make an ATA hard disk interface for the amiga 500 instead.

A500 hard disk interface

Finally, it was really inconvenient having to move the whole amiga, with all the dangling cables behind it in front of my monitor to use it, which is necessary since the keyboard and the computer is one unit. Having to clear up space and manage the tangling mess of wires is not fun, so I decided to make a PS/2 keyboard controller for the A500, to allow me to connect an external standard PC keyboard, and leave the amiga tucked away on the corner of my desk out of my way.

PS/2 keyboard controller

PCB Etching

I’m going through an electronics phase at the moment, and I did a few circuits on stripboards (a kind of perfboard), which are ok but it’s always a pain in the ass to wire them up correctly. Btw here’s a relatively complex one I did a few months ago. So, I thought it would be awesome to create my own PCBs instead of using messy error-prone perfboards all the time, plus I always wanted to try the laser-printer method for homemade PCB creation back from when I didn’t actually own a laser printer.

I didn’t want to start with a huge complex circuit, so I decided to make a PCB version of my vsync shutter glasses driver.

First step was to draw a schematic Read the rest of this entry »

VSync-driven shutter glasses

All my previous stereoscopic attempts are fun and cool, but what I really wanted was to manage to connect my cheap-o shutter glasses to my computer, and use them for stereoscopic rendering. The main barrier is that consumer nvidia cards do not include a stereo port (unlike expensive quadros), and their drivers don’t support stereoscopic OpenGL visuals.

I had already side-stepped the second problem by writing stereowrap, an LD_PRELOAD-based tool that fakes OpenGL stereo contexts for GLX apps and presents the stereo pair in a number of ways, such as various anaglyphs, side-by-side, etc.

So at some point I decided to attack the first problem. Turns out there’s a simple way to drive shutter glasses. It’s a brilliant idea, and I didn’t come up with it, but it boils down to making a simple circuit that toggles the shutter glasses when it detects a pulse on the montior vsync wire!

Original vsync shutter glasses driver schematic.
vsync stereo driver prefboard prototype
I immediately designed a circuit based on this design, but modified to work with the signals expected by my ASUS VR-100 shutter glasses. Then I wired it up on a perfboard, and it worked like a charm! Finally I added a sequential stereo presentation method to stereowrap, synchronized with vsync, and suddenly I can view all my stereoscopic programs in awesome full-color stereo glory.

The downside to this simple contraption is that it doesn’t really know whether the left or the right image is presented at any given time, it only knows when to switch between them. That’s why the switch is included in the circuit: if the image appears wrong, and you can really tell by your brain attempting to blow up while looking at it, the switch can be used to flip the glasses around instantly. If however the application can’t catch up with the refresh rate of the monitor and misses a vsync interval the images will flip again.

I plan to build a more intelligent, microcontroller-based, driver circuit at some point. But for now, the simple vsync driver works well enough.