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.
(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:
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!
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.
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.
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!
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.
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!
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.
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
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
While discussing various non x86 boards the topic came up about the Chinese government MIPS based processors, namely the Loongson-3A4000. I’ve tried several times on the past to buy one with no success however 2020 would make up with it as 2 separate leads yielded boards.
To me, there is a great deal of confusion around this setup as it goes by different names, and is sometimes spelt in English, other times Chinese (Simplified & Traditional) with different part numbers and vendors making it kind of confusing.
Various names include, but not limited to:
Lemote loongson
loongson-3-desktop
LEMOTE-LS3A4000-7A1000-1w-V01-pc
ICT Loongson-3A R4(loongson-3A4000)
Lemote LX-6901
Lemote A1901
龙芯3A4000+7Aå°å¼æœºä¸»æ¿
I don’t want to sound like I’m going to just shit all over this thing, but it’s not free, it’s not subsided, and it’s not cheap. Weighing in at 元3,500 RMB the LX-6901 is not a machine for the masses, however it is a non x86 machine for the classes.
Thanks to my day job I was able to get my buyer to trace down several companies, and ads placed on TaoBao and another from AliExpress. Last time I tried both routes, along with the board manufacter Lemote, I was unable to get anything. This time however both leads would work out so now I have 2.
I was told that it would take upwards of 2 weeks for the order(s) to be fulfilled and I should have them in 3 weeks. However 4 business days later this box arrived in my office:
presents from the orient
I suspect they need to temper people’s expectations on shipping, but luckily for me I’m not over seas, although shipping from China to Hong Kong does require a special permit for electronics.
Clearly the tape had been opened several times for various inspections as this shipment was destined to be exported. But props on the dragon tape!
As expected, two boards! Oddly and confusing enough both suppliers insist the boards are different.
Natrually, they are of course identical.
Here is a better glimpse at the board.
The Lemote LX-6901 is not without faults however, it has a memory controller issue and cannot operate correctly with 2 sticks of ram. Luckily my DDR4 extras are 16gb so it’s not bad for messing around. The board also can post ATI boards. However it doesn’t like my Asus Radeon R9 380 Strix board, although it posted fine. I have a few of the FirePro W2100 cards, not a remarkable card, but it does work.
In addition you do need a specific OS for the board, on vendor on AliExpress was unwilling to send me anything, while another on TaoBao was willing to send me UnionTech’s UOS.
System BIOS
the M.2 slot works fine and I was able to boot from USB, and install UOS. The BIOS is very ‘PC’ like, pressing ENTER will enter the bios, and you can change boot priorities, or drop to the UEFI shell if you so please.
BIOS initalization
Installation is pretty easy and straight forward. There is only a few options during install, the desination, if you should accept the default layout (why not)? and a language
The USB stick is slow, but it didn’t matter as I only needed to install twice. The first time I had both memory slots populated, and the board crashed at 5% of the install. I was able to do some searching around and found out about the bad memory controller, so popping out one of the DIMMs and I was able to install and use the machine.
UOS for the MIPS however is a seeming commercial product that is very difficult to buy outside of China (it may very well be allocated only for certain circles as you need a Chinese cellphone number, government ID, and some kind of project id?), although I’m still trying.
Not authorized
The phone support was useless, and I’ve had a few email exchanges on asking if it’s available for purchase, and if so how much. I’ll update if I can figure it out.
What does suck is that while UOS is not authorized you can’t get any OS updates, nor can you enable to root user. So yeah you can’t effectively own the machine with UOS. There is a ‘trial’ mode to enable a 90 day ‘grace’ period so at least I can add GCC and at least build software. Clearly if I can’t sort out UOS I’ll have to dump the kernel / initrd and restore another MIPS64EL Linux distro over the filesystem. Debian has MIPS64EL, and seems to be working to mainline the LX-6901.
UOS bills itself as a Windows replacement, and I have to say that I do enjoy using it. It has some rather ‘Windows’ qualities to it, like the sound mixer, and ease of installing apps from the ‘store’ however if it’s not in the store and it’s Not authorized you are out of luck. As much as I dislike distro of the week nonsense, I do like the idea of thousands of people being hired to flesh it out to make Linux usable, but only time will tell how much of it is translation to Chinese, and how much is developing software.
When it comes to performance the 3A4000 running at 1.8Ghz is faster than a Raspberry Pi 4, however not significantly faster CPU wise. However the big plus the MIPS does have is that it has a far more capable bus with M.2 and PCI-E slots along with SATA giving the board much better IO than any SOC solution like the Pis.
I built the BYTE Benchmark 5.1.3 and did this graph with data from running on a Zero for comparison. I had to adjust scales for some of this so its more visible, however the important data is here that CPU wise they are close together, but in the area of IO the Dragon pulls far ahead. For those who like the Linux boot score, the CPU ‘clocks’ in at 3594.02 BogoMIPS per core.
It’s been a large ‘discovery’ thing, and a long time since I’ve tried to make Linux a ‘daily driver’ and of course the scarcity of MIPS binaries on Linux is going to be an issue, but I’ll have to explore the apparent ARM/x86 compatibility as I can find more information about it.
Since this has been such a learning curve for me as I learn more things I’ll add them to this list:
Don’t get all to excited, it’s a terrible port, but it’s to the point where it can barely run stuff. Although I don’t know how much is me, and how much is GXemul. I probably should have tested on Linux first.
Anyways it’s enough to boot the Luna m88k OpenBSD ram disk up to the single user mode, and poke around. The hard disk doesn’t pick up, and I haven’t even tried the NIC, although the address is looking pretty bogus.
I wanted to try the PMAX version of Mach, but then it hit me, that there is no server to load. And porting the system level from Mach 3.0 to 2.5 looks way more involved than Mach 3.0 being ‘something minor’.
Back on the 88k front, the Luna shipped with something called UniOS-Mach, but good luck finding that in this day & age. I guess I’ll have to go back to Japan.
As an update, I added in the timer code from PCemu, and now that the timers appear to be firing some stuff like OS/F 1.0 get’s further!
OS/F 1.0 in single user mode
I need to go through the setup stuff a lot better as this is just untar’d and not setup at all. Not that it’s useful, but here, osf1-barely.7z .
So if anyone downloaded gxemul prior to this update, re-download it again! I put the m88k ramdisk kernel in there too so you can quickly test the Luna 88k emulation.
