undefined

points

[-]

For what it's worth, the Sub 68K (mostly*) does not share memory with the main 68K. This makes SMP impossible, but on the bright side there's no contention. Sadly, there's also no way for the faster Sub 68K to directly access the cartridge so I think it would be difficult to run Linux on that CPU at all unless you can cram everything into 768KB (program RAM + word RAM)

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

by cakehonolulu2 hours ago|

parent|

[-]

Ah, that'd be it then; it would've been such a cool experiment.

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.

by to11mtm4 hours ago|

prev|

[-]

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

by cakehonolulu4 hours 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).

by to11mtm4 hours 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...)