Close
0%
0%

rosco_m68k

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

Public Chat
Similar projects worth following
Starting from
$40.00
roscopeco has 36 orders / 5 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: https://github.com/rosco-m68k/rosco_m68k 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

  • V9958 - Beyond Hello World

    Ross Bamford8 hours ago 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 http://www.jrok.com/hardware/RGB.html  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
    .COPYLOOP:
     move.b...
    Read more »

  • Exciting new things!

    Ross Bamford5 days ago 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 https://discord.gg/zGUB7R8 .

    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 ;) ).

  • A busy weekend!

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

    So, I'm having a busy weekend here, having just launched the rosco_m68k on Tindie I've spent some time putting together my first few orders (thanks all who've ordered so far!) but luckily I've still found plenty of time for hardware hacking. 

    I've been busy working on the first expansion board for the computer, which is going to be a RAM expansion. I'm thinking of making it configurable for either one or two MB of expansion RAM, and where it maps into RAM will be configured by jumpers. The prototype is mostly working great:

    In this picture it's still using a couple of 7400-series ICs for address decoding, but I'm replacing them with an ATF16V8BQL which will make it easier to support the jumper configuration and such and will save space when this thing becomes a PCB. I'm probably also going to make a simple bus-board to break the expansion bus out to multiple connectors. I feel like doing that now, and making the first expansion compatible with it will save frustration later.

    Speaking of the 16V8 I've finally bitten the bullet and converted the WinCUPL code for the address decoder and IO glue to GALasm (not the original link, but the one I used). I've been meaning to do this for a while, because WinCUPL just deeply and severely sucks, and it only runs on Windows (as you might have guessed from the name) but because I've not really done anything with the CUPL since I first wrote it, I've just kept putting it off - it's good that I've finally had need to make some changes and do some new GAL code as it's spurred me on to finally do the conversion.

    I've not added GALasm to the Home-brew tap I created to house to m68k GCC toolchain, because I figure that most people will want to recompile the GAL code (I include the Jedec files in Git anyway) so it would just add bloat...

    While I was busy working on the RAM expansion, these turned up:

    So it looks like I'm going to be ever busier than I expected I would be this weekend. I can't wait to get started with these but I don't have the breadboard adapters back from JLC yet (these are shrink DIP packages), and in any event I want to finish off the RAM expansion so these will have to wait a day or two :)  

  • Arduino IO Device

    Ross Bamford04/07/2020 at 19:59 0 comments

    I'll keep this one brief as I've already written a long post about it elsewhere (all the gory details can be found there), but I spent far too much of the weekend making an Arduino talk to the rosco_m68k as an IO expansion (i.e. mapped into IO space and communicating with the CPU over the bus).

    This exposed a(nother) couple of issues with the board - IODTACK really needs to be exposed on the expansion connector, and the glue logic is a bit quick to drop DTACK when an address in IO space is no longer being strobed, but generally speaking once I'd figured those things out it went pretty well and I was able to get the Arduino to act as a simple single-register, write-only device connected to the m68k.

    The timing issue probably won't affect real hardware devices, and the IODTACK issue can be easily worked around so no need to re-do any boards at the moment, though I've raised issues on GitHub to address them at some point in the future.

  • Fake MC68010s!

    Ross Bamford04/07/2020 at 17:42 0 comments

    So I'm currently gathering parts to hopefully start offering kits on Tindie, and while most of the bits can be ordered directly from Farnell, some are more tricky to get hold of - especially the MC68010 and MC68901, since they're no longer in production. So I resorted to eBay, and received the first shipment of six MC68010s today. On opening the package, I was.... suspicious.

    These are the six ICs I received. On the right is a genuine MC68010P10. On the left are five that are either fake, or just rebadged, 68000s. The things that immediately made me suspicious:

    • The Motorola logo is incomplete
    • The font isn't right
    • The date code suggests these were made in week 1, 2019 (or possibly 1919!)

    You can't see it in this picture, but the surface of the ICs is also rough, suggesting the original markings have been removed.

    Sure enough, I threw them into a board and ran a quick software test which verified that these are, in fact, 68000s. They seem to work fine as 68000s, but trying to do anything 68010-specific (setting the VBR in my tests) results in an immediate illegal instruction exception.

    Fake ICs are sadly a fact of life, and luckily I'm working with my own design which explicitly specifies the 68010. I know that people buy these as an "upgrade" for Amigas and such, and I worry that people who do that will likely never know they're running a fake, as the software for those computers won't usually use any 68010-specific features.

    This bit of code will check whether you have a 68010 or not:

        movea.l #$20000,A0                ; Use $20000 as vector base...
        movec.l A0,VBR                    ; ... and load into VBR

     If run on a 68000, this will cause an illegal instruction exception.

    Because I felt like verifying that setting VBR actually worked too (unlikely it wouldn't I guess but y'know, completeness), I decided to expand this a bit to check these chips on the rosco_m68k:

    MFPBASE     equ     $F80000
    
      ifd REVISION_0
    MFP_GPDR    equ     MFPBASE+$01
    MFP_IERA    equ     MFPBASE+$31
    MFP_IERB    equ     MFPBASE+$09
    MFP_ISRB    equ     MFPBASE+$05
      else
    MFP_GPDR    equ     MFPBASE+$01
    MFP_IERA    equ     MFPBASE+$07
    MFP_IERB    equ     MFPBASE+$09
    MFP_ISRB    equ     MFPBASE+$11
      endif
    
        section .text
    
    ; Entry point here!
    kmain::
        move.w  #$2700,SR                 ; Disable interrupts
        movea.l #$20000,A0                ; Use $20000 as vector base...
        movec.l A0,VBR                    ; ... and load into VBR
        move.l  #TICK_HANDLER,$20114      ; Set up tick handler
        move.w  #$2000,SR                 ; Re-enable interrupts
    
    .LOOP
        bra.s   .LOOP
    
    
    GENERIC_HANDLER:
        rte
    
    TICK_HANDLER:
        move.l  D0,-(A7)                  ; Save D0
        move.w  $408,D0                   ; Read SDB byte 8
        tst.w   D0                        ; Is it zero?
        bne.s   .TICK_HANDLER_DONE        ; Done if not
    
        ; counted to zero, so toggle indicator 0 and reset counter
        bchg.b  #0,MFP_GPDR
        move.w  #25,D0
    
    .TICK_HANDLER_DONE:
        sub.w   #$1,D0                    ; Decrement counter...
        move.w  D0,$408                   ; ... and write back to SDB
        move.l  (A7)+,D0                  ; Restore D0
        move.b  #~$20,MFP_ISRB            ; Clear interrupt-in-service
        rte                               ; We're done
    

    (full code here)

     Right... Back to trying to get hold of some CPUs for these kits I've been talking about.....

  • Kits coming soon!

    Ross Bamford03/29/2020 at 19:01 0 comments

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

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

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

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

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

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

View all 42 project logs

Enjoy this project?

Share

Discussions

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:

https://forum.kicad.info/

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 https://hackaday.io/project/164087-8085-sbc/log/160589-programmng-the-gal

For Linux there is https://github.com/daveho/GALasm 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 (https://gitlab.com/DavidGriffith/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