Comments on: Revisiting Windows NT 4.0 MIPS on QEMU

By: Malcolm

Malcolm — Fri, 12 Nov 2021 18:25:15 +0000

I’ve been running wx86 on qemu 3.0.1 without patching and without encountering the problem. I haven’t dug through qemu to verify what happened, and it’s possibly something latent that I just haven’t seen yet.

The description of the problem seems a little strange to me though. Presumably wx86 is depending on instructions that actually existed in the CPUs that NT was designed to run on, otherwise it wouldn’t have ever worked. So it sounds like qemu wasn’t providing instructions that the chip was always supposed to have, which implies that fixing it upstream makes sense.

By: raijinkai

raijinkai — Thu, 11 Nov 2021 03:05:10 +0000

Has someone tested Wx86, and 32bit x86 programs on this new bundle? Last time you had to do a small hack and recompile to run it…
Also, seems there is still that bug in the screen color palette… Blue looks a bit purplish, instead pure blue (it can be seen better in the Sound and System control panel icons in the screenshot).

By: tenox

tenox — Wed, 10 Nov 2021 13:08:05 +0000

In reply to Mark. Yes! Overall the whole experience is much more stable and usable than before.

By: Mark

Mark — Wed, 10 Nov 2021 13:04:15 +0000

In reply to Bert. The Linux/m68k folks supplied a number of fixes for improving the reliability of the on-board SONIC ethernet in the past year since it is also used by QEMU's q800 machine, so I'd expect that the networking should be quite robust in the latest 6.1 release.

By: Bert

Bert — Wed, 10 Nov 2021 12:05:59 +0000

When i tried this a few years back the network connection would die if you stressed it too much, is it any better now?

By: tenox

tenox — Wed, 10 Nov 2021 09:46:29 +0000

In reply to Mark. Ha! Looks like it works even better and now it has the correct defaut mac address. Thank you for pointing this out! I'm going to update this.

By: Mark

Mark — Wed, 10 Nov 2021 09:33:42 +0000

In reply to tenox.

Oh I see – if you’re deliberately forcing the RTC back in time then you will still need -rtc, otherwise it will be set from the host clock.

If you don’t have “-global ds1225y.filename=nvram” then the NVRAM won’t be persisted across restarts which IIRC contains the boot partition information. The fix back in 2016 means the NVRAM MAC address will always be present and correct so it will be interesting to see what happens…

By: tenox

tenox — Wed, 10 Nov 2021 09:16:31 +0000

In reply to Mark. Oh thats super interesting. I will try dropping the size part. But the original posts didn't have ds1225y.filename, without it all sort of problems were coming up. Only when I added these flags things started working. As for rtc I added is specifically because I wanted to force clock before y2k. I remember needing to change it in the ARC bios all the time to a correct date. Let me try removing the size and see how that works.

By: Mark

Mark — Wed, 10 Nov 2021 09:00:58 +0000

FWIW for any QEMU since 2016 you should drop “-global ds1225y.size=8200” from the command line since it uses a hack to extend the NVRAM space into the NIC PROM area (see https://lists.gnu.org/archive/html/qemu-devel/2021-06/msg06951.html for the gory detail).

The problem with doing this is that the hack artificially extends the NVRAM over the PROM area containing the MAC address which allows the PROM access to succeed, but also allows the QEMU NIC MAC address and the NVRAM MAC address to be set separately which is never going to end well.

I’m also surprised that the “-rtc” part is needed – can you confirm that the guest clock is still correct if you remove this?