Hackaday 68k: A New Hackaday Project

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

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

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.

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.

145 thoughts on “Hackaday 68k: A New Hackaday Project”

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.

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

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!

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.

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)

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.

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.

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:

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?

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.

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.

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.

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.

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.

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)

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.

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…

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.

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.

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.

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.

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.

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

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.

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.

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

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.

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.

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.

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

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.

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…

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.

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.

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)

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.

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.

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.

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…

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

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.

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.

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.

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!

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)