10 ms·
Minimal single-board computer based on Motorola 68000
- mytailorisrich 6y agoGreat. At 12MHz and 1M RAM that's still above an Atari ST or Amiga 500. There used to be plenty of such computers based on 8bit to 16bit discrete CPUs (Z80, 680x, 8255, etc), with schematics in electronics magazines. This was great because everything was simple enough that you could fully understand and use 100% of the hardware yourself and code 100% of the software yourself. And all components were standard discrete ones (like this project), not SMCs, so there were also very easy to handle. You did not even need a PCB. I once built such simple computer based on a Z80 using good old wire wrap [1] on a prototyping board, which was quite a common thing to do, but quite a torture to be honest and I would not want to try with a 68000... [1] https://en.wikipedia.org/wiki/Wire_wrap https://en.wikipedia.org/wiki/Wire_wrap
- jacquesm 6y agoHaving worked on a fairly large 68K board that was wire wrapped I would not recommend it.
- dboreham 6y agoI built one with graphics floppy and scsi. Wasn't too bad mind you I was 19 so had infinite spare time and I worked the summer for a defense contractor so had unlimited wire wrap wire and gold plated sockets.
- jacquesm 6y agoI worked on a prototype board that was getting a little older (I did not wrap the original), apparently the tension of the wrapping tool was off or something else did not go according to plan during the original build because quite a few of the connections were flakey and had to be redone. This can be pretty tricky if there are sometimes 6 wires running to one pin and the whole thing is a rats nest of identically colored wires. I did get it all sorted out and working again but that wasn't my idea of having fun. Fortunately I got into software from hardware or I would have likely given up. You know you have a nasty problem when tapping the board can make it crash. Shades of Gollum and Coke.
- musicale 6y agoWire wrapped connections can actually be more reliable than soldered but a 16/32-bit 68K design is going to be at least twice the work (and twice the wires) of an 8-bit Z-80 design...
- jacquesm 6y agoThey indeed can be. When wrapped properly... I liked working on that board once it was brought up but the first two weeks seemed to last forever with minimal progress. Wire wrapped boards critically rely on the tension of the wire during the wrapping to make good metallic contact in such a way that oxidization can't make the connections degrade. The big advantage over soldering in my view is that you an 'unwrap' without damage to the pins in case of errors. If you do that with a closely populated board that has wires that have been soldered you will likely cause some damage.
- snvzz 6y ago>Great. At 12MHz and 1M RAM that's still above an Atari ST or Amiga 500. If CPU clock and base ram is all you care about, sure. The Amiga and the ST(E, the ST was pretty sad actually) chipsets did far more than some cpu paired with some ram.
- deleted 6y ago[deleted]
- yjftsjthsd-h 6y agoClarification on the "Forbidden (multiple devices selected) " bit - Am I reading correctly that the memory addressing is, essentially, a little buggy as a side effect of optimizing for simplicity, and that results in mapping multiple things to certain addresses? Also, I somehow didn't realize that you could buy what appears to be a new 68000, and for $8.95 (https://www.jameco.com/shop/ProductDisplay?catalogId=10001&langId=-1&storeId=10001&productId=2288039 https://www.jameco.com/shop/ProductDisplay?catalogId=10001&l...). In my defense, last time I searched it wasn't obvious, mostly because nobody labels it as a "68000"; it's a 68HC000P-12, which only in the details is listed as a "6800" (sic) family - I assume that's just a typo. And to be fair, I'm sure most people looking for a 68000-series know how to look for it; it's like expecting people to know that a 80486 is an x86 usually called a 486. Just a bit of friction for a newbie.
- jacquesm 6y agoThis was quite common. You only decode out as much as you need and if that results in phantom appearances of devices or ROM as long as it doesn't interfere with the operation of the device that is perfectly ok. Memory map aesthetics are important but sometimes circuit simplicity is more important.
- yjftsjthsd-h 6y agoThat's fair; I hesitated to call it buggy, because a well-understood bug that's documented and easy to work around or ignore and which nets you some benefit is only barely a bug at all.
- jacquesm 6y agoIf you want the same instruction set and and even smaller board you could use the 68008: https://en.wikipedia.org/wiki/Motorola_68008 https://en.wikipedia.org/wiki/Motorola_68008 they're going to be hard to find though.
- mark-r 6y agoI wonder why they used a 68000? The 68020 was a significant upgrade, and other than not being a DIP package it made a great SBC.
- tyingq 6y agoHe did mention through hole being desirable. A DIP 16Mhz 68010 could be an easy upgrade. And you would get virtual memory addressing.
- icedchai 6y ago68010's still need an MMU for virtual memory. So do 68020's, now that I think of it.
- tyingq 6y agoI see some evidence that an MMU is optional: https://news.ycombinator.com/item?id=7684824 https://news.ycombinator.com/item?id=7684824
- icedchai 6y agoMy understanding was the 68010 had "support" for virtual memory when used with an MMU due to improved exception recovery handling. For example, when accessing an invalid / unmapped memory address. See https://en.wikipedia.org/wiki/Motorola_68010 https://en.wikipedia.org/wiki/Motorola_68010 68000's didn't have that capability. An MMU of some sort would still be needed to implement the virtual-to-physical mapping of memory addresses.
- noone_youknow 6y agoMMU is optional, unless you want virtual memory. The 68010 fixes a bug in the 68000 whereby it didn’t stack enough information to recover from an address or bus error, but you still need an MMU if you want to actually do virtual memory in any performant fashion.
- mark-r 6y ago
- jjoonathan 6y ago> Due to the minimal address decoding circuitry, accessing certain memory regions will cause multiple devices to be selected. This should be avoided. Two bus drivers enter, one bus driver leaves!
- ChuckMcM 6y agoJust needs a frame buffer and you almost have a Sun-1.
- kabdib 6y agoOr an Atari ST. Just sayin'. :-)
- msla 6y agoI was just about to say that. More to the point, though, you'd need an FPGA for the custom MMU, which might be a sticking point these days, although there is a Sun-2 emulator: https://news.ycombinator.com/item?id=22350986 https://news.ycombinator.com/item?id=22350986 https://github.com/lisper/emulator-sun-2 https://github.com/lisper/emulator-sun-2
- rvense 6y agoAnother new 68k board that came out recently is Rosco: https://rosco-m68k.com/ https://rosco-m68k.com/ It's for sale on Tindie and the person who made it seems to focusing a lot on making a toolchain available etc. If you want to actually programme the 68k it looks like a good bet.
- filereaper 6y agoWe were taught on the newer Coldfire processors which use a modified m68k instruction set. I never understood the reason for the split address and data registers, it also seemed like the address registers had a few bits intended for segmentation? Anyone know the rationale behind the split address vs data registers design and architecture? Most other instruction sets use the same registers for both data and addressing, what advantage do specialized address registers give.
- Gibbon1 6y agoOut of my ass I think three things. One issue is gate loading. Connecting a large number of registers to a bus limits the max throughput. I remember some RISC processor they flubbed that. The second is the 68000 had two ALU's one for data and the other for addresses. So can do address and data calculations in parallel. Third separation means you need fewer bits to encode the register addresses in the instruction word.
- noone_youknow 6y agoI think Gibbon1 has hit the nail in the head in reply to this - it makes the instruction encoding smaller. It also allows the registers to be treated differently on-chip. Combined, this makes stuff like the register indirect with offset addressing modes on 68k both small and fast.
- dboreham 6y agoTwo ALUs?
- jejones3141 6y agoYup. The Signetics 68070 that was used in CD-i was like a 68000, but slower because it didn't have that second ALU.
- snvzz 6y agoThe memory map hurts. 68000 doesn't have a vector base register like 010+. Instead, the vector base is always 0x0, which here is in ROM, which is too much of a restriction. Installing a 010 instead should allow for getting around this. Also blatantly missing is a NMI switch. Still, it always makes me happy when I see open SBC designs based on the 68k family. Retrobrew[0] has a bunch of them, and they are less restrictive, or use 030 instead of 000/010. [0]: https://www.retrobrewcomputers.org/ https://www.retrobrewcomputers.org/
- musicale 6y ago> Also blatantly missing is a NMI switch Like a "programmer's key?" ;-) https://en.wikipedia.org/wiki/Programmer%27s_key https://en.wikipedia.org/wiki/Programmer%27s_key
- snvzz 6y agoI've had to make myself one for the Amiga 500. Just IPL lines -> diodes -> switch -> GND. The IPL lines can be found on CPU socket, Paula socket and left expansion port.
- bilegeek 6y agoUnfortunately, it seems like the 68010 is the only one completely out of production. You can find all the others easily on Digikey, even the '060. It seems like the 68030 would be ideal for both power and simplicity; 32-bit, better than the '020, yet easier to build than an '040 or '060 because it still has dynamic range bus addressing[1]. [1]http://s100computers.com/My%20System%20Pages/68030%20Board/68030%20Board.htm http://s100computers.com/My%20System%20Pages/68030%20Board/6... (ctrl-f for dynamic range bus addressing)
- snvzz 6y agoOut of production is most relevant at scale. Not as much as a hobbyist. 010 are easy to get from china. Some of them might be modern made clones, but I couldn't care less if they're equivalent. This many years later, it shouldn't be hard. 030 is indeed great, although no dip variant anymore.
- noone_youknow 6y agoDesigner of the rosco-m68k (which was mentioned in another comment - thanks!) here, always good to see another 68k SBC on the block. Looking forward to seeing how this evolves, would be especially nice to make it so $0 isn’t permanently a ROM address (to allow interrupt vectors to be changed). Even on 68010 I had to do some magic in the address decoder to make ROM be temporarily at $0 at reset.
- Teknoman117 6y agoMost of the boards I've seen that solve this have a shift register that counts the first 4 bus cycles. The data in pin is tied to 5v and the reset is tied to the reset pin on the 68k. IIRC, the clock pin is connected to the AS signal. If the 5th bit is zero, the ROM is selected. The addresses written into the first 8 bytes of the ROM are the initial (supervisor) stack pointer (typically the end of your RAM for embedded systems) and the ROM entry. At the start of the 5th bus cycle, the 5th bit goes high and the ROM is no longer mapped to the lower addresses and the CPU has jumped to the true ROM entry point. You could also of course have a register to flip the ROM being active in the lower addresses (default selected) that you later disable. You can also make a nifty DTACK generator by using another shift register. The clock is attached to the system clock, the data in pin to 5v, and the (synchronous, active when AS is deasserted) reset pin to AS. You then just AND'd the output of your chip select generators and an output bit of this shift register. (N)OR all the AND gate outputs together and wire that to DTACK (active low for the DIP parts). The first rising edge of the system clock after AS is asserted is the exact clock phase that DTACK should be asserted for a 0 wait states. Anything AND'd with the first bit of the shift register is a 0 WS peripheral, the second bit is 1 WS, third bit is 2 WS, etc. The DTACK de-assert at the end of the bus cycle also works correctly. AS deasserts in S7 (which is a falling edge of the system clock). The next rising edge of the system clock is in S0, which is when DTACK is supposed to be deasserted. (since the reset is synchronous, the clock edge will cause the shift register to reset and all the outputs will go low) My current side project is interfacing a 68010 (12.5 MHz) to an FPGA. Most of the issues are the bus voltage-level translation since all the FPGAs are only 3.3v tolerant these days. I have machinations to build a paged MMU for it that can address more than 16 MiB. I'd like to use a bigger m68k (68030 / 68040) in the future, but I'm starting with what I'm more comfortable with. the "Texas Cockroach" chips have fewer signals to worry about. Also, learning KiCad and how to use PCB-Way assembly since I have trouble with small surface mount parts (high-speed/density bus translators, currently designing with the 74LVC16T245). It's a bit hard to stay motivated when someone with a bit of patience and motivation (and have taken a decent computer architecture course) can build a 100+ MHz 32-bit RISC-V system in verilog on a ~$100 FPGA devkit.
- rcar 6y agoAs someone who has done a fair bit of tinkering with stuff like Arduinos, NodeMCUs, ESP32s, etc. along with Pis and similar, what sort of itch does this scratch for people that those wouldn't? From looking at the Rosco version, it doesn't seem like it's a cost savings or anything, and the hardware is certainly much weaker than modern options.
- rcar 6y agoTo be clear, I'm genuinely curious - this isn't intended as an insult to any of the folks who have worked on these projects.
- erik 6y agoNostalgia might be a factor. But I think the bigger appeal is that a system like this can be understood in a much more complete way than what you can achieve with a Pi or even an ESP32.
- kiwidrew 6y agoMost of the "modern" embedded stuff comes as a complete system-on-chip these days, i.e. all the peripherals and memory are integrated into the CPU on a take-it-or-leave-it basis. It's also rare for chips to offer an external parallel bus interface (the classic A0-A15 and D0-D7 pins), which means that any extra peripheral devices need to hang off an I2C/SPI port where the CPU core can't access them directly. And the available chips (AVR, ESP32, LPC2xxx, etc.) are all proprietary designs with a single manufacturer. Even the ARM chips, which generally use some variant of a Cortex-M core, have wildly different peripherals. So migrating between families is difficult/impossible. In contrast, "classic" chips like 8051, 6502, x86 and 680xx all have external parallel bus interfaces and are (or were) produced by multiple manufacturers (often as part of "second source" agreements). So when building a system using these chips, the designer has a large degree of flexibility and freedom to design the system architecture. Whereas building something using modern embedded chips is mostly an exercise in parametric search trying to find an existing chip which offers exactly the right set of peripherals for the intended design. It reduces the system designer to a mere consumer of off-the-shelf SoCs instead of being a true builder/architect.
- codezero 6y agoIt's funny how much this looks like the internals to my original Palm Pilot which I disassembled not too long ago :)
- mrlonglong 6y agoI'm just wondering if it wouldn't be easier to do without the ROM and map the 16MB to RAM, and then carve out the last 64KB at the 16th megabyte for IO space for devices, using an AVR as a bootloader to download code into the RAM? That would make it easier to manage the memory and interrupt vectors, yes?
- rasz 6y agono pdf diagram is a poor form :(
- genpfault 6y agoSo what are the options for proper digital video (DisplayPort/HDMI) generation on retro systems like this? Other than the typical (and ugly) "duct-tape a Raspberry Pi to it" and/or "software composite video to a converter dongle" approaches.
- snvzz 6y agoThe OSSC[0] is my go-to. OSHW, it takes component input (RGB, VGA, YCrCb) and audio, and outputs HDMI. Its line by line processing means virtually no latency is added. [0]: https://videogameperfection.com/products/open-source-scan-converter/ https://videogameperfection.com/products/open-source-scan-co...
- rasz 6y agoYou can duct tape vintage ISA VGA card instead http://tinyvga.com/avr-isa-vga http://tinyvga.com/avr-isa-vga + $5 vga-to-hdmi cable/dongle
- cmrdporcupine 6y agoFPGA makes all things possible. But then you ask yourself why you did this when you could have done the whole CPU there, too... As others have mentioned, there are plenty of chips that will take R, G, B + sync and spit out HDMI/DVI. But then you still have the issue of how to generate video in the first place. The Atari ST just had a simple 'shifter' type setup which stole RAM on the off cycle and spat (planar) video ram out to DACs, and if one is avoiding FPGA one can do that with just some 74series type counters and bus multiplexing... But it'd be a lot of chips... and an FPGA makes it sooo much simpler...
- tzs 6y ago68K single board computers are fun. Here's the one I did in college in 1982 [1][2]. 6 MHz 68K (I think). 4K 16-bit words of EEPROM. 1K 16-bit words of static RAM. Two RS-232 ports. The way the class worked was that they would supply the processor, and I think they may have also supplied the RAM, but everything else you were on your own for. Anything you see in those photos that makes you wonder "Why the heck did he use that!?" probably has the answer "It was cheap". That's why it is on an S-100 bus prototyping card--I found that at a surplus store. That's why the reset button says "CLR"--the Caltech EE stockroom had for some inexplicable reason a box full of cheap buttons from some old calculator. That's why the power connector is weird--found that and its mate at the same surplus store I found a power supply. I put a nice feature in the RS-232 connections. Note that the cable between the RS-232 connectors and the board plugs into an ordinary DIP socket, which is not a keyed connector. The way it is wired up is that it works both ways, but one of the ways is like using a null modem. There was one very amusing incident when I was writing software for it. The 68K cross assembler ran on Caltech's IBM 370. There was some HP workstation in the lab that you could enter your code on and it could submit it to the 370 for assembly and retrieve the output. The HP workstation was a few years old, and no one really knew much about it. It ran some weird OS and nobody had bothered to learn much about it--they just all knew enough to edit, submit stuff to the 370, and do simple file manipulation. The thing was full of several years accumulated projects from students, research code from professors, and who knows what else, so space was tight and no one really knew what was safe to delete. One day I'm using it to submit my code to the assembler, and I notice that in a lot of the file command there was some letter or digit (I forget which) that you had to include but didn't seem to have an obvious purpose. So I did the obvious thing--I tried one of the commands but with that letter or digit incremented. It turned out that was the drive specifier, and I was now using the second drive in the workstation--a drive that nobody else knew it had and was completely empty. They had been struggling with lack of free space on this thing for years, and all that time there was a second drive in it just sitting there empty! [1] https://i.imgur.com/Ts9wcfW.png https://i.imgur.com/Ts9wcfW.png [2] https://i.imgur.com/3D4rvdC.jpg https://i.imgur.com/3D4rvdC.jpg
- vhodges 6y agoAlso worth checking out: Bill Shen (plasmo) has his Tiny68K (in a number of variations including '020) system and one for the RC2014 eco system. The original: https://www.retrobrewcomputers.org/doku.php?id=boards:sbc:tiny68k https://www.retrobrewcomputers.org/doku.php?id=boards:sbc:ti... More recently: https://www.retrobrewcomputers.org/doku.php?id=builderpages:plasmo:cb030 https://www.retrobrewcomputers.org/doku.php?id=builderpages:...
- barochoc 6y agoIt’s been too long since I last played around like this. This put a bee under my bonnet and has me wanting to try something similar. It’ll be a disaster no doubt but I’ll learn from my mistakes. Thanks for posting.