Linux on the Sega 32X. Who needs hardware synchronization primitives anyway?

cakehonolulu 4 hours ago | parent | next [-]

After testing the waters with a Linux for Jaguar port; I basically set myself to get similar results on the 32X add-on for the Sega Genesis. Turns out that, even without hardware synchronization primitives, you can get smp-ready Linux: https://github.com/cakehonolulu/linux_ports

▲

msk-lywenn 11 minutes ago | parent | next [-]

Congrats. Any idea why one cpu reports 10 bogomips and the other 20?

▲

faragon 2 hours ago | parent | prev [-]

Thank you very much! Is the SSFv2 mapper supporting memory writes in the MiSTer FPGA, too? (Megadrive and/or 32x cores). Also, now that there's a SH3 core already available ([1] for replicating the Cave CV1000 system), it could be mind blowing having a system with 512MB of RAM on a SH3 at 100MHz running Linux.

[1] https://github.com/ika-musume/HS3

	▲	cakehonolulu an hour ago \| parent [-]
		Hi! 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.

▲

pizzaiolo an hour ago | parent | prev | next [-]

These recent posts remind me of an earlier time in the 2000s when people were trying to boot Linux from anything computer-like

	▲	cakehonolulu an hour ago \| parent [-]
		It's kinda like "Running DOOM on x"

▲

jonhohle 3 hours ago | parent | prev [-]

This is exciting! I didn’t see anything about I/O, but could the serial port be used for terminal access (or to drive keyboard input for the console). Lots of untapped potential.

With the Sega CD you’d get more RAM and a second, faster 68k

▲

cakehonolulu 3 hours ago | parent [-]

Hi! I'm basically forwarding UART data from the SH2s over to the M68K using a simple communication channel. Since the SH2s don't really have "direct" access to the Genesis's I/O port (They have TTL UART which caps at 4800 bps) I need this precise schema to have output. Technically speaking it should be simple enough to wire RXD too so you can interact with it. I saw some keyboard prototypes for the Genesis online (Which seem to use the Joypad ports) but I figured no one would have them so why bother writing a driver for it (Which again, would add more complexity to the M68K dispatcher; which does UART and acts as an INTC "master" to forwards IPIs between the 2 SH2s).

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

▲

to11mtm an hour ago | parent [-]

As a semi silly (But also possibly pragmatic, if we want to do this for more than simple 'fun') question... I wonder what it would take for projects like this, to take the video output and turn it into a (possibly not-visually-usable) jankhacked data output stream that could then be decoded?

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

▲

cakehonolulu an hour ago | parent [-]

Not a silly question actually.

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

	▲	to11mtm an hour ago \| parent [-]
		Well, when I say resources in this case, I mean UART bandwidth and the overhead of synchronizing that for output.... not so much memory itself (well, unless the overhead of the hackery for whatever 32x does as far as VRAM is worse, not sure if it's another tile engine or one just bangs bits...)