infinite-mac
infinite-mac copied to clipboard
Investigate DingusPPC
https://github.com/dingusdev/dingusppc is actively being developed and making progress (thread).
- [x] Basic boot
- [x] Video out
- [x] Sound out
- [ ] Disk image loading
- [x] Floppy
- [x] Hard disk (needs better disk image support, see #234)
- [x] CD-ROM
- [x] Add floppies to custom image disk drop-down
- [x] Multiple hard disks and CD-ROMs (limited by SCSI bus size)
- [x] Keyboard input
- [x] Mouse input
- [x] Pointer lock mode until absolute mouse position is implemented
- [x] Use alternate exception handling mechanism,
setjmp
/longjmp
appears to have a lot of overhead - [x] Add drop-down with CD-ROMs in custom instance
- [x] Mark machines as experimental in the UI
- [x] Custom RAM size support
- [x] Rebase with recent upstream changes
- [ ] Library
- [x] 7.1.2 HD image
- [x] G3 Beige ROM machine
- [x] Add Mac OS X 10.0 Install CD
- [x] Add Mac OS X 10.1 Install CD
- [x] Add Mac OS X 10.2 install CDs
- [x] 8.1 Disk Tools floppy for Beige G3
- [x] Add Mac OS X 10.3 install CD
- [x] Add OpenDarwin 6.6.2 install CD
- [x] 9.1 HD image
- [x] 9.2 HD image
- [ ] Bugs
- [x] Colors are offset (channels in the wrong order)?
- [x] Cursor is not drawn on G3 (missing hardware cursor support?)
- [x] 10.2 install CD boots on native build, does not build in Emscripten build
- [x] "Hum" noise after initial boot chime
- [x] Does not handle sample rate change from 44 KHz to 22 KHz (when playing a system beep after the boot chime)
- [x] Gossamer cannot boot with 256 MB because it allocates the memory regions twice
- [x] 8.1 install CD boots in native version but fails here
- [x] Implement #291 to allow mobile mouse movement
- [x] Add IDE driver to device image so Beige G3 can use hard drives
- [ ] Debugging
- [ ] Add mechanism for capturing stderr and/or stdout
- [x] Make fatal errors bring up the error UI instead of entering the debugger
- [ ] Performance
- [x] Profile to see why booting from a CD image is faster than booting from a floppy one -> floppy speed is realistically emulated
- [x] Experiment with inlining register read/write functions -> does not help
- [ ] Consider a pool for
TimerInfo
s instead of always creating new ones for the all the one-shot timers we go through - [ ] Track toolbox traps to see when we get the first WaitNextEvent (to measure time-to-boot)
- [ ] Do framebuffer checksumming before lookup table conversion
- [ ] Add UI for counters when profiling is enabled
- [ ] Investigate overhead of logging
- [ ] Missing DingusPPC functionality
- [x] Implement
CUDA_RESTART_SYSTEM
support so that we can operate with an empty nvram file - [ ] 7.1.2 (though not 7.5.3 or 7.6) do not finish booting on a 6100 from an HD (pointer to possible missing functionality). The same system folder does boot from a CD image, could compare SCSI operations
- [x] No text renders when booting from 7.1.2 CD
- [x] No text renders when booting from 7.5.3 CD
- [x] Custom RAM option has no effect on PDM
- [x] Mouse does not move when booting the Beige G3 from the 8.1 Disk Tools floppy (needs VBL interrupts, present in the https://github.com/joevt/dingusppc/ fork)
- [ ] idlewait equivalent (does a PowerBook do something to go into a low-power/idle state?)
- [x] Add support for extended mouse protocol and absolute mouse position (tech note)
- [x] Implement
What do you believe DingusPPC can bring to the table? I'm really wondering if we'll ever see OpenGL 1.1 or 1.2 support and far in the future perhaps even 3D acceleration on any of those PPC emulator? Probably QEMU but who knows if a new challenger could come and smash this boundary for us?
I briefly looked into QEMU, and it's massive project. Both from a code complexity of adapting it to run on the web and the performance side. The native binary is 17MB, and the qemu.js demo is ~40MB. The performance on the KolibriOS demo is also very slow, and that's a very small and fast OS.
DingusPPC has been making progress, and may be an interesting foundation for more accurate emulation (it has a MMU, so it's not limited to 9.0.4, unlike SheepShaver).
Indeed, QEMU is accurate, but it's slow as F.
It's not exactly fast, but I do have it booting 7.1.2 (which to the best of my knowledge does not run under either SheepShaver or QEMU, since they both emulate PCI-based macs): https://infinitemac.org/run?disk=System+7.1.2%20Disk%20Tools
Just the disk tools floppy for now, hard drive images will require some more changes on my side.
OMG it's soooooooooo slow hahaha!! :+1: The buzzing sound glitches starting from the Welcome to Macintosh screen are unbearable hahahah!!!
The DingusPPC-based Beige G3 machine now gets to the 10.2 install CD spinner, which is somewhat interesting: https://infinitemac.org/run?cdrom=https%3A%2F%2Farchive.org%2Fdownload%2Fapple-mac-os-x-10.2.0-build-6c115%2Fdisk1.iso&machine=Power+Macintosh+G3+%28Beige%29
EXCUSE ME !? WHAT !?
I let it run, and it breaks here. Probably a graphics issue, as there was no kernel panic. Also it was pretty slow, and one of the disk chunks did not load. I wonder if QEMU PowerPC compiled to WebAssembly would be faster than DingusPPC.
This is roughly as far as the native build gets to also (see https://www.emaculation.com/forum/viewtopic.php?p=76602#p76602), so don't expect a lot of fast progress beyond this.
FAIW, my PowerBook G3 Lombard does the exact same thing when booting the retail OSX 10.2 install disk. I had to install it on another G3, then clone the hard drive to my Lombard's NVMe (I replaced the 24 years old HDD with NVMe) and then it would boot. Perhaps this procedure of feeding it an already installed OSX 10.2 disk image could be tried with DingusPPC!
10.0 gets to the spinning pinwheel, and doesn't break. Although it never gets to the installer. Also it's about a hundred times faster.
Edit: Nevermind, it does break. DingusPPC's GPU implementation is not finished enough. I wonder if it is possible to edit the installer CD to disable the GPU
I see you added OSX 10.0 and 10.1 but could we add 9.2.2 as well or is DingusPPC not able to emulate Mac OS 9.1-9.2.2 ?
I see you added OSX 10.0 and 10.1 but could we add 9.2.2 as well or is DingusPPC not able to emulate Mac OS 9.1-9.2.2 ?
Added 9.1 and 9.2.2. They both still don't boot, but I assume they might someday.
New DingusPPC build aborts much earlier in the boot process with OOM error. Tried both your link above (10.2) and a 10.1 retail ISO. Also, is there a reason we can't define 256MB of RAM in the custom run options on IM? Why stop at 128MB?
New DingusPPC build aborts much earlier in the boot process with OOM error. Tried both your link above (10.2) and a 10.1 retail ISO. Also, is there a reason we can't define 256MB of RAM in the custom run options on IM? Why stop at 128MB?
Can confirm, the emulator doesn't even make it to the resolution switch, it dies at a black screen. For whatever reason the emulator is also failing to load disk chunks for 7.1.2.
@lg0735 can you include the URL that you're trying? https://infinitemac.org/run?disk=System+7.1.2+Disk+Tools works for me. DingusPPC's SCSI hard disk implementation is not fleshed out, so it won't work if you enable Infinite HD or Saved HD.
Separately, their CD-ROM implementation is better, so booting from the 7.1.2 CD also works (and is faster, because DingusPPC accurately simulates floppy drive timings).
@that-ben it looks like DingusPPC is now somehow allocating the emulated Mac memory twice, which is why it's bumping up against the Emscripten/Wasm limit (which had been set to allow 256MB: https://github.com/mihaip/dingusppc/blob/6f1b27944161426a390766536d7be8e58f7297c4/CMakeLists.txt#L140C1-L141). I'll need to investigate why that's happening.
It's kind of a good thing that there is a WASM memory limit this small, otherwise we would perhaps never have known that this bug exists with the new DingusPPC build. Though, if 256MB is the limit, why is IM not allowing the user to choose 256MB from the custom run dialog on the website?
I see it as an option for the "Power Macintosh G3 (Beige)" which is the other DingusPPC-based emulator:
@lg0735 can you include the URL that you're trying? https://infinitemac.org/run?disk=System+7.1.2+Disk+Tools works for me. DingusPPC's SCSI hard disk implementation is not fleshed out, so it won't work if you enable Infinite HD or Saved HD.
Separately, their CD-ROM implementation is better, so booting from the 7.1.2 CD also works (and is faster, because DingusPPC accurately simulates floppy drive timings).
@that-ben it looks like DingusPPC is now somehow allocating the emulated Mac memory twice, which is why it's bumping up against the Emscripten/Wasm limit (which had been set to allow 256MB: https://github.com/mihaip/dingusppc/blob/6f1b27944161426a390766536d7be8e58f7297c4/CMakeLists.txt#L140C1-L141). I'll need to investigate why that's happening.
The 7.1.2 disk tools works (although it's unusably slow)
What doesn't work is the 7.1.2 CD.
Also, with DingusPPC crashing, likely the reason it allocates the RAM twice is that 10.2 (and indeed 10.0 and higher) write something to PRAM so that when the machine reboots it goes to OpenFirmware to boot from the CD, which DingusPPC seems to interpret as "reinitialize the whole emulator", so it reinitializes all components, which doesn't log anything in the console, but instead of clearing the RAM, it just allocates a new 256MB block, which means it now takes up 544 MB of RAM, which is indeed over the limit. Obviously, this is not what we want. Switching the RAM back to 128MB gets us back to the Apple logo since this is now at the limit, not above. Likely the best solution for now is to just kick the RAM limit up to 1GB, so this crash doesn't happen as often.
And I am still getting disk chunk load errors. Maybe the Internet Archive isn't a good choice for CD streaming. (also it's slow as F, might want to host these CDs elsewhere)
@mihaip
I see it as an option for the "Power Macintosh G3 (Beige)" which is the other DingusPPC-based emulator:
Oh yeah! I tried to set the RAM BEFORE I chose the PM G3 lol, my bad! Thanks for pointing that out.
@lg0735
Likely the best solution for now is to just kick the RAM limit up to 1GB, so this crash doesn't happen as often.
Yeah, I was about to ask why not bump up the PM G3 dropdown menu to 1GB instead of 256MB? It's not like 1GB was a lot of RAM for nowadays modern devices anyway, they all can deal with 1GB no problem.
Maybe the Internet Archive isn't a good choice for CD streaming
The error you see (error 500) is because the remote server crashed (e.g. request timed out) or ended the Apache request abruptly on you. This COULD be due to too many requests at once. I've noticed this happening to me too, but it's pretty much random. I wonder if IM has a limit on how many chunks it requests at once, @mihaip perhaps you could enlighten us here? Are they queued and is there a limit to how many web requests it does at once? For most Apache web servers, especially crowded ones such as MR, MG, ARCHIVE.ORG it's best to limit to only 2 requests at once.
@lg0735
Likely the best solution for now is to just kick the RAM limit up to 1GB, so this crash doesn't happen as often.
Yeah, I was about to ask why not bump up the PM G3 dropdown menu to 1GB instead of 256MB? It's not like 1GB was a lot of RAM for nowadays modern devices anyway, they all can deal with 1GB no problem.
I meant the WASM RAM limit, as that is the limitation here. Although 1GB of RAM for a machine wouldn't be bad, considering the G3 can deal with up to possibly 4 GB, although only 768MB has been tested in a real machine.
I did also notice that clearing the browser cache typically fixes the Chunk errors, but this doesn't make a whole lot of sense (is the browser caching CD chunks and 500 errors? it should not be caching anything at all!)
although only 768MB has been tested in a real machine.
I'm not sure what that means, but my iMac G3 from the year 2000 has 1GB of RAM in it and it works just fine, even under Mac OS 9.
I did also notice that clearing the browser cache typically fixes the Chunk errors, but this doesn't make a whole lot of sense
It does, because whenever you clear the cache, it forces the browser to re-download the chunks and the second time around, the error 500 does not occur because at that exact moment, the remote server can actually fulfill the request (less crowded, less requests at once, etc)
I meant the G3 Beige has not been tested with over 768MB (as far as I could find).
Anyway, seems like the main issue with disk chunk issues is too many requests at once, and the caching of these chunks. That seems like it should be easy to fix (if the files are hosted on something other than the Internet Archive)
That seems like it should be easy to fix (if the files are hosted on something other than the Internet Archive)
I think it doesn't matter where the files are hosted as the number of simultaneous requests is code that can be tweaked on the client side as well.
That seems like it should be easy to fix (if the files are hosted on something other than the Internet Archive)
I think it doesn't matter where the files are hosted as the number of simultaneous requests is code that can be tweaked on the client side as well.
Actually, now that I've looked in the DevTools, the problem seems to be completely different.
Memory limit ??? I don't think I'd see that error on my PC as it has 32GB of RAM lol wat also, error 500 is coming from the remote server, not from your computer.
Memory limit ??? I don't think I'd see that error on my PC as it has 32GB of RAM lol wat also, error 500 is coming from the remote server, not from your computer.
I've encountered disk chunk load errors on a 4GB RAM laptop and a 16GB desktop. So I have no idea what is going on.
I did some fixes and bumped the Wasm memory limit, these DingusPPC configurations boot for me at least to some degree:
This is OUTSTANDING! 11/10 but I was wondering if you knew, ever since the first WASM build of DingusPPC on IM, the cursor is misaligned and you have to basically "calibrate" it by moving it to one of the corners and then slowly to the opposite corner, to get the emulator canvas to line up with the actual host OS cursor, at least in Firefox. If you click to capture the pointer, then it's fully usable as is, but if not, then there's a calibration issue initially when you first load the DingusPPC.
Couldn't get OSX to boot, it still errors out with 500 on me, I tried twice, I will check in approximately 2 hours. But System 7 works great!
Yes, 7.1.2 boots much faster now. It is also way more usable. I'm sure there is still some optimization that can be done but this is already insane. Next huge step would be to get ADB working so the Power Mac G3 (beige) can actually have working mouse and keyboard. I'm sure there's some code in QEMU/SheepShaver that can be reused for that.
Just for fun I decided to boot 9.2.2, and it craps out here:
At least it's a MacOS error, not an Emulator crash. (this is still further than it gets in SheepShaver!!)