Bochs to boot OS X under OS 9

[Jubadub]

So, as we were discussing here, we tried booting Intel OS X directly under Virtual PC, only to realize it most likely cannot be (directly) done with existing virtualization solutions available to the original Mac OS, due to no SSE/SSE2 and maybe even SSE3 support, if nothing else.

Until @teroyk let us know that Bochs 2.1.1 is available for Mac OS 9, and that that version does claim to have support for such SIMD emulation (more specifically: MMX, 3DNow!, SSE, SSE2 and apparently even something from SSE3 according to the docs). In fact, it even has, theoretically, support for x86_64! Madness!

Anyway, so I tried setting it up last night... All is good and well... Except that it seems that, rather than having options within the emulator to toggle on/off things like MMX (like Virtual PC), SSE, SSE2 etc., we have to compile Bochs 2.1.1 and tell the compiler we want those (and other) features.

There is a log file that Bochs writes to, "bochsout.txt", and on my side it clearly states that MMX is activated, but SSE2, x64 and so on are not. Meaning we have to recompile it!

Inside the file, it looks like this:

Code: [Select]

00000000000i[     ] Bochs x86 Emulator 2.1.1
00000000000i[     ]   February 08, 2004
00000000000i[     ] System configuration
00000000000i[     ]   processors: 1
00000000000i[     ]   A20 line support: yes
00000000000i[     ]   APIC support: no
00000000000i[     ] CPU configuration
00000000000i[     ]   level: 5
00000000000i[     ]   fpu support: yes
00000000000i[     ]   paging support: yes, tlb enabled: yes
00000000000i[     ]   mmx support: yes
00000000000i[     ]   sse support: no
00000000000i[     ]   v8086 mode support: yes
00000000000i[     ]   3dnow! support: no
00000000000i[     ]   PAE support: no
00000000000i[     ]   PGE support: no
00000000000i[     ]   PSE support: no
00000000000i[     ]   x86-64 support: no
00000000000i[     ]   SEP support: no
00000000000i[     ] Optimization configuration
00000000000i[     ]   Guest2HostTLB support: yes
00000000000i[     ]   RepeatSpeedups support: yes
00000000000i[     ]   Icache support: yes
00000000000i[     ]   Host Asm support: yes
00000000000i[MEM0 ] allocated memory at 0x126c2000. after alignment, vector=0x126c2000
00000000000i[MEM0 ] 512.00MB
00000000000i[MEM0 ] rom at 0xf0000/65536 (':bios:BIOS-bochs-latest')
00000000000i[MEM0 ] rom at 0xc0000/32768 (':bios:VGABIOS-elpin-2.40')
00000000000i[CMOS ] Using local time for initial clock
00000000000i[CMOS ] Setting initial clock to: Sat May 21 10:56:05 2022 (time0=3862119365)
00000000000i[DMA  ] channel 4 used by cascade
00000000000i[DMA  ] channel 2 used by Floppy Drive
00000000000i[VGA  ] interval=30000
00000000000i[VGA  ] VBE Bochs Display Extension Enabled
Now, fortunately, the documentation that comes with Bochs 2.1.1 provides the directions and instructions to compile it for Mac OS 9. It also mentions the flags we need to use to enable SSE2 and so on. It seems very, very doable, and the documentation is not messy nor too complicated to understand.

I'm not sure if I will attempt this myself, but I wanted to let you all know of this, because some of you might want to get involved and do it.

As a "bonus", if anyone of us figures out how to compile Bochs 2.1.1, from the way the documentation words things, we might additionally be able to compile subsequent 2.x versions, as well. Maybe even beyond. There are also some "optimization flags" and other such things that might allow us to make Bochs even faster under OS 9. There's great potential in learning how to compile this.

This is a lot like Mini vMac, in that you toggle on/off a lot of things during compile time, rather than generate one huge binary containing all the options. It has its pros and cons.

[Jubadub]

Also, some Bochs 2.1.1 OS 9 usage notes:

- Bochs does use a configuration file for things like specifying the path to your HD image, CD image, which device you want to boot from, how much RAM you want for your VM and so on. By default, it looks for "bochsrc.txt", which doesn't exist in the SIT archive they provide. But what does exist is a sample file, "bochsrc.dlx", which you can copy and rename, then play with. (Incidentally, that sample file is set to boot a tiny, little GNU/Linux system for you. The SIT archive comes with all of that, for your convenience.)

- When you increase RAM in the config file, you also need to, accordingly, increase the amount of memory to be allocated for Bochs itself. As in, "Get Info", then go to "Memory" and type it in.

- To create HD images, there's an accompanying app called "bximage". It tells you exactly what to do to create an image the way you want, up to around 32 GB. Thing is, there are 3 HD image options: flat, sparse and growing. If I select flat, which is the default, the program fails to create the image, for whatever reason. But if Bochs itself is configured to interpret whatever HD image you throw at it as either sparse or growing, it crashes OS 9, but flat is no problem. So you have to create the flat HD image file some other way. (I'm still looking into how.)

- The documentation details all the keywords and such you can use in the configuration file.

For the record, I already booted into Windows XP Professional SP3 32-bit and the included GNU/Linux system successfully. It works.

This build of Bochs 2.1.1 has been slower than Virtual PC for me, maybe because Bochs might be more accurate, but it's also possible the optimization build flag was not used, which we could if we rebuild it.

Hope this helps.

[Jubadub]

I just looked throughout the entire list of all changelogs of all versions, which is included with the source code of the latest Bochs version, 2.7, from 2021-08-01, and it seems that, although the last version they released binaries for Mac OS (and also Mac OS X) was 2.1.1, support for compiling for both Mac OS and Mac OS X is fully present. The only thing that changed for the worse, that too only recently (Bochs 2.6.10, from 2019-12-01) is this:

Code: [Select]

- GUI and display libraries
  [...]
  - Removed legacy guis "macos" and "svga" from display library auto-
    detection (still available using --with-XXX option).
To emphasize what they say at the end: "still available using --with-XXX option"

So even what was "removed" was not actually removed, and now requires us to specify the compiler option, rather than it being on/enabled by default. No problems there.

Did I mention Bochs, unlike VPC and I suspect also all the others, allows you to change your BIOS ROM? In fact, it seems it was from Bochs that the widely-used, hugely popular, both in real hardware and virtualization, SeaBIOS BIOS originated from.

[teroyk]

This build of Bochs 2.1.1 has been slower than Virtual PC for me, maybe because Bochs might be more accurate, but it's also possible the optimization build flag was not used, which we could if we rebuild it.

I afraid that Bochs code is not optimized at all for PPC or MacOS9. There might be big (even very big) speed boost even with little assembler optimizations in CPU emulation and more direct graphics acceleration emulation.

[Jubadub]

This build of Bochs 2.1.1 has been slower than Virtual PC for me, maybe because Bochs might be more accurate, but it's also possible the optimization build flag was not used, which we could if we rebuild it.

I afraid that Bochs code is not optimized at all for PPC or MacOS9. There might be big (even very big) speed boost even with little assembler optimizations in CPU emulation and more direct graphics acceleration emulation.

I researched more, and I can confirm both are true:

- Bochs seeks true accuracy like QEMU (and unlike Virtual PC and all others), so it has the potential to do more, but at the cost of speed;

- I also saw on the archive of the website of the original "MacBochs" port, by David Batterham, that, according to him (back in 1999, before Bochs 1.0 was released), assembler programmers for 68k, PPC and x86 were needed for such optimizations.

I suspect parts of Bochs' code were even used for QEMU when QEMU started (and since then, both projects contribute parts back and forth).

By the way, there's a CodeWarrior Pro 3 project file still included in the source code of the latest version, Bochs 2.7, released late in 2021. Bochs 2.1.1's source code has also a CWPro3 project file. In the 1999s, David Batterham was using CWPro1, then I think it was switched to CWPro2 and then finally CWPro3. Latest OS 9 version of CW is CWPro8, although even the final version, CWPro10 for OS X, can still target OS 9.

[teroyk]

By the way, there's a CodeWarrior Pro 3 project file still included in the source code of the latest version, Bochs 2.7, released late in 2021. Bochs 2.1.1's source code has also a CWPro3 project file. In the 1999s, David Batterham was using CWPro1, then I think it was switched to CWPro2 and then finally CWPro3. Latest OS 9 version of CW is CWPro8, although even the final version, CWPro10 for OS X, can still target OS 9.

CodeWarrior Pro 3 released date is 1998-04-07, so I don't think there is not any G4 optimization in prebuild binary.

[adespoton]

Your suppositions regarding BOCHS and QEMU are correct -- this is also why they are the two emulators with SSE support.

While a custom compile of the source using CW3 is definitely doable, there are also issues with multithreading and the multitasking model under OS 9 that are going to limit any potential performance gains regarding video passthrough etc.  So while it should be possible to install 10.2 on BOCHS on OS 9, it's not going to be remotely usable on a G3 Mac.

However, I should see if I can get it working under QEMU-PPC running 9.2.2 and then compare it to the performance of QEMU-PPC running 10.2.  My M1 Pro should be up to the task of doing both, and since there's no virtualization, we don't have to worry about resource contention.

I'll add this to my stack of "things I'd like to do this summer" unless someone else has the time to try it sooner

[Jubadub]

@adespoton Not sure about Bochs' case, but actually I have noticed a speed increase with the same emulators under OS 9 than a system like OS X, with Virtual PC 6 (and 7). It could very well be making use of true preemptive multitasking APIs in OS 9 (called MTask, MPTask or something similarly-named, valid for all of the toolbox AFAIK) that I don't think were available on 8 and earlier, which I figure Bochs for Mac probably is unaware of. Or carefully-crafted cooperative multitasking, without the preemptive overhead. In either case, VPC 6 is very responsive even in the background.

Incidentally, Bochs 2.1.1 is also incredibly responsive for a heavyweight Mac OS app, even if I go do another 7 different things in parallel. It does make me wonder about its code...

As for GPU passthrough (and possibly a lot else), my expectations are very low, mostly due to lack of special attention / maintainers for the Mac port more than anything else (VPC 3 had something with Voodoo, or so I hear), compared to the attention it got for *NIX and maybe even Windows. As for whether "Mac things" will help or get in the way, however, I have no idea. I wouldn't be surprised with either outcome.

We do hope to install 10.4 or later (not 10.2, as we are dealing with Intel releases and sadly there's no QEMU or equivalent for us to have PPC guests), and the bar is set to a point which we hope, and that too for high-end G4s, that it can at least boot, and potentially be just good enough to be useful for certain situations, like dealing with those stupid OS-X-format .zip files for files that can be used, and are even often intended, for Mac OS 9 and earlier. Our expectations were set throughout our journeys (via VPC) in the JaS, VPC6 and VPC7 Garden pages. Headaches and PITA situations in trying to deal with the OS-X-zip format are seen everywhere, but well-illustrated in this Garden topic. This is more than worth a shot, whether G3s can also join in on the fun or if it's a G4e-only party.

No matter what, though, even on a "G2", it cannot possibly be worse than when I got OS 9 (PPC) > VPC 6 with Windows XP (x86) > PearPC with 10.3 Panther (very bad PPC conversion even on native hardware). Now THAT was hell!

My M1 Pro should be up to the task of doing both, and since there's no virtualization, we don't have to worry about resource contention.

What do you mean by "no virtualization", in this case? I mean, QEMU + Bochs would mean 2 layers of that...
.

[Jubadub]

- To create HD images, there's an accompanying app called "bximage". It tells you exactly what to do to create an image the way you want, up to around 32 GB. Thing is, there are 3 HD image options: flat, sparse and growing. If I select flat, which is the default, the program fails to create the image, for whatever reason. But if Bochs itself is configured to interpret whatever HD image you throw at it as either sparse or growing, it crashes OS 9, but flat is no problem. So you have to create the flat HD image file some other way. (I'm still looking into how.)

OK, so I got this part figured out a lot better now. Basically, "bximage" cannot create files greater than 2 GB, a delimitation from Mac OS 8 and earlier that has not been patched on the Mac side of the source code, since maintainers for MacBochs disappeared circa 1999 when OS 9 was entirely fresh, and Mac-tailored development (at least for Mac OS, not sure about X) stopped. To be exact, 2048 MB, which is literally 2 GB, is fine, unlike with when creating images in VPC 1/2/3, whose true max was 2000 MB instead (48 MB less).

So I could create flat images just fine with this in mind.

This makes me suspect Bochs will not be able to use image files greater than 2 GB either, though, so it might be something to be careful about. This could also cause an issue with DVD images (which by the way I could use successfully in OS 9 in VPC 6 if I mounted them on the Desktop and let VPC 6 detect it automatically), so I'm hoping that if that's the case, I might be able to bypass the problem by mounting the image on the Desktop, and pointing to the mounted volume in my Bochs config text file (not sure yet how to specify absolute Mac directories for Bochs, though).

Ok, so that was that. Now onto a huge breakthrough discovery: Bochs has an "ips" setting.

What does that mean? It means "instructions per second". You literally specify how fast you want Bochs to perform, so to speak. And if you don't, it will use the default value of 1000000. You do not want it to use the default value.

So I punched in 5x that amount, and guess what? Bochs is literally 5 times faster now, no penalties on my machine (1.5GHz mini). Can I go higher? Not sure, but this setting has worked well for me for now, so I'm currently leaving it at that. I can try to improve it later, especially after recompiling Bochs, if any of us gets that far.

In any case, that is why it was so. Damn. Slow. It wasn't using my machine's capabilities at all, that too before we even got to recompile it to improve it further. For CLI OSes that are already installed, that default speed is ok, but for installers and/or GUI? Don't do that. In fact, unless you change it, Windows XP Professional SP3 32-bit fails to install at a later point (when it reboots), because it takes so long to bring up the final part of the installer process, it "times out" and gives you a BSOD telling you a driver or something got stuck in an "eternal loop", which is not true. lol
After increasing the ips, it moved past that and continued the install just fine.

Then there seems to be a related setting, "vga_update_interval", and documentation suggests that its value should one way or another be dependant on the ips value you set. Now, be it increasing or decreasing this value, I didn't see either action making things look nor feel any better, so for now I'm using the default value (300000).

Also, I cannot emphasize this enough: if you change the RAM in the config file, like lower it, then lower Bochs RAM allocation on Get Info, then increase it again in the text file and forget to do it for the Bochs app Get Info, Bochs will hang when you try to start it up, without telling you what happened, and until you realize what went wrong, it will leave you guessing, lost and confused, until you realize what happened. So be careful.

[Jubadub]

One more thing: If you keep starting and restarting it, Bochs does not seem to free up all of the used memory, and that won't show on the Mac's "About This Computer" screen. I also suspect it can leak memory, too.

In other words, it's good to restart the Mac after closing Bochs, and sometimes you will be required to, since otherwise the OS will tell you "you don't have enough free memory to open this program".

I also once saw my "File" menu in Classilla get corrupted with random crap, and other leak-looking glitches, when I was opening and closing Bochs too much, using it on and off, all at once and without restarting. At first I wasn't sure if Bochs did it, but by now I think it is most likely responsible.

So, using Bochs is a-ok. But once you closed it, then it's probably also a good idea to reboot Mac OS. Unless if there is a way to "close it correctly", because even when I select the "Quit" option, Bochs warns me the machine shut off as if it was a potentially-unexpected event. So it could be that all of this boils down to Bochs not shutting itself off correctly, which, hopefully, might not be a nightmare to patch?

I'm no C nor C++ guru, though, so I wouldn't count on myself to do any fixes. But in the archived website of the original MacBochs port, the author mentioned most (or all?) Mac-specific code is found all within a single file. (I forgot it, but the exact file name is mentioned on the website.)

[DrNo7]

Unless if there is a way to "close it correctly", because even when I select the "Quit" option, Bochs warns me the machine shut off as if it was a potentially-unexpected event.

Silly question but: do you power off the guest OS before quitting Bosch ? Because that is the usual message a virtualisation software gives when quitting without powering off (barring any "additions" that would transform it into a hibernation).

As for the memory leak, might be the same root cause (not powering off making the memory not reclaimed properly) or might be a missing feature of the code (as other OS have memory garbage collection so it is less of a problem).

[teroyk]

Then there seems to be a related setting, "vga_update_interval", and documentation suggests that its value should one way or another be dependant on the ips value you set. Now, be it increasing or decreasing this value, I didn't see either action making things look nor feel any better, so for now I'm using the default value (300000).

I don't mind if screen update is only couple times in second if it give more time to emulate cpu. But don't ask me, what that value should be. But looks quite big value...why programmers have made that update so synchronize to host machine vga horizontal blank (something like 1=refresh every horizontal blank, 2=count two horizontal blank, before refresh and so one).

[Jubadub]

Silly question but: do you power off the guest OS before quitting Bosch? Because that is the usual message a virtualisation software gives when quitting without powering off (barring any "additions" that would transform it into a hibernation).

I do, but even if I wait, for example, for Windows XP to tell me "it is now safe to turn off this computer" (which by the way seems to suggest ACPI wasn't being emulated, else the OS normally shuts itself off for you), and then Quit Bochs, I get the same message, as if the timing wasn't right.

That was a good question, though. I also wondered the same before, so I tried it out.

===========

Ok, so, I bring "news".

I tried playing with CodeWarrior 2 ~ 5, and with the source code to recompile Bochs, and on the way I learned a few things. (Note: Keep in mind I have close to no experience whatsoever with CodeWarrior, C or C++... Unfortunately my background is C#, JavaScript, and a bit of Java.)

First, there are 2 project files included: 1 for Bochs (MacBochs), 1 for bximage (to create disk images).

Despite the .SIT file name suggesting they are CWPro3 project files, it seems they are CWPro2 files: they open normally under CWPro2, and when opening on CWPro3/4/5, it asks me to convert the project files first.

Those projects also reference some libraries included with CodeWarrior, but maybe you will need to recompile them first (right-click on the library or library folder -> compile). After that, it's just the bximage specific files (just 1 file!), or MacBochs files (some 200 or so files). I got CodeWarrior 2/3/4 up to speed with those, but CW 5 was complaining about some things I just couldn't be bothered to deal with for the time being, so I stuck to CW2/3/4.

I started with Bochs 2.1.1 source, since that's the latest version they distributed binaries for, but I learned very quickly that the list of files of the source code changed for that version, and the accompanying CW project files were not updated with that. So for example CW will search for "sse2.c" or something like that, and it doesn't exist, because Bochs 2.0.2 and later refactored the code, so now there's no more any file with that name. Meaning it won't build.

So before I started getting lost trying to fix the 2.1.1 project file, I switched to Bochs 2.0.1 source, which still seems to have all the files the CW project seeks.

Now for reasons I don't know, CW was throwing errors during compile time, things that sounded silly, like "bool on;" and then say ";" was missing or that "bool is not defined" (wtf). I tried to get past those or figure it out, but before that, I decided to take a peek at the tiny bximage project instead.

So I went and tried to compile it: bximage compiled successfully, CW 2/3/4, and it functions just as the release versions. Great, I never compiled anything for the Mac in my life before, so that's cool to see. I took a peek at the code (it's small), and identified the exact part that errors out when you create images bigger than 2 GB, but I dared not try to fix that right now, as I was concerned of destroying my file system if I did something wrong. So for the time being I moved on. (Anyone that understands C or C++, feel free to take a look at it!)

Right now, I was going to go back to figuring out why the compiler barfs at the (old!) Bochs code, although I will give this a break for now. All this makes me wonder how the hell they prepared and released the Bochs 2.1.1 binaries. Cross-compilation, ignoring CW? Compiling under OS X for OS 9? Or whoever compiled it just didn't provide the up-to-date project files (if so, why?).

Maybe I will go into 1.x territory to get something working, but if someone knows CW or C/C++ better than I do (which is not hard...), Bochs 2.0.1 seems like the best place to start. Just don't count on me on this, I suck at this! You guys (@adespoton, @teroyk, @DrNo7) are probably more likely to successfully compile this than me.

Incidentally, I used Mac OS X 10.4 Tiger, after installing Xcode 2.4.1 fully (to get GCC etc.), to take the Bochs source code and run on the terminal "sh .conf.macos". Then I made a .sit of the whole folder and sent it back to my Mac OS 9.2.2 machine. Doing this might be important, else dealing with the source code on CodeWarrior will become even more complicated. (In 1999, there were less configure options, so it was less necessary, but after testing things out, I noticed that changed, and now there are lots of settings.)

[teroyk]

So before I started getting lost trying to fix the 2.1.1 project file, I switched to Bochs 2.0.1 source, which still seems to have all the files the CW project seeks.

Could it be that you have to have both sources..if you have to copy missing files from Bochs 2.0.1 source? or something?

[Jubadub]

So before I started getting lost trying to fix the 2.1.1 project file, I switched to Bochs 2.0.1 source, which still seems to have all the files the CW project seeks.

Could it be that you have to have both sources..if you have to copy missing files from Bochs 2.0.1 source? or something?

I don't think so, I believe they wouldn't have repeated all the other files if that was the case (also, that would be very weird!). I think it's because they had, like a C file for SSE code, then another C file for SSE2 code etc., and they just joined all SSE-related code (as there's also SSE3, and later on SSSE3 etc.).

So I think they refactored (reviewed/changed structure). It's no big deal, but the CW project file needs to be updated with such things else it loses track of what files should be part of the project.