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

Public Chat
Similar projects worth following
Starting from
roscopeco has 171 orders / 19 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 10MHz (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
  • 3 × Various 7400-series Chips The Glue Logic

View all 7 components

  • Xosera - VGA on rosco_m68k!

    Ross Bamford04/27/2021 at 20:13 0 comments

    I've mentioned Xosera briefly before, but in case you missed it, Xosera is a fully open-source FPGA-based video adapter created by my good friend @Xark . In the words of the project's Github:

    Inspired in concept by it's "namesake" the Commander X16's VERA, Xosera is an original open-source video adapter design, built with open-source tools, that is being tailored with features appropriate for a Motorola 68K era retro computer.

    Until now, video on the rosco_m68k has been a slightly hit-and-miss affair, with the main video card being the V9958-based one I designed last year. This is a nice little card, and works well, but suffers a couple of fairly major problems:

    • The V9958 is super-hard to get (at least if you care about getting genuine, working chips)
    • The 15KHz RGB video output (via SCART) isn't great if you're in a part of the world where SCART isn't really a thing
    • The V9958, while nice, is more suited to 8-bit-era machines. For rosco_m68k, I wanted something with a bit more power!

    Xark's been working on Xosera since fairly early on in the rosco_m68k timeline, and things have really heated up a bit lately since we decided that Xosera should be the standard video for the next rosco_m68k machine. Based on that, I (finally) got it together and designed the m68k bus interface board I'd been promising for months, and from there Xark has been doing fantastic work, delivering major new features and improvements almost daily.

    As well as having Xosera be the video on the next rosco_m68k, we also want to support the existing models too, so the first prototype bus board is designed as an expansion that works with all rosco_m68k models. It's in the prototype stages yet, so rather than having the FPGA and supporting hardware on-board, it accepts an Upduino 3.0 that plugs in and provides all the FPGA goodness. Likewise for the video interface - rather than hardwire for (e.g.) VGA a standard PMOD interface is used, allowing Xark free-reign during the prototyping and development stage - for example using HDMI rather than VGA for output.

    The prototype board looks like this:

    In true prototype style there's lot of extra jumpers and test points on there for us to use while debugging things, but the bring-up was pretty much effortless in the end. Aside from a minor issue (my fault) in which I got the POD pinout the wrong way around, it works great. Populated and hooked up (with PMOD on wires to correct for inverted pinout), it looks like this:

    We're not quite at the graphics mode yet, but have a couple of very-capable (and fast, this thing comfortably runs zero-wait-state on a 12MHz 68020, even on fast tight fill loops running out of on-die cache) text modes. Here's a little "tech demo" snake game I threw together while playing with it (in 100% m68k assembly):

    Here it is displaying something like 4096 colours at once (this time driven by Xark's AVR testbed, which he built while waiting for his prototype m68k PCB):

    This is very cool as it uses the advanced auxiliary registers provided by Xosera to monitor beam position and do clever things at just the right time. 

    And finally, here's a short video from the "self-test" sequence Xark wrote for AVR, and which I ported to m68k (keeping it in C++ and building with the rosco_m68k GCC toolchain). This is running at 848x480 at 60Hz (via VGA).

    Between Xosera and @MarkM's awesome work on IDE (that deserves its own log, which will be up soon!) things are moving fast over in rosco_m68k land. Be sure to like and follow the project for more, and for up-to-the-minute news come and join us on Discord

    To stay up to date with Xosera, be sure to like and follow Xark's project, and take a look at his log which has more of the juicy details. You'll find a lot more FPGA detail over there too.

  • A new main picture

    Ross Bamford03/17/2021 at 21:53 0 comments

    I'm just adding this log because it's the only way I can find to add pictures to the project. This is the special M68k 40th anniversary limited-edition board that we gave out as competition prizes last year :) 

  • Looking to the future!

    Ross Bamford03/17/2021 at 21:30 0 comments

    I've posted before about how it's getting harder to find some of the vintage chips used in this project, and things aren't getting any better. I have a pretty good source for MC68010s at the moment (and have stock), but things like the MC68681 and V9958 are so hard to find that I've had to stop offering them as part of the kit on Tindie :(

    With that in mind, there's been a lot of discussion recently over on Discord about future directions for the project, and the awesome community came up with some great ideas for the next major board version! Big thanks to everyone who's been involved in discussing this and suggesting ideas so far!

    The Next Major Board Version

    The new board won't replace the current one (in-fact, I've just sent of a new revision of the version 1 for manufacturing - more on that below!), but will be a kind of souped-up "pro" version - I'm thinking along the lines of A3000 vs A500 :) 

    Briefly, these are the specs we're working to at the moment:

    • Modular CPU, supporting 68020 or 68030 (modular, on a daughterboard)
    • Full 32-bit data and address bus on the mainboard
    • The MC68901 will be replaced in UART duty by a MaxLinear XR68C681 (PLCC, but mounted in a THT socket)
    • Expansion via an evolution of the current bus, with buffering and DIN 41612 connectors
    • 2MB RAM as standard, expandable (probably with SIMMs of some kind)
    • IDE on-board (thanks to MarkM on Discord)
    • I2C on board (with a PCF8584T)
    • Video on board ( with Xark's Xosera FPGA project)
    • Sound - Possibly something on-board, as yet undecided

    Obviously some of these components will be SMD, which is a shame as I've always wanted this project to be easily-solderable by those of all skill-levels, but I think for the "pro" version it's not such a big deal, and I'm planning to offer the kits with those few components pre-soldered. 

    In terms of design, it's very early days yet - I've barely broke ground in Kicad beyond setting up a new project and importing the relevant libraries, but I'll definitely keep updating here as things progress! And as always, all this is up for discussion, either in the comments here or on discord.

    The Next r1 Revision

    There's been a lot of work on the firmware lately, and the latest alpha firmware (v1.3) now has reasonably well-tested SD card support! In support of this I recently respun the r1.2 board with the addition of dedicated pins for an SD 5V adapter (like this one for example). There's also some bug fixes and general tidy up on there, making this the most reliable, most capable rosco_m68k ever. It will be launching on Tindie as soon as I get the boards back from the fab and check I've not made any silly mistakes :D 

    New 68681 board

    Following on from discussions on the next major version, I decided to back port some of the future-proofing ideas back to the r1, starting with replacing the existing MC68681 DUART board with a XR68C681-based one. The prototypes are working perfectly, and I'm waiting on a good quantity coming back from the fab right now. It looks like this:

    This will be supported out-of-the-box with the next firmware release later this week, and the board will launch on Tindie (with the option of getting new ROMs in the package) at the same time. This will allow me to once again offer full kits of the 68681, which I've not been able to do for a while because of a lack of original MC68681s of sufficient quality.

    Lots more going on

    There's lots going on with this project, and this post only just scratches the surface! There's all kinds of community hardware projects in the works, from a "super IO" board that e2k is working on to Henk's flat-out-awesome front panel, and there's a ton of software happening too. I'll definitely try to be better about updating here but if you want to stay in the loop, join us over on Discord!

  • MC68020 - First Steps!

    Ross Bamford11/22/2020 at 20:34 0 comments

    A while ago I bought some MC68020RC12s, and I recently decided it was time to do something with them, so I made a little adapter that allows the 020 to plug into the 64-pin DIL socket used by the MC68010 on the rosco_m68k. Of course this limits the 020 to 24-bit addressing and 16-bit data, but seemed a fun project and a good way to get started with integrating the 020 in preparation for the future.

    The idea is basically to connect up the 020 to the mainboard bus, plus allow it to have it's own clock. There's a little bit of glue logic translation done by an ATF16V8BQL on the board. The layout looks like this:

    The design isn't ready for prime-time yet, but I had a few prototypes made, and it works perfectly on the revision 1 board. There's an issue with DTACK generation on the revision 1.2 (which isn't new, we've known about it for a while but I've put off fixing it as it was "good enough" - until now). 

    When plugged into the main board (with some spacers on the headers going into the CPU socket to give some vertical separation from the RAM/ROM chips) it looks like this:

    Even with the 16-bit bus (and with a relatively-slow 12MHz 020), this is already showing an impressive turn of speed in benchmarks. The 10MHz 010 dhrystone results were:

    rosco_m68k 68010-10Mhz ROM gcc-7.5.0 - 1086 (-O1)

    rosco_m68k   68010-10Mhz     ROM             gcc-7.5.0        -      1086 (-O1)

    While the 020 gives:

    rosco_m68k   68020-12Mhz     ROM             gcc-7.5.0        -      2604 (-O1)
    rosco_m68k   68020-12Mhz     ROM             gcc-10.2.0       -      2860 (-O1)
    rosco_m68k   68020-12Mhz     ROM             gcc-10.2.0       -      2941 (-O1 -mtune=68020)

    (The score is the figure in the right column, for a fair comparison both GCC 7.5.0 (which we were using at the time we last benchmarked the 010) and the current GCC 10.2.0 have been tested.

    As usual, the design files, PLD code and gerbers can be found in the hardware projects repository in GitHub: 

  • 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 :) 

View all 50 project logs

Enjoy this project?


Discussions wrote 04/11/2021 at 07:17 point

Great project ... yesterday i got the board .....thank you for the work .... i will be happy for the next board ... i have 68020 here in pga ... that's realistic , because i can't handle plcc so good  .. hihi ...

  Are you sure? yes | no

Ross Bamford wrote 04/16/2021 at 23:20 point

Awesome :) Thanks for the kind comments, I hope you enjoy the board :)

  Are you sure? yes | no

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