Doom on SoftPC on an SE/30?
- Thread starter rplacd
- Start date
Give it a rest. AI can generate a lot of crap, gets facts wrong and may eventually be the downfall of man, but this project, and others like it such as the unix-style shell are pretty interesting use cases for AI that support our hobby. It means things are getting built that otherwise wouldn't. Whining about the use of AI to deliver these projects in each of the related threads is a useless contribution to the forum - maybe start an "Old man yells at cloud" thread in the Lounge.
This is a pretty cool project. I called my son down to see Doom II running on my SE/30.
My SE/30 has a 50mhz 68030 Bolle-cloned accelerator and a ZigZagJoe greyscale video board. When I tried to run it the first time I still have my monitor set to 256 shades of grey and was presented with 5 micro Doom screens at the top part of the display - very similar to what I get when I try to run MacFlim on the same hardware. I couldn't ever get MacFlim to work so I was worried I wouldn't be able to get Doom to work, but once I switched to black and white it worked fine.
On my hardware, it plays remarkably well - I was probably getting 15+ frames a second - quite fluid and playable. The issue at first was the dithering which made it difficult to see what I was actually playing, but as a proof of concept, it was pretty neat. I did play with the settings and could increase the quality which actually made it look pretty good and pretty playable, unfortunately when I tried to increase the size of the display area, it looked really bad no matter what settings I chose.
So again, pretty neat project and on an accelerated SE/30 it ran quite well.
That prompted me to try to run regular Doom II on my SE/30. The splash screen looked awesome in greyscale but after it loaded the models it crashed out with an unimpleneted trap. I didn't have a chance to check the Doom II requirements to see what might be the issuer here.
Thanks! Not easy to get a good set of dithering settings. the O and P keys adjust gamma, and the [ and ] keys adjust black pt. and the ; ‘ keys adjust white point (options screen indicates it as well in case I had a typo). — So you could play with those settings at runtime. But I haven’t found a solid set. There is also additional settings (red/green/blue dithering related) that could help more but those are hard coded and would require a recompile. I even have a python tool with GUI that lets you test out the full set of settings offline, but you have to feed it a doom screenshot as your preview and it wasn’t that great…. I wish I could get folks to try different dither settings till a clear winner is established. Send them a free MacPlus or something 
.
Hard to get a setting that looks good everywhere and not just in the current scene’s lighting. The No Lighting setting would help here but then you lose lighting effects.
FYI - for full screen on your maxed out SE30 I recommend the following: In Options… -> Hit DEFAULT settings button, then tick OFF the “Half line” and tick “On” the Full Screen. The quality level can be left at QUAD for speed but if you want you can pump it up to Medium or High but you’ll feel the frame rate hit. Thanks for giving it a go and thanks for the support.
F
. Hard to get a setting that looks good everywhere and not just in the current scene’s lighting. The No Lighting setting would help here but then you lose lighting effects.
FYI - for full screen on your maxed out SE30 I recommend the following: In Options… -> Hit DEFAULT settings button, then tick OFF the “Half line” and tick “On” the Full Screen. The quality level can be left at QUAD for speed but if you want you can pump it up to Medium or High but you’ll feel the frame rate hit. Thanks for giving it a go and thanks for the support.
F
slop lover says what? have some self respect
if anything, these worthless projects are useless contributions.
if you can't be assed to code your own software, why should i be assed to use it?
I understand your perspective but will give you the full picture. I’m as big a skeptic / critic / sometimes cynic / concerned citizen as you’ll find when it comes to AI. Especially when it comes to safety-critical applications, mental health, the environment, etc.
This effort probably took 14 hrs working with Claude Code in a terminal to get this to where it is — note this is not hitting “GO” and waiting for 14 hours, but interacting with it and making suggestions and at times fighting it. Probably more. Additionally about 8 hours just me work with resource stuff (the part that it couldn’t really try to do), process and tooling flow, testing on emulators and hardware, managing documentation and deployment wrangling with files etc between OS 7 and modern machine.
This wasn’t a hit ‘go’. and then ‘publish’ — And more importantly, we the vintage Mac community now have DOOM running on the SE/30. For 30+ years there have been people wishing for that and I’m happy to have delivered to that wish for myself and the vintage mac community - a community in which all are welcome, including yourself.
On a personal note - I actually was anticipating just the sort of response @finkmac had — It’s even exciting to have this conversation because Retro technologists and enthusiasts have to sort through how they, like everyone else, will grapple with AI in their favorite hobbies and pastimes. I say that with no assumption that there is a right or wrong answer and much less that I know the right answer (but I know lacking civility is wrong).
Here’s a great article I was reading tonight that puts a lot of real perspective on the shift AI brings. Essentially that the cost of producing code has now plummeted, but the need to comprehend it hasn’t. But removing the code-production bottleneck immediately hides the need to comprehend it — Worse yet, much of our comprehension was enabled by the time it took to produce code. So current processes are well poised to have the comprehension part risked by simply removing the code-production bottleneck. MacDoom SE/30 certainly suffers from this.
But I absolutely contend that in this specific case of a non-retail, open-sourced, 32+ year old video game software made playable on an even older hardware platform running 30 year old system software — it’s OK to have incurred the comprehension debt for the sake of meeting the interests of hobbyists tinkering different with ‘em.
Tell us again how you have no friends IRL - without actually telling us.
@superjer2000 - intersted to hear the 50MHz performance difference compared to stock 16MHz CPU, and thanks for being a positive contributor to this site!
@Mike68k, not a big fan of AI such as yourself, but thanks for this, will give it a try on the SE/30.
As a follow up, it looks like Doom II required a 68040 which is probably why I was getting the unimplemented trap error when trying to run it on my 50mhz 030 SE/30.
The fact that this janky AI supported port of a Linux version of doom runs as well as it does on my accelerated se/30 (I'd say at the same frame rate as I get on my 040 LC575) suggests that a highly optimized engine could be written that would allow for a grey scale doom to run on an properly equipped SE/30.
The fact that this janky AI supported port of a Linux version of doom runs as well as it does on my accelerated se/30 (I'd say at the same frame rate as I get on my 040 LC575) suggests that a highly optimized engine could be written that would allow for a grey scale doom to run on an properly equipped SE/30.
Any chance on tricking the robot into making an optimized version of Doom on 68k Mac? After having played Doom and Duke3D on a 40Mhz 68040 and a 66Mhz 486, I can see that the 68k processor can really throw down.
@superjer2000 . The thing to note about a Sinclair ZX Spectrum is, of course, that it's really a 1bpp bitmap system with a 32x24 character resolution, colour attribute overlay. The Bitmap video is at address 0x4000 and the colour attribute overlay is at address 0x5800.
Thus the primary requirement for an SE/30 is to chuck around 4x the bitmap around the screen. Which should be easy for a 16MHz 68030 vs a 3.5MHz Z80 especially since the ZX Spectrum's bitmap frame buffer isn't mapped in raster order. It's divided into 3 blocks of 2kB; subdivided into 8 character rows that start at +32*row, and within that 8 pixel scan lines that start at +256*scan. Thus, scan line 0 begins at 0x4000, scan line 1 is at 0x4100, scan line 7 at 0x4700, but scan line 8 (character row 1) begins at 0x4020 and scan line 9 is at 0x4120. Cool huh? (no).
The equivalent of a 320x200 display scaled up to the SE/30's 512x342 is 512x320.
