This is a deep dive on what is necessary to get Linux on the 68000-based Atari Jaguar. No specialized hardware/flash carts. All runs within the original hardware vision (2 megabytes of RAM) and gets to a Busybox shell. Linux repository with the changes: https://github.com/cakehonolulu/linux_jag
On of the few things where getting Doom to run on it wouldn’t be that cool. But I love the post, except for the part where you reminded me I was old by acting like no one remembers that thing.
I've actually thought of that, but the memory space is so limited that I feel it'd be impossible. Also considering the fact that no official memory banking solutions exist for the Jaguar... maybe it'd be an interesting technical challenge to have a custom mapper that can do both ROM and RAM.
This is very cool. I thought literally no one else was using/interested in the 68000 support in the kernel. It was actually subtly broken for a long time. I think the fixes I did went in to 7.0 or 7.1..
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.
> Biggest contenders are the original Macintosh (And Apple Lisa), the Commodore Amiga series of computers (With varying generations of the 68000), the Sega Genesis/Megadrive, the Neo-Geo AES, Plexus workstations... and the Jaguar.
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).
I think this is very impressive. I remember from eons ago people were running Linux on Amiga, but then it was the later models with 68040 processors with more RAM.
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?
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.
I've been slowly working on getting fuzix working on my amiga 1200. It boots the kernel I just don't have a file system for it yet. Though my 1200 has ~10MB RAM.
Do you only have a RAM expansion? If you have an MMU normal m68k linux will work for you. I have an a4000 running linux with an nvidia gpu ;) The drivers for the amiga filesystem etc all still work.
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.
Still occasionally bring out my old jaguar for Alien vs Predator to try and remember what the excitement was all about, but as to putting Linux on it, amazing effort, but I think I'm going to pass :-)
Not that I blame you... in comparison with pretty much the rest of cartridge-based systems, the available flash cart is priced higher (And AFAIK no DIY open-source ones exist). AvP is one of the best games to play on the system, it was future technology at the time it came out.
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).
Completely different. The ST and TT used bitplanes whereas the Jag is chunky, and can support both YUV and RGB colourspaces. 640x200 is possible at least https://youtu.be/XI3Pvx5Yh1U?si=2bp93CeNYPTGZZic
The pro move would be getting the Jaguar development tools with their assemblers for the GPU (yes, the Jaguar had a GPU) and the DSP up and running. With just the 68000 it's kind of a glorified Atari ST as a console.
I think it could be feasible (Like, embedding the utils), but I'm not too sure how I'd handle the "upload" of the RISC code for the Tom (While at the same time it's driving the Linux console) and similar...
We used to use the blitter for that and then there was a memory location to write to to initiate execution of what was uploaded. The Jaguar developer docs are available online if you haven't seen them.
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.
Ah yes, I'm more worried about the actual limits of what the combination of Linux + the initramfs can let us do (Memory wise, mostly).
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...
The GPU was relatively stable, the DSP OTOH was whack. But you could neutralize its most offensive bug just by repeating load instructions. It looks stupid, but it always worked.
Absolutely! You could possibly develop a custom mapper that provides extra RAM (I guess memory bank switching would need to happen) plus the ROM but as far as I'm aware it's not available.
About a minute and a half. It varies by 2~ seconds at most. Could possibly be related to how Linux does the calibrate_delay() stuff? (And well, I'm also not too sure on how deterministic it's supposed to be in terms of time).
Oh yeah, well that may be. Once I got X working in Slack, I did boot into that, but then again, back then I didn't know how to recompile my kernel and the machine did this interesting loop where it would try a few different drivers until it got to the one that worked with my matsushita CD drive.
I'm awaiting some screenies from a peer that has the flash cart for the Jaguar; don't worry, they'll get added! I have both the Jaguar and the Jaguar CD but don't have the flash cart...
> 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!
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”
Yeah, 8051 wins, it was and still is in everything (sdcards, sim cards, cables, ports...). I may have some trauma from spending too much time with Keil's 8051 C compiler that made me forget it.
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.
The 65xx series outsold the 68k by several magnitudes. One might argue about how complex OS's it could run, but e.g. GEOS shows 65xx based designs could go quite far.
This is a deep dive on what is necessary to get Linux on the 68000-based Atari Jaguar. No specialized hardware/flash carts. All runs within the original hardware vision (2 megabytes of RAM) and gets to a Busybox shell. Linux repository with the changes: https://github.com/cakehonolulu/linux_jag
On of the few things where getting Doom to run on it wouldn’t be that cool. But I love the post, except for the part where you reminded me I was old by acting like no one remembers that thing.
But… there was a commercial port of Doom to the Jaguar.
But not to jaguar GNU/Linux :P
thatsthejoke.gif
It had me looking up the specs for the Atari Lynx II that I had as a kid in lieu of a more popular handheld.
Heh. I had already been programming for 28 years when it came out.
Might be fun to run this as a barebones router.
I've actually thought of that, but the memory space is so limited that I feel it'd be impossible. Also considering the fact that no official memory banking solutions exist for the Jaguar... maybe it'd be an interesting technical challenge to have a custom mapper that can do both ROM and RAM.
This is very cool. I thought literally no one else was using/interested in the 68000 support in the kernel. It was actually subtly broken for a long time. I think the fixes I did went in to 7.0 or 7.1..
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.
Hi! Thanks for all your work honestly, I saw the patches and most (If not all...) were necessary to boot the kernel.
As for the mainline stuff: Sure! May I reach out to see how I can help?
I followed you on github. I think you should be able to see my email address? If not the one on the 68000 fix commits in the kernel works :)
> Biggest contenders are the original Macintosh (And Apple Lisa), the Commodore Amiga series of computers (With varying generations of the 68000), the Sega Genesis/Megadrive, the Neo-Geo AES, Plexus workstations... and the Jaguar.
Strange that they mention almost all well-known 68k machines, but forget the (extremely relevant in this case) Atari ST...
I basically wrote them down as they came to my mind, but I agree. I'm still waiting to find a decently priced Falcon 030...
> Falcon 030
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).
Back in the day my friends who did this ran NetBSD and not Atari's Unix, which was expensive and unsupported.
Good luck finding a TT030 cheaper than a Falcon030...
I have one in here in good shape I'll sell you. Bonus if you're in Canada to simplify shipping or pickup.
Actually interested if you're okay with shipping it across the sea.
If that doesn't work out, I'm in Ireland and also interested.
The Sega Saturn might also qualify, as its sound subsystem has a 68000 with 512 KiB of RAM. Running Linux on it might be trickier though.
Also, honourable mention for the Sinclair QL (though it was a 68008 machine).
I think this is very impressive. I remember from eons ago people were running Linux on Amiga, but then it was the later models with 68040 processors with more RAM.
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?
Hi! Glad you liked it.
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.
The 68040 has a MMU, the original 68000 doesn't.
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.
I've been slowly working on getting fuzix working on my amiga 1200. It boots the kernel I just don't have a file system for it yet. Though my 1200 has ~10MB RAM.
Do you only have a RAM expansion? If you have an MMU normal m68k linux will work for you. I have an a4000 running linux with an nvidia gpu ;) The drivers for the amiga filesystem etc all still work.
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.
Wow, i recognized the 68000 before i even saw the caption. That little chip sure powered a lot of different things back then.
Yeah, I also have a lot of nostalgia for the good ol' 68000.
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... .
Still occasionally bring out my old jaguar for Alien vs Predator to try and remember what the excitement was all about, but as to putting Linux on it, amazing effort, but I think I'm going to pass :-)
Not that I blame you... in comparison with pretty much the rest of cartridge-based systems, the available flash cart is priced higher (And AFAIK no DIY open-source ones exist). AvP is one of the best games to play on the system, it was future technology at the time it came out.
I see, this would've been totally rad in 1994:
https://www.youtube.com/watch?v=PlhrLC4cL2Y&t=1856
(Not a good player, though)
Surely I must have seen someone do this already on Slashdot like 25 years ago. Cheers for using a recent kernel though, that's neat.
Hi! Thanks! Though' I must say that it also helped lots that there's still m68k (Heck, even base 68000) arch code on upstream Linux...!
“Modern Linux on the Atari Jaguar” is not a headline I expected. Thank you for making it real.
Can it do 80 columns though?
Anytime!
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).
Can the Jaguar push a higher horizontal resolution? Does it use graphics hardware similar to the Atari ST family?
Completely different. The ST and TT used bitplanes whereas the Jag is chunky, and can support both YUV and RGB colourspaces. 640x200 is possible at least https://youtu.be/XI3Pvx5Yh1U?si=2bp93CeNYPTGZZic
640x200 pixels ought to be enough for anyone.
The pro move would be getting the Jaguar development tools with their assemblers for the GPU (yes, the Jaguar had a GPU) and the DSP up and running. With just the 68000 it's kind of a glorified Atari ST as a console.
I think it could be feasible (Like, embedding the utils), but I'm not too sure how I'd handle the "upload" of the RISC code for the Tom (While at the same time it's driving the Linux console) and similar...
We used to use the blitter for that and then there was a memory location to write to to initiate execution of what was uploaded. The Jaguar developer docs are available online if you haven't seen them.
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.
Ah yes, I'm more worried about the actual limits of what the combination of Linux + the initramfs can let us do (Memory wise, mostly).
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...
The GPU was relatively stable, the DSP OTOH was whack. But you could neutralize its most offensive bug just by repeating load instructions. It looks stupid, but it always worked.
It should be possible to build a custom cartridge to use some of that 8MB address space for RAM.
Absolutely! You could possibly develop a custom mapper that provides extra RAM (I guess memory bank switching would need to happen) plus the ROM but as far as I'm aware it's not available.
How long does it take to boot?
About a minute and a half. It varies by 2~ seconds at most. Could possibly be related to how Linux does the calibrate_delay() stuff? (And well, I'm also not too sure on how deterministic it's supposed to be in terms of time).
Honestly not that far off from my 486 DX2/66 back in the day
We're talking about the equivalent of booting with init=/bin/sh, I don't remember kernel init on x86 ever being that slow
Oh yeah, well that may be. Once I got X working in Slack, I did boot into that, but then again, back then I didn't know how to recompile my kernel and the machine did this interesting loop where it would try a few different drivers until it got to the one that worked with my matsushita CD drive.
Am I the only one who clicks on these kind of articles holding out hope to see the glimmer of Linux on an actual CRT from composit outputs?
But it's always just screen shots from an emulator...
I'm awaiting some screenies from a peer that has the flash cart for the Jaguar; don't worry, they'll get added! I have both the Jaguar and the Jaguar CD but don't have the flash cart...
> The Motorola 68000
> 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!
> Before ARM the m68k was possibly the most deployed processor architecture in history
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”
> My money would be on something smaller such as the 8051 (https://en.wikipedia.org/wiki/Intel_MCS-51)
Also MIPS. It was VERY popular in embedded. Also Sony’s PS1 and PS2.
Western Design Centre also claims over 6 billion 6502 compatible cores:
https://www.westerndesigncenter.com/wdc/about_us.php
Yeah, 8051 wins, it was and still is in everything (sdcards, sim cards, cables, ports...). I may have some trauma from spending too much time with Keil's 8051 C compiler that made me forget it.
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.
The 65xx series outsold the 68k by several magnitudes. One might argue about how complex OS's it could run, but e.g. GEOS shows 65xx based designs could go quite far.
Very neat!
Thanks! Glad you enjoyed it!