Yet Another m68k Homebrew

A full-featured Motorola 68k homebrew, this time with a 68010 running at 8MHz

Similar projects worth following
A Motorola 68k project, using the MC68010 processor running at 8MHz. 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: and PCBs and kits will soon be available on Tindie!

This project is a general-purpose Motorola 68k computer designed and built from scratch using mostly period-appropriate parts. It started out as a breadboard project, and has now progressed through a revision zero prototype, to a much-improved revision 1 board design that will be available to buy as either the bare board or a self-assembly kit.

The system is based on a 68010 running at 8MHz with 16KB ROM and 1MB RAM, and with a mix of PLD and TTL glue logic. It has an on-board UART and includes a serial boot loader that can load code over the serial port (using the widely-supported Kermit protocol). A simple proof-of-concept "kernel" also exists that can be loaded via the boot-loader, and gives a good starting point for developing code to run on the computer (i.e. it provides ready made link scripts and so on).

In terms of hardware hacking, the board provides a few GPIO pins with interrupt capability, as well as two software-controlled timers that can handle delay mode, event counting and (primitive) PWM. These are handled on-board by the MC68901 multi-function peripheral. All signals are also broken out on an expansion connector, so it should be quite easy to build expansions for this system to handle pretty much anything you can think of.

The next steps for the project are to design and build a graphics adapter (probably based on the Yamaha V9958) and other expansion cards, and to make these available to others who want their very own modern(ish) M68K computer!

  • 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

  • Kits coming soon!

    Ross Bamford3 days ago 0 comments

    The revision 1 PCBs I mentioned previously took about a week to arrive from JLCPCB, and I'm just as happy with them quality-wise as I was with the revision zero boards. They also represent the first boards that were designed (well, updated) in KiCad and exported for manufacture from there, and I'm pleased to say there were no unforeseen issues. I'm really liking KiCad now I've gotten used to it, and don't miss EAGLE at all. 

    With this milestone passed, I'm looking to start offering the computer in kit form on Tindie! The first iteration will be a sort-of "dev kit", in that it will be most suitable for hackers and devs, and I've been hard at work getting the software tidied up in preparation for that. The kits will come pre-loaded with the serial boot loader firmware and I've put together a "starter project" to easily spin-up an assembly or C project that's compatible with that so it'll be really easy to get started with the board.

    That said, it's not all work and no play - I've also spent a bit of time porting some recreational software. Here's a screenshot of Jeff Tranter's 'Adventure' running on the r1 board, loaded via Kermit:

    With lots of new development in the firmware and software, as well as the hacker-friendly improvements in the revision 1 board (GPIOs, timers, external interrupt capabilities and compatibility with "legacy" MC6800 peripherals included!) there's a lot of fun to be had with this board. I hope to be shipping kits in the next couple of weeks, and will update here as soon as I can.

    Oh, and before I go, here's how the revision 1 looks when populated and working:

    With this revision of the main board done, I'm turning my attention to peripherals. I already have a couple of graphics chips to play with and have ordered a few bits for experimenting with mass storage too, so watch this space for lots more development to come! 

  • Revision 1 PCB is out for manufacturing

    Ross Bamford03/17/2020 at 22:20 0 comments

    Just a quick update to the previous log in which I talked about having made a start on the revision one design: I've now finished it and sent if off to the fab!

    This revision includes a bunch of improvements, including:

    • An improved expansion connector with support for MC6800 (legacy) peripherals
    • A new IO and panel connector with GPIOs, software controlled timers and dedicated blinkenlight pins
    • Doubled clock rate for the UART (allowing up to 9600 baud in the super-reliable divide-by-16 mode, or 115200 in fundamental, though YMMV here).
    • Improved board layout (both in terms of place and route)
    • Fixes for some silly mistakes in revision zero

    This incorporates a number of suggestions made here in the discussion, so thanks to @Ken Yap and @henk.gooijen for those (not all of the suggestions made it into this revision but they're not forgotten!) and also to @paulvdh who took the time to help me import the project into KiCad and get started with it - I'm absolutely hooked now, and hardly miss EAGLE at all!

    The new boards should be here next week (global pandemic permitting), I'll update when they arrive!

    As always, the updated design is on GitHub: 

  • A brief software update

    Ross Bamford03/15/2020 at 22:17 0 comments

    I've spent a fair bit of time on the software for the board over the past week, and finally have a fairly nice serial boot loader working, meaning that software iteration is now much quicker  as there's no need to pull the ROMs and reprogram for each test. This also means fewer dead ROM chips (I've got a small collection of failed chips that haven't survived the constant pull/program/reinsert loops).

    This boot loader also handles initialisation of the rest of the system and provides a few TRAPs that can be used by loaded code. These are leveraged by a very simple proof-of-concept "kernel" that can be loaded by the boot loader and handles relocating itself from the initial bootload location, C linkage (with .bss initialisation etc) and provides the beginnings of a low-level library that interfaces with the machine via the aforementioned TRAP vectors.

    As well as proving the boot loader works, this will serve as a useful base-project for code that can be loaded by the loader, and means I can really start working on the software for the computer now I'm free of the the 16KB limit imposed by the ROMs.

    So with that, the PCB migration KiCad done and work started on the revision one board, it's been quite a busy week all round :)

    EDIT: Adding a link to the code in case anyone wants to have a look: the serial boot loader is here, and the POC "kernel" is here.

  • This is now an EAGLE-free zone!

    Ross Bamford03/15/2020 at 21:47 0 comments

    I've mentioned before that I was unhappy with the way Autodesk now do licensing for their EAGLE CAD package, and that I wanted to move to something else (probably KiCad). No sooner had I mentioned this than the community said it could be done with relative ease, and @paulvdh supplied me with a conversion of the project as proof. 

    Unfortunately I've had a few issues getting KiCad to work reliably on macOS Catalina, but I finally got it working perfectly and spent some time getting to know it, and I have to say I'm very impressed. I was a little apprehensive about "unlearning" everything I know from EAGLE and learning a new package, but it's actually been pretty straightforward. Having a pre-converted schematic I knew well has probably been a huge help :) 

    I've now committed the conversion of the revision zero board to Git, and have made a good start on the revision one PCB. I started by working out the kinks in the converted schematic (for example, removing the control bus in favour of global labels since KiCad doesn't currently supported buses made of named signals) and now have a schematic and PCB that pass both ERC and DRC with zero warnings or errors, which I've committed as the initial work on the revision one board. 

    After tidying up a few text-size and placement issues on the PCB and fixing some of the schematic component footprints, the revision one is looking like this:

    (I've also fixed the issues I raised against the r0 board at this point).

    The EAGLE files have now been consigned to (git) history - and it feels good to be using a completely open-source toolchain for the design of the project, without all the artificial limitations that EAGLE standard imposed.

  • Revision 0 - PCB Population & Debugging

    Ross Bamford03/01/2020 at 13:40 2 comments

    As I mentioned in the previous log, the revision zero PCBs arrived last week, and I finally had time to source the final few parts I was missing (a few IC sockets) and solder up the boards. I wanted to socket all the chips for this first population in order to have fewer variables when it came to checking if the board actually worked (i.e. it would eliminate the possibility of me blowing an IC through ham-fisted soldering - I've even socketed the 555!)

    I'm pleased to say that, a few minor issues aside, the board works perfectly, and is happily running the same firmware and test code that runs on the breadboard. The PCBs from JLCPCB are fantastic and lead-free hand-soldering was a breeze, even with the small clearances on a few of the vias I talked about previously.

    The finished board looks like this:

    I still haven't been able to get hold of any 74LS93s (they're in-transit from China) so I've substituted with a DM5493 I picked up as surplus from a local electronics store, and of course it works fine.

    Read more »

  • Revision 0 PCB - Arrived!

    Ross Bamford02/26/2020 at 19:35 0 comments

    Further to the previous log, the revision zero PCBs arrived today, and I have to say I'm really happy with them.

    As I expected, I immediately noticed a couple of things that I somehow missed during the design and checking stage, such as the right-angled trace under the odd ROM chip, and a couple of vias that are quite close to pads (pin 24 of the MC68901 at bottom right, for example), but I think I'll be able to work with it. I'm a bit annoyed with myself for missing these before sending the board for manufacture, but lesson learned for next time... 

    Speaking of next time, I talked previously about how I was looking at switching from EAGLE to something else, and no sooner had I said that than the awesome @paulvdh stepped in and spent some time proving that KiCad could not only import the EAGLE project, but could do it with minimal manual work. Just that would have been amazing, but Paul then went on to do lots of tidying up and fixing up of inconsistencies and finally made a bunch of comments explaining the work done and the differences between EAGLE and KiCad, so I'm now all set to start really getting to grips with KiCad. I really can't express how grateful I am to Paul for taking the time.

  • Revision 0 PCB - Possibly on its way!

    Ross Bamford02/23/2020 at 18:30 3 comments

    For the past few weeks I've been waiting for the revision 0 PCBs, and I was going to wait until they arrived before posting a log detailing the build, but I'm aware it's been a while and thought I'd do a brief update.

    I eventually decided to do a trial order with JLCPCB - despite my initial leaning toward OSHPark the price was ultimately the deciding factor - for prototype boards it just made sense to go with China where I could get five-off of the r0 board for a quarter of the price I'd pay for three from the US. I've heard (read) good things about JLCPCB so I decided to give them a go.

    Unfortunately, my timing was (as usual) terrible, and the boards have been waiting for production for over a month - the recent Coronavirus outbreak has really hit hard and nothing's been in production. They did re-start production on two-layer boards a couple of weeks ago, but my four-layer has been waiting for things to settle down.

    Naturally, I've been checking on the order frequently, and just now I've noticed that it seems to be progressing! Apparently it's now "waiting for carrier to pick up", so fingers crossed it is actually produced and will be here soon! I'll obviously update as soon as I know more.

    In other news, I've started looking toward a revision 1 design, with some changes I wanted to make and some awesome suggestions from @henk.gooijen (see the discussion for details - they're worth a look!). Sadly, I've fallen foul of the latest Autodesk debacle, as I cancelled my EAGLE standard subscription (with my typical terrible timing again) just before they stopped offering it as a standalone subscription. Now, if I want EAGLE standard again, I have to pay for Fusion 360 as well! This means that the price is now roughly four times what I used to pay, because they bundle it with a piece of software I neither want nor need.

    So, I've been looking around for an alternative. I'm prepared to put up with a learning curve,  and my needs are fairly modest:

    • Must work nicely on macOS Catalina
    • Must be able to import the EAGLE schematic for the project, ideally without manual fixes
    • Ideally would be able to import the EAGLE board with minimal manual fixes
    • Must be reasonably priced!
    • Must support four-layer boards of 160x100 (and ideally more layers/space)

    I've had a look at KiCad in the past, and that seemed the most likely candidate, but I've not been able to get it working reliably on Catalina yet. This is something that I think is being worked on, so it will probably be the way I go - and to be honest, I've always felt I should be using it anyway, rather than the proprietary EAGLE...

    In the meantime, if anyone has any suggestions for other software I might try, I'd love to hear about it!

  • 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.

View all 33 project logs

Enjoy this project?



paulvdh wrote 02/24/2020 at 10:30 point

I noticed there was some interest in KiCad for this project...

So I cloned the project from github and imported the Eagle files into a KiCad project.

The I updated the netlist, and did a DRC check in PcbNew (PCB part of KiCad).

The PCB had 0 errors and visually also looks OK, but I have not done any extensive checking.

I did notice the tracks are very thin (6mill or 0.1524mm) and on some places there are 3 tracks between two 0.1" pins.

Producing boards may be cheaper with some coarser design rules, but then, 4-layer boards are not very cheap anyway.

The schematic also imports reasonably well. Main remaining problems are small text with the labels on the wires, and long text near the busses. They apparently list all the wires in the bus. (KiCad is expected to do something with this in the future, probably in KiCad V6 which is expected around the end of the year (Maybe 2021). Also, the layout of the page borders is lost, but the title block is converted.

I could upload the zipped conversion to somewhere, but my git skills are near to non existent. I'm also not sure if this is very usefull, the total amount of work in this was about 5 minutes. (Typing this text takes more time).

I have no experience with M68K, nor much interest in this project. I just like KiCad, and if there is interest in this conversion I like to help a bit with that.

If you still have problems with getting KiCad to work reliably on Catalina, then I suggest to open a new topic on the KiCad user forum at:

Another small thing:

I noticed there were no mouning holes on the PCB, while there is plenty room to add some. Even simply screwing the PCB to a piece of wood would make a sturdier setup on your desktop while playing with it.

  Are you sure? yes | no

Ross Bamford wrote 02/24/2020 at 20:53 point

Wow, awesome! Thanks!

I'm going to DM you with my email address, if you could send me your conversion I'd really appreciate it - it may have only been five minutes work for you but I'm totally new to KiCad so it would likely take me much longer :) 

I've still not been able to get KiCad to work natively, even after disabling Gatekeeper the latest download crashes immediately at startup for reasons I've not yet debugged. I'll keep at it though and if I turn up anything potentially useful I'll take it to the forum.

In the meantime I've installed KiCad in a Fedora VM, not ideal but it works and I can at least start figuring out how to use it :)

  Are you sure? yes | no

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

Ross Bamford wrote 02/23/2020 at 18:09 point

(Replying to @henk.gooijen - Hackaday seems to limit the depth of replies on here).

I must admit I was pleasantly surprised that it worked and was so reliable at 8MHz on breadboard - I was anticipating all sorts of issues but it just shows that paying a pound or two more for the boards and being careful with the wiring pays off. I experienced the same issue with power fairly early in the project, but it's been much better since I migrated it to a star configuration for the power rails.

Love the idea of integrating a 5.25 FDD or IDE HDD! The only thing that's put me off doing that is the need to bring in a 12V rail (though once this thing is off breadboard and onto PCB that's something I'll probably do anyway). 

Oddly enough I've been thinking of doing a front-panel type thing, something like the front panel from the old Altair. Hadn't considered blending it with this project but that would be a nice toy to have and would be really cool to see :) 

I'm currently still waiting on the revision zero boards, and started looking at making some of the changes you suggested for the next revision, but sadly Autodesk have changed the licensing for EAGLE and I don't want to pay four times what I used to pay for it... I've been looking at KiCad but sadly can't make it work reliably on Catalina, so I'm kind of between CAD software at the moment :(  Whatever I end up using it'll take a while (unless I just bite the bullet and pay the increased price for EAGLE I guess) as I'm getting the impression there are no good ways to import EAGLE boards into other packages, so it looks like the revision one will actually be a whole new board based purely off the schematic (which is no bad thing I guess, I'll be less likely to take short cuts ;) ).

  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