Started in 2021, the Vulpis II is my original design Motorola 68010 CPU based homebrew computer, hand-wired on a large protoboard. The computer features a 10MHz CPU, a MC68451 MMU, four serial ports (two externally connected), and an on-board custom 640x480 monochrome VGA generator circuit. The computer is built on a 20x30cm custom designed pad-per-hole protoboard, with footprints on the edge for common D-sub, RCA, and power connectors. The computer was built up in several stages over the course of a few months.
The design of the hardware of the computer is of my own design, much like my other homebrews. It was built upon the experiences of my very first homebrew, a 68000 based SBC [HTTPS] that I retro-actively named the Vulpis, hence this machine being the Vulpis II. That computer was a rather minimal 68000 system that I originally built on bread-boards before moving it to a protoboard and eventually breaking it while soldering in some expansions. For this system I wanted to revisit the concept of a 68k based homebrew and make it much more capable than that SBC was. Now quite a number of years ago, likely while still originally working on the breadboard homebrew, I picked up a MC68451 MMU off eBay, with the intention of making a computer around it. I decided for this revisited system to finally make that a reality and use it. For best compatibility, and to allow for segment-faults to be recoverable, I decided to also change the CPU to the Motorola 68010. The 68010 is an improved version of the 68000, while pin and almost completely software compatible to the 68000, it changes the handling of BERR and some other fault states such that it can re-execute the faulting instruction. It does so by pushing additional internal CPU state onto the stack as compared to the 68000, which represents it's slight incompatibility. The 68010 also includes a special single-instruction loop "cache" allowing for certain move/loop instruction loops to operate without instruction fetches, more than doubling their speed doing memory to memory copies.
Hooking up the 68451 to the 68010 is a rather simple affair, involving passing through address lines 8 through 23 through the 68451, while 1 through 7 are left unaffected. Some buffers are used on the output side of the 68451 to allow the CPU data bus to write to the 68451 for programming, along with A1 through A5 being hooked up to the register select pins. The exact details can be found in the KiCAD schematics linked further down the page. The 68451 does add a single wait state penalty to addressing, but at 10MHz this isn't really all that noticeable either way. By default the 68451 is set up in a pass-through configuration with all reads and writes being mapped 1:1 from the virtual address space to the physical space, it is in this mode that my software is currently using (or should I say not using) it.
As opposed to my original bread boarded homebrew, this time I decided to embrace GAL chips. These chips are an early form of programmable logic, much like the more modern CPLDs, however they only have a limited number of macro-cells, but are available even brand new in DIP form. These allow for much more flexibility and tweaking of the hardware setup without re-soldering of wires. I made extensive use of them in this computer to replace random logic cells, with 3 being used for the CPU logic, and a whopping 8 in the VGA generator circuit which I'll be describing later.
The first GAL is being used for address decoding, breaking up the physical address space into a number of regions between the RAM chips, ROM, peripherals, VGA, and expansion and more. This GAL also handles the BOOTED flag, which maps ROM at address 0 until a jump to the normal ROM space. This is required as the 68k initially starts reading in the stack pointer then program counter from addresses 0 and 4. We want RAM however at these addresses after booting such that the vector table, running from address 0x000 to 0x400, is modifiable in software.
The second GAL is used for decoding the onboard peripheral space, as well as generating any needed wait states (DTACK) for them. Each peripheral is given a 8kB region to simplify the number of address lines needed. Three cells of the GAL are used for a counter for wait states that can be decoded along with the address to delay sending a /DTACK signal to the processor.
The third GAL is used for MMU support as well as miscellaneous address decoding logic such as generating individual high/low strobes for the 8-bit halves of the 16-bit bus. It's functions are better described in the logic file for the GAL. It also handles auto-interrupt vectoring for MC6800 type peripherals, though none are currently hooked up to the system.
As with the hardware, all software for this machine is custom designed from the ground up. Originally during bring up this was entirely written in 68k assembly language using Easy68k as an assembler, however as a personal goal I decided to set up a GCC cross-compiler and custom linker scripts for the system. Compiling the cross-compiler was not much of an issue, though it did take some time to get the linker scripts and the boot strap assembly code working to the point that I could write and run C code on the machine.
Currently the software is not in a complete state, but sitting as a technical demo of the machine waiting for time to revisit it. The current code creates a "virtual" 80x25 text terminal on the screen and can echo keyboard presses onto the screen, as well as display text received over a serial port. Keep in mind that since the display is a pixel based frame buffer and not a character based display this requires blitting the font to the screen, and scrolling requires copying almost the entirety of the framebuffer.
The end goal with the software is to create an early Macintosh inspired GUI system on here to show off the power of the CPU and the monochrome framebuffer, and in terms of operating system at least a basic multi-tasking environment allowing perhaps multiple terminal windows to be open at a time running terminal emulation software hooked up to the serial ports. As with basically all of my homebrew computers the goal is running software written by myself, rather than porting existing operating systems. Though with this system I may try in the future to port a UNIX-like operating system to the board, though I'm not aware of any that support the 68451 MMU.