(This is a guest post by Antoni Sawicki aka Tenox)
This was previously well covered by Gunkies and Neozeed, however as almost a decade passed, some improvements could be made and annoyances fixed.
Firstly NT MIPS now works in 1280×1024 resolution under QEMU. It previously had issues with mouse tracking, but this is now fixed. So the new image has a higher resolution.
Secondly the old images were made with FAT filesystem which I didn’t like too much. The reason for that is the infamous RISC NT osloader needs to be placed on a FAT partition. Then, if NT is installed on a second NTFS partition the default drive will be D:\, C:\ being the just the osloader drive. This was super annoying in practice. So a common procedure was to just have one FAT partition for both osloader and winnt. I have fixed it by supplying a pre-partitioned disk and specified the second partition for osloader and the first for NT.
Also I only had just a bare/vanilla image with no additional software installed. The new image includes most of the available apps, including IE3, some editors, Reskit and Visual Studio.
Lastly I wanted to figure out all the right settings and flags for qemu as they were discrepancies between different sources and nothing seem to work smoothly. The correct flags seem to be:
qemu-system-mips64el -hda nt4.qcow2 -M magnum -global ds1225y.filename=nvram -L . -rtc "base=1995-07-08T11:12:13,clock=vm" -nic user,model=dp83932
The -rtc flag is not really needed if you are ok with having the current date in the guest.
Thanks to Neozeed for figuring out the network settings! Unfortunately the old/legacy -net nic -net user is no longer working while the new -device doesn’t like dp83932. The documentation was quite helpful.
Thanks to reader Mark for pointing out the correct NVRAM settings! See comments below.
The new image with all the apps preinstalled is here and a plain “vanilla” here.
Curiously this now works right out of the box on QEMU 6.1 and is pretty smooth and stable compared to what it was before. Good job QEMU team and thank you! Just in case I still keep the old binaries for Windows made by Neozeed here.
Update: I built Yori for NT MIPS! You can download here!
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?
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.
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…
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.
When i tried this a few years back the network connection would die if you stressed it too much, is it any better now?
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.
Yes! Overall the whole experience is much more stable and usable than before.
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).
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.