An exciting day here – after several months of delays (firstly due to me procrastinating followed by production delays due to Coronavirus) the PCBs for my retro m68k computer have arrived!
I eventually decided to have these made by JLCPCB in China, and I have to say I’m very impressed with the quality and finish. On unpacking I immediately noticed a couple of things I didn’t spot before sending the gerbers off, but those are my mistakes – the fab is actually pretty much perfect. Drill is spot on and the silkscreen is lined up perfectly.
Obviously how satisfied I am may change once I get the components soldered on, but I’m pretty confident that the board will be absolutely fine. I’ll update here once I’ve done that.
Time for another update on the rosco_m68k, my homebrew retro computer project. As always, regular updates can be found on hackaday, so please do check there for the details (and like/follow if you want to!) – this will be more of a digest of what’s been going on over the past couple months.
So I guess the headline thing that’s been happening recently is that I’ve started working toward having a PCB manufactured for this thing. I realised I needed to press on with this after I took the breadboard in to work for a geek-out session with some of my awesome colleagues, and had a totally nerve-wracking commute with the breadboard (it survived, save for one current-limiting resistor which developed a loose connection).
So I started work on reducing the component count (more on that later) and actually designing a PCB. It’s now pretty-much ready to go off to OSHPark for manufacture (Yes, I could get it cheaper but I like purple and, y’know, yield) and looks like this:
So that’s the hot-of-the-press headline (I finished it today), and I’ll update more once the boards are made. In the meantime, if you want more details, follow the project on Hackaday for (usually) weekly updates.
Lowering the component count?
In the original design of this computer, I went for a full 7400-series TTL design for all of the glue logic, and that was cool. I learnt a lot about designing with discreet logic gates, was forced to really think about the way I wanted my circuit to work, came to understand propagation delay in a way I didn’t before, and bought a lot more breadboard. That last point is important – fifteen 7400-series chips, while cool, take up a lot of physical space. And PCB fabs charge by the square inch.
It had been pointed out to me before (thanks, Ken!) that I could do with a couple of programmable logic devices what I was previously doing with ~fifteen discreet logic ICs, so I decided (in the interests of staying sane and solvent) to investigate. After a good bit of reading and learning, I’ve now replaced most of the 7400-series on the board with two ATF16V8QL (link to PDF) CPLDs.
This is a win in more than one respect – not only has it saved me board space but it’s made routing the PCB much easier, cut down the current draw of the board, fixed up some propagation delay issues and allowed me to (finally) fix the bug with the expansion select line. These chips were available at the time the CPU I’m using was released, are still in production today, and cost me around £1 each (delivered, based on 5-off, from Farnell in the UK). They’ve taken over all address decoding and IO glue logic, and I highly recommend them.
What About Software?
Things haven’t stood still on the software front – since my last blog I’ve fully integrated the MC68901, gotten timers and interrupts working, and made the UART work such that the computer can now talk over serial (via a CP2102 Serial-to-USB converter I had lying around). Work on an OS for this thing continues apace, and it already has some basic memory management, a fully async serial driver, and has been demonstrated with some (very) basic multitasking. My immediate plan is to implement a way to load software via serial (Zmodem) in the immediate term to make it so that, as I continue to develop the kernel, I don’t have to physically pull the ROMs to reprogram them.
It’s Going Well, Then?
I like to think it is, yeah. I’m having tons of fun, and this thing is starting to look like a product. Once the PCBs are made and I’ve done some more on the software, I think this thing will be at a point where other people might want one. Obviously it’s a 16/32-bit computer in a 64-bit era, but I kinda feel like it might make a great starting point for people wanting to really get to grips with bare-metal, without all the lies abstractions that modern architectures force on them.
The PCB design gets me to a point where the core computer is done, and the expansion connector I put in means I can continue to develop new bits without worrying about disturbing the ever-so-fragile connections on the existing breadboard. This will mean graphics, networking, and who knows what else.
And even if it never goes anywhere beyond the three prototypes I’m going to be building soon, I’ve learnt a hell of a lot from this project, and continue to do so every time I work on it – and that’s really all that matters, right?
I’m still having a ton of fun with the rosco_m68k single board computer, and regularly writing project logs on Hackaday. If you’re interested, be sure to follow the project there as that’s where the regular updates happen, but here’s an in-brief update on what’s been happening.
Firstly, the board now has a lot more wires:
The ROM and RAM are both now hooked up to the buses, along with a MC68901 Multi-Function Peripheral that handles IO.
The system is successfully running code from the ROMs, and the RAM is working fine. I have code that does a full write/read test of the on-board RAM, and other code that just uses it and both are fine.
There’s some new glue logic to support the MC68901 (the top board in the picture) which has upped the chip-count a bit, and I’ve completely redone power distribution which was starting to get a bit shaky due to the way the project has grown.
Everything is connected together via the buses in the center of the picture, and the control bus has grown to accomodate all the CPU control lines and the address decoder outputs.
I’ve had a bit of a nightmare this weekend trying to get the MFP working properly (See this and this on Hackaday if you fancy a laugh) but it’s finally working, and I’m almost at the point of sending “Hello, World” to a serial terminal. After that, I’ll be off to the races with this project – debugging is so much easier when you can actually output stuff rather than just run logic traces.
That’s all for now – as I say if you want to know more be sure to like and follow on Hackaday!
Somewhere around the time I got bored with Advent of Code 2018 (well, the challenges grew to become total time-sinks), I decided my project for the new year was going to be a homebrew retro computer.
I decided that, rather than something 8-bit based on the Z80 or 6502, I wanted to go up a generation and build something 16-bit.
Apart from gaming and a bit of BASIC programming on 8-bit machines like the Spectrum and C64, my first “real” computing was done on the Amiga, a machine which still has a special place in my heart today. For that reason, I decided I wanted to build something based on the Motorola 68000 series processor.
I chose the 68010 which (as far as I’m aware) was never used in the Amiga line, but which is slightly more capable than the 68000 (e.g. interrupt vectors can be moved around and it can support virtual memory when used with a 68451 MMU, though I’m not likely to do the latter in this build). Mine is rated for 10MHz, but I’m only running it at 4MHz at the moment).
The key differences between this and an 8-bit Z80 or 6502 build are:
Dynamic registers, so the clock cannot be stopped or single-stepped (this can be emulated by manipulating /DTACK though).
Asynchronous data bus and DMA support, with /BGR, /BGA, /BERR and /DTACK to take care of.
16-bit data bus, so more wires needed.
24-bit (with some caveats) address bus, so lots more wires needed, but 16MB of address space available!
Internally, the m68k family is 32-bit.
/UDS and /LDS lines for selecting upper and lower data bytes, so a more complicated address decoder and ROM/RAM in pairs.
No separate IO space, further complicating the address decoder.
More complicated requirements around /RESET and /HALT handling, especially at power-on.
I started gathering parts in January, and so far have the crystal clock circuit, the reset/halt circuit, and have gotten the CPU freerunning with /DTACK grounded and the various other bus management lines tied high or low as appropriate.
The address decoder is designed, and I already have the RAM and ROM chips ready to go. I’ve also built an EEPROM programmer because I’m too impatient/cheap to order one and wait for it to arrive.
All this means that, pretty soon, I should be able to get it running some actual code!
Fun times are ahead! If you’re interested, you can follow the project over on Hackaday.