Close
0%
0%

68000 minimal homebrew computer

Single board computer (128KB SRAM) build in 1991.

Public Chat
Similar projects worth following
Back in the 90s I was studying computer science. To me, it was all pretty theoretically and was wondering if I could do something with the stuff I learned. One day I decided to build my own little computer. Would it be a 8086 (or NEC V30 which was 30% faster) or MC68000? The latter had a far more interesting machine instruction set, and while I also was planning a pascal compiler, I choose the MC68000.

In the summer of 1991 it was all soldered together. At the same time, my jonger brother was building a "real" computer based on the MC68010. He builded also an EPROM programmer, with was connected to the parallel port of mine IBM-clone. With that device we moved forward and programmed the first 27C128 EPROMS. These have to be erased with UV-light, we used an old sunlit for that.

With little steps forward the micro computer was coming alive; the first characters were spit out on the UART. In the end a program could uploaded to the RAM and run.

(work in progress...)

Introduction

Is the design of a 68000 single board computer (SBC) difficult? If you see the huge chip (dip 64) you should think so, but it is relatively simple. Compared to other CPU's like the Intel 8086, the address and data-lines are all directly available. Boards with 8086 CPU needs several latches to demultiplex the address and databus, and extra chips means extra wires.

For a simple design you need to connect all the address-lines of the CPU to the address-lines of the ROM and RAM, dito with the datelines. Besides that, a couple of logic chips will complete the design.

In this chapter I explain how I designed the SBC; I hope this will inspire you to build a SBC also, wether is is 68000, 6502 or Z80! 


Design goals

The design had to be simple (KISS/keep it simple, stupid); a minimum of chips but "by the book". It should run a pascal compiler I was writing:

  • 64/128K SRAM (that should be enough; DRAM is to complicated).
  • EPROM for BIOS/start up, size doesn't matter.
  • UART for simple but fast input/ouput (no VDI).
  • VIA for timer interrupts and basic input/output.
  • No bus-buffers.
  • No keyboard / floppy disk / harddisk / sound / video card etc.

I read a couple of books and magazines I found about this subject and took what I liked.

Memory map

The MC68000 cpu needs ROM at startup at address 0x0000 till 0x0007 for stack pointer initiation and program start address. On the other hand the (interrupt)vectors are located in the first 1 KB, which you like to be in RAM-memory. But hey, KISS we decided, so the ROMs are at 0x0000and the vectors are fixed!

A 74LS139 demultiplexer gives you 4 banks for ROM/RAM/IO. The popular 62256 SRAM's are 8 x 32K large so every bank has a size of 64K. (Remember that the data-bus is 16 bits wide, so you always need two ROM chips and two (or four) RAM-chips).

BankAddressFunctionChipSize
0.0x0.0000 - 0x0.7FFF
0x0.0000 - 0x03FFF
EPROM
EEPROM
2x 27C128
2x 28AT64
2x 16KB
2x 8KB
1.0x1.0000 - 0x1.FFFFSRAM2x 62256
2x 32KB
2.0x2.0000 - 0x2.FFFFSRAM2x 622562x 32KB
3.0x3.0000 - 0x3.001E
0x3.0001 - 0x3.0003
VIA / IO 
UART 
MC6522
MC6850
16 bytes (even bytes)
 2 bytes (odd bytes)



Power circuit

The good old and uncomplicated! 78S05 linear voltage regulator gives 1.5 Amp; more than enough for the system. Although this kind of regulators spoils a lot of energy, this is how it was done the 90's.

Lineair voltage regulator 78S05

Reset circuit

The CPU has two lines (/HALT  and /RESET) which has to be asserted for at least 100 mSec at startup for a proper reset. A fine task for the good old 555. But  the /HALT-line also is an output that signals the CPU is running. So it's better not to connect /HALT and /RESET together. That means extra glue logic (open collector inverters 74LS05) and a LED as run-indicator.

Reset circuit 555
Run indicator


CPU clock

The CPU is running on 8MHz; to get a nice 50/50 duty cycle a divider is added, although I have seen many projects with no divider. Perhaps you can skip that part, but I used the other part of the 74LS92 also for the correct clock for the UART.

Memory decode


/DTACK & /VPA

The MC68000 can work asynchronous (/DTACK) and synchronous (/VPA). /DTACK  is used for ROM and RAM; with this line you can add wait-states, which we don't want. (For a simple design it's better to lower the clock speed if the memory is to slow). /VPA is for MC6850 (UART) and MC6522(VIA) devices. Be aware the /DTACK and /VPA should not be asserted at the same time.

  • /VPA should be low when reading/writing to the UART/VIA. It should also be low when the processor is performing an interrupt cycle. The processor expects a vector on the bus, but much easier is the initiate an auto vector. The interrupt cycle is active if /AS is low and FC0, FC1 and FC2 are all high. Luckily FC2 doesn't need to decoded.
  • /DTACK should be low when reading/writing ROM and RAM, so simply invert the /VPA line.

UART clock

The MC6850 has a programmable internal...

Read more »

Portable Network Graphics (PNG) - 74.46 kB - 11/08/2021 at 20:35

Preview
Download

Adobe Portable Document Format - 835.64 kB - 11/08/2021 at 20:35

Preview
Download

Adobe Portable Document Format - 1.58 MB - 11/08/2021 at 20:35

Preview
Download

Adobe Portable Document Format - 1.00 MB - 11/08/2021 at 20:35

Preview
Download

Adobe Portable Document Format - 1003.56 kB - 11/08/2021 at 20:35

Preview
Download

View all 7 files

  • 1 × MC68000 Microprocessors, Microcontrollers, DSPs / Microprocessors (MPUs)
  • 2 × 27C128 ERPOM 8x32KB
  • 4 × 62256 RAM 8x32KB (piggy backed)
  • 1 × 6850 UART
  • 1 × 6522 VIA (programmable pors)

  • New board

    Steven11/24/2023 at 12:43 2 comments

    Fuzix

    Unfortunately, the 128KB RAM is too little for the system to run Fuzix. In theory, I could change the board a bit and swap the 32KB RAM chips for 512KB RAM. But every time I looked at the wires at the back of the board, I'm too afraid I will permanently damage the board. So, I give up...

    Then I thought, let's make a new board with 2x AS6C4008 RAM chips based on the old design. It was easy to make the schematic in Kicad, but I thought it was an automated process to design the PCB from the schematic. How mistaken I was! In the PCB editor, I got stuck with a rats nest, and couldn't design a decent PCB. So, I gave up again...

    Then again, someone must have designed a tiny and simple(!) 68000 PCB board with just RAM, ROM, and a UART without fancy components. Searching the internet and I found this: 68K-nano by Matt Sarnoff. This is exactly the design I was looking for!

    68K-nano

    I ordered and built this board, and it works fine for me. Made two minor changes:

    • AT28C64B for EEPROM; these are in stock with me and pin compatible with the AT28C256.
    • Added an 11.0592 MHz crystal to the UART; now it is easy to change the CPU clock speed without altering the divider in the BIOS.

    This board runs stable at 24MHz (!) (Matt rated this at 12 MHz). I am now porting my BIOS to this board. After that, I can proceed the Fuzix port on the new board...

  • How fast can it run?

    Steven11/24/2023 at 10:56 0 comments

    Introduction

    Back in the nineties, I was worried if the system could run on 8 MHz. In the end, it did, but now I am curious about what the max speed is. The CPU is a MC68HC000 CPU rated for 16 MHz, but it is unlikely to reach that. The components are pretty slow; the RAM has a speed of 120 ns, and the EEPROM is even slower with 150 ns. The UART and the VIA are old 6800 components and the glue logic is a mix of LS and HCT logic.

    Bypass

    To test the maximum speed, I had to change the oscillator circuit. Normally, the output of the crystal is divided by two to get an exactly symmetrical output. The  is that the crystal runs twice the processor speed. So for an 8 MHz CPU speed, a 16 MHz crystal is needed. And with simple HC(T) logic, you can't go much faster than that. So I soldered a switch to bypass the divider; the CPU runs at the same speed as the crystal.

    Testing

    So, I tried:

    • 8 MHz: check 
    • 10 MHz: check 
    • 12 MHz: check 
    • 16 MHz: check (!) 
    • 20 MHz: check (!!!) 
    • 24 MHz: fails

    So, the old system runs stable at an astonishing 20 MHz!

    How is that possible? Well, the 68000 spends 4 clock cycles for reading/writing a 16-bit word. The successor, 68020, uses only 3 clock cycles, so you could say the 68000 has a built-in wait state. The clock for the UART and VIA is divided by 10, so 20 MHz leads to a clock of 2 MHz, which is the upper bound of the capabilities.

    It is amazing that the old system runs so fast!

  • Porting FUZIX

    Steven02/04/2022 at 16:50 2 comments

    Introduction

    Wouldn't it be nice to have a proper and working operating system running on this board? I've looked for Minix, but that way to large and complex. Then I read about FUZIX. It is a unix "like" operating system designed for old tiny 8 bits systems with a Z80 or 6502 CPU, and is ported to all kind of single board computers including MC68000! It is even ported to the Raspberry pi pico!

    All the hardware is driven by FUZIX; the BIOS is only used for starting the system. The most interesting is, it has a build in (unix like) filesystem.


    System requirements

    • Some kind of IO (serial will do) > check.
    • The operating system occupies about 64K, I have 128K > check.
    • Reoccurring interrupts (100Hz) for scheduling and multitasking; I have a programmable timer+IRQ > check.
    • Some kind of storage; the system is has a (very slow) interface for SD-card > check.
    • Optional RTC; the system is connected to a DS1307 RTC > check.
    • Free programable vectors (trap #12 used for calling the system). Oops; the ROM is mapped from 0x0000 to 0x4000; all vectors are fixed. But is this really a problem? Of course not; the BIOS is owned by me and I can easily reroute trap #12 to ROM, and use an RAM address for jumping. Just need to change the vector address in fuzix > check.

    But on the other hand; this will be a major project...


    Tool chain (Jan 2022)

    The first thing before you can even think of porting this, is a tool chain. That's not as simple as it looks; you need a m68k cross assembler/linker/compiler and they are not common these days. First I tried serveral LINUX scripts and virtual box, but that didn't work for me; all kind of errors I couldn't handle. Then I found on Rosco's Rosco's pagem68k gcc toolchain installed from home-brew; that worked like a charm on a Macbook and Mac mini! Easy to install and the compiler, linker and assembler were working at once!


    Geek... it compiles! (Jan 2022)

    After downloading FUZIX from git it got really exciting; I expected all kind of compiler errors, but it compiled without any error! Of course it isn't working but for me this is a big moment to decide to go further. I have a Fuzix.ELF file which easily can be converted to a S19-file. I even got the addr2line util working; tip it needs a "-f" option to work. 

    First steps (Feb 2022)

    After changing lot of assembly coding for TTY and SD-card it now shows -without crashing- fuzix' start text and detects the SD-card. Also the 100Hz clock interrupt are on. The next step is to create and mount the filesystem.

    Out of memory (march 2022)

    Since the last update I made some progress:

    • Updated the BIOS for rerouting trap #12 through memory.
    • Added tty input (so I can enter bootdev "hda1".
    • Created the whole disk image by compiling all the provided stuff and wrote it to a SD-card. (It could compile all but one file: the find-util).

    Fuzix stopped with the message "No /init". This can mean anything; no filesystem, wrong filesystem, no access rights, wrong file type, wrong relocation information etc. After some debugging it turned out that the system is out of memory. After reducing the disk buffers from 16 to 4 (that saves me 6 KB) it started /init. But then again out of memory. Init is forking itself and needs another  31 KB. 

    Of course I can remove some unused device drivers from the kernel, saving me some extra KBs, but the gap is at least 20KB.  I am afraid the 128 KB is not enough for a 68000 system to run :-( 

    I really have to think about heating up the soldering iron and add  more memory to the system...

    Found some memory (March 2022)

    After investigating the system, I found a lot of wasted memory:

    • Every process gets 16kB stack (elf2flat -s 16384); I reduced this to a configurable max 1kB.
    • Reduced (temporaly) the disk buffers from 16 to 3 (freed 7 kB).
    • Reduced (temporaly) the number of processes from 16 to 5 (freed a few hundreds...
    Read more »

  • Reflashing the BIOS

    Steven11/07/2021 at 18:35 1 comment

    Back in the old days EPROMs were used to store the BIOS. To erase them, you need UV light. I used a sunlamp for that, but I havn't got that one anymore. Besides the procedure to erase them was a bit time consuming, which increased the turnaround time of developing and testing. So I was looking for a better replacement.

    I found that the 27128 EPROM (16kB) could be replaced by a AT28C64(B) EEPROM (8kB), without changing the circuity.

    The tool chain I used in 1991 was MS-DOS based and ofcourse completely outdated. some parts were self written in turbo-pascal. To set up a new one, more future proof, I wanted to be abled to use it as well on windows as on MacOS, perferably open source. And it should be compatible with the old sources too. For now I am using:

    • EASy68K: as simulator for testing routines.
    • vasm: assembler to assemble the 68k mnemonics to S19 (hex) file.
    • src_cat: convert the motorola S19 hex format to Intel hex, and to split the file for the two EPROMs (odd and even).
    • TL866plus: programmer & software to program the EEPROMs.

    ...and after thirty years, the new BIOS is flashed!

    This is the programmer my brother build to program the EPROMs, I wrote the software in turbo-pascal. Data was send by the parallel/printer port. In the box there should be a counter and latches, to program the chips. It's amazing what we build ourselfs those days...

    Now I am using this little box (TL866 plus) which is cheap to buy and very functional. Even the old EPROMs could be programmed and it is easilly connected by USB. The software runs on windows but I read it should also also run on linux under wine.

  • Reducing power

    Steven11/06/2021 at 18:16 0 comments

    Month ago I bought two CMOS replacements for the CPU: MC68HC000. The advantage of this CMOS CPU is that it consumes less power. Unfortunately the replacement was not that simple as you think. The replacement came from China and were used chips. They were desoldered and some of the pins were bent. But after some gentle wiggling I managed to get all the 64 pins in the right holes...

    The current in the system drops from 480 mA to 280 mA, so a reduction of 40%.

    Besides the power consumption and therefor a lower temperature, there are no advantages for this chip. In the old days I had a PC with the CMOS replacement of the INTEL 8080, the NEC V20. This CPU was 25% faster on the same clock speed as the original. I remembered that all the chips on the board were warm, but the CPU keeps cool.

  • Dusting the project

    Steven05/16/2021 at 14:16 0 comments

    I hadn't looked on to it for years (no time, creating an extra room in the attic and so on), but it kept itching... On the other hand it seems so strange fiddling around with old hardware, a simple ESP32 has more capabilities and speed than a 68k will ever have.

    Two reasons for dusting 1) I found out you could still buy very cheap (used) spare parts like 68000 chips (in China) and 2) I found this (and other sites) where many people greb their soldering iron and creating all kind of old and new -cool- hardware projects. And wouldn't it nice to combine this old hardware with new and very cheap hardware like SD-cards, RTC, 1-wire temp sensors and so on, like we use to do with Arduino and ESP32?

    The board was build in the ms-dos time, with turbo pascal and a cross assembler as main development tool  on a XT 8MHz IBM-clone (with by the way I overclocked it to 9 MHz). Since I went away from windows to MaxOs, I have to use (temperately) a virtual Box with 32 bits windows with the necessary tools. The goal is to use as many as possible standaards like VT100 (serial terminal program), Free pascal / Lazarus (as development tool), X-modem (uploading programs), FAT16 etc, so I won't be dependent from specific hardware/software.

    Clock circuit

    After powering up the board sometimes came alive but always was unstable. I found out one loose wire (for the interrupts) but that doesn't solve all the problems...

    As as student I didn't have an oscilloscope, in those days way to expensive. But this was the moment to buy one! For only about EUR 200 you can get yourself a reasonable one. After connecting it to the clock circuit of the board the problem became clear. On the scope you can see a sneaky spike after the first clock pulse, which let the CPU crash. And also the frequency is a strange 16.95 MHz (bottom left corner) with *every* kristal I used (from 2 till 24 MHz)?

    The clock circuit was copied from the one in the XT-pc; two inverters (with a 330 ohm resistor over every inverter) and the crystal between it. Only the circuit was mentioned for LS logic and I builded it with HCT (c-mos). The result is a very unreliable oscillator...

    So I rebuild it to a suitable circuit which worked with crystals from 5 till 24 MHz (ground tone only) using a 74HCT04 and after dividing it by two there is a stable and clean 50% duty cycle clock.

    Lessons learned: never modify a circuit unless you completely understand it fully.

View all 6 project logs

Enjoy this project?

Share

Discussions

Steven wrote 11/29/2021 at 18:40 point

Hi, havn't thought of that, using EASy68K as toolchain. I use it now for debugging purposes only. The good thing is, it also runs on mac (and linux) as a simple to install package in PlayOnMac.

  Are you sure? yes | no

Peabody1929 wrote 11/28/2021 at 20:24 point

I use the website and applications at EASy68K.  URL: easy68K.com  It is possible to assemble code, simulate it and create burn files for the S-Record object code.

  Are you sure? yes | no

Steven wrote 11/08/2021 at 20:46 point

Hi MacGyver, a question like that I expected... it's no problem to share the schematics but they are not as beautiful I usually find on this side. The original schematics are drown on paper; I really should use a program to create a nice schema. The originals are added to the files, I hope you enjoy it!

-Before you start, check if you can get the components or replacements.

-If you want to build a SBC on breadboard, you could use a 68008; this one has an 8 bit databus so less wires.

-The #rosco_m68k  project builds also a beautiful  board, one of my favorites.

  Are you sure? yes | no

Peabody1929 wrote 11/07/2021 at 23:26 point

Would you post the schematic for the board?  It looks like it would be easy to build.  I have always wanted to have a 68000 DIY SBC.

  Are you sure? yes | no

Steven wrote 05/16/2021 at 10:30 point

I wrote a pascal compiler then, using the famous TURBO-pascal dialect. It includes strings, lazy boolean evaluation, variant records, pointers and lots of default procedures (like upper()). Some of them are written in Pascal, others is 68k assembler. In my compiler it is very easy to combine these two. What is missing is file handling (as there is no storage) and floating point (I don't need this at this point).

For some time I used a coldfire board, but coldfire lacks some instructions (like DBA, movem) and included others (mul.L). After upgrading to Windows 10/64 bits software to program the board is not working anymore. Now I'm moving back to 68k and the old board, but unfortunately the compiler is becoming a bit buggy in the boolean evaluation. I will fix this later (and have a workaround).

Most of the software development I do with the self build compiler, and some (time critical/bios) in 68k assembly). The eventual goal for the complier is a self-complier; that means that the compiler can compile itself (on windows and on the system itself). And you are right, 68K assembler is extremely suitable for building a compiler. Later I will test some old benchmarks, found in #Kobold - retro TTL computer ("How fast is the thing anyway").

Right now I am working on SD-storage (I will post a log soon).

  Are you sure? yes | no

zpekic wrote 05/14/2021 at 04:14 point

Pascal could totally run on this one - and fast too! Was it ever written?

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates