26th anniversary of Linux!

As the joke goes:

Happy 25th birthday, Linux! Here’s your f-ing cake, go ahead and compile it yourself.

So it’s always a fun time for me to push my old project Ancient Linux on Windows.  And what makes this so special?  Well it’s a cross compiler for the ancient Linux kernels, along with source to the kernels so you can easily edit, compile and run early Linux from Windows!

As always the kernels I have built and done super basic testing on are:

  • linux-0.10
  • linux-0.11
  • linux-0.12
  • linux-0.95c+
  • linux-0.96c
  • linux-0.97.6
  • linux-0.98.6

All of these are a.out kernels, like things were back in the old days.  You can edit stuff in notepad if you so wish, or any other editor.  A MSYS environment is included, so you can just type in ‘make’ and a kernel can be built, and it also can be tested in the included Qemu.  I’ve updated a few things, first with better environment variables, and only tested on Windows 10.  Although building a standalone linux EXE still requires a bit of work, it isn’t my goal here as this whole thing is instead geared around building kernels from source.  I included bison in this build, so more of GCC is generated on the host.  Not that I think it matters too much, although it ended up being an issue doing DooM on GCC 1.39.

So for people who want to relive the good old bad days of Linux, and want to do so from the comfort of Windows, this is your chance!


Download Ancient Linux on Windows
Download Ancient Linux on Windows

Null DooM, GCC 1.39, GO32 and DPMI


phew.

DooM via DJGPP v1 GO32

Around the time of the x68000 port of DooM, I was cutting down the DooM source for a null/portable version.  I never could get it to actually run either using EMX or  DJGPP 1.03, as I couldn’t get it to link to save my life with a constant never ending battle of unresolved symbols. After a while I just used what I had towards the x68000 version and concentrated on getting it up and running, and just shelved the null/portable effort.

Later on I wanted to get it running again as part of messing with another cross compiler, as DooM isn’t a trivial application to port and verify correct operation. And in the process of trying to get the null version to build and run on Windows using TDM GCC, I wanted to make sure it at least kept compiling with GCC v1.x.

Once more again I was able to compile individual files but unable to link.  But this time, I just looked at the diffs for binutils, I thought it should be somewhat easy to get hosted on Windows.  Although versions may point to binutils 1.0, I had to use binutils-1.9.tar.gz even though the diffs are against Mar 24 1991, and the source for 1.9 is dated April 17 1991.

My first effort gave me a linker that would happily link, but go32 would either refuse to run the executable, or just crash.  I was going to give up again, but I found mention in another file that DJGPP actually uses the linker from G++, the C++ compiler which was a separate thing in the late ’80s and early’90’s.  This time it worked, and I could link a trivial hello world style application!

Now that I finally had a cross linker actually working, I didn’t want to compile under emulation, so looking at the other diffs, they didn’t look too extensive. I went ahead ,and took DJGPP v1.06 and patched up the compiler & assembler to get a full cross toolchain.  And in no time, I had a null version of DooM running on MS-DOS well at least tested on DOSBox.

This was fun, and all but I didn’t see any easy way to do fun things like hook interrupts so I could get the keyboard & clock like any good MS-DOS program.  DPMI greatly eased this kind of stuff, so looking at the DJGPP history, DJGPP v1 version 1.10 actually adds preliminary DPMI support!  And in the next version, DPMI was much more better supported, however the binary format had changed from a.out to COFF as part of the move to v1.11. I was able to take the memory, and DPMI portions from the final v1.12 libc, and manually build and run them against the v1.06 library / dev tools.

And much to my surprise, it actually worked!  At least having the wrong format didn’t have any effect on how GO32 worked for me.

So feeling lazy, I snagged some of the support code from Maraakate’s revamp of DooM, just to make sure of the timer code, and the keyboard code, and again verified that I can build with the keyboard & timer ISR and I’m able to play the v1.9 shareware & commercial levels fine.  I haven’t done a thing to clean up or update the DooM source itself against all the dozens of bugs and issues with Ultimate DooM, or other games like Chex Quest etc.

I’m sure 99% of people wouldn’t care but you can download it here:

Win32_DJGPPv1_DooM.7z
Download crossdjgppv1

Although I’m using DPMI to drive realtime events, if I looked further at the GO32 v1.06 environments I could either figure out how it operates it’s timer, or modify the extender directly to drive the PIC timer and keyboard as I need.  But overlooking that, the vintage 1991 software is more than capable of running DooM.

Found some more ancient GNU software

I found a bunch of them here: ftp://ftp.ne.jp

CVS brows of the following:

I didn’t know that GNUmake 2.9 and prior was actually part of binutils.  I guess at some point I’ll build the older ones on 4.2 BSD to round out the experience.

And I don’t know where to find Emacs 18.41 and going further back.  Although I did find emacs1855.taz a DECUS (Digital Equipment Computer Users’ Society) image from late 1989.

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.

Downloads

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 2.7.2.2 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-12.5.i386.zip

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
./hello

Fun?!

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

AmiDevCpp

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!