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 :)
I am humbled.
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.
>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.
The full Linux kernel does have m68k support, but it needs a 68020 or better CPU. This gets you real memory protection, VM etc.
He must be a true genius, to be able to infer the second from the first.
This guy is definitely a genius for other reasons, though!
It's "delay loop", which at least gives some clue that it has to do with timing. I'm sure the OP at least knows this, but just had a typo in his blog post.
I dug up this link: http://git.uclibc.org/uClibc/tree/libc/stdlib/setenv.c?id=30... 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.
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.
Sounds like you visit the wrong libraries. Try plan9's
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!
I wonder if you could do this with a modern CPU and RAM. What would it look like?
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.
There is a problem. Many processors use dynamic registers and require a clock above a certain rate to refresh the registers. Yes, no kidding, dynamic ram cells as CPU registers. I know for a fact that the first 386 was dynamic and onlyrated down to 10 or 15 or so MHz (was fooling around with low power ops, if the thing sleeps 90% of the time at 25 MHz, you can't run the chip at 100% utilization at 3 MHz...). You can see a slight mismatch if your CPU registers are only rated down to 15 MHz and you can't reliably breadboard above maybe 5 MHz ... Of course this is analog world and a chip rated to run down to 12 Mhz will almost certainly run at 10 Mhz, maybe even 5 at least sometimes, if you're careful not to run at max temp or min power supply voltage or whatever. And adding to the fun, after (sometimes long after) the first dynamic versions of a CPU come out, someone (often a licensed competitor) makes a fully static version of the chip, sometimes pin compatible. As you can imagine, early on in development, being able to troubleshoot logic by running at a tenth of a Hz is very convenient. If you've ever wondered what "fully static" means on a microcontroller data sheet, well, now you know. And you know why you can't breadboard a classic 80386 but maybe a more recent fully static clone would work.
userbinator's comments about packages are also correct and there is a low speed workaround of carrier to DIP converter boards and proto boards. I've hand soldered many a surface mount TQFP, its very easy. There are many companies selling SMD proto boards, some cheaper, some fancier, but a realistic place to start is googling for "schmartboard", as pretty much if the SMD package exists, they sell a proto board for it, ready for projects like this.
Unfortunately the industry is moving toward BGA packages and the official new hardware to mount those is like $5K although I'm sure I could rig something up much cheaper.
Schmartboard also makes 1.0mm pitch BGA adapter boards, but a lot of the high-end stuff these days is moving to 0.8/0.5/0.4mm pitch. Of course, for those kinds of things, the extra parasitics of an adapter board are probably a no-no in any case.