This is also a demo of Hackaday Projects, our new, fancy online documentation tool for all your adventures in making and tinkering. Did you know we’re having a contest on Hackaday Projects? Make something sci-fi, and you’re in the running for some really good prizes. There’s soldering stations, o-scopes, and a lot of other prizes being thrown at the winners. It’s awesome. First one to build a working Mr. Fusion wins.
In this update, I’m going to go over the beginnings of the video board, why Hammond enclosures are awesome and terrible at the same time, and some thoughts on turning this into a kit or product of some type. Click that, ‘Read more…’ link.
The Video Board
Like I’ve said before, I’m using the Yamaha V9938 video display processor as the graphics chip on this computer. It’s the easiest way I can get an 80×24 text mode – perfect for that *NIX goodness – and should be able to pull off some cool demoscene stuff. It’s pin compatible with the V9958, so I have that option, and it’s also fairly simple to interface to the rest of the computer:
That’s from the V9938 Technical Data Book. Big PDF warning there. On the right side of that graphic is the DRAM interface for the video memory and the pins for video output. There are a few different configurations ranging from 16k of VRAM to 128k of VRAM. Of course I’m going with the 128k option, using a quartet of TMS4464 DRAM chips I picked up from Jameco. Here’s the schematic of the VRAM interface:
I don’t want to wire wrap that. It’s a lot of fiddly, short bits of wire. It’s also extremely simple and won’t be seeing any changes in its design. The solution to my laziness is, of course, to make a PCB.
Because the connections to the V9938 are just an 8-bit data bus and a few control signals, and the output is dead simple for composite output, this greatly minimizes the amount of wirewrapping I’ll need to do. Even if I tried wrapping a V9938, I’d run into a problem: the pin pitch isn’t 0.1″, rendering all my wirewrap adapters useless.
If you’re wondering about the physical size of the board, it’s just a wee bit larger than an Arduino. Yes, I know what you’re thinking, but a 128kB V99X8 will not fit on a standard Arduino shield. 16kB, maybe. In any event, when I get these boards back, I’ll have a go at driving it with an Arduino. Just because.
Yeah! Fancy Video!
I’ve never had any luck with Hammond enclosures. The die-cast aluminum guitar pedals? I’ve ruined dozens of them drilling holes for pots, switches, and jacks. The enclosure for the 68k is no different. It’s a beautiful case, no doubt about that, but I am cursed with a mystical ability to always mess up the drilling, painting, or some random thing when it comes to Hammond enclosures.
The original plan for this backplane + enclosure combo was to have a small extension board on the front (hence, “frontplane”) that broke out the power and reset lines so this computer would at least look the part of an early 80s homebrew computer. Also, having a power and reset switch on the outside of the case is a good idea anyway.
Because of the complete failure of my ‘frontplane’ plan with the stock front panel, I’m going for something much, much cooler: a custom CNC’d aluminum panel. Right now I have holes for a power switch, a reset button, and a 5mm LED for power indication.
The basic circuit for this frontplane is very simple: The lines on the backplane are broken out on a huge 2×32 pin header. There’s also a small three-pin header for the PS_ON and POWER_OK lines for the ATX power supply. Ground the PS_ON line with the switch, and the power… uh, turns on. The PS_ON line provides +5V when the power is on. Attach the LED to that.
The reset circuit is the same from the CPU board: a Maxim DS1812 supervisory and reset circuit in a single TO-92 package.
Creating the milled front panel and new, improved frontplane was an interesting exercise in mechanical design. First, I created the front panel as a 3D model, exported the top view as a DXF, and imported that into Eagle. Then, I took the board file for the backplane and overlaid the holes. Then it’s just a simple matter of removing the parts and traces from the backplane I don’t need – everything except the pin headers – and making a board.
So there you go. Fun adventures in mixing mechanical design with circuit board creation. This, like just about everything else relating to the 68k project, is up on the github.
Oh yeah, a kit
For some reason I can’t comprehend, a lot of people have asked if I’m going to make the 68k into a product, or at the very least a kit. I don’t quite understand the demand; the fun of homebrew computers is designing and building them.
That doesn’t mean I won’t entertain the idea. In its current form, though, a 68k kit would be absurdly expensive, take hours and hours to assemble – the RAM card alone would be three or four hours – and would have an extremely high number of unsatisfied buyers. It only takes one misplaced wire to screw the entire thing up, you know.
So, an improved, single-PCB kit is the only option. This is months and months in the future, but here’s what I’m thinking:
- Uses the currently-in-production 68SEC000
- Already assembled.
- A MiniITX or MicroATX motherboard form factor.
- Uses 30 or 72-pin SIMMs for the RAM.
- Some sort of expansion port.
- User-updatable ROM.
That last bullet is the sticking point. I’ve been turning this around in my head for a while, and I can’t come up with a good way of doing it. The problem is I need a small amount (~64kB) of EEPROM or Flash that can be accessed on a parallel bus. That means 15 address lines, 16 data lines, and control signals. I need a way of reprogramming this, in system, with few additional parts, cheaply.
The obvious solution is to throw a big FPGA in the system for address decoding, an SPI bus, and in-system reprogramming of the ROM. That may end up being the eventual solution to this problem, but I’m thinking there’s an even more clever and cheaper way of doing things.
I’ve toyed around with doing the whole ‘in system ROM reprogramming’ thing in a 6502-based retrocomputer, and it is possible by using a microcontroller and a bunch of shift registers to program the ROM. This takes up a lot of board space and is extremely kludgy.
Another solution would be something like this amazing retrocomputer that actually should be a product. It uses a 40-pin PIC microcontroller as the RAM, ROM, and ACIA. It is, without question, the most innovative project in the retrocomputing world for the past few years and presents an interesting solution to the problem of in-system ROM programming: just put the ROM on a big microcontroller.
Are any of these ideas the right solution? I don’t know, because I’m not designing this computer as a product right now. This problem has been bothering me for a while, and I’d love to hear some more ideas. In any event, there’s plenty of space on my ROM board to prototype some in-system reprogramming. Come up with a good idea and I might put it in.
That’s it for now. You can continue to follow the progress of the Hackaday 68k over on Hackaday Projects. Be sure to comment and give a skull to the project. Seriously, give the project a skull. I’m losing to [Mathieu]’s Mooltipass project in the skull department. I need more skulls.