Yet Another m68k Homebrew

A Motorola 68k homebrew on breadboard, this time with a 68010 running at 8MHz

Similar projects worth following
A Motorola 68k project, using the full-fat MC68010P10 processor (as opposed to the 68008 8-bit CPU). The design is zero-wait-state for both ROM and RAM, with optional wait states for IO devices. As well as designing and building the hardware, I'm building a small microkernel-based operating system with preemptive multitasking. I've provisionally decided to call this computer the rosco_m68k. Design and code lives on github: .

This project is yet another m68k homebrew computer that is starting to look like it might actually be finished someday.

The idea is to design and develop a system running the Motorola MC68010P10 with supporting circuitry and then port my existing minimal OS to it. 

This is starting to look like it'll actually get completed someday. Right now, I have a 68010 running at 8MHz with a mix of PLD and TTL glue logic. The CPU is hooked up to control, data and address buses allowing it to talk to the memory and run code from the on-board ROM.

IO is handled by the Motorola MC68901 Multi-Function Peripheral. This gives a UART for a serial terminal amongst other things. I plan to use a Yamaha V9958 to give graphical output, and have not yet decided on a sound chip.

There's (at least) one area where this project won't be period-appropriate - I plan to integrate USB to make it easier to work with in the twenty-first century.

  • 1 × Motorola MC68010P10 The CPU
  • 2 × Atmel AT28C64B The 16K ROM
  • 2 × Alliance AS6C4008 The 1MB RAM
  • 1 × Motorola MC68901 The Multi-Function Peripheral
  • 4 × Various 7400-series Chips The Glue Logic

View all 7 components

  • Plans for 2020, and OSHWA certification

    Ross Bamford12/31/2019 at 14:23 0 comments

    Wow, it's been a bit quiet here since August, and for that I apologise. I've been very busy with work and family commitments and haven't had much time to spend on any of my personal projects. However, as we move into 2020 I'm planning to ramp it back up!

    In no particular order, this is what's on the agenda next year:

    • Finally getting the r0 boards populated (more on that in an upcoming log)
    • Working in some fixes and changes (many of which were suggested down in the comments, thanks @henk.gooijen and others!) for a revision 1 of the board.
    • Tidying up the Zmodem firmware I've been working on and getting it committed to github (Again, there's another log in the pipeline for this!)

    Generally speaking, what I'm hoping to achieve in 2020 is having a small offering of bare boards and possibly kits for this project at a very reasonable price. The kits would of course included pre-programmed PLDs and ROMs.

    In the meantime, the project is now OSHWA certified (number six in the UK). Although the project has always been open-source hardware, and has the open-gear icon, that is very much self-certification - the OSHWA certification is recognition that the project fits with wider-community definitions of open hardware, and I'm looking forward to putting the mark on the revision one board!

  • Serial Now Fully Working!

    Ross Bamford08/27/2019 at 19:01 0 comments

    As I mentioned previously, I have been having some odd problems getting the serial receive working on the MC68901. No matter what I tried, it just wouldn't work. I went into some detail in the previous log about the lengths I'd gone to to try and fix this, so I won't reiterate here. I'll just say new MC68901's  I ordered from China finally arrived today, and everything now works perfectly.

    Turns out my suspicion about the SI pin (or possibly RC I guess) being dead on my original 68901 was spot on, and I'm not going crazy after all.

    So onward with the PCB fab! Oh, and on that note, I've just finished documenting the new board's expansion connector on Github - have a look if pinouts are your thing.

  • Another PLD and (finally) a PCB!

    Ross Bamford08/23/2019 at 18:39 0 comments

    Exciting times ahead! I've spent the last couple of days tidying up the schematic and finally made a start on a PCB design in Eagle. It turns out that PCB design is hard, but I've pushed on with it, learnt a lot, and started over at least four times (ripup ; has been a go-to command). I've used the autorouter to help me see where component placement was sub-optimal, and then I've moved things around and tried again. I wish I could say I'd hand-routed everything but I've definitely had help from the autorouter - I let it get me started and then spent many hours redoing its craziness. So I guess the final board is a kind-of collaboration between me and the autorouter...

    One thing I found early on was that the board was just too full to allow sane routing. There were still eight 7400-series chips on there when I started, so I decided it was time to put some more of the glue logic onto an ATF16V8BQL. I wrote another bit of CUPL code to handle more of the glue logic. The code looks like this (pin declarations etc omitted, full code here):

    IACK         = FC0 & FC1 & FC2;
    MFPDS        = LDS # IACK;
    RAMOE        = RW;

    And just like that, four 7400-series ICs were removed from the schematic. Obviously I tested it first on the breadboard before I tore down the old circuits, but it works like a charm.

    That done, the routing was made a bit easier, but (being cheap) I was still trying to do everything on a two-layer board. I quickly gave up on that though (I think after the third ripup;) and switched to a four-layer design with power and ground planes. Sure it's upped the cost (OSHPark are quoting me USD 248 for three boards vs $124 for three two-layer boards) but it's worth it, both from the routing point of view and the electrical one - I'm confident I won't have any issues with burnt out traces or grounding issues.

    This is the board as it currently looks (Layers 2, 15 and bNames omitted for clarity):

    It's by no means perfect (I'm still a n00b remember) and probably isn't done at this point, but it passes all the electrical and design rule checks (with OSHPark's rules included) and I'm reasonably confident it will work, so I'm going to go ahead and order three as prototypes and see how it goes.

    Before I do that though, I'm waiting on those replacement 68901's to arrive, because depending on whether they fix the problem or not I may have to do a bit more work on the design - if so I'll update the board before I send it off for manufacturing.

    As usual, all of this is now merged into master and available on Github. You'll also find updated schematics there (also as a PDF if you're not an Eagle user) and an updated BOM.

  • All new schematics and BOM

    Ross Bamford08/14/2019 at 21:24 0 comments

    As I mentioned before, I'm starting to look toward the day when this project will produce a PCB, and I've spent some time today taking a big step toward that - putting all the schematics together properly in Eagle, sorting out the IC count a bit more by using previously-unused gates where possible, and getting it to dump a prelimimary BOM.

    To keep things sane, this has meant I've had to move to more than two schematic sheets. Unfortunately, that means that the schematic is no longer compatible with the free version of Eagle. While this is unfortunate, I've mitigated it somewhat by checking in (to git) the schematic as a PDF and dumping the BOM in text format. I'll keep these up to date whenever I change the source schematic, so anyone wanting to use the schematic can still access it without having to have a paid copy of Eagle.

    I will admit to agonising a bit over this decision, and considered switching to a different CAD package (e.g. KiCad) but the reality is I don't know them, and I do know Eagle pretty well, so switching at this point wasn't really viable.

    As always the designs are on Github. The PDF schematic can be found here, and the BOM is here. The old (obsolete) schematics are still available here.

    This is a major step toward getting a PCB designed and fabbed (there's been talk of that being an Anglo-Aussie collaboration which would be awesome) and I'm pretty pleased with the results.

    (In other news, I've not given up on the serial input issue I talked about in my last log. I've hacked on it a little more and gotten to the point where I need to rule out a problem with the MC68901 itself, so I've ordered five more which should be here in a week or two).

  • (Not) Receiving Serial Data

    Ross Bamford08/12/2019 at 20:28 0 comments

    I've grown tired of pulling the ROMs for programming every time I want to try something in the firmware, and having managed to kill one of the ROM chips while doing so (ESD I guess) I decided the time was right to hook up the 68901's Serial In line to the cp2102's TX line so I could hook up a simple Zmodem implementation, allowing me to send code to the running board via the serial link. The idea behind this is to allow me to more quickly iterate on the firmware that will eventually interface with mass storage devices and such.

    Unfortunately, having been at it now for a couple of days, I just don't seem to be able to get it to work. No matter what I do, the 68901 just doesn't respond at all to input.

    To begin with I built the new code into the async serial driver and set it up so that the whole thing would be interrupt driven (by the RX Error and RX Buffer Full vectors), but it didn't work. The interrupts were never generated.

    (As a side note, in the course of doing this I did come across a bug in the serial transmit code that caused it to silently die after the first time the ring buffer becomes completely empty, which is now fixed, so that's something at least).

    For sanity, I went back to basics and wrote a simple 'echo' program in pure assembler that didn't bother with the interrupts at all, and just did polling on the RX Buffer Full and TX Buffer Empty. Still nothing - the MFP never sets the buffer full flag.

    Getting desperate, I hooked up the probe to the SI line and ran a few-seconds of trace while I pressed keys in minicom, and sure enough the UART decoder in PulseView showed the data was getting there just fine. I did this because I was worried that Minicom's hardware flow control might be causing problems, even though I have the cp2102's CTS line grounded right now (eventually I'll drive it from one of the MFPs GPIO lines but for testing grounding it should be just fine).

    I tried lowering the baud rate (all the way down to 4800), switching from the fundamental clock mode to the divide-by-16 mode (which I know can make a difference to receivers), and finally I decided to port someone else's code (actually, the monitor program from the awesome Rhombus project: to my board, in the hope that their working code would show me what I was doing wrong.

    This isn't a perfect test as I've had to make some changes to the MFP initialisation code (my clocks are different frequencies to Rhombus and I don't have any compatible crystals at the moment) but I've only changed the timer frequencies and switched from using two timers on the MFP to just having one timer driving both TX and RX clocks, which is the way my hardware is set up (as I write this, I'm wondering if/how that might be the cause of the problem...?).

    Anyway, to cut a long story short, it doesn't work, in exactly the same way that my own code doesn't work. Right now, I don't have any idea why.

    I'm going to take a break from this tonight, and hopefully have fresh ideas tomorrow. In the meantime, if anyone's got any ideas or suggestions I'd love to hear them - hit me up in the comments :)

  • New Address Decoder is in!

    Ross Bamford08/03/2019 at 20:11 8 comments

    In my last log, I talked about how I was getting started with PLDs in hopes of replacing the 7400-series chips that made up my address decoder. I'm pleased to report that I refined the CUPL code for the ATF16V8B I'd bought, and the chip is now on the board and working perfectly.

    This has brought multiple wins to the project - I've saved a fair bit of board space (8 7400-series have been removed) so the eventual PCB fab will be cheaper, power requirements are lessened, and I've finally been able to fix some bugs in the original decoder design (e.g. gating everything off with /AS and /IACK meaning less additional support circuitry is needed). This also means that /EXPSEL now works as I originally intended.

    The rough CUPL code I posted last time has been considerably cleaned up (it was originally a dump from Logisim's combinatorial analysis). The main logic for the six output pins looks like this:

    !EVENRAMSEL  = IACK & BOOT & !UDS & !A23 & !A22 & !A21 & !A20;
    !ODDRAMSEL   = IACK & BOOT & !LDS & !A23 & !A22 & !A21 & !A20;
    !EVENROMSEL = IACK & ((A18 & A19 & A20 & A21 & A22 & A23) # !BOOT) & !UDS;
    !ODDROMSEL  = IACK & ((A18 & A19 & A20 & A21 & A22 & A23) # !BOOT) & !LDS;
    !IOSEL      = IACK & !A18 & A20 & A21 & A22 & A23;		
    !EXPSEL     = IACK & ((!A20 & A23) # (!A20 & A22) # (A21 & !A22) # 
                  (A21 & !A23) # (A20 & !A21) # (A18 & !A19 & A20));

     It's probably still not perfect and could maybe be made more simple, but it does the job and is a big improvement on the previous code.

    I can't overstate how much this has improved things - before I tore down the old decoder I spent some time running traces of the old select lines vs the new, and it was startling - the old one was fast enough but with the new one, there is virtually no delay between the input and output. I'm pretty sure I could take the system up from 8MHz now to the CPU's rated 10 with no problems. I could probably even overclock to 12MHz and things would still be fine - the limiting factor now is the ROM (which is already nearly maxed out).

    The board now looks like this:

    The new decoder is to the left of the ROMS. The wide open spaces to the left and below it are where the old address decoder used to live. For comparison, here's an older iteration of the board with the decoder (and it's copious wiring) still in place:

    As per usual, all the code for the PLD is available (along with all the designs and code) on github.

  • First steps with programmable logic devices

    Ross Bamford07/15/2019 at 19:04 3 comments

    I'm starting to become really nervous about the breadboard-based nature of the project as it grows and becomes more complex. This was really brought home to me a few weeks ago when I had to transport the board to work where I was demoing it to some interested colleagues - the transport went fine and the board made it there and back in one piece, but it was pretty nerve-wracking plugging it in a hoping it still worked!

    For this reason, I've started to think about doing a PCB design with the board as it stands today. This would have expansion bus capabilities, allowing me to continue to design new bits (e.g. graphics) on breadboard, but would cement the working core of the computer onto a proper, reliable board.

    Before I can do that though, I've decided to revisit some of my earlier decisions in light of this new plan - specifically, the address decoder and glue logic should probably be handled by programmable logic rather than discreet logic as they currently are.

    The current design (with lots of 7400-series chips) works well, but is pretty power-hungry and takes up a lot of board space. Previously this didn't really matter, but if I'm now going to be spending $5-$10 per square inch of board space, I want to make sure I'm making the most of those inches. Replacing many of the fourteen 7400s with two or three PLDs makes a lot of sense now - it'll mean cheaper boards, and less soldering when the time comes to assemble them.

    My reason for using discrete logic initially was for the learning experience, and I'm really glad I did it. I'm a lot more familiar with the 7400-series now, and have become used to designing circuits with them. I've found numerous uses for them in other projects too.

    But going forward, it's time to cut the chip count. With that in mind, I've gotten hold of a bunch of Atmel ATF16V8BQL CPLDs, and started learning to use them (I've never done CPLDs before, so all good for more learning!)

    My first stab has been the address decoder (CUPL code here - but go easy on me, this is my first time!) and, in basic testing, it seems to work exactly as it should. It even fixes a couple of bugs in the existing address decoder, including making the EXPANSIONSEL line work sanely and gating the whole thing off with the CPU's /AS line.

    Even better, it now takes up one twenty-pin DIP rather than a whole bunch of 14-pin DIPs, and uses less power. I've not actually integrated it into the build yet so may find it doesn't work in some horrible way, but according to the datasheet it should be plenty fast enough (faster than the discreet logic design) and as I say in manual testing it seems to perform perfectly, so I'm not expecting any big surprises (I know, I know, famous last words...)

  • Async Serial Output

    Ross Bamford07/15/2019 at 18:46 0 comments

    It's been a few weeks since I've updated here as I've not had as much time to spend on the project as I'd like, but some progress has been made on the software side - I'm now using a proper toolchain for the firmware, consisting of GCC and VASM, so no more Easy68k weirdness to trip me up!

    I've also fleshed out the Serial output via the MC68901 such that it is now completely interrupt driven. This replaces the polling it was doing previously. Whenever the software writes to the serial output, the data is placed into a ring buffer and the MC68901's vectored interrupts drive the actual output from there.

    The serial driver is implemented partly in a mixture of C and assembly - the C code is here and the assembly is here. The top level directory for the firmware is here and contains all the code, the Make build, and bits and bobs like the linker script that ties everything together.

    This was all done in a bit of a rush as I was giving a talk on the computer (and demoing it) at work so I wanted to have some level of sophistication. It's all since been cleaned up and is now pretty nice (in my opinion). The next step in the plan is to enable the RX serial line, and then put in a simple protocol (probably xmodem initially) to allow software to be uploaded via serial link, freeing me from the 16K ROM limit and allowing me to develop the OS without pulling the ROMS for programming every time I iterate :)

  • Vectored Interrupts are Now a Thing

    Ross Bamford06/18/2019 at 08:02 0 comments

    In my last log, I talked about how I was getting interrupts to work, but that I hadn't yet made them work properly. It appeared that, no matter what the interrupt source in the MFP it would always present $FF as the vector during IACK. This was especially strange because the vector base set in the MFP's VR register is $40, so where the $FF was coming from was a mystery.

    I suspected my DTACK generator wasn't robust enough as it didn't take IACK into account, so my first step was to redesign the DTACK generator to take that line into account. No EAGLE schematic yet but in Logisim the design looks like this:

    This also adds in a way to generate the MFP's DS signal during IACK since the MC68010 doesn't appear to assert LDS during this time, and without DS the MFP won't generate DTACK.

    This improved things somewhat, but it still wasn't working. Breaking out the probe and looking at the data lines during IACK was telling:

    A glance at the mess that is D0 (and to an extent D1 and D3) told me what the problem was - I know the bus doesn't float at this point (especially because it's still not stable after the MFP asserts DTACK), so this can only be contention.

    Sure enough, further tracing revealed that, due to the design of the address decoder, the ROMCS lines also get asserted for a short while during an IACK cycle. This is because I didn't gate the address decoder off with anything which, while not exactly efficient, was good enough at the time. Gating it off with AS wouldn't help, as the CPU asserts AS during IACK. I realised I could gate it off with the inverted IACK signal from the new circuit from the shot above.

    That looked much better:

    Nice clean edges, and tracing all the data lines showed the MFP was putting 0100 0101 on the bus, which is $45, exactly the right vector for the MFPs Timer C interrupt.

    A quick fix in the software to put the handler on vector $45, and all is working perfectly. Just need to tidy it up on the board and wire it up correctly, and I can move on to the software support for the interrupts. Currently it's just thrown together on an extra board, and looks like this:

  • System Timer Interrupt

    Ross Bamford06/16/2019 at 21:35 4 comments

    Now I have the MC68901 MFP integrated and the UART is working, I spent a bit of time this weekend setting up Timer C of the MFP as a timer tick I can use in the OS for multitasking.

    For testing purposes, I've set the timer up at about 18Hz and have the interrupt handler just flash an LED connected to MFP GPIO 0. That way, I can visually see that the handler is being run. The code that sets up the MFP now looks like this (I've also upped the UART to 19200 baud):

    * Initialise MFP
    * Trashes: D0
    * Modifies: MFP Regs
    * GPIOs
        move.b  #$FF, MFP_DDR   ; All GPIOs are output
    * Timer setup - Timer D controls serial clock, C is kernel tick
        move.b  #$00, MFP_TCDR  ; Timer C count is 0 (equivalent to 255) for 18Hz
        move.b  #$0C, MFP_TDDR  ; Timer D count is 12 for 19.2KHz
        move.b  #$71, MFP_TCDCR ; Enable timer C with /200 and D with /4 prescaler
    * USART setup
        move.b  #$08, MFP_UCR   ; Fundamental clock, async, 8N1
        move.b  #$05, MFP_TSR   ; Set pin state high and enable transmitter
    * Interrupt setup - Enable timer C interrupt for kernel tick
        move.l  #MFP_VECBASE, D0
        move.b  D0, MFP_VR
        or.b    #$20, MFP_IERB  ; Enable Timer C interrupt...
        move.b  #$20, MFP_IMRB  ; ... and unmask it.

    The code for the handler is very simple:

        bchg.b  #0, MFP_GPDR

    Because I'm using vectored interrupts, this should be on vector 0x45 (MFP_VECBASE is 0x40 and Timer C is at offset 5 in the MFP), but because of a limitation of my IO DTACK generation it's not actually working that way - the IO DTACK circuit doesn't take account of /IACK and so /DTACK is immediately asserted, presumably before the MFP can put the vector on the bus. This causes the vector to always be FF, so for now the handler is just mapped there for testing.

    To actually fix this, I'll need to revisit the /IODTACK generator. I've not put anything down in EAGLE yet, but my plan is to build something like the following:

    Which is basically the same as it is now, with the addition of /IACK into the logic to cause it to work when the CPU is doing an acknowledge cycle.

    There may be a bit more to it, as I'm not 100% sure at this point what the CPU does with /LDS during an acknowledge. The MFP needs its /DS to be asserted along with /IACK so I may need to do a bit more work there, but I'll know tomorrow when I've had chance to look again at interrupt acknowledge in the MC68010 manual.

View all 26 project logs

Enjoy this project?



henk.gooijen wrote 11/07/2019 at 13:40 point

The MC68901 data sheet specifies that the clock does not have to be the same frequency nor same phase as the system clock. So, you could use a separate 4 MHz metal can oscillator and remove the LS93! That will make the 68010 clock completely free to be chosen as there is no dependency anymore. I'd love to get the 68010 running at 10 or even 12 MHz (I think I have a ceramic 68010-12) ...

  Are you sure? yes | no

Ross Bamford wrote 12/31/2019 at 13:24 point

You're right that there doesn't have to be a phase relationship between the CPU and MFP clocks. As I say, the only reason I'm using an 8MHz clock in this iteration is to be able to easily divide it for the MFP, which made sense as the design evolved (it was a 4MHz system clock initially as that was the crystal I had lying around). I'm definitely look at replacing the current clocks with independent canned oscillators in the next revision, initially mostly for board-space and clutter savings, but now also for the reasons you suggest - your point about making it easier to increase the CPU clock is an excellent one. My part is a 10MHz but I wouldn't be surprised to find that it's reliable at 12...

(There is another reason that I never looked at going above 8MHz as the design progressed, which was that I felt I was probably pushing the limits a bit with the breadboard-based prototype, and I wanted the first revision of the board to be a 1-for-1 match of the breadboard design so I was starting with something I knew to be functional).

Thanks again for your awesome suggestions and comments, and apologies for my delayed response - between work and the holidays I've not had much time.

  Are you sure? yes | no

henk.gooijen wrote 01/05/2020 at 20:25 point

Work always comes first, this is just a hobby to enjoy!
I also have a ceramic 68010 10 MHz chip, but my intention was not to "overclock" it, but running it just at 10 MHz. With that clock, VPA will be 1 MHz, perfect for the legacy parts like 6821 and 6850 (also 6840, but I guess the 68230 PIT is a nice chip. I have sereral ceramic 68230 on the shelf :)  If you "overclock" you will need the legacy "A" part (68A21) for 12 MHz or the "B" part (68B21) for up to 15 MHz.

Very understandable that you kept the clock "low". 8 HMz is already almost unbelievable for such a breadboard setup! I also found out that you have to wire power supply to each breadboard directly, not from board to board! From board to board I "lost" 0.6V, making the entire design flaky (and that was way less complex than your 68010 project)!

My main reason for VPA (and 1 MHz cycle) is to add a 5.25" (or 3.5") floppy disk interface (I prefer 5.25"!), using the 2793 FDC. I have done that with a 6809 (and wrote a simple "DOS" in 6809 assembler. Love to do that again in 68000 assembler. "Old-fashioned" IDE can be done with programmed I/O using one PIA (if you don't mind slower data transfers). Building this is not for speed, but for fun :)

Given the "eurocard" modularity approach, I am thinking of some sort of "blinkenlight" console. With a bit of firmware, you can use toggle switches to load registers, set up the PC, load a program manually into memory, and start it. A row of 20/24 switches to load an addres, use 16 of them to store a data word, a selector rotary switch to display the selected register contents on LEDs or on (hex) displays. The red "dot" displays from HP would look cool ... apologies if I get carried away :)

  Are you sure? yes | no

henk.gooijen wrote 11/07/2019 at 10:39 point

Another observation.

You connect the HALT LED via IC9C, so that it can lite up by the reset button *and* the HALT* line from the CPU. However, you connect the RESET LED directly to the NE555 output.

Why not use IC9D (as far as I could see, it is not used) like IC9C? Connect the inputs of IC9D to the RESET line of the CPU, and connect the RESET LED to the output. That way, you can also see the RESET LED lite up on reset *and* when the CPU asserts RESET*.

On the CLK of the MC68901, I see that the processor clock is divided by 2 using the LS93. I have not checked whether the CPU clock and the CLK of the MC68901 must have a relation ... If you substitute the LS04, 8 MHz xtal and discrete R/C parts with a metal can oscillator, you could use a 20 MHz oscillator, and use the LS93 as a by-2 divider to get 1 MHz, and use a by-5 divider to get 4 MHz. I will look into this a bit more.

  Are you sure? yes | no

Ross Bamford wrote 12/31/2019 at 13:18 point

It's a good observation, many thanks for that :) I'll definitely look at making that change for the next revision. The current circuit is one of the oldest bits of the design (along with the clock) and the changes you suggest would certainly make it more sensible!

  Are you sure? yes | no

henk.gooijen wrote 11/07/2019 at 10:20 point

Ross, I enjoyed reading the logs.

If you have not yet sent the .BRD files (gerbers) to the PCB fab, I would like to propose a few changes. For reference, I am looking at the PCB with the RESET button in the top right corner.

You could move R14 to the left and rotate the RESET LED 180 degrees to free up some space. Same for R13. Below the RESET button S1 you could add a 2x3 pin header and add traces from the RUN LED, RESET LED and the button S1 to that 2x3 pin header. That way you have a neat connection of the LEDs and button for wiring to a front panel. If you use a front panel, you just remove the 2 LEDs on the board (or disable them by removing an added jumper in their trace?).

For the same reason (and one more to come ...) I would move the serial pin header JP1 from the left lower corner to the right lower corner. Now the serial traces do not run all along the PCB long side edge anymore.

After you moved JP1, you can change the position of the 64-pin expansion connector. If you want to add one or two boards (more RAM, video/graphics. SD card ...) it would be nice to have a DIN41612 edge connector (2x32). That is the reliable connector also used in VME systems.

You can keep the power supply header PWR in the lower right corner, but is power supply also connectable on the 64-pin expansion connector? For a small backplane-based system that would be very handy.

One final thought, although I would have to look better at the schematic ... The CLK for the MC68901 is at max 4 MHz (data sheet). If that CLK is derived from the 68010 clock (8 MHz xtal with LS04), you cannot easily "upgrade" to run the CPU at 10 MHz. I would propose to put a small square metal can 4 MHz oscillator below the NE555. However, I do not know whether the CPU clock and the MC68901 CLK must have some timing relation, or can be completely independently of each other.

Given the PLDs, adding the "legacy support" (6821, 6840, 6850), implementing VPA would be easy, I guess. True, instead of the 6821 you can use an 68230 but that chip is bigger (but you can use the DTACK as it is for the 68901.

Studying your schematics a bit more.

  Are you sure? yes | no

Ross Bamford wrote 12/31/2019 at 13:16 point

Hmm, you make some very good points with respect to the LEDs and the button, and I like your thinking of adding a header for a front panel. This version of the board is really designed mainly as an SBC but I've thinking of doing the next revision to be more backplane/case friendly so I'll definitely look at your suggestions for that. I'm playing around in EAGLE with the next version so I'll update on here soon :)

I also like your suggestion of moving the serial connector, both to shorten its traces and for the idea of moving the expansion connector. Swapping that out for the DIN41612 you suggest would fit in great with my plans as well, I'll definitely look into swapping out the headers for one of those!

(And yes, power can be connected via the expansion connector too. I didn't specifically design for it but there's nothing that precludes it either. The expansion power pins just connect directly to the power and ground planes and there are no diodes).

As I say, in the next revision I hope to break out the legacy peripheral support onto the expansion connector (at the expense of at least the chip selects for the on-board RAM and ROM which aren't needed there anyway) so I think the way to go for legacy peripherals would be to either make the IO decoding more robust (currently there's no simple way to use it for anything other than the 68901 which just takes up the whole of IO space) or to use a subset of the expansion space, and have a second off-board decoder kick in when the boards EXPSEL line is low. I've not thought a great deal about that yet though, there may be better ways.

  Are you sure? yes | no

henk.gooijen wrote 01/05/2020 at 20:39 point

Pity that my Eagle license is only for up to 100x160 mm 2-layer boards. I am "stuck" at Eagle version 7.6 and cannot justify paying for an upgrade. Their pricing and upgrade paths are a mystery to me since Eagle is owned by AutoDesk (IIRC).

I thought that the address decodig could easily be refined within the PLDs. To keep things simple, I do not see dynamic RAM implementation, and for hobby purposes my guess is that 1 or 2 MB (or MW) is "enough" ... hmmm, who said that too some 40 years ago :)  But at $800000 an I/O address range would be OK. RAM would be from $000000 of course. If I/O speed is really critical, you can use the base register to set it to this $800000 so that it becomes the "zero page".
From $C00000 you could have EPROM for developed programs you don't want to load from disk.

  Are you sure? yes | no

henk.gooijen wrote 11/06/2019 at 20:22 point

Ross, I really like your design! I was designing an 68010-based simple system, but re-inventing the wheel ... The only thing I miss is support for the old 6850 / 6821. You only need to decode an address range for "legacy peripherals" and connect that to VPA. Of course, you should connect VMA and E to the expansion connector.

I see your CPU is a 10 MHz 68010. Would the design also run with an 10 MHz Xtal?  Why not use a 10 MHz metal can Xtal-based oscillator. It has the footprint of the 74LS04, and they even exist in the size of an NE555 timer IC. Using the metal-can oscillator means several discrete components (R and C) less on the PCB.

Just found your project moments ago ... going to look at the board size (is it Eurocard 100x160 mm?)  Planning on supplying bare boards and programmed AFT16V8 chips?

  Are you sure? yes | no

Ross Bamford wrote 12/31/2019 at 13:00 point

Wow, thanks! And thanks for your detailed comments, I'm going to reply to each individually so I don't miss anything :)

There are a few signals I wish I'd broken out to the expansion, including the legacy peripheral support and also the GPIOs from the 68901. I'm going to re-do the expansion in revision 1 to take care of that.

The CPU would run at 10MHz but, as you noticed, I'm simply dividing the main clock to get the 4MHz max clock for the 68901. The reason I didn't use canned oscillators in the first version is that one of the things I wanted to learn going in was how to build my own clock (I've always used canned in the past) and, to be honest, when the project was getting started I simply didn't have any in my parts bin, while I did have a few crystals. You definitely make a good point though and I'll look into switching out those parts in the next revision :)

And yes, once I've got the kinks ironed out, I'm hoping to offer bare boards, pre-programmed ATF16V8s, and maybe even complete kits.

  Are you sure? yes | no

henk.gooijen wrote 01/05/2020 at 20:44 point

If you are going to make eurocard-sized boards with DIN41612 connectors, bring out all busses and control signals, I definity would buy it!  The entire system would be limited to 2 or 3 boards, otherwise you would have to add bus receivers/transceivers. The key is that it remains a small system, not just an SBC, but a small system with -some- expandability (parallel and serial I/O, the 2793 FDC ...)

  Are you sure? yes | no

Jacob MacLeod wrote 10/13/2019 at 21:05 point

Nice computer!

  Are you sure? yes | no

Ross Bamford wrote 12/31/2019 at 12:51 point

Thanks :)

  Are you sure? yes | no

Warren Toomey wrote 08/07/2019 at 02:22 point

Thanks Ken, good to know about GALs. What about CPLDs? I'm guessing they mostly have a JTAG interface, so I'd need to put a JTAG header for each one on the PCB.

  Are you sure? yes | no

Ken Yap wrote 08/07/2019 at 02:31 point

That I don't know, it's on my todo list. But sounds right from the specs of the prototyping boards I've seen on sale for around $20. You could also use a CPLD with a PLCC form factor and program outside before putting into a socket on the production board.

  Are you sure? yes | no

Warren Toomey wrote 08/07/2019 at 01:49 point

Question: what tools (software/hardware) are you using to program the CPLD? I'm trying to find open source tools and a programmer that I can plug into a Linux box. Also, what resources did you use to learn about CPLDs? I know Verilog but have only done FPGAs. Thanks, Warren

  Are you sure? yes | no

Ken Yap wrote 08/07/2019 at 02:06 point

GALs are quite simple CPLDs. You can find some links in my log

For Linux there is compiler and the popular TL866 programmer will handle the 16V8. There are open source drivers for this programmer. I use it in a virtual XP machine with USB forwarding though.

  Are you sure? yes | no

Ross Bamford wrote 08/07/2019 at 07:22 point

For my first steps with the AFT16V8s, I've been using WinCUPL which is provided free by Atmel. It's pretty terrible and Windows only, but it was a start. I just check in the compiled output in to Git so I'll never have to use it again :D

For programming Ken's right, the TL866 programmer (I have a TL866II plus) can be programmed via open-source drivers on a linux box - I use Minipro ( and it's great. The programmer cost me about UK £50 with a bunch of chip adapters and shipping.

  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