EMX 0.9d rehosted on Win32

EMX on Win32

I know it’s utterly pointless… But yeah GCC 2.8.1 + EMX 0.9d, hosted (running) on Win32.  The main reason is that I wanted to be able use use my substantially faster Win64 machines to build stuff for OS/2.  And since I have a 4 core (+4 hyper thread), I want to be able to use make with the -j 16 flag, and say compile QuakeWorld/2 in under two seconds.

I was able to get the binutils 2.6 derived stuff to compile, along with the ‘ancient’ binutils which is notably the linker that EMX depends on.  I would imagine this ought to be able to compile PDOS, although my own simple attempt at InfoTaskForce met with spectacular failure.  While it does compile fine using an older EMX 0.8h based release.

EMX 0.9d on Windows 10 x64

EMX 0.9d on Windows 10 x64

As you can see, it can compile the dhyrstone benchmark, and run the MS-DOS version via the MS-DOS Player.


System 16

A long long time ago, back when I got a Pentium 100 the wonderful world of emulation was really starting to be possible with such a high powered CPU.  First was the simple Game Boy emulators, then a Commodore 64 emulator, the incredible Amiga Emulator, the beginnings of SIMH (back when it was only a PDP-11 emulator), and then I found the SEGA emulator, System 16.

It was really cool being able to play 16bit arcade games on the desktop, although rather slowly.  From there everyone knows the rise of MAME.  But while looking around for a small 68000 C compiler, I came across the source code to an older version of System 16, 0.53 on archive.org.  Naturally it’s for MS-DOS, as was everything back in the day.  Also slightly interesting is the 68000 emulation, written by Bernd Schmitd of UAE fame.  So for the heck of it, I set about getting Thierry Lescot’s System 16 building again.  I’ve never used allegro before, so it was a bit of a fight to get a version of it to actually build.  It turns out that I should have been building version 2.11 with tools of that era (why on earth was I using GCC 4, and binutils 2.18?) and instead stick with GCC and some much older binutils.  And in no time I had build the library, and it’s examples.  With that done, I was able to re-build System 16 with GCC 4.1.2 and get a binary!

Back in the day, I actually did have an Altered Beast arcade board.  Sadly it died in a move, someone near and dear just saw the PCB as “garbage” and tossed it.  Sigh, but I did have ROM dumps, as I did a refresh of it forever ago.  Anyways I still have the ROM files, so I guess that is nice.

Anyways I fired up the emulator and got what is known as the “jail bar” effect, which is from a bad ROM.

Corrupt tiles

Corrupt tiles

Notice the sprites

Notice the sprites

The System 16 splits it’s memory into a program space, a sprite memory bank, a tile memory bank, and RAM for stack and things like the palette.  As you can see the program is certainly running, and the sprites are good.  I did some poking around a bit later, and noticed that due to a logic bug, the texture ROMs are actually never loaded!

So a quick patch, and now we get Altered Beast up and running!

Altered Beast title screen

Altered Beast title screen

demo play

demo play

Well, now isn’t that great!

Not that I would imagine anyone would really care, I mean MAME is a thing, and even from the readme:

Altered Beast : No sound emulation

So it’s pretty quiet.  Additionally the source is pretty restrictive:

These sources can’t be used for commercial purpose, any new version of the
emulator done with these sources must specify my name somewhere on the screen
et docs and I must be informed about any new release of the emulator.

For anyone interested you can find the source & binaries out on sourceforge.

Craziest cross compile yet!

Windows 10 to target Linux 0.11!

It works!

It works!

Sadly that ancient line program only runs ELF binaries, so that won’t work to test.

As I mentioned gcc doesn’t work. I need to tear more into DJGPP
to see how they did it or just use it’s gcc driver to run this.

In the test directory I’ve mimic’d what a Linux 0.11 install does when compiling
a single file into an exe.

simply run:

c_ hello

and it’ll compile hello.c into hello.

C:\aoutgcc>..\bin\cpp -v -I../include-0.12 -undef -D__GNUC__ -Dunix -Di386 -Dlinux -D__unix__ -D__i386__ -D__linux__ hello.c C:\Users\neozeed\AppData\Local\Temp\001.cpp
GNU CPP version 1.40

C:\aoutgcc>..\bin\cc1 C:\Users\neozeed\AppData\Local\Temp\001.cpp -quiet -dumpbase hello.c -version -o C:\Users\neozeed\AppData\Local\Temp\001.s
GNU C version 1.40 (80386, BSD syntax) compiled by GNU C version 5.1.0.
default target switches: -m80387

C:\aoutgcc>..\bin\a386 -o hello.o C:\Users\neozeed\AppData\Local\Temp\001.s

C:\aoutgcc>..\bin\ld -o hello ../lib/crt0.o hello.o ../lib/libc.a

Wasn’t that fun?

The ‘best’ way I can think of to test is to tar the exe like this:

C:\aoutgcc>..\bin\tar.exe hello.tar hello

And then run it with the Linux 0.11 on Qemu which can be found here:


qemu -L pc-bios -hda linux-0.11-devel-060625.qcow2 -no-reboot -m 16 -k en-us -fda hello.tar

Then once Linux boots, do this:

tar -xvf /dev/fd0
chmod +x hello


For anyone who wants to play at home, here is the complete sources, and binaries.

Stupid error building binutils

So I’m starting a new VM, and after installing Debian, and the important packages, build-essential and the Linux headers…

#  apt-get install build-essential linux-headers-$(uname -r)

I got this fine error trying to build binutils:

gcc -g -O2 -o sysinfo sysinfo.o syslex.o
syslex.o: In function `main’:
/usr/src/binutils-build/syslex.c:1: multiple definition of `main’
sysinfo.o:/usr/src/binutils-2.22-human68k/sysinfo.c:1: first defined here
collect2: ld returned 1 exit status

Turns out I didn’t have bison/flex installed.  Oops!

Oh well easy enough to solve.

#apt-get install bison flex

Otherwise, remember to build binutils/gcc in it’s own directory or that’ll cause other fun down the line.

Don’t forget you need GMP 4.2+, MPFR 2.3.1+ and MPC 0.8.0+ to build GCC…

#  apt-get install libgmp-dev libmpfr-dev libmpc-dev


Antoni sent me a link to this project, AmiDevCpp. It is a nice little wrapped up IDE for cross compiling applications for the following platforms:

  • AmigaOS (m68k)
  • AmigaOS4 (PPC)
  • MorphOS(PPC)
  • AROS (i386, ppc and x86_64).

Naturally it doesn’t work correctly on Wine.. .Oh well, but for you Windows users out there that haven’t installed Cygwin this is an easy way to cross build stuff for the ancient Amiga platform.

Apparently he was able to rebulid the infamous aclock using this cross compiler…

xv6 revisited…

I was hoping to do more with this, but things are going other ways in life.  Anyways a while back I had touched on xv6, a MIT teaching tool and semiport of Unix v6 to the i386!  The best part about it, is that it is SMALL…

I’ve been playing with it the last day on the latest version of Qemu and hit a snag with its SMP support (yes it does have that!) so I played with it, and couldn’t figure it out so I had to turn it off.. It is something ACPI related, and probably along the reason why Windows x64 doesn’t run on new Qemu either..

I’ve built the cross compiling environment needed (A bare elf compiler/linker/assembler) and managed to smash enough of it into a single directory that you won’t need MinGW installed, but can rather invoke ‘build.bat’ which will compile link, dd the disk image, and launch Qemu.

I’ve had trouble with mkfs so… you’ll have to live with a prebuilt root image.

If you want to build your own cross compiling toolchain, there is a good guide here on the OSWiki.  Naturally you’ll want my previous post on some snags I ran into on MinGW if you do choose that as your target environment.

What I’d love to do is port newlib, and see just how useful this xv6 could become..  I would imagine adding signals (well beyond kill) may allow things like bash 1.x to run, and maybe gcc itself.. Which would be cool.

You can download my work here.  Check it out, it’s cool!