It’s no secret Hackaday loves retrocomputers, classic hardware, and vintage tech. Now that we have a great way to present long-form projects, it only makes sense that we combine our loves with a new build. Over the next few months, I’ll be developing a homebrew computer based on the Motorola 68000 CPU, documenting everything along the way, and building a very capable piece of hardware that will end up hosting a few Hackaday webpages. I already have a solid start on the project and will be posting on our front page to discuss the major parts already in progress, and those yet to come.
There are a few reasons we’re taking on this project. With few exceptions, most of the homebrew projects we see are based around 8-bit micros – specifically the 6502 and Z80. 16 and 32-bit CPUs really aren’t that much more difficult to work with, and if we can spearhead a renaissance of the 68k, 65816, or even a 386 (!), we’re all for that. Also, it’s been suggested that we host the Hackaday Retro site on retro hardware, and what better way to do that by documenting a build on our new project hosting site?
That’s a very brief introduction to this project. Let’s take a closer look at what hardware we’ll be using, what software we’ll get running, and what you can do to help.
While this post is only intended to serve as a very broad overview of what this project will become, there are a few details that are pretty much set in stone:
First off, the hardware
You’re probably wondering what kind of hardware this new project will sport, and how I’m planning on quickly turning ideas and schematics into functional circuits. For that, it’s bullet point time:
-
A backplane, wirewrap design
![Backplane for Hackaday 68k](http://hackaday.com/wp-content/uploads/2014/02/backplane-design.png?w=300)
This computer will be constructed on separate boards for the CPU, RAM, ROM, and any other peripherals we come up with. All the connections will be wire-wrapped. There are a few reasons for this. First, if you have the wirewrap sockets, wire, and tools, it’s a much better and easier way of prototyping a circuit than a bread board. Second, it’s just so classic; the 68000 was released in 1979, and at the time this was the way to create a one-off computer. Yes, we’ll eventually make some PCBs, but you just can’t top a wirewrap design for ease of prototyping.
-
A Motorola 68000 CPU
Why the 68k? We see a lot of retro and homebrew computers come in on the tip line, but with few exceptions they’re 8-bit CPUs like the 6502, 6809, and Z80. The 68k was the first popular CPU of the 16-bit era that eventually made its way into Amigas, the original Mac, Sega Genesis/Megadrive, a ton of arcade games, and early UNIX workstations. It’s an amazing, elegant chip that’s able to be used as the brains of a real-world computer that does something useful.
-
Four Megabytes of RAM
![Ram Bank Design](http://hackaday.com/wp-content/uploads/2014/02/ram-bank.png?w=300)
Yeah, you read that correctly. Crazy, isn’t it? With a 24-bit address space, the 68k can address up to 16 Megabytes of RAM without bank switching. Compare this to the 64kilobytes of address space of the 6502 and Z80, and it’s easy to see how much more capable the 68k is. Also, with modern SRAMs, it’s a piece of cake to get zero wait states.
-
A Yamaha V9938 Video Display Processor
Of course this computer will need some sort of video output and for that we’ve gone with the same video chip found in the MSX2 home computer. I expect this to be mostly used in the 80×24 text mode, but this chip also gives us the ability to some very respectable 16-bit graphics.
-
Ethernet
-
Compact Flash/IDE hard drive
-
PS/2 Keyboard
-
Maybe a 6581 SID chip?
The ultimate goal of this project is to build a really cool retrocomputer that’s able to host Hackaday’s retro site. It only makes sense to put Ethernet and some form of storage. We’ll need a keyboard, obviously, and no modern retrocomputer would be complete without the sound chip from the Commodore 64.
How About Some Software?
The TL;DR of the software is: “Something UNIX-ish, with a C compiler.”
Putting a 68k C compiler on this computer isn’t hard, but UNIX is. The first UNIX workstations used two 68000 CPUs – one for normal processing, and another to reset the first if a page fault occurred. Putting a *NIX on something without virtual memory or an MMU is of course possible, but that’s a lot of engineering I’d rather not get into. A much better solution would be uCLinux. It’s designed for embedded systems and has ports for just about everything, including the 68000. This, a C compiler, and a text editor are all anyone really needs for a fully functional computer.
Where we’re going from here
This is just the first post in what will eventually become a very, very long build log. It’s also a great test for our new Hackaday Projects site where most of the development will happen. You can check out the current build log right here and of course use the really cool sidebar comment feature to point out better solutions, circuits, and code.
What you can do
If you’d like to help out between now and the next post, have a look at the build logs on Hackaday Projects, leave a comment, shoot me an email if something’s really annoying you. If you’re feeling really ambitious, build a clone! I’m putting all the schematics up on Github. One last thing. I’d like to give a shout out to Apex Electronics for supplying a ton of wire wrap sockets.
Also, I’d really like to do a few videos of me troubleshooting the inevitable problems I’ll have with an in-circuit emulator. If anyone knows where to get a Fluke 9010a, 9000-68000 pod, or has a better idea for an ICE, drop a note in the comments.
Saddle up for the next few posts: going over the mechanical design of the Hackaday 68k, and blinking an LED with a 24-bit address bus.
AmigaOS. Just because.
AmigaOS is way too tied into Amiga hardware specifics, otherwise, it would be the obvious choice. If only there were a 68K version of AROS. uCLinux will work, but at least back when I looked at it (1998), it required register-relative addressing, so you have memory location independent code, but on the 68K that means limiting to 32K, since relative jumps are only 16-bit offset. If they have a relocating loader like AmigaOS, that problem is eliminated. And since every 68K system is different, they’re bound to have lots of flexibility in the board support modules.
There actually *is* an m68k build of AROS:
http://www.natami-news.de/html/distribution_download.html
And even a replacement kickstart rom that has decent compatibility.
Yes but chip set? Toomuch going on in Alice, Paula and agnus for cmpatability on a CPU only clone.
Now, an FPGA add on option card would be good. And we all know the lady that can make that happen in a flash. Haha get it? FLASH. I made geek joke.
AROS 68k doesn’t require the Amiga Chipset, but will run all non hardware hitting applications (which should be most of them as games were the ones that mostly did that). Certainly all the software that would be needed to run a website would run, as they were all OS legal :)
I can’t see the point of using a chip from a ratty old 8-bit box, the 68k powered stuff (Amiga, Atari, Nintendo) had way better graphics than the older generation.
I’d challenge the community to clone the Amiga graphics chipset into an FPGA, it was pretty damn capable and excellent for 2D games.
That said, the new FTDI graphics driver chips seem to do a lot of the hard work for you.
Oh, the HaD68k project doesn’t have chip support of course.
I was just clarifying that AROS does exist for the m68k Amigas.
Amiga in FPGA has already been done. Check out minimig project.
Has anyone have a copy of GCOS 6 from Honeywell? GCOS was designed for the 68000, my old memory is correct.
This is great!
I love that old chip, cos it was in my Atari ST in the 80s-90s. Even cut my teeth with Assembly language on it!
However something of a personal preference, but might be cool, is to give it some more capable graphics and sound, as inevitably I had a bit of Amiga envy back in the day! Giving it a VGA or DVI/HDMI output would bring it into the modern age a bit making it more ‘relevant’. A simple Web Server doesnt seem worthy for some reason.
Memory is obviously very limiting so perhaps just a 256 colour palette on 320×240 makes for a reasonable 76KB with palette, memory mapped. Plus as per back in the day, other (inevitably slower) Hi res modes such as 640×480 or, shock horror, 800×600!!
I’d buy a kit if you did this and turned it into a product.
Jeez I just realised I typed this on a thin mobile computer with a true colour 2048×1536 display!!! Oh how times have changed!
There’s no way this project is going to have better graphics than an Amiga. Simply because we’d be comparing it to an Amiga. Amigas rock.
Putting HDMI in this thing would be really, really cool, and there’s probably some chips out there that will do this for me automagically, but I’m *really* trying to have the only programmable components in this project be the ROMs – no GALs, CPLDs, or any of that crap.
> I’d buy a kit if you did this and turned it into a product.
You’d think so, but this is specifically designed as a one-off project. These Eurocard connectors are *expensive*. I think I might have north of $700 in components in this box before it’s done.Much, much more if I actually had to pay for the wire wrap sockets.
There’s still a possibility I could turn this into a Mini-ITX (or smaller, standardized) sized board. That would bring down the price significantly. Still, by the time I get to that point, I may have a better project in mind.
Thats cool, i’ll still be really interested in the outcome.
But why do u need to use Eurocard? So this isnt going to be single board like the old 16bit computers? Im no electronics engineering grad, only hobby level so please excuse my ignorance!
Because Eurocard is cool. That’s pretty much the reason for Eurocard.
No, this won’t be a SBC; everything is going to be on seperate cards – the CPU on one card, the RAM on another (I’m actually running out of room on the RAM card, btw), Video chip on another card…
It’s just an easy way to modularize everything. The next few posts will just be me fooling around with the CPU card, making it blink a LED. Then we’ll add a ROM, then RAM, then a serial card. By then I’ll be shooting characters out over a serial port. Then the real fun starts.
There is always the option of finding surplus VME backplane. You don’t need to use all of the pins.
Eurocard isnt cool, its expensive
ISA on the other hand is not only cool, but retro and would let you add standard ISA cards – IDE controller, sound card, or even VGA card
S3329-ND ISA 31+18 pin edge connector 8 bucks on digikey, or free with a hot gun and few old pc motherboards.
If you use those passive ISA AT backplane (e.g. 90 degrees riser card for old Compaq), it is bussed already. Or go old school – hack saw out your own backplane from the old PC motherboard. BTW that *was* the origin of the word ‘hack’. :)
If you look around, you can find hole per pad ISA AT protocards with the gold plated fingers. Some even have a small decoder circuit that you can populate.
I have a few multifunction card – one vintage with DRAM expansion and other couple with Super I/O onboard – serial, parallel port, IDE and floppy. Using those would save a lot of work. Let’s not forget the Diagnoistic card with 7 segment LED. Useful and looks cool for debugging.
WRT to connectors- you might take a look at PCIe x16 connectors on some old motherboards. They should have plenty of pins even for fully 32-bit implementation, they are ubiquous, relatively cheap and their opposite connector is PCB itself.
Are you going to design it to follow the VMEbus standard? It seems silly to wire it in a eurocard form factor but use a different bus layout, and this way you would get access to all of the various 68k peripherals out there (nice big boards of ram, disk drive interfaces, etc)
VME is really complex, and doesn’t have any advantages for this.
I’m using 64-pin Eurocard sockets. So no VMEBus. or NuBus. Or anything cool, unfortunately. 64 pins is more than enough to do what I want to do, anyway.
I’m only using the 64-pin sockets because of the difficulty – if not impossibility – of designing a two-layer 96-pin backplane.
Building a VGA-timing-compatible video card in discrete logic would be a little awkward, but totally doable. The hardest part is designing things to run at 25MHz or higher, but restricting a first version to 1bpp means the only IC that runs at the full clock rate is the shift register itself. After that, connecting that to a TMDS transmitter looks fairly straightforward.
I have seen project reusing old ISA cards. Using ISA Ethernet 3Com or NE2000 is easy
http://www.dclausen.net/projects/avr_ethernet/
http://www.ethernut.de/en/isa/
http://www.ulrichradig.de/home/index.php/avr/webserver
and here is VGA
http://tinyvga.com/avr-isa-vga
http://www.wrljet.com/isabus/
more on isa in old computers
http://www.baltissen.org/newhtm/hardware.htm
To run AmigaOS, he’d have to put in a ROM like replacement for the AmigaOS Roms, which are copyrighted and He’d probably have to pay the current owners for permission.
Pretty cool. I’ve designed more 68K systems than most people… it’s really a pretty great chip to work with, and the bus is maybe the last one slow enough to work ok in wire-wrap format. Haven’t actually used WW since the mid 1980s… on the Commodore 128 project. We had gone to PCB prototyping by the time the Amigas rolled around. I’ll check out the schematics if I get a chance.
Whoa! We are graced by your presence.
In 1985, right after graduation from college, I decided to build my own computer, built around the Z80. But once I realized how cheap 68Ks had become, I built my own, kind of like this project — wirewrapped using a S-100 backplane (but not following the S-100 standard), just TTL parts, with 128KB of DRAM, serial port (no video), and a timer chip. Programs were saved/loaded over the serial port in hex format. Once I got it working I put it away and eventually tossed it. I did keep the monitor/disassembler/assembler I used for it though:
http://thebattles.net/crypt/index.html#68k
It is nothing impressive or sophisticated, but it did lead to my next job building OCR machines with 68Ks and ‘020s.
Checked out your site Jim. Pretty cool!
Question for David Haynie if I may:
As information is somewhat hard to come by and it looks as if the prototypes were destroyed and because I’m curious and it’s always been a big “what if?” topic, how complete was the Amiga AAA chipset you were working on before Commodore went south?
I just have to say… WE’RE NOT WORTHY! WE’RE NOT WORTHY!
The Programmers’ Cheer —
Shift to the left, shift to the right!
Pop up, push down, byte, byte, byte!
;^)
Second verse…
Shift to the left,
Shift to the right,
Mask in, mask out, BYTE, BYTE, BYTE !!!
Ummm… video please? :-P
68000 running Linux kernel 3.7 and playing mp3!
https://www.youtube.com/watch?v=gu0Y4vliJcQ
http://www.youtube.com/watch?v=mncS0ZLWKSY
and hosting a webpage, so impressed.
Nice project.
Have a look at nuttx. Gregory Nutt just resurrected an old 68k support package for it.
Also for the fun, have a look at the CT63 addon card for the Atari Falcon by Rodolphe.http://www.powerphenix.com/CT60/french/present63.htm
You could do worse than using the S-100 (IEEE-696) bus for your backplane. There were 68K CPU cards produced for this bus in the 80s. This would allow you to leverage old cards that are still available i.e. video, serial/parallel,disk drive, etc. Don’t forget to use active termination ala the Morrow WonderBus backplane. When I replaced my Imsai backplane with the wonderbus, it bacame more stable.
Good luck with your project.
I would actually recommend the old ISA bus. There was the Goldengate card for the Amiga that bridges the 68000 style bus to the ISA.
You can find all kinds of old cards from Ethernet to video for that. Somewhere there are linux drivers, so there is some code that can be lifted. Pick some of the Ethernet that have onboard memory buffer though as it would save a lot of work not having to implement DMA.
I would at least put small CPLD like those XC9500 series on them to simplify work on glue logic.
Second. It rather, something just like golden gate, to bridge from the system block to io cards. What about ISA? More modern. More cards. Would graft better sound and easy network and storage.
where do you get the 68k?
I picked up two from eBay. Some seller in Utah, iirc.
They’re plastic-encased parts, and not the cool purple and gold vintage ceramic parts, but they’ll do. Both rated to 10MHz, but I’m doing all the timings for running this thing at 8MHz.
Thank you! Wouldn’t it be possible to install the same OS which was on the Mac 128k ? And would it change anything except for the Power consumption if you use the CMOS-Version of the 68k?
That’s a negative on the Mac OS.
There are a few technical limitations to the HaD68k; I’m not doing DMA, so I’d have to kludge something together for the video. I really doubt this is possible.
There’s also the weird chips I’d need to source again. Getting a 68k is easy enough on eBay, But I’d need to find the SCSI controller, and source the Integrated Woz Machine. That means ripping one out of an existing 128k (or 512k, or whatever). I’m just not going to do that.
Legally, I doubt Apple would appreciate me giving the ROMs out.
As far as the CMOS and HMOS versions, I don’t think there are any differences except for power consumption. I know there are quite a few differences between the HMOS and CMOS versions of the 6502, so if anyone knows any cavaets between the H- and CMOS versions of the 68k, now’s your time to shine.
Oh. I’m using the CMOS version.
So this would be the 68HC000?
yep.
I just read, that the 68HC000 is still being produced by Freescale.
Actually to run Mac OS you would not need the IWM unless you want floppy drive, you only need the SCSI controller (NCR 5380) and off the SCSI you could run floppy and hard disk, and, correct me if i am wrong, you can get the ROM off the internet and then split it in half (if thats how HI and LO ROM works) to get your HI and LO ROMs, then just put the half on to two 64k ROMs and viola ( according to my massive technical knowledge(sarcasm) ) it should work.
You’re only problem then would be video.
IIRC 68k Macs had custom ROMs which you would also have to replicate.
This might be a Project….!
If you’re interested in trying to get a MMU for your 68k there is the slightly obscure 68451 which is compatable with the base 68000’s. I’ve been meaning to build a 68k computer myself (I’ve got the reference manuals, a 68000, a 68451 that I picked up off of ebay, an old motorola serial chip, and some assorted stuff) but haven’t spent the time to sit down and learn the 68000 enough to start designing the circuit.
(disclaimer – I ported Unix to all these machines back in the day)
The ‘451 is slow (many wait states), and very hard to program – the other alternative is a ‘sun’-style MMU (basically some sram and some glue).
The 68000/68010 date from a time when most unixes were swapping rather than paging – you can pull off a paging kernel (system 5 or BSD) on a ‘451 but it will be even slower. You can pull off a swapping kernel on a 68000 (without the 68010 bus error fixes) if you hack the compiler to probe the stack in a well known way (on a swapping system that’s the only bus fault that needs to be restarted)
Can you provide more details? I really want to build a 68k machine and port UNIX over to it; Don’t care about speed. What is the glue involved in a Sun-style MMU? What’re the bus error fixes?
This is a terribly documented problem here, none of the homebrew community seems to have implemented an MMU-enabled 68010 machine
Would it be too hard to use one of the later 68K chips with an MMU, maybe a 68030? Would make Unix easier. OTOH not using an MMU gives direct access to the bus, so makes I/O and realtime easier.
I don’t think you want to wire wrap a 68030
Chicken!
So where do you get the actual 68000 chip ? Ebay ?
Yep. See comment above.
Does the V9938 have gen-lock?
I would disagree with the statement in the project site that the 68000 is extremely powerful. Compared to today’s standards, it’s a very slow beast, with very long instruction cycle counts.
AVR chip doing 8-bit stuff is faster than the 68000, but has the usual 8-bit CPU memory limitations.
MHz are not everything. Also, there’s always *some* processor that’s faster/better, but that’s not really the point is it?
The point is that the 68k is nowhere near “extremely powerful”. Even when it came out, it was only moderately powerful. Sure, it was better than its 8 bit contemporaries, but that’s about it. Compared to a modern CPU, like you would find on a Raspberry PI, it’s pitifully slow.
BTW, did you know that 68000 was marketed as “VAX on a chip” and that it was also design philosophy behind it ? “Moderately powerful” as you say ?
What was on the market that was substantially better than 68000 at the time ?
Failing that, what was even close ?
Of course, it’s impossible to compare it exactly with other CPUs on the market, because other CPUs either appeared a few years earlier or later, and a few years made a lot of difference. However, if you draw a graph with CPU performances over the years, the 68k does not stick out extremely far. Maybe it’s just a little bit at the high end of the range, but nothing spectacular.
How would you feel if hackaday had announced a retro project based on the “extremely powerful” 80486 ? It would probably make you frown at the silly notion of calling the 80486 extremely powerful. But calling the 68k (running 50 times slower) extremely powerful, and you get approving nods from the fans.
But 68000 was compared iwith everything else within real world, not graphs.
Look at Atari ST, for example. It’s an example of clean design with 68000. Then look at its performance and compare it with PC’s of the day. It’s like day and night.
WRT to 486, I don’t have problems with it because it’s slow today, but because it was architecural crap from the day one. Look at the FPU, for example. 68000 was example of how it should be done even long time after it came out…
BTW, take a look at 68000 ISA from modern perspective.
Could you use such core today effectively instead of e.g ARM ?
Sure. ColdFire is example of that.
Now look at _anything_ from x86 non-64 bit. What part of it is still relevant today ?
And before you even utter intel’s Atom or Galileo program, look at jhow much manufacturing muscle they had to put behind it, all for mild or moderate success at best.
You are making apples-to-chandelier comparison.
Look at what was avaliable at the time of 68000. And what was achieved witho only 70000 or so transistors.
68k has decent punch for its weight even today, otherwise there would be no ColdFire.
And its easy to see that top players in x86 world ( Intel/AMD) would have much easier job if they could simplify instruction decoders for 68k instead for x86.
x86 instruction decoding is a non-issue. It’s been solved. Besides, it’s not obvious that 68k instructions are ‘better’ in any meaningful sense of the word. The huge success of x86 architecture is no coincidence.
Not really. Had it been “solved” AMD wouldnt been working on ARM-based Opteron.
instruction deceoder issue has never been really solved.
And any comparation of 68K and x86 of the day is silly. 68K ran circles around it, at least up to and including 486. 68000 was a bullseye. Problem is that after that Motorola got gready and lazy. “Modern” 68xxx became unreasonably expensive.
68000 was about as fast as a 80286, depending on the clock frequency. The ‘386 was faster than a 68030, and the ‘486 faster than the 68040. No circle running at all.
The advantage of ARM has nothing to do with better instruction set, or easier decoding, and AMD is not making ARM based chips because they have problems with the instruction decoding. ARM’s primary advantage is that they’ll sell the IP for integration in 3rd party SoC (and that their IP is small and simple enough that it’s easy to apply).
Instruction decoding is a trivial problem, compared to all the problems you have to solve with speculative super scalar execution, instruction reordering, branch prediction, cache coherency, and fast memory access to name just a few things. All the things that are done in a modern CPU, like converting the x86 instructions to internal RISC micro ops would also have to be done if you used 68k instruction set as a base.
Not true.
Put an Atari ST along any 286 PC of the day and it’l run circles around it in many applications. Put FPU on each and difference will explode further.
x86 was “faster” on some later models on some selected benchmarks.
In real life, 68000 simply obliterated it.
WRT instruction decoding, it is BIG part of the story. Instruction decoding problem was main reason behind Intel’s wandering into P4 etc.
Greetings from the future! Where are the ARM based Opterons you promised?
Huge sucess of x86 family is coincidental with IBM’s decision to go with 8086 for their PC’s. And that decision had nothing to do with 68000 performance.
They simply had 8086 on stock, so they used that. For a machine they didn’t really take that seriously.
And BTW, AVR is:
– simple RISC
– pipelined
– it has hardware acceleration for some ops ( shifts, multiply etc)
68000 has none of that. It does its best to fetch next instruction while executing current one, but it can’t do better than 4T since that is lowest cycle time.
Also, not that 68000 can do quite a few things during one instruction while AVR offers simple load-store memory access…
Great stuff :-)
Wiring up a computer on breadboard works with CPU like 68000 or Z80 because they are in DIP style. How does one wire up a 386 that uses PGA? Not on a standard breadboard for sure.
A PGA to DIP adapter, perhaps?
I haven’t gone as far as a large PGA, but I use PLCC sockets on stripboard by cutting the track between each individual socket pin, feeding wires through adjacent holes around the socket and soldering them in something approaching “dead bug” style.
Do you have an affordable source on all those wirewrap ic sockets?
No. Wire wrap sockets are just freakin’ expensive unless you somehow have a hookup.
Before I went to Apex Electronics, I had no idea 64-pin ww sockets even existed. I was planning on doing the 68k socket with machine pin headers. In fact, right now, all the RAM chips (eight 32-pin PDIPs) are snug in their custom machine pin header sockets.
There’s a reason nobody uses wire wrap any more. It’s just outrageously expensive.
It was always outrageously expensive, but chips were a lot more expensive back then, so the cost could be tolerated sometimes. Hobbyists could get sockets (and often chips) very cheaply by buying old wrapped panels that had been scrapped… no one in industry would bother unwrapping them.
Brian, you are still member of the Kiwi forum. You’ll find Kiwis CPLD design files in the internal area. Maybe it’s VHDL DRAM module is an option instead of many SRAM chips…?
Holy crap, it’s the guy who inspired this project.
Right now I have all the RAM chips socketed, and with little homemade paper lables on the underside of the board. All I need to do now is grab a beer, wire wrap tool, turn on some Deep Space Nine, and have some fun wrapping them up.
It’s not an optimal solution, I’ll give you that, but it’s easy. If I ever turn this project into something that can become a product, I’ll probably be using DRAM instead.
Cheers!
Always good to know Kiwi inspires people. :) Unless you already have a working design, SRAM is good to start of from. Beer helps to keep up the mood and a steady hand. But not too much or you wrap a short-cut. ;)
Btw, finally I finished the Kiwi rev 2 and ordered five boards last week. These should arrive next week. Three are sold, one is for me and one still waits for a buyer. The bare PCB costs 75€ now. Much cheaper than the 300 bucks I paid for my rev 1. :)
As for the operating system: Some time last year I started porting EmuTOS. The console mode works already. Which you can see here: http://www.youtube.com/watch?v=Y2deWhZ2X8M
Atm I try to port the VDI layer of GEM. Maybe there will be a GUI in the future. :)
Might be better off making PCBs to connect regular sockets to 0.1″ pitch header pins. :p Those 0.025″ square pins that can be used for wire-wrapping.
The price of custom PCB has dropped a lot and that a well designed double sided board can work better than wire wrapping.
Yeah. And if you worry about mistakes, place double pinholes next to IC pins with a cut trace between. Made a miswire? Cut the trace, pick it up with wire in the hole, reroute. Do the same for the other end.
Sure it adds lots of board space, but makes repairs almost as easy as a breadboard, and way easier than wire wrap.
One way to make this happen without a huge chip count is to use a microcontroller as the system chip. I’ve seen a couple Propeller based retro computers that use the propeller for video generation and I/O interface. This cuts down on a lot of discrete chips because you can write software modules to implement many of the features. The computer is still a real computer, but it is more like the late 80’s C&T type PC computers that had VLSI ASICs to do much of the heavy lifting.
I forgot to add, you can leverage much of the SD interfacing that is already done for the Propeller, so you can get SD card FATfs support out of the gate, or just use it for a hardware interface to the SD. The 3.3v thing isn’t much an issue, most 5v logic triggers at 2.7v, so the 3.3v MOSFET drivers will drive a 5v input, for the other direction you just use a 3.9k resistor to drop the voltage through the clamping diodes, no level shifters are required. If you want bidirectional drive, you’d have to use a level shifter or a resistor/transistor driver.
BJT transistor level shifter and a few k series resistors do not scale well into the MHz nor into a shared bus that have lots capacitance. There are 74CBT (and a lot of newer variants) that implements that with much less capacitance effects, so the concept is sound, but the discrete solution does not scale well. The largish Miller capacitance of the *discrete* BJT/MOSFET kills it. For that to scale, they have to be chip technology MOSFET.
Stuff like that is *rarely* unstood by people. They might know the DC analysis, but not the AC side of things.
google for “Two Transistors Form Bidirectional Level Translator” by Jim Hagerman to see the spice simulation. Notice the slow rise time beyond 3V.
I improved on his design a bit by using small capacitors (about 100pF) in parallel to R2 to cancel out some of the Miller effect that he was seeing. That extended the range to a few MHz, but puts a lot of capacitance load in the bus.
tl;dr
I dare someone to get an Intel Atom working. At least with some of them their publicly available datasheets contain pinouts, plus plenty of technical documentation on how to get it up and booting…
And why would anybody want that creeping horror? World is full of pcs already.
I have actually been very seriously considering that… I just haven’t yet been able to convince myself that starting another (very complex and time consuming) project on top of all my others is a good idea. Probably someone will do it before I get around to it, and then I won’t be so excited about it.
I’ve been wanting to, I just have absolutely 0 knowledge about EE to do it.
Yeah, Amiga, my first thought too. But I’ve still got two A2000 in the basement. In any event, the 68010 is the pin
compatible drop in replacement “fixed” 68000. So I’ll think of the 68k project as 68010 based. Of course the 68020
and 68040 are nice too… My favorite thing about the 680×0 is that they are CISC chips and have a regular register
set (8 data and 8 address). Great for assembler.
I was going to suggest going with the 68010. Pin compatible with the 68000, solves your page fault problem, and gcc will generate code without blinking. Back in the day, many of us upgraded out Tandy 6000 machines with 68010’s running @ 10Mhz (vs stock 8mhz). They were pretty nice little systems running Xenix (System III).
For the OS might I suggest.
OS/9 if you can find it.
A port of NitrOS-9 maybe.
or CP/M-68k and here is the source code http://www.cpm.z80.de/source.html
If I were to start a new 68K based project, I’ll probably go with a 68020 instead of a plain 68000. The 68020 is close enough to the 68000 that it’s easy to interface without running into all the issue you would have with a 68030.
i agree, and alto the 020 has a dynamic bus sizing =)
And what about hackening a Sega Genesis (Mega Drive) into a useable computer? It has already a 68000, video, audio and basic I/O. Some memory mapped peripherals altogether with ROM and SRAM would sit into the cartridge slot. You could use a Genesis emulator as a tool for development of the OS. Just an idea, tough….
You bastard! Few hours of my life gone :) Googling up everything about Genesis/megadrive + reading documentation + researching uclinux on 68k. Game cartridge slot has all the pins necessary (DTACK, clock etc).
It would be a great project.
Now I feel cheated. I had a C64, Genesis with a hardware addon (keyboard port, casette and maybe floppy port) would make a lot better home computer in the early nineties.
Do it ;)
I have an original SNASM breakout box for Genesis if anyone can find the rest of the parts for it (IIRC it needs an ISA card to a PC, and the EPROM cart), and I’ve also got a Mega Drive with the socketed 68000 and exposed BREAK pin.
There’s the VAX 68000 unit too, which was a general purpose 68k ICE, but they’re very rare. I’ve got all the original documentation for it if you do find one, though.
The 68030 was the original home of the second coolest operating system ever made: Alexia Massalin’s Synthesis. Check out her thesis for the a complete mind blowout.
http://valerieaurora.org/synthesis/SynthesisOS/
I think you should adjust the Wayback Machine forward a few years and make a machine to run Synthesis.
Cool idea, but AFAIK the Synthesis source code has never been published? Perhaps Alexia can be convinced to open source it if the code is still around?
Great project! Posted to http://anycpu.org/forum/ (which is a kind of complement to http://forum.6502.org/ )
http://www.amazon.com/Microprocessor-Systems-Design-Hardware-Interfacing/dp/0534925685
has pretty much everything there is to know about a 68k including schematics
Alan Wilcox’ “68000 Microcomputer Systems: Designing and Troubleshooting” is probably a better investment (if you can find it), as it deals specifically with building a 68000-based computer from scratch.
Reading things like these make me wish I’d stolen some 68K, 68HC11, 6800, 6809 dev. boards I used in school.
Oh, I’m sorry, did I say steal? I meant borrow. Yes, of course I meant borrow.
(c;
I’m interested. I’ve made a 68008 board, with 512KB RAM, IDE, a Z8530 and a 6522. No video or ethernet though. I’ve had it running CP/M-68K and compiled stuff for it with GCC. One of my plans for the future is a 68010 with a 68451 MMU.
Any specific reason to choose V9938 over the V9958? It’s more or less completely compatible with the addition of a few more modes with up to 19628 colours and also horizontal hardware scrolling (V9938 only has vertical).
Well I haven’t bought the chip yet, so sure.
Ebay, $50, dual core tablet – all retrocomputers at your fingertips..
What about one that doesn’t yet exist?
And even less for a driving sim so why would anybody have a vintage/kit/race car?
It scares me that Haynie doesn’t know there IS a 68K version of AROS.
And a V9958 VDP would be a big improvement over the V9938.
Design this and i will build one (although I’d use a 68HC000).
Definitely a project to follow.
That’s two reccomendations for the V9958. I’ll do it.
I am using the CMOS part, it’s just easier, simpler, and less confusing to leave out ‘HC’.
Using v9958 you get a hw signal useful for syncronize cpu accesses to vdp. Otherwise it is difficult to efficently handle delays since the depends on a lot of factors: screen mode, write or read pending from cpu, vblank period, sprites enabled,blitter idle or working (you can send data for cpu while blitter is working). Plus i suggest you to use vectorized ints, so the response can be quick. Adding a timer with high res and ints could be useful also
I would suggest using the MC68VZ328 (comes in a TQFP 144) or MC68SZ328 (If you have access to 8 layer boards and can solder BGA) instead of the plain 68000.
Why .. because it they have SDRAM controllers, DMA, UART etc built in… and a bootstrap mode to get the system up and running so you don’t have a chicken and the egg problem getting your flash programmed.
That would be cheating :)
on the other hand buying Palm m515 and expanding ram/adding some universal system bus would be extremely cool
8-bit CPU’s may not be useful, but they are for people trying to get to the core of computing. I still have a hard to putting together the essence of it in my head, if only I could watch the electrons…
Anywho, I have nothing to add, just that this is:
http://www.reactiongifs.com/wp-content/uploads/2013/11/tight.gif
Any chance that terminal access would be granted to select users (minus root access)?
Aside from that, would magnetic tape be used for backup (in case of stupid)? Or would that add too much as far as power/complexity requirements are concern?
I’m planning on using some sort of micro for the PS/2 keyboard. I guess it wouldn’t be *that* hard to add a cassette tape interface. Woz did it in three chips, you know.
Three chips? I wonder which ones, I’m gonna look that up when I get a chance. Other than that, I was thinking maybe using the terminal and tape would allow for remote access and off-site storage kind of how it was when ARPANET was getting started.
If you’ve got the processor’s full attention, you just need enough address decoding to give you a pin you can flip. Condition the signal with a resistor or two, and a capacitor, and you’ve got all you need. Do the same thing on an input pin, polled by the CPU, and have it count the time between bit-flips. Counting the period gives you the pulse-length, and by using two pulse lengths you can have 0 and 1. Pulses of 1/2400 and 1/1200 of a second are commonly used.
Pardon me mentioning it again, but using this simple hardware (the address decoding was in a ULA, but that’s all it was, for the tape interface) the Sinclair Spectrum could fill 48K of RAM in about 3.5 minutes, while lesser (mostly American) machines would take half an hour for 64K, and gods HELP you if a bit came through wrong! The BBC Micro addressed tape errors by displaying the the currently loading tape block on the screen, so you could rewind back to a point before the error and keep on loading.
I loved my Atari XE, didn’t much love having to find something to do for the half hour it took to load a new game when I got bored of the old one. Still Star Raiders by itself justifies the whole line of machines.
If this post is to have any practical value, it’s to look to the British machines if you want to do audio tape storage. The American stuff was terrible. The ludicrous cost of disk drives and ROM carts from the USA (usually the dollar price with a pound-sign stuck before it) made tapes much more popular in Europe and the UK.
Final note, the Sinclair Microdrive used almost the same design as the cassette tape interface. An inch-square cartridge full of continuous tape, running at whatever speed the cheap DC motor could shunt it along at, read with a normal audio tape head, did the same all-work-done-by-the-CPU trick to load the same 48K in about 8 seconds.
WRT to Sinclair Microdrive, not quite. At least on QL, microdrive used ULA2 for de/serializing and bit rate was around 100kbit/s. IIRC same mechanism was used for NETwork.
QL had 7sec tape spin time and in that time it could effectively read or write up to 100-ish KB max.
Sinclair did it in two! One of them was a ULA but still.
Without a proper MMU, there’s very little distinction between root and regular users.
This reminds me of the 68000 system I built using Vector PC/AT prototype cards and an AT bare backplane. I kept the ISA connector compatible with PC cards but used the AT connector for all of the 68K unique things. Wiring was with the Vector wiring pencil as wire wrap was way too expensive.
There was a CPU card with a 68010 and a socket for the 68451 MMU. Although I have a MMU I never used it and just kept bypass jumpers installed. The second card had all of the support stuff: 128K SRAM, EPROM, 68450 DMAC, 68901 MFP, PC keyboard interface, etc.
Minix as the OS? It was the original inspiration for Linux, is open source and runs (or at least ran) on a 68K
Have a look at
http://www.s100computers.com/My%20System%20Pages/68000%20Board/68K%20CPU%20Board.htm
Also, for general stuff
http://www.vintage-computer.com/vcforum
Having dabbled in ASM for the 68000, I recon its a FAR better architecture than the x86.
There is a reason some of the greatest arcade machines of all time have used the 68000 (or in some cases multiple 68000s)
Couple suggestions>
1. CPU
Screw DIP64 an old MOS. Use 68SEC000/20 in FN package. It’s in modern(ish) fast CMOS, so it can be insanely overcloked over official 20MHz and it can work under wide range of supply ( 2.0-5.5V IIRC)
Also it would be nice to consider upgrade path to something with 32-bit internal paths and 32-bit bus – as a possible later upgrade option. 68020/30/40 etc are not in production anymore ( and they are not 100% compatible with 68000), ColdFire is missing some of the opcodes ( but it might be nice as an option for projects that don’t really need 68000). And there is option of using CPU32/32+ within some microcontroller.
If you go that route, you get some periphery already within chip and in some models even a simple secondary core for I/O stuff…
2. bus
a. 64 pins is going to be too tight. Use 3-row DIN connector with 96 pins.
b. signal quality matters. This means some termination and especially good ground and power ( 1 pin for ground is NOT nearly enough !). You might consider 12V power on bus and extra small switcher on each daughterboard.
c. You need good brown detect and reset circuitry on main board
d. You might take a peek at VME standard. Early VME stuff had signalling that was directly meant for 68000, so interfacing was more or less matter of a few buffers.
3. Extra standard circuits for video etc.
It might be prudent to forget these. Picture generation can be done with simple CPLD, often better and with less baggage than with prepackaged circuits of the day.
4. IO. You might consider something like PIC for that, perhaps some beefier model if you want USB host, Ethernet etc.
5. Blitter thingie
You might consider using dsPIC for 2D acceleration. 68K is slow on the bus. At 20MHz one memory cycle takes at least 4T, which means 5Mcycles/s = 10MiB/s for instrructions and data combined.
If you have to copy a buffer from location X to Y, you’d have troubles achieving 4MB/s and with any useable screen size/depth this could be bad. 1280x1240x16bp takes cca 2.5MiB, so even clearing the screen would be slow.
This is where something like dsPIC could come on its own, especially if it could be supported at low level with video circuitry ( like “fast page” reading/writing successive locations with perhaps something like scatter-gather or fixed stride etc etc).
such thingie could also generate syncs and do some cool audio generation etc etc.
6 bus II
Sending data across the bus means time penalty. You’d have to use buffers and lines would better be terminated. All this means hihger energy consumption ( termination, drivers etc) and lower speeds – no decent place of overclock, which is a shame since 68SEC000 should be madly overclockable.
So, you might consider:
a. Using more integration on the card with fewer cards. You could contain all highest speed stuff on CPU/video card and use the bus just for slower IO, which coud tolerate waitstate here and there.
b. using shorter bus with fewer card slots ( e.g. 4 seems reasonable), perhaps with lighter and/or selective termination.
c. shortening the backplane further by mounting connector on both sides by alternating them ( first on top, second on bottom etc)
Good luck! :) Reminds me of my Project, the Kiwi.
If you need help, information, software, look here:
http://www.ist-schlau.de
http://www.ist-schlau.de/phpBB3
I took a look at what’s still in production of 68k family and it seems there is not much else besides legendary 68000. Out of those, SEC version seems as best choice. It’s bvased on freshest manufactiuing process, and it comes in small package ( = low inductance and easier to cool down if needed for extreme OC – thin plastic)
Also, SEC should be easier to OC while working at 3.3V Using 3.3V might be benefitial for:
– being able to find better other components at lower prices ( CPLD, microcontrollers, memory)
– lower power drain
– lower noise on the bus
Other options fall off for one reason or another:
– 68010 Meh, whole point of it was to fix a few bugs in 68000, that was needed to work good with external MMU. Since MMU brings extra waitstates and since 68010 is hopelessly obsolete for classic OS with virtual memory, this option makes no sense.
-680(EC){2,3} nice, but not in production anymore
-68040 – there are some models stil in production, but it is outrageously expensive
-68060 not in production anymore
– ColdFire : not really 68000 compatible.
So, if this means that you never intend to venture outside 68000, it might simplify a thing or two. You might be able to work with cheaper bus and smaller connectors.
If you simplify the bus to work just for simple I/O, you might be able to use IDE cabling and squeze everything on 40 pins or so, with plenty of grounding etc, so instead of going for relatively expensive backplane you could use cheap cable and connectors.
You could even opt for one of those “modern” 80-wire ATA-100/130 cables, where each other wire was GND. Which means you’d get grounding for free…
ALso, there is no good reason why should you limit yourself to ATA and 40 wires. You could simply use wider cable and longer connectors. You only need 10-20 cm of the cable, so price shuldn’t be an issue….
Note that ATA was meant to serve higher bandwidth than anything 68000 can deliver, so throughput shouldn’t be an issue, even with address/data multiplexing…
>SEC version seems as best choice.
The 68SEC000 is the same core used in the the DragonBall VZ and SZ.. the VZ is clocked to 33MHz and the SZ is 66MHz. The reason the VZ is 33MHz I think is the peripherals. I don’t think it’s possible to actually overclock the VZ to see if it will run at 66MHz because the PLL isn’t stable after 33MHz (it’s in the chip errata I think…). I think the bog standard 68SEC000 will run at least 66MHz basically. That all said the SEC chips are now pretty expensive (Like $20+ on digikey) but brokers have them for a lot less. But if you’re going to mess around with brokers you might as well just get the 68VZ328 instead and make use of its SDRAM controller, SPI etc etc. You can use 32MB of SDRAM with the 68VZ328. :)
great. But I couldn’t find neither of them on Freescale.
it did +D
unsoldered two 68EZ328
and re-soldered on adapters
http://s14.postimg.org/vnsxdf0kh/68_SEC000_and_68328_2.jpg
(too crazy, isn’t it ?
=)
“-680(EC){2,3} nice, but not in production anymore”
You can thank the Sendai fab closure for that (which also affects the non-SEC 68000s), which was actually planned before the earthquake BTW: http://cache.freescale.com/files/shared/doc/pcn/PCN13644D.htm
d’oh =(
So now the obvious question, why the 68000? I mean the 8088 would have been a much better option as DOS runs on it, as does hundreds of old favourite dos games from the early 80s up until the 90s. Name one person who would not love playing Leisure Suite Larry on a 8088 without having to run dosbox on a over performing modern desktop computer. Just imagine what fun it would be to run Larry on a 8088, 1mb RAM and a sd card based ssd on a 7″ lcd display or an old monitor. Even push things up a bit to a old 80386dx40 and we’ll soon be playing doom against each other using serial cables. Please consider this as a possible project as this would mean a lot to a lot of people. I would volunteer, but my knowledge of electronics is a bit limited.
That’s kind of stupid. There are plenty old motherboards around that would work well enough in DOS mode. Why bother with new one ?
And even if you tried, you’d find soon enough that working with 8086 is not as simple as 68000, let alone recreating all of PC’s peculiarities. Also, where would you get 8086 ?
I don’t (personally) think 8086 project is stupid. Even if you not finding it interesting it’s going to be awesome for a lot of people and educating aswell.
I will volunteer for such a project straight away..
You can easily find 8086/8088 on ebay atleast, I’ve bought a batch of 20 SAB8086 on the cheap.
SID that’s great!!!
With an FPGA you can emulate 68k too.
Now add a POKEY and a YM along with SID ;-)
Maybe a Jaguar’s Blitter too.
Honestly I’d take a POKEY over a SID. The SID is more popular, though.
Any chance this will run AROS (http://www.aros.org/) as its primary OS? For those not in the know, it’s available for the MC680x0 range of CPUs, open source, hardware-independent and a 100% source level compatiable clone of AmigaOS.
Yes, but both sounds like a charm :-D
Melodic SID with the raw power of POKEY!
This is very interesting, and I am heartened to see a more advanced homebrew project taking shape. I can say, however, that I’m a bit disappointed at yet-another “no GAL, no CPLD” project. I think It’s absolute madness to chew up PCB real estate and sacrifice flexibility (hackability?) when a few GALs, or a single CPLD, can do the work of a dozen or more SSI/MSI chips. The Altera MAX7000 and Xilinx 9500 CPLD families, for example, are both wonderful for 5V systems. The venerable 22V10 GAL has been around since the 1980’s, and so is very ‘age-appropriate’ for retroputing projects such as this one. The 68K is a capable CPU and so I get a bit disappointed when I foresee it shackled it with compromised logic that results from space and power constrained design limits. Using programmable logic results in smaller PCB, or more logic in the same area, than with SSI/MSI devices.
The traditional arguments against using programmable logic in hobby projects are that the tools are expensive (not true) and not open (true); that the work product becomes obsolete over time (not true); and that the devices are hard to obtain (not true). My experience is quite the opposite: I use Altera MAX7000S devices in lots of retro-like projects, for example. The Quartus tool from Altera is web-based, license-free, and zero-cost. The only tool outlay is for the USB JTAG tool which is pretty cheap (<$20). The obsolete work product (i.e. proprietary HDL) is not really a valid argument, anymore, if one sticks to standard HDL such as VHDL and Verilog. These CPLD are easy to obtain – you can still buy those devices, new, today as well as easily find them surplus e.g. evilBay. GAL are even more plentiful, but at this point I prefer the power and flexibility of larger CPLD. The benefits of using programmable logic are too hard to ignore: want to change the memory map? Change a few lines of VHDL and upload via JTAG. Done. Want to add a register for a control bit you forgot about? No sweat. Need to tweak the timing or add a wait state for that peripheral chip? Trivial. With a typical SSI/MSI design, all of these lay somewhere between merely icky and pull-your-hair-out awful.
In my mind, there's far more 'risk' associated with hard-to-obtain or spendy specialty peripheral chips (e.g. MC68451, 6581 SID, etc.) The SID, in particular is a wonderful chip (I have a small stash of my own pulled from broken C64's in the 1980's) but I wouldn't consider that device for a widely-applicable project when they are $30-and-up per chip except as a strictly optional "add-on".
I look forward to watching this project unfold and will follow with great interest!
-tom
You’re absolutely correct. There’s a lot more risk in using old, vintage chips, and it will eat up a bunch more board space.
The reason I’m going for the ‘no gal, no pld’ thing is simplicity. When I’m done, I’m going to draw up the final schematics, architecture, everything and anyone will be able to copy it without any programming (except for the ROMs).
There has been some talk about making this a ‘product’ of sorts. Selling some boards, or even completed systems. This project is only the first part of making this a product. I’ll have to replace all the glue logic with a GAL, and probably implement some stuff in an FPGA. For now, though, I just want to do this old school without any programmable logic.
hi guys
i think the first problem about these projects is the eprom emulator, and then the debugger.
i have opened a pretty thread on EEVBlog talking about hw debugger, and trying to group up information about gdb (gnu debugger), trying to understand how it works, what it needs, and how to use it. Then i wanted to create a new debugger and i am still designing it.
In short: for m68k we need gdb talker, something that can “talk” over the serial line in order to read/write registers and memory, setting breakpoints and so on
we could re-use the old gdb-68k-talker … but, in my purposes … i wander why not to put something like the jtag_ADI into a soft core, or … why not to add such a debug_tap to a 68k soft core (like tg68k, for example): it could be nicer, faster (especially to upload things into memory), and much more powerful !
unfortunately i am not skilled enough to realize these things, but these are my idea
about the eprom emulator … i have opened an other nice thread talking about what is existing (commercial product), and what could be re-used with linux. I am planning to create an eprom emulator for something like 27C040 (512Kbyte) @ 3.3V and @5V, so it could be used with 68hc11, 68EC000/8bit, 68008
with a bit of extra circuits it could be possible to have 2 eproms emulated for 16bit systems (e.g. 68000 with its 16 bit bus)
just ideas, guys =)
Any project status?