Close
0%
0%

rosco_m68k

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

Public Chat
Similar projects worth following
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 (The classic r2 has also been tested up to 20MHz with a 68020). 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, We're 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 our store: https://store.rosco-m68k.com

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 × SST39SF040 The 1MB FLASH ROM
  • 2 × Alliance AS6C4008 The 1MB RAM
  • 1 × MaxLinear XR68C681 The Dual UART
  • 3 × SN74LS148 The Interrupt Encoder

View all 7 components

  • Xosera Board is available!

    Ross Bamford02/15/2022 at 22:08 3 comments

    As I've mentioned before, the rosco_m68k has a super cool retro-appropriate video adapter capability thanks to Xark's Xosera. While this is using an FPGA, the features it provides are right out of the machines we all know and love from the late 80's / early 90's.

    While Xosera is still very much in-development, I'm pleased to say that the Xosera expansion board for the rosco_m68k is now available on Tindie for just $30 (PCB only). 

    It's worth noting that, due to the fast pace of development, this is really aimed at early adopters right now, who don't mind living on the bleeding edge and are happy to source their own components (including an UPduino) - there is no kit option. Although things might change and you may have to reprogram the FPGA gateware at times, we're committed to continuing to support this adapter layout going forward, so you won't need to replace the hardware.

    Take a look at Xark's project on Hackaday and the Github repository for all the details - for now, I'll just leave this Xosera version of a pretty classic demo here...

    (I will just add that this is using scrolling palettes and the Xosera copper to do it's stuff, and I think it looks awesome! For more details check out the original Discord post where it was announced!)

  • rosco_m68k classic 2.1 production QA looks good!

    Ross Bamford11/08/2021 at 22:01 0 comments

    Following my previous log about the first 2.0 prototype boards, I found a few small issues after receiving them. I'm happy to report these are all now fixed, and I have the new production candidate boards (r2.1) back from the fab. I've populated a couple for QA testing and so far everything is looking pretty good!

    I also have the new Xosera production candidate boards, so keep an eye on the store for some exciting new stuff coming very soon!

    In the meantime, here's a close-up of the latest 2.1 boards up and running :) 

    And a boot with the 2.0 firmware, with output via Xosera (grabbed with an HDMI capture card, the inset shows the UART output)

  • The best case ever!

    Ross Bamford10/11/2021 at 20:16 0 comments

    I've been meaning to write a log about this for a while, but have been pretty terrible at writing updates lately as there's been so much going on with the project over on Discord and Tindie. However, better late than never (and apologies to Henk for the lateness). 

    @henk.gooijen has been working on what is quite probably the best custom-made retro computer case I've ever seen, and he's putting a rosco_m68k at the heart of it. Words cannot adequately express how awesome this case is shaping up to be, so I'll lead with a picture.

    I mean, honestly, just wow. 

    Henk's has the front-panel custom made for the m68k bus, and has designed backing PCBs for all the LEDs and switches. It's super professional!


    Behind that awesome front-panel, Henk's put together a full case, including expansion slots (based on a version of my baseboard, which he's had to hack due to my lack of foresight or regard for standards - suffice to say I'll know better in future and will be designing with the case in mind!).

    And here it is with the rosco_m68k in place (at right of the picture), along with the expansion card that interfaces to the front-panel. (at left).

    Needless to say, I'll be getting one of these made for myself in the very near future!

    I've only really scratched the surface here, if you want to follow along for yourself and see how this awesome project progresses, check it out on Github!

  • rosco_m68k r2.0 out for prototype!

    Ross Bamford10/11/2021 at 20:00 0 comments

    There's been a lot going on over on Discord lately, and the pace is really picking up in rosco_m68k land! 

    One of the big things I've been trying to get done for quite some time is the rosco_m68k r2 (which, to differentiate from the upcoming Pro version, is to be renamed the rosco_m68k Classic). I'm pleased to say that I found some time over the weekend, and the first r2 PCBs are now in production at the fab!

    This is going to be a huge quality-of-life enhancement to the existing r1.23 board, with highlights including:

    • On-board XR68C681 replaces the MFP, providing 115.2Kbps serial
    • 1MB ROM, up from 64KB max on the current board
    • The new ROMs are flashable in-circuit (no more pulling to update!)

    Under the hood there are more improvements, including a move away from 7400-series logic and manufacturability improvements that should increase reliability. As well as providing a faster UART out of the box, removing the MC68901 is a big win for the project as it means one less out-of-production IC to source.

    I'll update more once the new boards are back from China, but in the meantime, here's a (already slightly-outdated) render from Kicad:


  • rosco_m68k Pro - Now it's own thing!

    Ross Bamford07/24/2021 at 21:38 0 comments

    As things are starting to heat up on the rosco_m68k pro, I decided it was time to spin it out into it's own project. Be sure to like and follow if you want to get the updates I'll be posting as things progress! https://hackaday.io/project/180929-roscom68kpro

  • 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: https://github.com/rosco-m68k/hardware-projects/tree/master/r1_020_expansion 

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

View all 55 project logs

Enjoy this project?

Share

Discussions

Gravis wrote 11/09/2021 at 20:19 point

Have you tried to get Linux to run on it?  It should be possible now, even with only 1MiB or RAM: https://tiny.wiki.kernel.org/

  Are you sure? yes | no

Ross Bamford wrote 11/09/2021 at 22:12 point

Hi! :) I haven't tried it myself, but a few people in the community have done some work with uCLinux and this board. Nothing has gotten all that far as far as I know, and the lack of MMU and small RAM would mean it would be pretty limited.

  Are you sure? yes | no

geiss.kh 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:

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