
68 Katy – 68000 Linux on a Solderless Breadboard - dpw
http://www.bigmessowires.com/2014/11/17/68-katy-68000-linux-on-a-solderless-breadboard/
======
josteink
That is seriously good work and an amazing DIY project!

I remember when I was a kid, trying to just get a pre-made Linux-image boot on
my Amiga. I had a 68020 CPU, but due to no MMU and no FPU (neither being
"normal" accessories at the time) I just couldn't get the thing to boot at
all. Later, when I acquired a 68030 CPU, I at least had the MMU covered, but I
was still a kid and didn't have a budget for a FPU. So I still couldn't get
things booting.

Granted, back then I wouldn't know my way around Unix if I had been handed a
booting system, but I was curious about this "Linux" thing which was supposed
to be superior if you wanted to run BBSes, multitask and do stuff like that.

But despite all those resources I had, I couldn't get things going. And here
this guy gets Linux running on a home-built 68008-based system of all things.

That is seriously cool!

Edit: I may be mixing up my 68k models. I also had a plain 68000 earlier,
which was definitely not up for the task. If I'm mixing things up, please
forgive me. It was a long time ago :)

~~~
vt240
Your post just brought back a flood of memories for me about the frustration I
went through as a kid trying to port free software to 68k BSD. I started out
running MachTen [1] which ran under System 7 on the Mac. There was something
odd about the way it did dynamic linking, I can’t remember now, but it just
turned any port into a nightmare. I don’t know why it took me so long to
figure out there was a mac68k NetBSD, which had a much better/compatible
toolchain for building stuff. I don’t remember ever trying to get linux going
on 68k, but I can sympathize.

[1]
[https://www.tenon.com/products/machten/23-info.shtml](https://www.tenon.com/products/machten/23-info.shtml)

------
segmondy
Amazing, he did in 3 weeks and that seems like 3 weeks of part time work,
that's amazing. It's amazing how much work we can put out in a small time if
we are focused. I lost it during the video when he got tangled up in vi. In
1998, I got a Sun 3 workstation which has a 68000 cpu, the only thing I could
get to run on it then was NetBSD. It's amazing that a single person can now
build such a computer and run Unix on it within 3 weeks. Just amazing, how
time changes things.

~~~
noonespecial
I built almost the same thing as a senior final project in digital electronics
in 2000. It took me 7 months and I never even troubled myself to go beyond
simple assembly programs.

I am humbled.

------
diydsp
Great project! Good hustle with the multiple attempts...

I smile at the use of a 555 as an interrupt timer... I did the same thing in
my 8088 senior project in 1996... Typically one wants the interrupts to be
accurate and periodic (hence hardware dividers to adjust the rate), but the
555 is (typically) based on RC time constants and as such is subject to heat
changes :)

So your operating system runs differently at different times of the day :)

Also, mine had potentiometers to control the two external interrupts (556), so
you could change the interrupt rate in hardware and there was plenty of pot
noise which was easily detectable in the output audio stream... tee hee
memories.

------
mutagen
Steve of BMOW has done several amazing hardware projects including a homemade
CPU from logic chips and CLPDs, Mac floppy emulators, and more. Rather than
link them here, browse the links on his sidebar and read the descriptions of
each project.

>Schematics? Forget it. Everything was built incrementally, one wire at a
time, while staring at chip datasheets. It’s an organic creation.

Yeah, that's real hardware hacking right there.

------
zurn
To clarify the article's text, uClinux is not (just) a distribution, but a
version of the kernel that rus on MMU-less hardware.

The full Linux kernel does have m68k support, but it needs a 68020 or better
CPU. This gets you real memory protection, VM etc.

~~~
pantalaimon
Wasn't uClinux merged into mainline a long time ago?

~~~
zurn
You can build it from the mainline git repo, but what you get is a version of
the kernel with defining features of Linux/Unix missing.

~~~
pantalaimon
What's missing? I haven't used uClinux before but I consider it on a cortex m4
- what should I be wary of?

------
lovelearning
"...hung at calibrating display loop. Aha, I needed a timer interrupt...."

He must be a true genius, to be able to infer the second from the first.

~~~
bjackman
Not-genius here: I've actually come across this problem trying to boot Linux
on enigmatic hardware. If you look in the Linux code it's actually reasonably
simple to work out what it's waiting for.

This guy is definitely a genius for other reasons, though!

------
pjc50
2MHz on a breadboard is good going. Getting linux into half a meg of Flash is
also extremely good going, even if it is uClinux.

------
unwind
The article spoke about a suspected memory leak in setenv(), I assume it uses
uClibc but it was a bit light on the details (no source code links in the
article, that I could find).

I dug up this link:
[http://git.uclibc.org/uClibc/tree/libc/stdlib/setenv.c?id=30...](http://git.uclibc.org/uClibc/tree/libc/stdlib/setenv.c?id=308bd3f7988e13267b67c7a17c36ba2ad92b3c1c#n50)
which I believe is the relevant function.

Unsurprisingly for this level of library code, it's not 100% super-obvious or
easy to understand. Especially the details on the in-library memory management
are unknown to me, but I thought it might be interesting.

~~~
dfox
The whole putenv()/setenv()/unsetenv()/environ API is inconsistent hack that
is essentially impossible to implement without introducing memory leak in at
least one of these operations without introducing some complex additional book
keeping. The good news is that there aren't that many reasons to actually use
these functions, as only reasonable usecase for modifying environment is
changing environment of spawned subprocesses, which can be done by
constructing your own environ and passing it as envp argument to exec().

On the other hand the memory leak is mostly negligible and one would assume
that for reasonable program that calls setenv (ie. does not call setenv in a
loop) probably smaller than cost of the aforementioned extra book keeping.

~~~
bigmessowires
I used the older uC-libc, not the newer uClibc (no dash in the name). You're
right. There's a tiny leak in this version of setenv(), when you set a value
for an environment var that already exists. It leaks the old value, which
seems to be an intentional design choice, in case anything was holding on to a
pointer to it.

------
Theodores
I built a 68008 breadboard 'computer' as a student with 6522 VIA, an EPROM of
'code', some RAM and some LED lights to show if anyone was home. It took a lot
of work to get that far. And that was a long time ago. The benefits of the
68008 were the same - minimal pins to wire up, more chance of it actually
working.

Anyway I am impressed that someone can get a distro working on 68008, getting
to the start line of that project is a big deal, going the extra miles - very
impressive!

------
bayesianhorse
I would never be able to keep all these wires straight in my head. And that's
even a step-down in terms of wiring from the BOMW1 project...

------
kubiiii
Kudos for wiring this (and also for the rest). I can't seem to succeed wiring
much simpler circuits on the first attempt, and get mad going through all the
connections to see what's wrong.

------
chubot
This is amazing! It's pretty surprising to me how little there is on the
board. It looks comprehensible.

I wonder if you could do this with a modern CPU and RAM. What would it look
like?

~~~
userbinator
A lot of newer CPUs aren't available in DIP packaging which means they won't
be usable with a breadboard; the M68k is one of the more unusual ones in that
it's available in a 64-pin DIP, the longest common DIP package. E.g. all the
x86 processors moved to square packages starting with the 80186/80188, only
the 8086/8088 were in DIP.

DIP packages are problematic for high-speed operation since the leads to the
pins near the ends are longer than the ones in the middle, creating signal
skew; hence the move to square/BGA packages.

That being said, there _are_ microcontrollers with a relatively powerful ARM
core and in DIP, but they usually have internal memory and use the pins for
peripherals, not as a full memory data/address bus.

~~~
Narishma
A lot? Make that pretty much all. The only things you still find in DIP format
are very low-end micro-controllers.

~~~
kjs3
Not ARM microcontrollers, which the OP specifically references. NXP’s LPC810 &
LPC1114 are really the only game there, and they don't support external memory
AFAIK (and it's an M0). Of course, there are a lot of shops bonding an QFP ARM
or similar to a slip of PCB that's DIP form factor, but that's not exactly the
same.

------
adamman
I would love to take a class for building a computer like this.

~~~
rbanffy
The hardware is remarkably simple. It's the software that's tricky. It's
nowhere near the level of insanity (all for good reason) you find on modern
PCs where you boot without knowing how exactly you'll get to your RAM.

------
lectrick
Reminds me of the days when the 680x0 series was still a Mac thing and Yellow
Dog Linux was a compatible distro.

