Linux on the Atari Jaguar
cakehonolulu.github.io
cakehonolulu.github.io
I have some potential performance fixes for linuxmd like optimizing the multiplication that happens each time the kernel time infra needs to be updated. Would be cool to see if they help for you too and then get a "Tested-by" on the patch to mainline.
As for the mainline stuff: Sure! May I reach out to see how I can help?
Strange that they mention almost all well-known 68k machines, but forget the (extremely relevant in this case) Atari ST...
Get a TT and make it your daily driver with Atari Unix.
About the list, the 68000 and its descendants ended up in most of the Unix/technical workstation and small mini computer market before everyone moved to RISC (Sun to SPARC, HP to PA, and so on).
As far as I remember no one ran it on a 68000 with 2 megabytes of RAM.
Could Linux today run on an Amiga 500 with RAM expansion, in this same way?
In theory it should be possible I think?
I don't exactly recall the memory differences (Chip RAM vs Fast RAM and all that) but assuming you have enough Chip/Fast RAM and thereabout of a megabyte in a storage medium for the actual kernel binary; I don't see why it should not be possible.
If WHDLoad is a thing on base 500/500+ then you'd be able to fit more stuff on the "userspace" side of things, since 1.44 megs can't really hold much (And having to swap floppies in the way Workbench does it is not something I'm sure can be done on Linux).
The main issue I see is that you'd probably need to "free" up memory by unloading Workbench (If it's loaded) and possibly re-configuring the hardware (So it's in a known good state for Linux), but yeah; it should honestly be feasible.
If you have the stock 020 we (me and the other people messing with this stuff) can make that work. the 68000 support needs one tiny thing, fixing the stack frame differences between the 000 and the 010+, and it'll boot on basically anything.
I already have patches to do it.
For the moment I have a floppy disk that loads my network card drivers and then copies the kernel over the network into ram. That makes debugging things way easier than having to burn a floppy with every code change.
Linux can be built to not need a MMU, I have used that on Coldfire and Microblaze systems, I presume this Jaguar port is using it too.
But "little" is not quite the correct word to describe it, especially not when using DIP packaging as shown in the image in the article. Actually, the 68000 was right at the limits of what could be feasibly packaged as DIP. Later 68000 machines like the Amiga 600 used the PLCC version to save space and costs (https://bigbookofamigahardware.com/bboah/media/download_phot...). Actually, the Jaguar also had the PLCC version: https://www.the-liberator.net/site-files/retro-games/hardwar... .
https://www.youtube.com/watch?v=PlhrLC4cL2Y&t=1856
(Not a good player, though)
Can it do 80 columns though?
As for 80 columns... I'd probably need to choose a different (Narrower) font. With a bit smaller font I reckon it should be feasible to have it (Since current one has 8x8 glyphs).
Once the GPU or the DSP was running. You could then chain overlays together by running to a location in the GPU itself from which you called the blitter to upload the next segment and then you could just jump to its first instruction. I believe later compilers enabled just running the GPU from main RAM but it has been decades.
It was unwittingly extremely useful mental preparation for programming in cuda a decade later.
In theory it should be feasible but I'm not too sure how you'd "adapt" the way of doing things within Linux; the environment is very limited and I can't think of a way to cleanly make the Tom more "accessible" (While again, Tom is already executing the object lists to drive the Linux console). Doesn't help that it'd need additional afterthought not to trip it up with one of the many hardware erratas both Tom & Jerry had...
But it's always just screen shots from an emulator...
> Overall, it got lots of traction commercially; it ....
Before ARM the m68k was possibly the most deployed processor architecture in history. In the late 1990s it was in printers, cars, personal digital assistants, erc, as well as all the home computers, arcades and unix workstations it found it's way into in the 1980s and early 1990s.
It's sucessor, the Coldfire, could have taken ARMs place...
Probably this is the reason it's still in the Linux source tree!
My money would be on something smaller such as the 8051 (https://en.wikipedia.org/wiki/Intel_MCS-51)
Also, between m68k and ARM there was PowerPC. It got used a lot in embedded systems. Because “the newer the car, the more microprocessors it has”, chances are it got used more than m68k.
FWIW, Google’s AI gives me:
- for the m68k: “industry analysis and historical data indicate that hundreds of millions of units were produced across the architecture's lifespan”
- for PowerPC: “By 2008, Freescale Semiconductor had already shipped over 100 million Power Architecture-based MCUs for automotive powertrain management alone. Hundreds of millions more have since been produced for networking, industrial automation, and aerospace applications.”
- for the 8051: “according to industry accounts and semiconductor historians, the cumulative production of 8051-based microcontrollers is estimated to be on the order of billions to tens of billions of units”
Also MIPS. It was VERY popular in embedded. Also Sony’s PS1 and PS2.
But I still think 68k was king of that era for discrete CPU's that could go anywhere, and run a high level OS/complex software, before the MCU and then SoC era came and stole m68k's crown.
Sure, PPC took the m68k's role of discrete CPU in automotive, aerospace, networking and consoles for a while, but I don't think it is the king.
Back to TFA, I think the m68k got a bit more than just "commercial traction"! Which is why it will hopefully stay in the kernel for a long time.