Linux on the Sega 32X. Who needs hardware synchronization primitives anyway?(cakehonolulu.github.io) |
Linux on the Sega 32X. Who needs hardware synchronization primitives anyway?(cakehonolulu.github.io) |
[0] - See this Spritesmind forum thread https://web.archive.org/web/20190209161834/http://gendev.spr... (Internet Archive link because the live site is mostly unusable due to the scraper deluge)
Yes so, this was tested within a software context; the ASIC that does the bus arbitration on the side of the 32X has some of the required pins as N/C. They do a much more interesting deep-dive on the link you added.
I initially thought the 68000 side /UWR & /LWR pins were wired to the complimentary 315-5818 ones (Since there wasn't any apparent difference between the pinouts of both).
This makes the setup a bit different since you'd not be addressing the cart's PSRAM, but instead, the 32X's SDRAM. With XIP (Like on the Jaguar port) you could probably pull it off (Not sure if you'd be able to cram the entire Busybox environment but maybe a small program could do it).
Good thing is, this is actual Linux (And not uCLinux) so there's still stuff that can be disabled further if for some reason it can't fit still on the available memory.
The BogoMIPS value is derived from a calibration that Linux does against the timer of choice so it could very well be a reason why.
Honestly, no idea if Krikkz's Extended SSFv2 is even implemented on MiSTer. I'd have to check but considering the rarity of it I'd be surprised if it was there.
Porting Linux to SH3 is surely easier than what it has been for SH2 (SH7604, more precisely); and considering it has 512MB of RAM you probably can just get away with a non-stripped to the bones Linux image (And initramfs, of course). It surely sounds like a good playground.
But it also has some RISC jank of the era, such as branch delay slots.
The branch delay slots/load delay slots thing was also something that plagued some MIPS processors back then too; 5th generation of consoles (At least, from Sony, Nintendo and Sega) had either all or a subset of those quirks on their flagship machines.
With the Sega CD you’d get more RAM and a second, faster 68k
As to the Sega CD; it'd probably be cool but this is already super-slow as it is (There's lots of bus contention already from 2 x SH2s and 1 x 68000) so yeah.
Maybe a cool project would be SMP for the 2 68000s (Sega CD + Genesis) but I'm not even sure if there's any form of SMP available for arch/m68k in Linux (If both 68000s are wired you could maybe get away-ish with some simple bringup but can't really say for sure).
* Word RAM can be swapped between the 68Ks, or can be operated in a split mode where each 68K gets half. There's no mechanism to allow both 68K's to access the same bank simultaneously though.
I mean, there's a lot of hand-waving there (i.e. it would only be output which could complicate ease of using it practically) OTOH it might free up resources?
(I'm not experienced in this hardware level so I apologize if this idea is absolutely stupid/impractical.)
There's really clever ways you can get down to scratch that space-saving itch; I'm not knowledgeable about it either (I'm just really bad when it comes to analog signals) but if you really, really needed to shave off even more stuff; I reckon that the video console driver could possibly be reduced to something far more esoteric (That'd need signal processing to get tangible output of). But at that point, just use UART (Which is simple-enough already and should not really starve you out of much memory).
Regardless, I don't really know if there's the notion of an SMP-enabled m68k board based on Linux so I would not really know where to start.
For SuperH, I've gotten very lucky because there's a single CPU subtype (J2, https://j-core.org/) which has SMP tidbits that helped me understand what to look for and where in terms of wiring the 32X's CPU subtype.