Announcing EmuWoW Beta 1 (AXP Preview1)

Freecell & Winver

This is a guest post by CaptainWillStarblazer

Hello, everyone. This is a continuation of my previous blogpost on EmuWoW (formerly win32emu) found here, but to summarize, I’m the 18-year-old developer behind a project that allows running applications compiled for the MIPS/Alpha version of Windows NT on standard x86 PCs through emulation, but without requiring a full system emulator. Since that last post, the project has made some substantial strides.

Since then, I’ve adapted the MIPS emulator from MAME, which is both more accurate and faster than my own (writing my own was a fun exercise but to the end of running applications, borrowing an emulator was a better decision). This alone enabled WinMine to function, which can be seen below.

Winmine for MIPS!

Around the same time, another VirtuallyFun member named x86matthew entered the scene. His prior credits include a similar project, for Win16. He was inspired by the initial win32emu blog post, created his own similar project called WoWMIPS, which quickly started running a few simple apps, such as WinMine, Solitaire, and Notepad. Be sure to check out WoWMIPS – MIPS Emulator for Windows, Part 1: Introduction, and parts 2,3,4,5,6!

This had actually been what I was hoping for from the beginning; I always saw win32emu as a proof of concept for a smarter person (either myself in the future or someone else altogether) to come back later and do it better, and this is a massive undertaking for a single individual. What makes x86matthew’s WoWMIPS so incredible is its clean design. For one, there’s no thunk DLLs required. When an application tries to import a DLL, the host x86 DLL is first loaded, and then any attempts to get the address of an exported procedure from it are then redirected to an auto-generated stub of MIPS code which invokes the emulator to call the function. In other words, the thunk DLLs are generated at load time. Additionally, there’s no window procedure thunks required either. Instead, MIPS code pages are marked as non-executable, causing an access violation when Windows attempts to call them. Using an exception handler implemented via Windows XP’s Vectored Exception Handling feature, one can detect this and then invoke the emulator to execute the callback. Storing the CPU state in thread-local-storage allowed proper support for multithreading. I duplicated these design choices into EmuWoW, and the results largely speak for themselves. Unlike WoWMIPS (at time of writing), EmuWoW is still capable of loading MIPS DLLs (and will prefer to do so if possible), however.

Various MIPS Windows NT applications running

To aid the process of fixing faults in the emulator, I hacked up a quick, minimal debugger into EmuWoW. First of all, there’s a “crash screen” which will indicate the type of error and dump registers and the current instruction if there’s a fault, and a running disassembly can be printed as you go, but most crucially, there’s a limited degree of interactive debugging functionality.

The built in debugger to EmuWow

The main capabilities contained herein are dumping registers and memory to the screen, disassembling regions of memory, listing loaded modules, getting import entry points, setting breakpoints, and single-stepping, along with printing functions. It’s no gdb (especially for the lack of PDB symbol support), but it’s something.

MIPS is all well and good, however, but we can already emulate Windows NT for MIPS. MIPS is a fairly clean, simple architecture, often used for teaching, and short of weirdness like delay slots, is dead simple to emulate. And it fits the bill for what I’m trying to do here – a RISC architecture Microsoft abandoned, fixed-length 32-bit instructions, the works. However, adding support for the DEC Alpha AXP will finally get this project to where it was intended to be from the beginning, and I hope for it to eventually be able to run the Visual C++ compiler toolchain under EmuWoW. Being able to compile (and even test!) Alpha apps on readily available modern PCs will be a game-changer, and I intentionally wrote EmuWoW to be CPU-agnostic, so adding rudimentary support for the Alpha wasn’t difficult. Like with MIPS, I lifted the emulator from MAME. This admittedly did pose some challenges, due to MAME’s use of C++ features such as

  • Classes (which I had to substitute for passing pointers to structs)
  • Templates (which I had to substitute for macros)
  • Function-style casts (which I had to change into C-style casts)

There was a lot of weirdness in how Alpha function calls, but it was my misunderstanding of the calling convention, and when to consider values to be 32-bit vs 64-bit posed a modest issue, but I got it to the point where some very simple DEC Alpha programs started to run, though many of them have various issues.

Various Dec Alpha Windows NT applications running

This is the first time this has ever been possible; emulation of AXP NT programs on standard PCs has just become possible now. I’m hoping to see EmuWoW continue to evolve, and I welcome contributions, whether that be improving support for the CPUs I already have, adding support for another (such as PowerPC) or anything else. To take a look at the code, go to github.com/bhty/emuwow and to download EmuWoW and try it out for yourself, click here.

Win32Emu / DIY WOW

This is a guest post by CaptainWillStarblazer

When the AXP64 build tools for Windows 2000 were discovered back in May 2023, there was a crucial problem. Not only was it difficult to test the compiled applications since you needed an exotic and rare DEC Alpha machine running a leaked version of Windows, it was also difficult to even compile the programs, since you needed the same DEC Alpha machine to run the compiler; there was no cross-compiler.

As a result, I began writing a program conceptually similar to WOW64 on Itanium (or WX86, or FX-32), only in reverse, to allow RISC Win32 programs to run on x86.

The PE/COFF file format is surprisingly simple once you get the hang of it, so loading a basic Win32 EXE that I assembled with NASM  was pretty simple – just map the appropriate sections to the appropriate areas, fix up import tables, and start executing.

To start, I wrote a basic 386 emulator core. To complement it, I wrote my own set of Windows NT system DLLs (USER32, KERNEL32, GDI32) that execute inside of the emulator and then use an interrupt to signal a system call  which is trapped by the emulator and thunked up to execute the API call on the host.

For example, up above, you can see that the emulated app calls MessageBoxA inside of the emulated USER32, which puts 0 in EAX (the API call number for MessageBoxA) and then does the syscall interrupt (int 0x80 in my case), which causes the emulator to grab the arguments off of the stack and call MessageBoxA.

To ease communication between the host’s Win32 environment and the emulated Win32 environment, I ran the emulated CPU inside of the host’s memory space, which means that to run applications written for a 32-bit version of Windows NT, you need a 32-bit version of win32emu (or a 64-bit version with /LARGEADDRESSAWARE:NO passed to the linker) to avoid pointer truncation issues, to prevent Windows from mapping memory addresses inaccessible by the emulated CPU.

To get “real” apps working, a lot of single-stepping through the CRT was required, but eventually I did get Reversi – one of the basic Win32 SDK samples – to work, albeit with some bugs at first. Calling a window procedure essentially requires a thunk in reverse, so I inserted a thunk window procedure on the host side that calls the emulated window procedure and returns the result.

It’s amazing, it’s reversi!

After this, I got to work on getting more complicated applications to work. Several failed due to lack of floating-point support, some failed due to unsupported DLLs, but I was able to get FreeCell and WinMine to work (with some bugs) after adding SHELL32. I was able to run the real SHELL32.DLL from Windows NT 3.51 under this environment.

Freecell
Minesweeper

One might wonder why I put all this work into running x86 programs on x86, but the reason is that there’s the most information about, and I’m most proficient with, Windows on the 386. Not only does Windows on other CPUs use other CPUs, but also there’s different calling conventions and a lot of other stuff I didn’t want to mess with at first. But this was at least a proof-of-concept to build a framework where I could swap the CPU core for an emulator for MIPS or PPC or Alpha or whatever I wanted and get stuff running.

Astute readers might be wondering why I didn’t take the approach taken by WOW64. For those who don’t know, most system DLLs on WOW64 are the same as those in 32-bit Windows, the only ones that are different are ones with system call stubs that call down to the kernel (NTDLL, GDI32, and USER32, the first of which calls to NTOSKRNL and the latter two calling to WIN32K.SYS). WOW64 instead calls a function with a system call dispatch number, which does essentially the same thing. The reason for this is that the system call numbers are undocumented and change between versions of Windows. WOW64, being an integrated component of Windows, can stay up to date. If I took this approach, I’d either have to stay locked to one emulated set of DLLs (i.e. from NT 4.0) and use their system call numbers on the emulated side, or write my own emulated DLLs and stick to a fixed set of numbers, but either way I’d somehow have to map them to whatever syscall numbers are being used on the host.

As I went on, I should probably also mention that what I said earlier about loading Win32 apps being easy was wrong. Loading a PE image is pretty straightforward, but once you get into populating the TEB and PEB (many of whose fields are undocumented), it quickly gets gnarly, and my PEB emulation is incomplete.

Adding MIPS support wasn’t too much of a hassle, since the MIPS ISA (ignoring delay slots, which gave me no shortage of trouble) is pretty clean and writing  an emulator wasn’t difficult. The VirtuallyFun Discord pointed me to Embedded Visual C++ 4.0, which was invaluable to me during development, since it included a MIPS assembler and disassembler, which I haven’t seen elsewhere. After writing a set of MIPS thunk DLLs and doing some more debugging, I finally got Reversi working.

There’s still some DLL relocation/rebasing issues, but Reversi is finally working in this homebrewed WOW!

I’d encourage someone to write a CPU module for the DEC Alpha AXP (or even PowerPC if anyone for some reason wants that). The API isn’t too complicated, and the i386 emulator is available for reference to see how the CPU emulator interfaces with the Win32 thunking side. An Alpha backend for the thunk compiler can definitely be written without too much trouble. Obviously, the AXP presents the challenge that fewer people are familiar with its instruction set than MIPS or 386, but this approach does free one from having to emulate all of the intricate hardware connections in actual Alpha applications while still running applications designed for it, and I’ve heard the Alpha is actually quite nice and clean. MAME’s Digital Alpha core could be a good place to start, but it’ll need some adaptation to work in this codebase. Remember that while being a 64-bit CPU with 64-bit registers and operations, the Alpha still runs Windows with 32-bit pointers, so it should run in a 32-bit address space (i.e. pass /LARGEADDRESSAWARE:NO to the linker).

Theoretically, recompiling the application to support the full address space should enable emulation of AXP64 applications, since the Alpha’s 64-bit pointers will allow it to address the host’s 64-bit address space, but I’m not sure if my emulator is totally 64-bit clean, or if the AXP64’s calling convention is materially different from that on the AXP32 in such a way that would require substantial changes. In either case, most of the code should still be transferable.

I also want to get more “useful” applications running, like development tools (i.e. the MSVC command line utilities – CL, MAKE, LINK, etc.) and CMD. Most of that probably involves implementing more thunks and potentially fixing CPU bugs.

This project is obviously still in a quite early stage, but I’m hoping to see it grow and become something useful for those in the hobby.

For those who want to play along at home, you can download the binary snapshot here: w32emu.zip

A more complete version of the writeup is available here: https://bhty.github.io/og/win32emu_VirtuallyFun_Post.htm and you can find the project here https://github.com/BHTY/Win32Emu/.

Windows NT demo on the DECstation 5000

Well this was unexpected find! Thanks to hyenasky over on discord.

While the platform had a few mentions here and there but it’s great to have found a talk about the product with video of it running.

Interestingly enough Compaq was apparently in charge of the ARC specifications? Also kind of funny how the do touch on that maybe one day it could be available for the Dec Alpha, but as we know DEC pivoted away from the MIPS entirely to focus on the Alpha.

The other part being how the Pentium/Pentium Pro was entirely unexpected from the wider RISC market that thought they had the migration point out of 386/486 based machines.

Unfortunately, like the platform, Alexandre Bronstein exited DEC to go onto other ventures, oddly enough at Veritas being pulled back into dealing with Microsoft with the disk manager.

Word & Excel for MIPS

Years ago when I’d bought Office 4.2 for Windows NT, it only included i386 & Alpha builds of Word and Excel in the box, and a coupon for MIPS and PowerPC.

About the only thing interesting is that it actually ran under Win32s.

But today looking at term24‘s uploads on archive.org, I saw two CD-ROM images:

I quickly fired up Qemu MIPS NT, and confirmed that both do in fact contain a MIPS version! Excel does have the PowerPC version as well.

As far as I know the only RISC platform to get apps from Office 97 was the Dec Alpha, but at least MIPS users can rejoice now, knowing that they too have been blessed with 32bit Office 4.2 apps!

One of the amazing things about NT & portable apps is that visually, they look identical. So other than me telling you that these are the MIPS native versions, there really is no way to tell.

Well, other than there is no ntvdm running. There is no WOW needed here!

100% native.

I guess the only other question is that since the Word is 1994, and Excel is from 1995, did they have earlier versions for Windows NT? It seems like everything was finally coming together for RISC NT, except the users. Would a release of 64bit Windows 2000 on Dec Alpha save the platform by bringing a strong 64bit platform with integrated JIT i386 WoW built in? (AXP64 Windows 2000 didn’t use !FX32). I guess we’ll never know.

Revisiting Windows NT 4.0 MIPS on QEMU

(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!

[TUHS] 4.4BSD sparc, pmax binary recently compiled

Well this came as a bit of a surprise, but also a great thing!

 I compiled 4.4BSD to get pmax and sparc binary, from CSRG Archive CD-ROM #4
source code.

    http://www.netside.co.jp/~mochid/comp/bsd44-build/

  pmax:
    - Works on GXemul DECstaion(PMAX) emulation.
    - I used binutils 2.6 and gcc 2.7.2.3 taken from Gnu ftp site,
      as 4.4BSD src does not contain pmax support part in as, ld,
      gcc and gdb.
    - Lack of GDB. I got rid of compile errors of gdb 4.16, but that
      does not work yet.
    - gcc included can not deal c++ static constructor. So, contrib/groff
      can not be compiled. Instead, it uses old/{nroff,troff,eqn,tbl..}.

  sparc:
    - Works on sun4c. I use on SPARCstation 2, real hardware.
      TME sun4c emulation can boot to single user, but it locks up in
      middle of /etc/rc.
 
 CSRG Archive CD-ROM #4's source code (just after Lite2 release) seems
have differences from CSRG's binary distributions before (2 times),
e.g. mount systemcall is not compatible.

 I used NetBSD 1.0/sparc, NetBSD 1.1/pmax for 1st (slightly) cross
compiling. NetBSD 1.0/sparc boots and works well on TME emulator.
SunOS 4.1.4, Solaris7 works too, but this 4.4BSD binary doesn't..

-mochid

So this is a heck yes, let me boot this thing up! It’s been a while since I last messed with GXemul, but even this old version runs 4.4BSD!

And yeah it’ll boot up! Exciting.

As mentioned it’s based off the CD #4 from the CSRG set. Really if you are interested in old UNIX, be it BSD or AT&T get this set!

Back of the set aka contents

On the back you can see it’s the last source dump including all the SCCS tags. This plus the extra “historic content” is what you need! Maybe it’s the emulation, maybe it’s the last cut of 4.4 but mounting a CD-ROM just works. So nice. Although the source on the CD isn’t directly buildable. There is some issue with the MIPS locore which needs a patch from mochid, but with the fixes in place it’ll build and run!

Obviously the unanswered question is where is the i386. And that is probably the greatest 90’s software bungle that is either conspiracy to profit or just incredible lack of vision when it comes to platforms. It’s certainly easy to have an off version of reality in University, especially with nice OEM hardware grants to see the world in one light, Just as the Amiga/Atari home computer wars both ignored the vastly inferior PC for it’s laughable beeper, CP/M like OS and woefully inadequate CGA graphics. But the PC was modular and it was an open platform, the industry didn’t have to wait for IBM to make a 32bit PC, instead you had people adding 386DX processors on 286 motherboards complete with 80287 coprocessors, and custom memory controllers to retrofit the memory bus.

CSRG had TAHOE dreams, HP 680000 plans, then SPARC. All the while missing out on the unwashed masses with their 386 and 486 machines. I haven’t tried it, but I bet BSD/OS 1.1 will patch in pretty well for i386. And why would it? Because that was the ticket to the pre pre pre .com bubble of commodity minicomputer UNIX on the desktop. But that blasted 1-800-ITS-UNIX ruined it all, and this ‘hey guys’ project took the UNIX crown.

I’ve been playing with updating the GXemul ‘port’ I did along with integrating SLIRP so I can telnet it. The timing is very shakey and I’m not too happy with it. And I want to redo the disks and sources to be a cleaner ‘merge’ so it just ‘makes’ in the normal places like a native build. If I had crazy people money I’d want to port this to the Loongson-3A4000, but that’d be crazy, instead it’d be more worth my while to try to make an Amiga or Atari ST.

But what do I know, my cellphone runs Mach/BSD!

Minecraft on the loongson-3A4000 / Lemote A1901

It runs!

This was a bit more work than I had anticipated. However flygoat had done much of the legwork for me. The first thing to get is flygoat’s mc-loongson.zip. I made a local download as I suspect many will not have QQ or WeChat (Or don’t want to admit to the government that you are downloading this…).

I’m not sure if it’s a MIPS thing or a UOS thing, but it had Java 11.0.4 in by default, which is CRAZY slow

$ /usr/lib/jvm/java-1.11.0-openjdk-mips64el/bin/java -version
openjdk version "11.0.4" 2019-07-16
OpenJDK Runtime Environment (build 11.0.4+11-post-Debian-1deb10u1)
OpenJDK 64-Bit Zero VM (build 11.0.4+11-post-Debian-1deb10u1, interpreted mode)

I installed version 8, but they are ‘in parallel’ in different directories… I guess it’s the .net hell drift all over again. Although to be fair I’ve only dealt with vendor installed java on Linux where it’s all fixed to single versions.

/usr/lib/jvm/java-1.11.0-openjdk-mips64el/bin/java --module-path /usr/share/openjfx/lib --add-modules=javafx.controls,javafx.fxml,javafx.base,javafx.media,javafx.web,javafx.swing -jar HMCL-3.2.139.jar

One annoying thing is that it cannot find JavaFX over and over despite it being installed, so I had to manually add the ‘module-path’. This is the syntax for version 11, I’m not all that sure on the version 8 syntax.

$ /usr/lib/jvm/java-8-openjdk-mips64el/bin/java -version
openjdk version "1.8.0"
OpenJDK Runtime Environment (Loongson 8.1.3-mips64r2-uos) (build 1.8.0-1.8.0.212-2deepin-b00)
OpenJDK 64-Bit Server VM (build 25.71-b00, mixed mode)

I changed the /etc/alternatives/java to point to version 8, which although causes the launcher to crash launching the actual exe, it’s trivial enough to change it to version 8. Although the command is… unwieldy but save it to a shell script.

I’m sure it won’t paste well, but here we go.. and it’s in my homedir sooo here we go!

/usr/lib/jvm/java-8-openjdk-mips64el/bin/java “-Dminecraft.client.jar=.minecraft/versions/1.15.2/1.15.2.jar” “-Duser.home=null” -XX:+UnlockExperimentalVMOptions -XX:+UseG1GC “-XX:G1NewSizePercent=20” “-XX:G1ReservePercent=20” “-XX:MaxGCPauseMillis=50” “-XX:G1HeapRegionSize=16M” -XX:-UseAdaptiveSizePolicy -XX:-OmitStackTraceInFastThrow -Xmn128m -Xmx7936m “-Dfml.ignoreInvalidMinecraftCertificates=true” “-Dfml.ignorePatchDiscrepancies=true” “-Djava.library.path=/home/neozeed/mc-loongson/.minecraft/versions/1.15.2/1.15.2-natives” “-Dminecraft.launcher.brand=HMCL” “-Dminecraft.launcher.version=3.2.139” -cp /home/neozeed/mc-loongson/.minecraft/libraries/com/mojang/patchy/1.1/patchy-1.1.jar:/home/neozeed/mc-loongson/.minecraft/libraries/oshi-project/oshi-core/1.1/oshi-core-1.1.jar:/home/neozeed/mc-loongson/.minecraft/libraries/net/java/dev/jna/jna/4.4.0/jna-4.4.0.jar:/home/neozeed/mc-loongson/.minecraft/libraries/net/java/dev/jna/platform/3.4.0/platform-3.4.0.jar:/home/neozeed/mc-loongson/.minecraft/libraries/com/ibm/icu/icu4j/66.1/icu4j-66.1.jar:/home/neozeed/mc-loongson/.minecraft/libraries/com/mojang/javabridge/1.0.22/javabridge-1.0.22.jar:/home/neozeed/mc-loongson/.minecraft/libraries/net/sf/jopt-simple/jopt-simple/5.0.3/jopt-simple-5.0.3.jar:/home/neozeed/mc-loongson/.minecraft/libraries/io/netty/netty-all/4.1.25.Final/netty-all-4.1.25.Final.jar:/home/neozeed/mc-loongson/.minecraft/libraries/com/google/guava/guava/21.0/guava-21.0.jar:/home/neozeed/mc-loongson/.minecraft/libraries/org/apache/commons/commons-lang3/3.5/commons-lang3-3.5.jar:/home/neozeed/mc-loongson/.minecraft/libraries/commons-io/commons-io/2.5/commons-io-2.5.jar:/home/neozeed/mc-loongson/.minecraft/libraries/commons-codec/commons-codec/1.10/commons-codec-1.10.jar:/home/neozeed/mc-loongson/.minecraft/libraries/net/java/jinput/jinput/2.0.5/jinput-2.0.5.jar:/home/neozeed/mc-loongson/.minecraft/libraries/net/java/jutils/jutils/1.0.0/jutils-1.0.0.jar:/home/neozeed/mc-loongson/.minecraft/libraries/com/mojang/brigadier/1.0.17/brigadier-1.0.17.jar:/home/neozeed/mc-loongson/.minecraft/libraries/com/mojang/datafixerupper/4.0.26/datafixerupper-4.0.26.jar:/home/neozeed/mc-loongson/.minecraft/libraries/com/google/code/gson/gson/2.8.0/gson-2.8.0.jar:/home/neozeed/mc-loongson/.minecraft/libraries/com/mojang/authlib/1.6.25/authlib-1.6.25.jar:/home/neozeed/mc-loongson/.minecraft/libraries/org/apache/commons/commons-compress/1.8.1/commons-compress-1.8.1.jar:/home/neozeed/mc-loongson/.minecraft/libraries/org/apache/httpcomponents/httpclient/4.3.3/httpclient-4.3.3.jar:/home/neozeed/mc-loongson/.minecraft/libraries/commons-logging/commons-logging/1.1.3/commons-logging-1.1.3.jar:/home/neozeed/mc-loongson/.minecraft/libraries/org/apache/httpcomponents/httpcore/4.3.2/httpcore-4.3.2.jar:/home/neozeed/mc-loongson/.minecraft/libraries/it/unimi/dsi/fastutil/8.2.1/fastutil-8.2.1.jar:/home/neozeed/mc-loongson/.minecraft/libraries/org/apache/logging/log4j/log4j-api/2.8.1/log4j-api-2.8.1.jar:/home/neozeed/mc-loongson/.minecraft/libraries/org/apache/logging/log4j/log4j-core/2.8.1/log4j-core-2.8.1.jar:/home/neozeed/mc-loongson/.minecraft/libraries/org/lwjgl/lwjgl/3.2.2/lwjgl-3.2.2.jar:/home/neozeed/mc-loongson/.minecraft/libraries/org/lwjgl/lwjgl-jemalloc/3.2.2/lwjgl-jemalloc-3.2.2.jar:/home/neozeed/mc-loongson/.minecraft/libraries/org/lwjgl/lwjgl-openal/3.2.2/lwjgl-openal-3.2.2.jar:/home/neozeed/mc-loongson/.minecraft/libraries/org/lwjgl/lwjgl-opengl/3.2.2/lwjgl-opengl-3.2.2.jar:/home/neozeed/mc-loongson/.minecraft/libraries/org/lwjgl/lwjgl-glfw/3.2.2/lwjgl-glfw-3.2.2.jar:/home/neozeed/mc-loongson/.minecraft/libraries/org/lwjgl/lwjgl-stb/3.2.2/lwjgl-stb-3.2.2.jar:/home/neozeed/mc-loongson/.minecraft/libraries/org/lwjgl/lwjgl-tinyfd/3.2.2/lwjgl-tinyfd-3.2.2.jar:/home/neozeed/mc-loongson/.minecraft/libraries/com/mojang/text2speech/1.11.3/text2speech-1.11.3.jar:/home/neozeed/mc-loongson/.minecraft/libraries/com/ibm/icu/icu4j-core-mojang/51.2/icu4j-core-mojang-51.2.jar:/home/neozeed/mc-loongson/.minecraft/libraries/org/lwjgl/lwjgl/3.2.2/lwjgl-3.2.2.jar:/home/neozeed/mc-loongson/.minecraft/libraries/org/lwjgl/lwjgl-jemalloc/3.2.2/lwjgl-jemalloc-3.2.2.jar:/home/neozeed/mc-loongson/.minecraft/libraries/org/lwjgl/lwjgl-openal/3.2.2/lwjgl-openal-3.2.2.jar:/home/neozeed/mc-loongson/.minecraft/libraries/org/lwjgl/lwjgl-opengl/3.2.2/lwjgl-opengl-3.2.2.jar:/home/neozeed/mc-loongson/.minecraft/libraries/org/lwjgl/lwjgl-glfw/3.2.2/lwjgl-glfw-3.2.2.jar:/home/neozeed/mc-loongson/.minecraft/libraries/org/lwjgl/lwjgl-stb/3.2.2/lwjgl-stb-3.2.2.jar:/home/neozeed/mc-loongson/.minecraft/libraries/org/lwjgl/lwjgl-tinyfd/3.2.2/lwjgl-tinyfd-3.2.2.jar:/home/neozeed/mc-loongson/.minecraft/versions/1.15.2/1.15.2.jar “-Djava.library.path=/home/neozeed/mc-loongson/.minecraft/versions/1.15.2/1.15.2-natives” “-Dminecraft.launcher.brand=HMCL” “-Dminecraft.launcher.version=3.2.139” -cp /home/neozeed/mc-loongson/.minecraft/libraries/com/mojang/patchy/1.1/patchy-1.1.jar:/home/neozeed/mc-loongson/.minecraft/libraries/oshi-project/oshi-core/1.1/oshi-core-1.1.jar:/home/neozeed/mc-loongson/.minecraft/libraries/net/java/dev/jna/jna/4.4.0/jna-4.4.0.jar:/home/neozeed/mc-loongson/.minecraft/libraries/net/java/dev/jna/platform/3.4.0/platform-3.4.0.jar:/home/neozeed/mc-loongson/.minecraft/libraries/com/ibm/icu/icu4j/66.1/icu4j-66.1.jar:/home/neozeed/mc-loongson/.minecraft/libraries/com/mojang/javabridge/1.0.22/javabridge-1.0.22.jar:/home/neozeed/mc-loongson/.minecraft/libraries/net/sf/jopt-simple/jopt-simple/5.0.3/jopt-simple-5.0.3.jar:/home/neozeed/mc-loongson/.minecraft/libraries/io/netty/netty-all/4.1.25.Final/netty-all-4.1.25.Final.jar:/home/neozeed/mc-loongson/.minecraft/libraries/com/google/guava/guava/21.0/guava-21.0.jar:/home/neozeed/mc-loongson/.minecraft/libraries/org/apache/commons/commons-lang3/3.5/commons-lang3-3.5.jar:/home/neozeed/mc-loongson/.minecraft/libraries/commons-io/commons-io/2.5/commons-io-2.5.jar:/home/neozeed/mc-loongson/.minecraft/libraries/commons-codec/commons-codec/1.10/commons-codec-1.10.jar:/home/neozeed/mc-loongson/.minecraft/libraries/net/java/jinput/jinput/2.0.5/jinput-2.0.5.jar:/home/neozeed/mc-loongson/.minecraft/libraries/net/java/jutils/jutils/1.0.0/jutils-1.0.0.jar:/home/neozeed/mc-loongson/.minecraft/libraries/com/mojang/brigadier/1.0.17/brigadier-1.0.17.jar:/home/neozeed/mc-loongson/.minecraft/libraries/com/mojang/datafixerupper/4.0.26/datafixerupper-4.0.26.jar:/home/neozeed/mc-loongson/.minecraft/libraries/com/google/code/gson/gson/2.8.0/gson-2.8.0.jar:/home/neozeed/mc-loongson/.minecraft/libraries/com/mojang/authlib/1.6.25/authlib-1.6.25.jar:/home/neozeed/mc-loongson/.minecraft/libraries/org/apache/commons/commons-compress/1.8.1/commons-compress-1.8.1.jar:/home/neozeed/mc-loongson/.minecraft/libraries/org/apache/httpcomponents/httpclient/4.3.3/httpclient-4.3.3.jar:/home/neozeed/mc-loongson/.minecraft/libraries/commons-logging/commons-logging/1.1.3/commons-logging-1.1.3.jar:/home/neozeed/mc-loongson/.minecraft/libraries/org/apache/httpcomponents/httpcore/4.3.2/httpcore-4.3.2.jar:/home/neozeed/mc-loongson/.minecraft/libraries/it/unimi/dsi/fastutil/8.2.1/fastutil-8.2.1.jar:/home/neozeed/mc-loongson/.minecraft/libraries/org/apache/logging/log4j/log4j-api/2.8.1/log4j-api-2.8.1.jar:/home/neozeed/mc-loongson/.minecraft/libraries/org/apache/logging/log4j/log4j-core/2.8.1/log4j-core-2.8.1.jar:/home/neozeed/mc-loongson/.minecraft/libraries/org/lwjgl/lwjgl/3.2.2/lwjgl-3.2.2.jar:/home/neozeed/mc-loongson/.minecraft/libraries/org/lwjgl/lwjgl-jemalloc/3.2.2/lwjgl-jemalloc-3.2.2.jar:/home/neozeed/mc-loongson/.minecraft/libraries/org/lwjgl/lwjgl-openal/3.2.2/lwjgl-openal-3.2.2.jar:/home/neozeed/mc-loongson/.minecraft/libraries/org/lwjgl/lwjgl-opengl/3.2.2/lwjgl-opengl-3.2.2.jar:/home/neozeed/mc-loongson/.minecraft/libraries/org/lwjgl/lwjgl-glfw/3.2.2/lwjgl-glfw-3.2.2.jar:/home/neozeed/mc-loongson/.minecraft/libraries/org/lwjgl/lwjgl-stb/3.2.2/lwjgl-stb-3.2.2.jar:/home/neozeed/mc-loongson/.minecraft/libraries/org/lwjgl/lwjgl-tinyfd/3.2.2/lwjgl-tinyfd-3.2.2.jar:/home/neozeed/mc-loongson/.minecraft/libraries/com/mojang/text2speech/1.11.3/text2speech-1.11.3.jar:/home/neozeed/mc-loongson/.minecraft/libraries/com/ibm/icu/icu4j-core-mojang/51.2/icu4j-core-mojang-51.2.jar:/home/neozeed/mc-loongson/.minecraft/libraries/org/lwjgl/lwjgl/3.2.2/lwjgl-3.2.2.jar:/home/neozeed/mc-loongson/.minecraft/libraries/org/lwjgl/lwjgl-jemalloc/3.2.2/lwjgl-jemalloc-3.2.2.jar:/home/neozeed/mc-loongson/.minecraft/libraries/org/lwjgl/lwjgl-openal/3.2.2/lwjgl-openal-3.2.2.jar:/home/neozeed/mc-loongson/.minecraft/libraries/org/lwjgl/lwjgl-opengl/3.2.2/lwjgl-opengl-3.2.2.jar:/home/neozeed/mc-loongson/.minecraft/libraries/org/lwjgl/lwjgl-glfw/3.2.2/lwjgl-glfw-3.2.2.jar:/home/neozeed/mc-loongson/.minecraft/libraries/org/lwjgl/lwjgl-stb/3.2.2/lwjgl-stb-3.2.2.jar:/home/neozeed/mc-loongson/.minecraft/libraries/org/lwjgl/lwjgl-tinyfd/3.2.2/lwjgl-tinyfd-3.2.2.jar:/home/neozeed/mc-loongson/.minecraft/versions/1.15.2/1.15.2.jar net.minecraft.client.main.Main –username USERNAME –version “HMCL 3.2.139” –gameDir /home/neozeed/mc-loongson/.minecraft –assetsDir /home/neozeed/mc-loongson/.minecraft/assets –assetIndex 1.16 –uuid UUID –accessToken TOOOOKENNNNNN –userType mojang –versionType “HMCL 3.2.139” –width 854 –height 480

Naturally you’ll need your own username, token, uuid..

One thing is for sure, setting the graphics to higher details gives better performance. I suspect that it’s a matter of pushing more of the rendering to hardware, out of software mode.

I have it set to Fabulous! graphics, render distance of 25 chunks, no vysnc, clouds fast, mipmap level 2.

While it does take a while to load up, join the server, and do the initial world loading, you can watch all 4 cores run at 100%, but once it’s loaded in, it’s down to a single core at 100%, and the other 3 are hovering around 10-25%. So once jit’d and loaded in it seems to run okay.

They are jackhammering downstairs and I could make this 1 minute clip in a brief moment of peace. This is before I figured out that the more acceleration you give Minecraft, the faster it runs with the GPU doing the heavy lifting (I think).

Is this the machine for the Minecraft enthusiast? Hardly, but Minecraft is the Java success story, where a platform like this, a fringe non mainstream platform will run a commercial app. This is where the real portability of binutils/gcc/libc and Linux prove to be the winning platform.

Adding a Radeon RX 570

I saw this card while I was out, and I’ve seen mention of some Radeon’s working on the Lemote A1901 board, although it didn’t like my Asus Radeon R9 380 Strix, I’m guessing it’s too old? I can’t find it now, but there was some mention somewhere of someone using a 500 series card (I don’t understand the AMD number schema), so I figured I’d get the 570 as it was just over $100 USD, and it has 8GB of VRAM, so it ought to be somewhat usable if I guessed wrong on the compatibility.

But I did get lucky! The card not only was able to initialize, but UOS came up to the desktop!

glxinfo -B gave the following output:

name of display: :0
display: :0 screen: 0
direct rendering: Yes
Extended renderer info (GLX_MESA_query_renderer):
Vendor: X.Org (0x1002)
Device: Radeon RX 570 Series (POLARIS10, DRM 3.27.0, 4.19.0-loongson-3-desktop, LLVM 7.0.1) (0x67df)
Version: 18.3.6
Accelerated: yes
Video memory: 8192MB
Unified memory: no
Preferred profile: core (0x1)
Max core profile version: 4.5
Max compat profile version: 4.5
Max GLES1 profile version: 1.1
Max GLES[23] profile version: 3.2

So there we go, 8GB of memory, and ‘Accelerated: yes’. It’s also FPS locked to the screen refresh so it’s running a steady 60fps for the display I’m using. I need to build some later games that use GL to really push the machine.

The one big ‘negative’ is that the video card sits over the SATA ports, so I need to get an L connector SATA cable, as now I can’t use my 2TB spinning rust disk with the fancy GPU in place. And it makes my 800 watt PSU all the more justified.

I’m just glad that the portable drivers, well are portable!

Adding a 32bit runtime to UOS

AKA what happens when your OS is from one Debian like distribution and lags behind the rest of the world, but you want to run a parallel infastructure. Obviously for people who have sane setups their stuff is in sync and this doesn’t apply.

HOWEVER for people who use USO they will find out quickly that it’s a Debian derived MIPS64EL based distribution, but they don’t keep any MIPSEL (32bit) binaries. So I was thinking add in the dpkg arch, and some deb sources and I’d be good to go, right? Except the stuff is out of step so what happens is that UOS decides it wants to replace the OS with what is on the mipsel repos. Even when specfiying the arch’s directly.

deb [by-hash=force arch=mips64el] https://professional-packages.chinauos.com/desktop-professional eagle main contrib non-free
deb [arch=mipsel] http://deb.debian.org/debian buster main contrib non-free

I tried.

So the good news is that I asked around and found a solution that I’d never heard of, “debootstrap”. The general page is here:

What it boils down to is that it’s a script set that will download enough DEB’s and extract them onto a directory and prep it out as a chroot/jail. And you can specify whatever architecture you want, you can even use qemu to run totally alien stuff! I’d never heard of this before, such a shame.

From my rough notes I did something like this:

/usr/sbin/debootstrap --arch mipsel buster /usr/local/mipsel http://deb.debian.org/debian

This will install the mipsel platform of Buster into /usr/local/mipsel

running the following gets me into the chroot/jail/container..

LANG=C.UTF-8 sudo chroot /usr/local/mipsel /bin/bash

YES it’s that simple! Although there is some house cleaning to be done:

apt install makedev
mount none /proc -t proc
cd /dev
MAKEDEV generic

Making the devices sure took long enough, but now I could do the regular update, add in some compilers and stuff, X11, and whatnot and get things going. Remember to mess around with xauth to get X11 forwarding from chroot working

Now for the ‘fun’ part of linking the libs…

ln -fs /usr/local/mipsel/usr/lib/mipsel-linux-gnu /usr/lib32
ln -fs /usr/lib32/ld.so.1 /lib/ld.so.1

Then you need to ‘config’ ld.config with

cat > /etc/ld.so.conf.d/mipsel-buildroot.conf
/usr/local/mipsel/usr/lib/mipsel-linux-gnu
^D

Phew we are almost there!

$ file /usr/local/mipsel/bin/dash
/usr/local/mipsel/bin/dash: ELF 32-bit LSB shared object, MIPS, MIPS32 rel2 version 1 (SYSV), dynamically linked, interpreter /lib/ld.so.1, for GNU/Linux 3.2.0, BuildID[sha1]=22877e3a9a83675b22a121c9d2f8943d7339e7db, stripped
$ sudo ldconfig;/usr/local/mipsel/bin/dash
$

And just like that we now can run dynamically linked 32bit MIPSEL binaries on UOS.

As a bonus (from stackexcahnge) here is how to run Xauth to get forwarding from the chroot. From the ‘base’ physical machine run:

$ xauth list
latitude/unix:0  MIT-MAGIC-COOKIE-1  d4474d13c

Now with that cookie run this in the chroot:

# xauth add latitude/unix:0 MIT-MAGIC-COOKIE-1 d4474d13c
# xclock

and the 32bit Xclock should pop up on your 64bit desktop.

Wasn’t that fun?!

Annoyance with the MIPS linker: relocation overflows

gcc disasm.o audio.o configuration.o dialog.o file.o hostcall.o keymap.o main.o memAlloc.o misc.o screen.o screenConvert.o sdlgui.o shortcut.o scalebit.o input.o fe2.o ../fe2.part1.o ../fe2.part2.o -L/usr/lib/mips64el-linux-gnuabi64 -lSDL -o ../frontier

/usr/bin/ld: ../fe2.part1.o: in function <code>load_binfile': fe2.s.c:(.text+0x180): relocation truncated to fit: R_MIPS_CALL16 against</code>fopen@@GLIBC_2.2'
/usr/bin/ld: fe2.s.c:(.text+0x19c): relocation truncated to fit: R_MIPS_CALL16 against <code>fseek@@GLIBC_2.0' /usr/bin/ld: fe2.s.c:(.text+0x1a8): relocation truncated to fit: R_MIPS_CALL16 against</code>ftell@@GLIBC_2.0'
/usr/bin/ld: fe2.s.c:(.text+0x1c0): relocation truncated to fit: R_MIPS_CALL16 against <code>fseek@@GLIBC_2.0' /usr/bin/ld: fe2.s.c:(.text+0x1e4): relocation truncated to fit: R_MIPS_CALL16 against</code>fread@@GLIBC_2.0'
/usr/bin/ld: fe2.s.c:(.text+0x1f0): relocation truncated to fit: R_MIPS_CALL16 against <code>fclose@@GLIBC_2.2' /usr/bin/ld: fe2.s.c:(.text+0x280): relocation truncated to fit: R_MIPS_GOT_DISP against</code>stderr@@GLIBC_2.0'
/usr/bin/ld: fe2.s.c:(.text+0x284): relocation truncated to fit: R_MIPS_CALL16 against <code>fprintf@@GLIBC_2.0' /usr/bin/ld: fe2.s.c:(.text+0x290): relocation truncated to fit: R_MIPS_CALL16 against</code>exit@@GLIBC_2.0'
/usr/bin/ld: fe2.s.c:(.text+0x2b4): relocation truncated to fit: R_MIPS_CALL16 against `__assert_fail@@GLIBC_2.0'
/usr/bin/ld: fe2.s.c:(.text+0x2c4): additional relocation overflows omitted from the output
collect2: error: ld returned 1 exit status
make[1]: *** [Makefile:18: ../frontier] Error 1

I’d never heard or seen this before, and yeah it’s some MIPS’isim.

Apparently it’s something called a “global offset table” which of course has a 64k entery limit which can cause an overflow if you are doing something crazy like running a disassembler and having tens of thousands of instructions.

Looking at the GCC MIPS options page, there is hope, one can opt for a more iniffecient and larger table with the simple option of -mxgot

FrontVM-2 20061120

And now I can link frontvm.