Homebrew Computer Is 16 Bits Of Awesome

We’ve seen our share of homebrew computers over the years. Usually, these bare-bone systems use a small, early 80s-era microprocessor such as the Z80 or 6502. These little 8-bit machines are awesome, but somewhat limited in their capability. [BigDumbDinosaur] sent in a computer he’s been working on for a few years now featuring the infamous 65816 CPU – the same CPU found in the Apple IIgs, the Super Nintendo, and [Jeri Ellsworth]’s C-ONE computer.

The 65816 is a direct descendant of the venerable 6502 CPU found in the Commodore 64, Apple II, and just about every 80s microcomputer of note. [BigDumbDinosaur] chose the 65816 for its backwards-compatibility with the fun to program 6502 and the ability to use high clock rates and tons of address space for a very cool design.

After a ton of careful design and consideration, [BigDumbDinosaur]’s computer included a real-time clock, a watchdog timer, a serial port, 256kB of ROM, and 128kB of RAM.

It’s a really wonderful build, but [BigDumbDinosaur] isn’t done with this project yet. He’s working on version 2 of a 65816 computer that will use programmable ‘glue’ logic, a lot more RAM, have a SCSI interface (for a hard drive), and have preemptive multitasking.

An awesome job, and it’s wonderful to see the wonderful 65816 make its way into another homebrew computer. Now if only we could find a 68000-based homebrew computer…

23 thoughts on “Homebrew Computer Is 16 Bits Of Awesome

      1. Brian, when the 65C816 is in emulation mode (as it would be following power-on or reset) it behaves almost like a 65C02. I say “almost” because all opcodes work whether in emulation or native modethere are no “undocumented” opcodes. However, until it is switched to native mode, the ‘816 has only 8 bit registers, hard wires the stack to $0100 and restricts some functionality (e.g., the MVN and MVP instructions are basically useless).

    1. dattaway2, it calls it “direct page” because it can be relocated anywhere in the first 64K, so for example each task can have its own “zero page.” It’s a 6502 that’s extended in ways that make it much more nimble in various areas. The bank byte seems to scare people off; but remember you can totally ignore it if your memory map is 64K or less, and you’ll still get a ton of benefits from the additional instructions and addressing modes. And if you’re constantly dealing with 16-bit values, the ‘816 is much easier to program. It outperforms the 68000 in the Sieve of Isosthenes benchmark, in spite of being so much simpler. Do look into it. You’ll be pleased.

    2. dattaway2: The 65C816 is a 65C02 on steroids and is much more capable. One of the ‘816’s particularly useful features, as noted by Garth Wilson, is its relocatable zero page (now referred to as direct page). This handy feature allows the programmer to give subroutines there own private zero pages. When used with the relocatable stack pointer, it becomes quite easy to write fully recursive code and to use the stack for complex parameter passing.

      1. Just because the 6510 is a direct successor to the 6502 doesn’t make it the same chip. The added digital I/O and tristate address bus are the factors that allowed access switching between the full ram and the Basic ROM. At that rate, you might as well say it’s a 6501, but with an added internal clock oscillator, even though MOS pulled the 6501 and they were developed side-by-side.

        1. …which were indeed part of making the C64 so successful. However, the uP inside the 6510 was the NMOS 6502, with all the bugs and quirks (which later got fixed in the CMOS version), and the same instructions and op codes. Current-production 6502’s do allow making the address lines high-impedance (pin 36 of the DIP is a bus-enable input), and have a lot of additional hardware and software enhancements– but we still call them 6502’s.

  1. Fun! This definitely brings back memories for an old hardware guy like me. The slow debug process that happened in the days before comprehensive simulation and large boards full of TTL, PALs and primitive FPGAs. But the thrill when a board was working.

  2. After a ton of careful design and consideration, [BigDumbDinosaur]‘s computer included a real-time clock, a watchdog timer, a serial port, 256kB of ROM, and
    128kB of RAM.

    Some minor additions and corrections to the description of POC V1:

    * There are actually two serial ports, each capable of independently running at 115.2 Kbps. Port A drives the console (a WYSE 60 terminal) and port B is connected to one of the serial ports on my UNIX box, allowing me to transfer machine code to POC V1 using Motorola S-records.

    * I’m using a 256Kb x 8 EPROM, of which only 8KB are actually in useI had a bunch of 27C256 EPROMs laying around getting dusty. :-) A 27C128 will also work without any circuit modification.

    * All glue logic is in 74AC discrete gates, which according to my timing analysis, would support 20 MHz operation if I could get the I/O hardware to run that fast.

    * POC V1 doesn’t use the A16-A23 address bits that are MUXed on the data bus during Ø2 low. Therefore, the 128KB of RAM is not entirely used. 52KB are available for programs, data, stack space and direct page (aka zero page) space.

    * RAM starts at $000000, I/O hardware is at $00D000-$00D7FF and ROM is at $00E000-$00FFFF. All I/O is interrupt-driven.

    * The ROM contains a BIOS, interrupt handlers, reset functions and a machine language monitor. BIOS functions are accessible thruogh a jump table. Following reset, the 65C816 is switched to native mode and stays there.

    * This unit has been tested and found stable with a 15 MHz Ø2 clock, using an NXP 26C92A DUART to drive the serial ports. When I first constructed POC V1 I used an NXP 2692A, which has a slower response to the /CEN (chip enable) input. The highest speed at which the unit was able to operate with that DUART was 12.5 Mhz…and that was pushing it.

    * I have working SCSI, implementing the 8 bit bus and the SCSI-2 protocol. To do this, I built a host adapter that plugs into the real-time clock (RTC) socket, with the RTC being mounted on the host adapter. The SCSI primitives are interrupt driven, use the 53C94 controller’s DMA channel, and can attain a sustained transfer rate from bus to core of approximately 500KB/second with a 10 MHz Ø2 clock. Currently attached to the SCSI port is a Seagate 18.2 GB LVD hard drive (with an adapter to work with the 8 bit bus), a Plextor CD-ROM drive and an H-P DDS2 tape drive (4mm helical scan). All peripherals are functional, and the computer can load and execute a master boot record from the disk.

    The picture at the top of this article is of the POC unit after applying several hardware patches. With the addition of the SCSI host adapter, I had to apply more patches to connect some needed signals between the “expansion port” socket (the former RTC socket) and the 74AC138 I/O decoder. The wiring started to get unwieldy, so I updated the PCB layout, got some new boards made and built POC V1.1. POC V1.1 is identical in appearance to the above picture, minus the blue wire. Please visit my website for some more info, including schematics. It’s not up-to-date but is getting there.

  3. This is great work. It makes me if anyone has build something around the ‘816 based SA1 chip found in some SNES carts. ISTR it has multi bus master hardware built in but some sort of externally programmed MMU which means it can’t bring itself up, so it has to work in a multiprocessor system.

  4. I still remember my 65816 days back when I was doing ASM hacking on Super Mario World on the SNES.
    I wonder if anyone is still using (or adapting) those ASM hacks I wrote…

  5. If you google “Sinclair QL” you will find the venerable 68008 based PC from Sir Clive Sinclair. A fair number of people over the years have designed their own new versions with processors such as the 68040 etc.

  6. It remind me of the board with which I learned about embedded system and assembly programming. (use the same RTC!)
    However the cpu was a 80188 @16MHz. Oh and cpu bus were made with wire-wrap.

    No, this was not 25 years ago, it was.. 5 years ago.Needless to say after a few class using these, a single chip PIC uc was a gift from the gods!

    1. lwatcdr: Maybe add a Propeller chip to handle video out, audio, and maybe a PS2 keyboard interface?

      Why? If you read some of the narrative on the website you’d know why it doesn’t have those devices attached to it, especially a Propeller chip (can’t think of any good reason why I’d want one). This unit is a “proof of concept” device and as such, was designed to be the simplest thing I could conjure that would be functional. It computes with alacrity, has console I/O, has auxiliary I/O for communicating with other systems, can drive SCSI peripherals and is smaller than a scratch pad.

      POC V2 may have an integrated console, although I’m more likely to mate a WYSE ASCII keyboard to the unit than a PS/2 unit. Like most old-school computer programmers, I prefer the ASCII layout over the IBM Selectric layout the I’d be forced to use with a PS/2 keyboard. This thing is not a PC, y’know. :)

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.