A full-featured Motorola 68k retro computer, starring a 68010 running at 8MHz

Public Chat
Similar projects worth following
Starting from
roscopeco has 98 orders / 12 reviews
Ships from United Kingdom
The Really Old-School Computer, m68k (rosco_m68k) is a Motorola 68k-based general-purpose retro computer, designed for the MC68010 processor running at 8MHz (though the board and standard firmware also work with a 68000!). 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 ton of software including firmware, standard hardware libraries, quick-start project templates and utility programs. Design and code lives on github: and PCBs and kits are now 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 is 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

  • MC68681, SPI, LCDs and SD Cards - an overdue update!

    Ross Bamford10/11/2020 at 02:44 2 comments

    Wow, it's been three months since I last updated here, but that's not because nothing's been happening with the project - in fact, exactly the opposite! I've been so busy improving things and keeping up with the awesome stuff the community are doing that I've just not had time to write a log for a while!

    For this log I'll just do a quick update on what's been happening over the past couple of months, with a promise to get better at keeping things up to date here on HaD. 

    MC68681 DUART

    Something that's always been a sticking-point for me (and for quite a few others now) is the 9600 BPS speed limit on the built-in MC68901 UART. As a step toward addressing this, I designed a whole-new comms board for the rosco_m68k, based around the (very capable!) MC68681. This brings two independent UART channels, the potential for future expansion with some additional IO ports, and makes uploading code to the system much less painful thanks to it's reliable support for baud rates up to 115.2Kbps. 

    Even better, this is a drop-in replacement for the MFP UART, with recent revision 1.2 ROM builds supporting it out of the box (with auto detection). The board itself looks like this:

    I talked a bit about the design in a previous log, but at that point the board wasn't generally available, and the code for it was nowhere near complete (beyond a breadboard design and a basic demo). That's all changed, and it's now available on Tindie :)

    SPI & LCD Awesomeness

    There's been a lot of development lately around getting bit-banged SPI working, using the GPIOs provided by the MC68901, and @Xark changed the game by implementing some new SPI routines that were >5x as fast as the ones we had before. Not content with that, he went on to use his new SPI routines to implement an awesome bit-banged SPI LCD slide-show for the rosco_m68k! 

    The code itself is awesome, but the video shows it even better:

    That's right - this is a 16/32-bit m68k system pushing full-colour images out over SPI via the (almost forty-year-old) MC68901, all driven by some super-optimised hand-crafted assembly SPI routines. Totally awesome!

    (In other news, Xark also became the first committer on the project who isn't me, and has already made some great contributions!)

    SD Card Support

    Hot on the heels of Xark's SPI stuff, we were able to revisit the SD Card support, specifically using the faster SPI routines to get a decent speed boost. 

    It's early days yet (the code is still sitting in a PR but will likely be merged by the time you read this) but it's looking pretty good - SD support is in the development ROMs, with an SD loader, pretty-complete FAT support (thanks to ultraembedded's FAT library) and support for SD filesystems in user code via a new standard library.

    And more!

    There's been so much more going on that I haven't mentioned here - expect an upcoming post about a totally awesome front-panel project, a brand-new but very promising OS, and tons of other stuff. And this time, I promise it won't be three months before I do those posts!

  • V9958 80x24 Console

    Ross Bamford07/08/2020 at 21:56 0 comments

    Now that the V9958 video board is shipping on Tindie, and I've gotten fresh stock of all the options for the base board, I've been working on getting a basic text mode console supported by the standard firmware. It took me a while to get used to the way the V9958 works, but thanks to the pretty great Yamaha documentation that's still available online (link for V9938, the V9958 documentation just lists the changes) it wasn't too difficult to make something work.

    Here's a shot of it running Jeff Tranter's adventure, with the unmodified code that runs on the board without video connected.

    (Sadly I don't currently have a CRT to run it on, but I'm working on that!)

    Getting this working in the firmware in a way that was compatible with the current revision 1 board presented two challenges - firstly, I had to write the code for the console, including taking care of scrolling and tracking cursor position etc, and secondly I had to somehow find a way to get the code to fit in the severely-limited 16KB of ROM (a good chunk of which is taken up by the Kermit routines already). 

    Read more »

  • Benchmarks!

    Ross Bamford06/13/2020 at 19:41 1 comment

    Over on Discord, @Xark recently did some work on porting some old dhrystones to the rosco_m68k, which gave a feel for the performance of the board for the first time, and the results are encouraging! In Xark's words, we "blew the doors off an outdated Dhrystone text file found somewhere on the Internet" :D

    Obviously these are to be taken with a hefty grain of salt as they're hardly "fair" - we're using a much more modern compiler than was likely available for any of the other machines on the list, and we also don't have an OS to get in the way. To try and make it a more even fight we did limit the GCC optimisation to -O1, which feels like it should be roughly on-par with the optimisations that would have been done by the compilers in use at the the time the other machines were benchmarked. 

    To see how the rosco_m68k stacked up against other machines of the same era, we ran the benchmarks with both 8MHz and 10MHz system clock. The results were thus (further down the list is better):

    Last updated 06/06/2020 by Xark
    *----------------DHRYSTONE VERSION 1.1 RESULTS BEGIN--------------------------
     * TYPE                         SYSTEM                          NO REG  REGS
     * --------------------------   ------------    -----------     ---------------
     * Apple IIe    65C02-1.02Mhz   DOS 3.3         Aztec CII v1.05i  37      37
     * -            Z80-2.5Mhz      CPM-80 v2.2     Aztec CII v1.05g  91      91
     * -            8086-8Mhz       RMX86 V6        Intel C-86 V2.0  197     203LM??
     * IBM PC/XT    8088-4.77Mhz    COHERENT 2.3.43 Mark Wiiliams    259     275
     * -            8086-8Mhz       RMX86 V6        Intel C-86 V2.0  287     304 ??
     * Fortune 32:16 68000-6Mhz     V7+sys3+4.1BSD  cc               360     346
     * PDP-11/34A   w/FP-11C        UNIX V7m        cc               406     449
     * Macintosh512 68000-7.7Mhz    Mac ROM O/S     DeSmet(C ware)   625     625
     * VAX-11/750   w/FPA           UNIX 4.2BSD     cc               831     852
     * rosco_m68k   68010-8.0Mhz    ROM             gcc-7.5.0        -       862 (-O1)
     * DataMedia 932 68000-10Mhz    UNIX sysV       cc               837     888
     * Plexus P35   68000-12.5Mhz   UNIX sysIII     cc               835     894
     * ATT PC7300   68010-10Mhz     UNIX 5.0.3      cc               973    1034
     * rosco_m68k   68010-10Mhz     ROM             gcc-7.5.0        -      1086 (-O1)
     * Compaq II    80286-8Mhz      MSDOS 3.1       MS C 3.0        1086    1140 LM
     * IBM PC/AT    80286-7.5Mhz    Venix/286 SVR2  cc              1159    1254 *15
     * Compaq II    80286-8Mhz      MSDOS 3.1       MS C 3.0        1190    1282 MM
     * MicroVAX II  -               Mach/4.3        cc              1361    1385
     * DEC uVAX II  -               Ultrix-32m v1.1 cc              1385    1399
     * Compaq II    80286-8Mhz      MSDOS 3.1       MS C 3.0        1351    1428
     * VAX 11/780   -               UNIX 4.2BSD     cc              1417    1441
     * VAX-780/MA780                Mach/4.3        cc              1428    1470
     * VAX 11/780   -               UNIX 5.0.1      cc     1650    1640
     * Ridge 32C V1 -               ROS 3.3         Ridge C (older) 1628    1695
     * Gould PN6005 -               UTX 1.1c+ (4.2) cc              1732    1884
     * Gould PN9080 custom ECL      UTX-32 1.1C     cc              4745    4992
     * VAX-784      -               Mach/4.3        cc              5263    5555 &4
     * VAX 8600     -               4.3 BSD         cc              6329    6423
     * Amdahl 5860  -               UTS sysV        cc 1.22        28735   28846
     * IBM3090/200  -               ?               ?              31250   31250

    It was really exciting to see these results - the rosco_m68k is the fastest 68000 in both the 8MHz and 10MHz categories :) 

    I will say again that the lack of an OS at the moment is probably a distinct advantage here, although these results were captured with the system timer tick running which does some memory access a couple hundred times a second and toggles a GPIO periodically, so it's not like there was nothing else going on - I like to think the results are in some way representative.

    You can find the code along with the results in a text file here.

  • (Dramatically) Improving Comms Speed

    Ross Bamford06/07/2020 at 18:56 0 comments

    One of the things that's become an increasing problem on this project is the MC68901 Multi Function Peripheral. Way back when I started this project (actually when I ordered the very first MC68010 for it!) I ordered a 68901, almost on a whim, as it seemed like a very capable chip that would take care of a lot of problems for me. To an extent that turned out to be true, but the venerable MFP brings with it more than its fair-share of problems too.

    Read more »

  • V9958 - Beyond Hello World

    Ross Bamford06/04/2020 at 22:45 0 comments

    Development on the V9958 board continues apace, and after a false start due to a silly mistake in the first revision things are back on-track with a revision 1 prototype. The design is now validated and working really well. So far it's baby-steps in terms of software, with just enough to show an image.

    That's the board image from the website, scaled to a suitable size for the V9958 and reduced to 256 colours. It's bundled in with the code that sets up the VDP and copies the data into video RAM (64KB populated in this image, just enough for testing). Output is RGB via SCART, using a six-pin DIN connector which is compatible with readily-available cables designed for BBC Micro and Acorn computers :) 

    (Aside: There's also a header on-board with RGB and sync signals that will be compatible with things like  for those in non-SCART countries, and I plan to do a small daughterboard based on some CXA1645s I have lying around that will fit that header too).

    Address decoding and selects for the VDP are handled by a couple of 16V8s, and the decoding is specific to the address range needed by the four ports the VDP exposes. I was keen not to repeat the short-sighted mistakes made earlier (with the MC68901 for example, which greedily takes all of odd IO space), and going forward will be doing the same with all the expansions. The next main board revision will also fix the underlying issue with the MFP decoding too.

    Programming the V9958 is actually quite a nice experience. I've not done any real "in-anger" work with it yet, but what I have done has been pleasant. Its register set-up isn't especially arduous, and it has some nice features like auto-increment for both VRAM address and register number that make things nice and manageable. The documentation is pretty great too, though it's a bit unfortunate that one has to consult the original 9938 documentation in conjunction with the changes listed for the 9958 in a separate document. I suppose when these documents were current they would have been actually printed on real-life paper, so it makes sense that there wasn't a completely new document for the (relatively few) changes between the 9938 and the 9958.

    I did run into a slightly odd issue that took a little bit of debugging (here, MAME once again proved worth it's weight in gold) - it turns out that the V9958 is a little bit picky about the order of things during initialisation, and this isn't totally obvious from the manual. Being able to single-step things and view memory in MAME was invaluable.

    In the end, the code to display the image above is quite compact. This is the meat of it, including complete set-up of the VDP, switching to G7 mode, and copying the data to video RAM (the 'SLOWDOWN' subroutine referenced below is simply three NOPs and an RTS):

        ; Set mode G7, disable interrupts and enable output
        move.b  #%00001110,PORT_WREG_SETUP   ; Write DG=0,IE2=0,IE1=0,M5=1,M4=1,M3=1
        move.b  #$80,PORT_WREG_SETUP         ; To register 0
        move.b  #%01000000,PORT_WREG_SETUP   ; Write BL=1,IE0=0,M1=0,M2=0,SI=0,MAG=0
        move.b  #$81,PORT_WREG_SETUP         ; To register 1
        ; Set PAL mode
        move.b  #%10000010,PORT_WREG_SETUP   ; Set 212-line, PAL mode...
        move.b  #$89,PORT_WREG_SETUP         ; .. to register 9
        move.b  #%00000000,PORT_WREG_SETUP   ; Select BG: GGGRRRBB
        move.b  #$87,PORT_WREG_SETUP         ; .. In VDP register 7
        move.b  #%00001010,PORT_WREG_SETUP   ; Select 64K DRAM, disable sprites
        move.b  #$88,PORT_WREG_SETUP         ; .. In VDP register 8
        ; Set pattern layout table to 0x0
        move.b  #%00011111,PORT_WREG_SETUP   ; bit 16 of 0x0, constant 11111
        move.b  #$82,PORT_WREG_SETUP         ; .. to register 2
        ; Set up to write VRAM at 0x0
        move.b  #0,PORT_WREG_SETUP           ; VRAM Base at 0
        move.b  #$8E,PORT_WREG_SETUP         ; > register 14
        move.b  #0,PORT_WREG_SETUP           ; Set VRAM A0-A7
        move.b  #$40,PORT_WREG_SETUP         ; Set VRAM A8-A13, and write enable
        move.l  #_image_start,A0
        move.l  #_image_size,D0
        bra.s   .COPYSTART
    Read more »

  • Exciting new things!

    Ross Bamford05/30/2020 at 19:13 0 comments

    There's so much going on with the rosco_m68k at the moment, it's hard to keep up! Not just the stuff that I'm planning (of which there is lots!) - it's really exciting to see what the growing community are doing too. There's always a ton of conversation going on over on the discord server, with new and cool projects (both software and hardware) being worked on.

    In no particular order, we've got a floppy-drive controller @henk.gooijen is planning (to go alongside the absolutely awesome monitor software / firmware he's created - screenshot below), a real-time-clock integration thanks to @RTS4E75 (and an IDE interface in the works). Some people are even working on some amazing FPGA stuff that's totally beyond me at this point - @Claude is working on interfacing the M68k bus to an ice40up5k (on a upduino 2.0) and @Xark has made some amazing progress on his VGA video card. I'm not going to talk too much about that as I don't want to spoil the surprise, Xark tells me he's planning to write up a Hackaday project about it, so keep an eye out for that - it's exciting stuff (we've already seen some amazing output from it on a VGA monitor!).

    As I've said before it's pretty humbling that people are finding so many cool things to do with this little project that started out on breadboard as a "I wonder if I can do that" thing about 18 months ago. I love that people are picking this up and running with it, and having so much fun :)

    Of course, the community is great for finding things that could be improved, and there's a whole bunch of things that have already been earmarked for a future board revision. Everything from better bus connectors to tighter IO Space decoding and bigger ROM is in the works, and as well as the V9958 video I talked about in the last log I'm also working on sound (YM2149F) and some firmware/software improvements. 

    I've also ordered a bunch of ICs today for various expansions I'm planning - including some much-needed MC68681 DUARTs and *lots* of 7400 series bus transceivers, some 22V8 GALs and various other support chips. Things have taken off so quickly that I've not had as much time as usual for hardware lately - I'm really looking forward to diving back in!

    If you want to get involved, or even if you just want one to play with (we now have a bunch of precompiled example programs, including a BASIC interpreter!) I've just received fresh stocks, so grab yours on Tindie.

    As promised, here's a screenshot of Henk's frankly awesome monitor. Keep your eyes peeled for an upcoming post from Xark in which he tells me he'll be showing some really cool pics too :) 

  • V9958 - First tests successful!

    Ross Bamford05/16/2020 at 22:21 0 comments

    It's been another dizzying couple of weeks on the rosco_m68k project, with lots of community activity going on, Tindie orders to ship and more stock to source, but I've still had time for some good old-fashioned hacking. I've been focusing on the video card mainly, and it's now at a point where prototype boards are ordered and have been shipped by JLCPCB.

    In it's current state, the board looks like this:

     (Well, it's changed a bit since that photo as the video RAM at bottom right understandably didn't work in this configuration :D) 

    The centrepiece here is the V9958 (on it's SDIP->Breadboard adapter centre right), supported by a couple of 16V8 GALs for decoding and glue, all hooked into a prototype bus board (top left). The main board is top-right. I was pretty impressed it worked at all, and it took a little tinkering to get it going, not because of issues with the design so much as issues with breadboard in general. 

    To begin with, I didn't have any suitable DRAMs, so while I waited on their arrival I decided to try hooking up an old (battery-damaged) Amiga trapdoor expansion PCB to see if it would work. Results were encouraging:

    Obviously it's not quite there, but there *is* some output, so I knew I was heading in the right direction. Again, the ability to prove this out in MAME was a massive help, this is what the screen above looked like in the emulator:

    Eventually the DRAMs arrived, which is when I took the shot of the board you saw in the first picture. This improved things somewhat, but also made other things weirder:

    (all the H's are deliberate, I changed the character I was clearing the screen with to check I was actually writing the DRAM - MAME couldn't help here as it was all about cycle times and refresh).

    This is the point where I took the first picture in this post, where the DRAM was tacked on to yet another breadboard and jumper wired in. Of course I suspected this to be the problem, and sure enough, after moving the DRAMs onto the same board as the V9958 itself and making sure the wiring was sound, I was finally able to get a decent "Hello World" out of the VDP!

    With this success, I finalised the schematics for the prototype board with some input from everyone over on Discord, and drew up a quick board design to send off for manufacture. It's on it's way, and I'm really looking forward to building it and proving the design before moving onto the final design of the board.

    The PCB is quite compact (it's a prototype, and I'm working hard to keep prototype costs to a minimum after spending far too much on prototype RAM and bus boards):

    The final design is going to incorporate some great community suggestions (like the amplified RGB and sync signals going to the header as well as the DIN, and the colour bus being on a header too), but for now I just want to make sure the basic thing works, and this will do just that.

  • Lots going on!

    Ross Bamford05/07/2020 at 18:29 0 comments

    Whew, it's been a busy couple of weeks here on the project, with lots going on and lots to update, so I'm going to give a quick rundown here of the main developments that have been happening. 

    Tindie launch - response has been amazing!

    It's almost a month since the rosco_m68k launched on Tindie, and I've been amazed by the response! I honestly wouldn't have believed back when I started this project that anyone else would be particularly interested in it, but it seems like it's going to be a modest hit, and I'm super grateful to everyone who's ordered one, or added them to their wish lists - thank you all so much!

    Rest assured that the money from sales will be put to good use designing new expansions for the rosco_m68k, expanding the software, and generally making it better all the time. A V9958 video board is already in the works (more on that later!), a RAM expansion has launched today and there's a new local-bus / backplane board coming real soon (just needs one more spin through manufacturing to correct some minor issues).

    Once again, huge thanks to everyone who's already built their very own brand new, really-old computer, and if you haven't got yours yet but would like one, you can find it available now on Tindie.

    Community is growing!

    Now the rosco_m68k is "out there" and people have jumped on board, it's been great to see a bit of a community growing around it. It's truly awesome getting together with people and hearing their plans and ideas for the computer, things they want to try and new stuff they want to make.  

    We're using Discord as a place to meet, and it's great to see people there who have been long-time friends of the project since the breadboard days here on Hackaday as well as new faces. If you'd like to get involved we'd love to say hi - find our server at .

    The computer has an emulator!

    Speaking of community, @Micko_mame joined Discord after building his rosco_m68k kit, and hasn't stopped amazing me since with the things he's doing with software. As a developer of the MAME emulator, Micko knows his way around the source of that project, as he demonstrated with a real mic-drop moment when he posted a picture of the rosco_m68k firmware and examples running in the emulator. 

    I cannot understate how awesome this is, debugging on a single-board computer with no kernel and only serial IO can be a challenge at times. Micko's MAME fork will really speed up the software development, both by reducing the compile-run loop time and allow single step debugging in a nice window, as seen in the shot above.

    This really came into it's own recently when I was writing the initial bootstrap test code for the V9958 - writing to registers and especially to VRAM can be a bit challenging on that chip and it's hard to know if the code actually does what you think it does. Of course MAME supports the V9958, and Micko did the necessary wiring to expose it to the rosco_m68k target, and we were off to the races. Just being able to peek at VRAM and the V9958's registers saved a ton of debug time.

    You can find Micko's MAME work in his fork on GitHub and trust me, it's well worth checking out - it supports RC2014 too if Z80 is more your thing than m68k :)

    We are running MicroPython(!)

    Another of Micko's mic-drop moments was when he announced (pretty much on day one!) that he'd gotten MicroPython running on the rosco_m68k! This is awesome on so many levels - I mean, it's a 68k running Python for one thing, but it also could open the door to a really nice machine monitor, written in python (with some assembly/C glue of course) and driven from the Python REPL. I'm super excited to start playing with it (I've sadly been head-down packing orders for shipping, frantically sourcing components and designing the V9958 expansion, but I'm going to be getting back to some software this weekend).

    To get this running, Micko also had to do a minimal port of Newlib,...

    Read more »

  • V9958 - Getting Started

    Ross Bamford04/27/2020 at 02:02 0 comments

    I had a little time this weekend, so I finally made a start with the V9958s I received a couple of weeks ago. I've not gotten all that far, but I have sanity checked that I can power the chips and hook them up to the bus on the rosco_m68k. As is tradition on this project, I want to develop the thing on breadboard before committing to a design (especially given the 9958 is completely new to me) but there's a hiccup - the V9958 comes in a 1.77mm pitch "Shrink DIP" package, which obviously isn't breadboard friendly.

    I looked around on the nets for an adapter, and while I did find one (that was oddly enough designed for the V9958 and included the crystal and caps) it didn't ship outside the US. I also found a generic SDIP64 to breadboard converter on Amazon, but that one was out of stock. No matter, I fired up KiCAD and ran off a simple adapter in PCBnew:

    I did this about ten days ago, and JLC had it back to me in a few days (I guess because it's such a simple board, in green and quite small, they were able to panel it more quickly than my usual oddball-sized-and-shaped-boards-in-blue) and of course it works great. In the pic above I've attached power and the clock - later I hooked up the bus and was able to get the chip talking to the computer in a rudimentary fashion. Because of the width of the adapter it doesn't fit 'normally' into the breadboard, and has to straddle the power rail of two side-by-side boards, but that's no problem.

    I have a bunch of these little adapters, so if anyone is doing anything breadboard-based and needs to work with a wide SDIP of up-to 64-pin, let me know and I'll list them on Tindie for around $5 including shipping.

  • RAM Expansion arrived, and CPUs on the way

    Ross Bamford04/20/2020 at 22:00 0 comments

    With their usual speed, JLC got the RAM boards manufactured and shipped to me before I'd had chance to gather all the components (I'm still waiting on some right-angle pin-header sockets), so I quickly soldered one up to test it out and happy to say it works perfectly. Here it is hooked up, in the 2MB configuration:

    I'll be offering this on Tindie soon in case anyone else wants to expand their RAM. Do you need a RAM expansion for the rosco_m68k? I mean, this thing supports 4MB (and you can technically have more than one connected, though I haven't finished the bus board design yet) - no-one could ever need that much RAM, right? :D 

    In other news, I'm finally seeing some movement on the 68010's I ordered a few weeks ago. After quite a bit of back and forth, I'm reasonably sure that these are the real-deal (not like the fakes I unfortunately picked up a month or so ago). Pictures have been sent, date-codes have been checked and assurances have been given, so all that's left is to actually receive them and test them. Needless to say, if they aren't genuine I'll unfortunately have to keep holding out for CPU stock for Tindie orders. That said, I have a good feeling this time around (and I have some backups on order too, just in case ;) ).

View all 46 project logs

Enjoy this project?



Søren Møller Dath wrote 04/28/2020 at 14:12 point

Nice project you are doing. Reminds me about another m68k here designed as a backplane computer within a nice Hammond enclosure. I'm looking forward to learn more about the graphics controller. Have you thought about expansions boards with ethernet and CF for storage? That would be awesome. 

  Are you sure? yes | no

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