GXemul for Win32

Luna m88k booted off RAM disk

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.

For the crazy among us, go ahead and try gxemul-0.6.2-ultra-primative.zip The name says just how stable it is.

In the meantime here is a super low resolution capture of the screensaver from a Luna via http://www.nk-home.net/~aoyama/luna88k/

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.

21 thoughts on “GXemul for Win32

  1. GXemul should run be able to Ultrix and OSF/1 1.0 fine, at least older versions did. I have some quite old win32 builds made with cygwin+Xming back in 2007, and a slightly newer 0.6.0.1 from last year. I did look at the old images I have and my OSF/1 is Rev 166, or that’s a rebuilt kernel from the install versus what’s on the cd, dunno, been so long!

    • Even if you can share a disk image that’d be fantastic…

      I need to look at the X11 code to see how easy it is to port to SDL… No Cygwin stuff, pure Win32!

      • Yeah I figured you wouldn’t be using cygwin. 😉 Didn’t matter to me back but as at least I could use it, there were mouse issues with X though in some versions. Uploaded my old disk image and some screenshots here.
        http://www.shawnnovak.com/stuff/osf1/

        Also I had forgotten that I did put my cygwin builds on my ftp at some point: ftp://ftp.muleslow.net/ultrix/gxemul/

        They’re old, use cygwin, but they work if you need something to pry at. Thinking back I seem to remember there may have been issues running OSF/1 in the 0.4.x versions and that may have been why I kept older versions around, but it boots in my 0.6.0.1 build.

        • AWESOME! super thanks! I’ve just had so many stack smashing issues with cygwin where it’ll fork bomb and other weird stuff so I’ve kept it at arms length or in a VM. It was also why I did the MinGW build of dynamips.

          I think going through some notes that gxemu 0.3 emulated the MIPS processor cache more accurate (or at all?) allowing more things to install. I uh ‘found’ the source to OS/F 1.0 and figured it may be fun to see if I can self host, and more importantly amputate stuff like cache interactions or just force a report of 0kb sized stuff to see if it’ll run more consistent.

          That and it’ll be interesting to see if my build, or the Linux build of 0.6.2 works at all.

          Also from reading stuff it seems that many ‘newer’ compilers are optimizing stuff out that breaks things in mysterious ways (like setting the boot devices…) I’m not sure if it’s an -O1 vs -O3 thing, or if something like -Os is the way to go, as smaller is better anyways.

          • Yeah there’s always issues with cygwin, had to rebase everything last time I need to use these as well. Seems like it was somewhat better a decade ago….. I had set up an old archive of cygwin to build the newer version last year and there were some issues with cygwin and versions past 0.6.0.1 which is why that’s the version I built instead of the latest.

            It’s possible this OSF/1 image wasn’t a complete install, I think there was a patch level that I skipped and that could have messed some cleanup stuff up, but again it’s too long to remember the exact details. I’d be happy to try making a new installation and seeing if it does anything different.

          • Yeah the rebasing wars is what led me to see if I could actually build native versions of some stuff. I use dynamips a bunch and being able to kick Cygwin was massive. Shame I did it so late in the game that basically nobody cares.

            Gxemul was a wild guess if it’d work, but the wiki page says it’s CPU emulation is in a CPU independent manner so it was worth the test.

            Things like man pages are certainly missing from the OS/F image, although the dynamic linker is certainly working. I uh ‘found’ source to 1.0 and looking at the kernel there really isn’t much of any changes from the CSRG dump.

            The i386 code is the same that I have, with the exact same bug in setting cr registers in the wrong order.

        • Thanks! I forced it to boot single user (change the scsi ID to 1..) and just changed it so that xdm doesn’t spawn in the inittab, and allow getty on the console. So yeah it’s up and running!… with all these weird .new…* files.. I thought post install it would have killed them.

          But super cool!

  2. Wow this is wild! Awesome. I remember running Ultrix on GXemul years ago but it was somehow difficult.

    Can has someone build Mosaic for it and make some screenshots with WRP?

  3. Neo, would you check the GXemul SGI O2 SCSI emulation? Its the only thing left to have a 100% emulated SGI Machine I guess.
    🙂

    • Yes I have been following that, but it only emulates an SGI Indy, and its slow as a sloth.
      GXEmul has much better performance and emulates the O2 machine

  4. In 2009 I was messing around with GXEmul on Windows (back when it was a pure-C project) via Cygwin initially, and then started working on a minimal patch to get it to build and run using MSVC. I got it far enough along that it would boot a PMAX and output graphics to a window (all graphics done through GDI). I don’t think the keyboard was hooked up so it was simply a demo.

    A couple of years later I revisited it, refining the patches so that the project had a clear graphics interop layer that had implementations for both Windows and Unix. Some anecdotes: Originally I rewrote the shell scripts in perl, but later decided it was simpler to write a simple shell emulator in perl and invoke that instead. Also, the build times were very slow in Windows because of all the processes launched so I switched some code in the makefiles to use awk to cut the build times in half.

    In the end, I got interested in other things and never completed the project, but I still have my patches lying around if there’s interest in looking them over to see if there’s anything of interest to your efforts.

    • Sure! There is a lot of drift in gxemul, so newer doesn’t mean better..

      Just as my crap is like a ‘omg it linked!’ bare effort. I’m surprised it runs anything to be honest, but that isn’t the result of my work.. I’m just a monkey banging a keyboard lol

      • Yeah, it’s an interesting system! Getting anything modern to compile for it has been a struggle though 😀 GCC 3 requires perl, which doesn’t want to compile. Bash causes the ancient MIPS c compiler to dump core… I think I’ll with GCC 2.7 first, I read somewhere that that will work…
        I’ll also have to see if I can get the serial console to work, it would free up memory to run without X.

        • Use these, fellow OSF/1 afficionado:

          This is perl 5, version 32, subversion 0 (v5.32.0) built for mips-mips_osf1

          Reading specs from /usr/local/gcc-3.0.4/lib/gcc-lib/mips-dec-osf2/3.0.4/specs
          Configured with: ../gcc-3.0.4/configure –prefix=/usr/local/gcc-3.0.4 –enable-languages=c,c++,f77 : (reconfigured)

          Later versions are off the table.

          Other GCC versions from the working variety: egcs-1.1.2, gcc-2.8.1, gcc-2.95.3

          And both binutils-2.9.1 and binutils-2.10.1 suck, as noted.

          By all means disable X: set XLOGIN to “false” or anything, and start an xterm script from inittab with for example DISPLAY=192.168.1.198:1

          Then redirect port localhost 6001 to wherever with whatever (ssh/redir.tgz, etc)

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.