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
That was something I also noticed; I can't say for sure (Since I haven't yet checked) but I feel like I may have done something incorrect when wiring the FRT (The timer) to the secondary, smp-enabled SH2.
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.
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.
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.
Neat to see this on HN after discussing this a bit with you on the Emudev discord (I'm Mask of Destiny there). I'm curious if you tested this on hardware. I think I mentioned this previously, but my understanding is that the SH-2s are incapable of writing to the cartridge area [0]. This would seem to preclude using the cart as RAM even with the extended "SSF2" mapper. Did you find that to be not the case or was this only tested in an emulator?
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.
I was actually thinking, if memory is the bottleneck; I could always go with the Saturn instead (Or find a way to have the 32X catridge writes go through…; but I’m no EE unfortunately).
I do recall having a RAM expansion cartridge in mine that could possibly be used to fit more stuff if the main 2MBs it had were too little to hold Linux.
Yeah, the Saturn is probably the more practical target. The SH-2s are clocked a little faster, the memory bus is 32-bit wide and there's an off-the-shelf 4MB RAM expansion cartridge. There's also a readily available, first-party PS/2 keyboard adapter (this adapter can also be used on the MD, but you need a custom passive adapter since they switched connectors).
> 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.
It does require an MMU technically, this kernel is built with that in mind but I see no mention of uCLibc whatsoever on the kernel log (Or that I remember out of all the files I saw open). I’ll see if I can pinpoint exactly what it is.
For those unfamiliar with the Hitachi SuperH architecture, imagine THUMB. ARM even had to license some of the patents from Hitchai when they developed THUMB. SuperH architecture is not the same thing as THUMB, but it has a lot in common, mainly use of 16-bit instructions, and instructions that only specify two registers rather than three.
But it also has some RISC jank of the era, such as branch delay slots.
> 16-bit instructions, and instructions that only specify two registers rather than three
These are not strange design features. I'm surprised they were patented? For example, most non-SIMD x86 instructions are two-operand. The trade-off between two-operand and three-operand has been known for a long time. (Shorter instruction encodings, but sometimes you need more instructions)
I actually didn't know the THUMB thing; pretty interesting stuff...
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.
Doom can't compete with the ZMachine running on a pen, on a J2ME phone and even a PostScript file. And, with patience, you could even play Zork (or any other Z3 game such as Tristam Island) on a printer.
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
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).
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.
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.
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.)
This is how Lumacode works, for home computers and consoles that don't have a digital display output. It encodes data in brightness levels of the composite video signal that can be reconstructed on the other end. An example: https://github.com/c0pperdragon/LumaCode/wiki/VIC-II-dizer-(...
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).
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...)
Hate to hear about your ASIC issue. I have too many boxes sitting idle because some custom bit of semiconductor has gone wonky with no way to replace other than cannibalism.
Banter aside; I was basically on a tunnel-vision/nerd-snipe/however you want to call it to get it to run; GCC report is still coming. It’s just that I’ve never sent out (a report) to them (gcc) and wasn’t really sure how to proceed (Even though they give out a pretty step-by-shep guide) so I wanted to finish the bringup and then try to make some easy reproduction code (That’s not compiling Linux, that is).
I actually have a comment on GH from one of the many cool people that’s (I think?) maintaining the GCC backend for SuperH.
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
Congrats. Any idea why one cpu reports 10 bogomips and the other 20?
That was something I also noticed; I can't say for sure (Since I haven't yet checked) but I feel like I may have done something incorrect when wiring the FRT (The timer) to the secondary, smp-enabled SH2.
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.
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
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.
Neat to see this on HN after discussing this a bit with you on the Emudev discord (I'm Mask of Destiny there). I'm curious if you tested this on hardware. I think I mentioned this previously, but my understanding is that the SH-2s are incapable of writing to the cartridge area [0]. This would seem to preclude using the cart as RAM even with the extended "SSF2" mapper. Did you find that to be not the case or was this only tested in an emulator?
[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)
Hi! Nice to see you here.
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.
I was actually thinking, if memory is the bottleneck; I could always go with the Saturn instead (Or find a way to have the 32X catridge writes go through…; but I’m no EE unfortunately).
I do recall having a RAM expansion cartridge in mine that could possibly be used to fit more stuff if the main 2MBs it had were too little to hold Linux.
You got me thinking…
Yeah, the Saturn is probably the more practical target. The SH-2s are clocked a little faster, the memory bus is 32-bit wide and there's an off-the-shelf 4MB RAM expansion cartridge. There's also a readily available, first-party PS/2 keyboard adapter (this adapter can also be used on the MD, but you need a custom passive adapter since they switched connectors).
> 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.
Doesn't actual Linux require an MMU?
It does require an MMU technically, this kernel is built with that in mind but I see no mention of uCLibc whatsoever on the kernel log (Or that I remember out of all the files I saw open). I’ll see if I can pinpoint exactly what it is.
Careful, or at this rate you'll end up running Linux on the Sega Saturn's 68000.
For those unfamiliar with the Hitachi SuperH architecture, imagine THUMB. ARM even had to license some of the patents from Hitchai when they developed THUMB. SuperH architecture is not the same thing as THUMB, but it has a lot in common, mainly use of 16-bit instructions, and instructions that only specify two registers rather than three.
But it also has some RISC jank of the era, such as branch delay slots.
> 16-bit instructions, and instructions that only specify two registers rather than three
These are not strange design features. I'm surprised they were patented? For example, most non-SIMD x86 instructions are two-operand. The trade-off between two-operand and three-operand has been known for a long time. (Shorter instruction encodings, but sometimes you need more instructions)
I actually didn't know the THUMB thing; pretty interesting stuff...
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.
These recent posts remind me of an earlier time in the 2000s when people were trying to boot Linux from anything computer-like
It's kinda like "Running DOOM on x"
Doom can't compete with the ZMachine running on a pen, on a J2ME phone and even a PostScript file. And, with patience, you could even play Zork (or any other Z3 game such as Tristam Island) on a printer.
Interesting, I hadn't heard of Petersen's algorithm before. There's a similar algorithm by Lamport (of course): https://lamport.azurewebsites.net/pubs/fast-mutex.pdf .
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
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).
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.
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.
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.)
This is how Lumacode works, for home computers and consoles that don't have a digital display output. It encodes data in brightness levels of the composite video signal that can be reconstructed on the other end. An example: https://github.com/c0pperdragon/LumaCode/wiki/VIC-II-dizer-(...
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).
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...)
Do I have to get Linux running on my SORD M68MX now?
(I actually planned to do this but unfortunately there seems to be a hardware issue and it seems to inside an irreplaceable ASIC :()
Yes. It's a moral imperative. :-)
Hate to hear about your ASIC issue. I have too many boxes sitting idle because some custom bit of semiconductor has gone wonky with no way to replace other than cannibalism.
"Didn't have the time at that moment to file a bug report"
Because you were busy working on that so urgently needed port of Linux to the Sega 32X?
Aha! You got me ;)
Banter aside; I was basically on a tunnel-vision/nerd-snipe/however you want to call it to get it to run; GCC report is still coming. It’s just that I’ve never sent out (a report) to them (gcc) and wasn’t really sure how to proceed (Even though they give out a pretty step-by-shep guide) so I wanted to finish the bringup and then try to make some easy reproduction code (That’s not compiling Linux, that is).
I actually have a comment on GH from one of the many cool people that’s (I think?) maintaining the GCC backend for SuperH.
TL;DR: It’s coming.
I wish the original XBOX port of GNU/Linux was revived. A custom Slackware install would be ideal for this.