a month ago •
Quick story. I brought this computer to the Vintage Computer Festival 9.1 last year to show Bil, Dave, and all the other cool people at the event. At the time, I was freerunning the processor, watching the blinkenlight count up. Great stuff, and proof that the CPU works.
A few hours into the show, the CPU board stopped working. It just wouldn't free run. No idea why, as I was able to get the board working by wacking it against a table once I got home.
Then the Hackaday Prize happened, and then the summer con season happened. I've been working on this off and on in the meantime, but no *real* progress. I made a better RAM card (more on that in a bit), but it's still a bit away from sending characters out over the serial port.
Since then, I got the wire-wrapped CPU card free running again, and I decided to take it to the Vintage Computer Festival X last weekend. When I pulled it out of the box and turned it on.... nothing. This computer hates VCF for some reason.
Therefore, I have decided to build a proper CPU PCB. It's just buffers, the CPU, a clock, and some blinkenlights:
And I have to route that before I leave my house for a month for con season. Great.
I had a front panel milled out of a big ass piece of aluminum. Here are the videos of the milling:
And a picture of the front panel:
That panel was made by the SeeMeCNC guys when I was up there for the Midwest RepRap Festival. I traded a gigantic (5 foot x 8 foot) hackaday flag - made by me - for the CNC work. All the relevant files are up in the Git.
Front panel not included. I'm moving the reset circuitry to the front panel, btw. Another board to build.
Four megabytes of RAM
I hated the wirewrapping on my RAM card. The initial plan for all of these cards was to prototype them with wire wrap, then build a board. I met myself halfway on this one.
That's the layout for the RAM chips, eight 4-Megabit chips. You'll notice there is no control circuitry on this one; there's a reason for that. I might want to change the control circuitry to a PAL or something down the line. Easiest solution is to make a proper layout for the RAM chips themselves, break out the data, address, and control lines, and leave everything else up to wirewrapping. Easy enough.
Since I'm doing all of this from scratch, It would be nice to have a development tool.
That's the Motorola Educational Computer Board, the official 68k trainer from 1981. It works, I have it plugged into a terminal, and it has a great monitor in ROM. I'll be using this heavily once I get a few characters spitting out of the serial port of my project.
Picked that up on eBay for $40, btw.
Also on the eBay Front...
I have most of DTACK Grounded.
DTACK Grounded. the journal of simple 68000 systems, was a newsletter put out by [Hal Hardenberg] on how to design a simple 68000 system.
Most of DTACK grounded covers the development of a 68000 add-on card for the Apple II and a BASIC interpreter. It's good writing, and the issue ever 68000 homebrew wants to read - number 6 - tells you exactly what you need to leave out, what you need to leave in, and what pins to connect to where.
If you want to read these for yourself, here you go.
I did pick something up at VCF...
That's a 12MHz 68000. Five dollars. It's an actual Motorola part, so this is what I'll be using from now on. I don't know if I'll be running it at 12MHz; I specced all my decoding logic for 8MHz. I'll try it - it's just changing a crystal - but I don't expect this computer to run at 12MHz.
That's it for this update.
I'm leaving for NYC next weekend, and LA a few days after that. I won't be home for a month and for some reason that means no Windows, and no Eagle. Don't read too much into that last sentence.
I need to get this CPU card done and sent off to fab. It's exactly like the earlier wire-wrapped CPU card, only this one hopefully won't fail all the time.
So... yeah... it's been embarrasingly long between this update and the last, but hey, I've been busy, and technically, I have...
Read more »
a year ago •
This is something I've written about in a front page Hackaday post, but I think it's time to go over a little more of the theory of what I'm doing here. First, a video:
This is called freerunning the processor. Basically, it executes one instruction, the program counter is incremented, the address is increased by one, and the CPU just sits there, doing nothing, cycling through its address space. Attach a few LEDs to the address pins, and you have an incredibly complex binary counter, also known as blinkenlights.
That's the simple explanation. It's a fair bit more complex in practice. I need to tie a few pins to +5 volts, and ground DTACK. Oh, what about the instruction to freerun the processor? NOP, right? NOPe.
When the 68k first resets, it reads the program counter vector. The program counter vector must be an even address, and the opcode for NOP is $8E71. See that one at the end? That means NOPping the CPU from boot would create an illegal address exception. Then bad things happen.
So, I need an instruction that does nothing, and is even. Inclusive OR Immediate (ORI) does this. Specifically OR.b #0,d0. Bonus, this instruction in hex is $0000, or all zeros. All I need to do to freerun the processor is ground all the data lines.
My first go at freerunning the CPU only used one LED. This LED was tied to the A20 line through an inverter. I hate to waste the five extra inverters on that chip for a single LED, so I added another three.
Now I have status lights for the top four addresses in the computer. Since I'm putting the ROM at $FF0000, the serial port at $FE0000, the video peripherals at $FD0000, the microcontroller at $FB0000, I have a graphic representation of what the CPU is doing with all its peripherals. That's pretty cool. Useful blinkenlights.
a year ago •
Although it might make sense to start this project by building a CPU module first, I decided it would make more sense to start with the memory for this system. This serves two purposes: as an explanation of how the 68000's memory-mapped I/O works, and to have a relatively simple circuit built before embarking on the more complex that include the CPU module.
A 68000 memory access primer
As with the 6502, 6800, and 6809, memory access is controlled by the R/W line. Basically, when the R/W line is high, the 68000 reads from the data bus. When the R/W line is low, the 68000 writes to the data bus.
Unlike the older, smaller, 8-bit CPUs mentioned above, the 68000 also has additional control lines to deal with. /UDS and /LDS are the upper and lower data strobe lines. These signals indicate valid data on data lines D0-D7 (for /LDS) and data lines and D8-D15 (for /UDS).
In addition to the data strobe lines, there also exists an address strobe line, /AS. This signal indicates a valid address on the address bus.
Reset Vector Generation
Before designing our memory modules with these signals in mind, it's very important to figure out how this computer is going to boot. All computers require some amount of RAM somewhere in the address space, and at least a few instructions telling CPU what to do on a restart somewhere else. The 6502, for instance, requires an instruction in ROM at $FFFC, and a few bytes of RAM at $0000.
This isn't a problem for the designer of a 6502 computer - just put some RAM at the bottom of the address space, and your RAM at the top.
The 68000 is different. It's reset vector, or the place it looks for instructions on a reset, is at $000000. The 68000 also requires a small amount of RAM at address $000000. Let that sink in. The naive analysis of these two facts means we must store the first instruction in RAM. RAM that will be uninitialized when we boot the computer.
Fortunately, Motorola application notes give us an easy way to get around this. The solution is to deselect the RAM and select the ROM during the first four bus cycles. This can be done with a 74164 binary counter, using the /AS line as the clock input, and making a /ROMSELECT control signal with one of the outputs. This /ROMSELECT or /BOOT signal (I'm using the two interchangeably) will allow CPU to read instructions from the ROM on reset.
Above is a fairly broad overview of the ROM board's circuitry. I'm using two 32kB EEPROMs for the ROM, split between high bytes and low bytes. This gives me 64kB of ROM for this computer, more than enough to set up a few things on boot and eventually pull data off a hard drive.
There are basically three main components of the ROM module: an address decoder that enables the ROM, memory control logic that selects which chip is being read, and the ROM chips themselves.
According to the memory map I have in my notebook, the 64kB of ROM will be decoded at $500000 through $50FFFF. This means the ROM is selected whenever address lines 22 and 20 are high, and lines 23 and 21 are low. A three-input NAND gate (74ls10) and a few inverters are all that are needed to enable the RAM.
Of course, I'll also need to include the /AS line and the /ROMSELECT line. Easily done.
ROM Memory Control
The ROM memory control is used to toggle the output enable pins on the EEPROMs. The Motorola 68000 user manual has a table going over when valid data should be on the data bus according to the /UDS, /LDS, and R/W lines. Long story short, the above circuit will work just fine for enabling either EEPROM.
Yes, this is much more complex than the ROM module. This is a product of the 68000's huge address space, and my desire to have a ludicrous amount...
Read more »