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.
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.
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...
> 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!
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).
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...
> 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!