Mariko’s x68000 GCC 1.42 on Windows

Yes, I probably need a better hobby.


D:\proj\142\gcc-1.42_x68000>gccnew.exe -v -c x.c
gcc version 1.30 Tool#2(X680x0)
hcpp.exe -v -undef -D__GNUC__ -Dmc68000 -Dhuman68k -DHUMAN68K -DMARIKO_CC -Dmariko_cc -D__mc68000__ -D__human68k__ -D__HUMAN68K__ -D__MARIKO_CC__ -D__mariko_cc__ x.c C:\Users\jason\AppData\Local\Temp\x.cpp
GNU CPP version 1.30 Tool#2(X680x0)
hcc1.exe C:\Users\jason\AppData\Local\Temp\x.cpp -quiet -dumpbase x.c -fhuman -version -o C:\Users\jason\AppData\Local\Temp\x.s
GNU C version 1.30 Tool#2(X680x0) (HAS Ver 3.XX syntax)
compiled by GNU C version 5.1.0.
default target switches:
x.c: 5: Message:ì┼ôKë╗é═ìséφéΩé─éóé▄é╣é±
run68 has.x -e -w -u -i . C:\Users\jason\AppData\Local\Temp\x.s -o x.o
D:\proj\142\gcc-1.42_x68000>run68 ..\hlkb\hlk301.x x.o CLIB.L
D:\proj\142\gcc-1.42_x68000>run68 x
Hello x68000 from GCC 1.30 Tool#2(X680x0)!

Microsoft Windows [Version 10.0.10586]

I’ve gotten the compiler to build natively as a win32, however the assembler & linker are x68000 programs that I run via run68.  libgcc.a is missing so there is no floating point support at all.  I have to figure out how to generate it.  Right now it’s using the SHARP/Hudson libraries on the C Compiler PRO-68K ver2.1 disks.

I don’t think this will be of value to anyone, but for the hell of it, you can download my incredibly rough port here.


Linking doesn’t work by default, so you have to manually link, as what I did above.

Linux 0.01 remake

While further searching around on Linux 0.01, I came across DrAcOnUx’s site which features a Linux 0.01 remake!

It’s really great, first off there are several versions in the steps of the evolution of the project:

Linux-0.01-1.x :
– need gcc 1.4
– few change from official linux-0.01, only some bug fix, + minor change to build it in a linux system instead of minix

Linux-0.01-2.x :
– same version as linux-0.01-1.7, which was just ported to work with gcc-2.x and gcc-3.x

linux-0.01-3.x :
– this is the last version
– need gcc-4.x
– use elf binary format instead of a.out, and you have some program working on it

As I actually do have a working GCC 1.40 + Binutils I though it would be great to build his first phase on Windows.  With a little playing around in the makefiles, and the build program to open files in binary mode, I had a kernel!

Linux 0.01 remake

Linux 0.01 remake

Obviously there is issues with the executables that I have from Linux 0.10/Linux 0.11.  But we are mounting the disk, and using the /dev tree devices.  I put the remake versions on my cvsweb to walk though what changed.

Using an older ‘modern’ Linux machine with GCC 4.1 I was able to compile the remake #3 kernel, and even better with the provided disk image from the downloads page it works!

# gcc -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v –enable-languages=c,c++,fortran,objc,obj-c++,treelang –prefix=/usr –enable-shared –with-system-zlib –libexecdir=/usr/lib –without-included-gettext –enable-threads=posix –enable-nls –program-suffix=-4.1 –enable-__cxa_atexit –enable-clocale=gnu –enable-libstdcxx-debug –enable-mpfr –with-tune=i686 –enable-checking=release i486-linux-gnu
Thread model: posix
gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)

Linux 0.01 remake #3

Linux 0.01 remake #3

For any aspiring software historians out there, this early version of Linux from September of 1991 will be of course VERY interesting!

Linux 0.01 on Qemu!

Well sort of.

Linux 0.01!

Linux 0.01!

I looked at the source again, and for some reason 99% of it compiled without issue.  I recall having all kinds of issues, but clearly I was doing something wrong back then.  At any rate, all I really had to do was modify the commenting style in the 8086 boot block code, and modify the image creation tool to open files in O_BINARY mode for Windows, and I got an image that will boot, then panic because it has issues reading the hard disk.  I tried the seemingly small ‘fix’ from Linux 0.11 but it’s not working.

If anyone cares, I updated the sourceforge download, as MinGW-aout-linux–001_010_011.7z

Ssystem 1.6

ssystem logo

With all the talk of a possible ‘rocky’ earth like planet making the news, I thought it would be fun to seek out a really ancient (ha!) OpenGL program that did a basic simulation of our solar system.  I am of course talking about ssytem.

Back in the late 90’s I have to admit that this was pretty incredible to look at!  Although it was using OpenGL in software only, and to be honest the best and more stable way to use ssystem was on Windows of all things.

Microsoft had a deal with SGI around the 1993 timeline, and after the release of Windows NT 3.1 they were able to work out a deal to bring Windows NT to the SGI MIPS computers platform in exchange from OpenGL being made available on Windows NT.  SGI couldn’t see a way to monetize NT on their hardware and the port never actually shipped, evidence of it however is present in the leaked Windows NT 4.0 source code.  However OpenGL would prove very import for Microsoft as workstation style graphics could now run on ‘prosumer’ grade OS Windows NT 3.5, and eventually there was even a runtime for Windows 95!

All the old websites, and archives of ssystem have been wiped out, however I did find a copy of the source code for version 1.6 on a HPUX site of all places.


With a filename tracked down, I was able to locate in a partial backup of the main site here:

So I thought I could start there.  Ssystem needs the GLUT toolkit and I found a ‘pre-configured’ version 3.7 that Microsoft Visual C++ 6.0 can build on the command line here. Naturally with all the textures, it does rely on the IJG JPEG library (libjpeg) and I used version 6b as ssystem itself dates from 1999.

There was a bit of work to be done with the source code, as I had to massage it to compile with Visual C++, lots of missing headers, and there were some collisions in the lex for parsing the config file, but they were trivial to clean up.  After a bit of going back and forth with a seemingly defective pre-built version of GLUT, re-building it myself got it to link a working executable:

ssystem in orbit around Europa.

ssystem in orbit around Europa.

Of course in this day & age, any machine these days has hardware OpenGL acceleration so it is pretty trivial to run this program.

The artifacts in the picture were common at the time, and it’s how I remember it all those years ago so I’m not to worried about it.

I tried to compile with Visual C++ 4.0 however when trying to link I got this error:

Microsoft (R) 32-Bit Incremental Linker Version 3.00.5270
Copyright (C) Microsoft Corp 1992-1995. All rights reserved.

init.obj : error LNK2001: unresolved external symbol _glBindTexture
ssystem.obj : error LNK2001: unresolved external symbol _glBindTexture
stars.obj : error LNK2001: unresolved external symbol _glBindTexture
init.obj : error LNK2001: unresolved external symbol _glGenTextures
astrolib.exe : fatal error LNK1120: 2 unresolved externals
NMAKE : fatal error U1077: ‘link’ : return code ‘0x19’

I’m not sure why, as I re-compiled with Visual C++ 6.0 and I get a working executable.  More bizarre if I try to link the objects that were compiled with Visual C++ 4.0 with Visual C++ 6.0 it also fails in the same way.

I’ve placed in everything I could find into this archive: ssystem-1.6.7z including a pre-compiled version, and the high resolution images.  Along the way I also did find a backup of the site which actually has a much smaller download of ssystem 1.6 as  You may need to play with ssystem.conf to get a more respectable display.  I have also tweeked it to work find on my machine, using the highest values I could get away with, without running over the 2GB per process limit on 32bit processes.

Let’s also not forget the SETI crazy of the 1990’s.


Linux at 25 years!

As we quickly approach this amazing milestone, I think it’s always interesting to re-visit the roots of Linux, back to the really ancient versions.  Thanks to the hard work of, the oldest intact Linux source code available is Linux 0.10 from November of 1991.  A popular writeup on 0.10 was up on which appears to have been vaporized, but thanks to is preserved.

Since this version is complete I thought it would be fun to run it through the Linux 0.11 build process & toolchain to see if I could get a working kernel.  Well I had a few stumbling blocks, the bootblocks and the keyboard assembly driver were giving me issues, and for the sake of time, I went ahead and replaced them with the code from 0.11, and along with minor patching to the IDE disk driver.  I added in a simple line to let me know I was actually booting up my franken 0.10 kernel with Qemu.  Also I found later versions of Qemu work much better with 0.10 regarding the IDE disk.

Linux 0.10 on Qemu, cross compiled on Windows

Linux 0.10 on Qemu, cross compiled on Windows

I know it’s not much to look at but it really is building and running.  I’m using the disk for the 0.11 series, as the userland seems to somewhat work.  It’s very touchy, and prone to crashing as it ‘has a bug in the buffer cache’ that I didn’t feel like trying to track down.  Nobody should be using this for anything serious anyways.

Install the 0.11 a.out GCC 1.40 on Win32 cross environment (I guess you can build them on Linux too if you so desire), and if you have a working MSYS environment you can run ‘make’ and it should give you a kernel.  The command file ‘linux.cmd’ will boot it up, and attach the disk image that I used to test.  There are permission errors, and well.. errors.  0.10 was not able to selfhost, but it should be enough to boot, mount the root, and run stuff like the sample ‘hello world’ program.

For those who like to browse the source, I have a browsable tree here.

And for the 2-3 people who care, here is my updated linux-0.10 source tree hosted on sourceforge.