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
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.
It’s really great, first off there are several versions in the steps of the evolution of the project:
– 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
– same version as linux-0.01-1.7, which was just ported to work with gcc-2.x and gcc-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!
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.
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.
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:
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.
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 http://www.wam.umd.edu/~kamelkev/Ssystem which actually has a much smaller download of ssystem 1.6 as ssystem-1.6.zip 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.
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 oldlinux.org, the oldest intact Linux source code available is Linux 0.10 from November of 1991. A popular writeup on 0.10 was up on kerneltrap.org which appears to have been vaporized, but thanks to archvie.org 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.
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.
And even better, on eBay I managed to fine one. And much to my surprise when it arrived it was NIB, from 1999!
As you can see, there isn’t much inside that box, a CD-ROM of the manual, a brief leaflet, and of course the drive itself and a single 40MB clik! cartridge. I have to say that it’s all pretty neat.
The disk itself is pretty small. It does remind me of the older minicomputer disk packs with a removable sleeve to protect the media, but like a three and half inch floppy it is spring loaded to keep users away from it.
The disk gently slides into the drive, to give a very satisfying ‘click’ sound to it.
Unfortunately for me, since this was one of those late night impulse purchases I should have remembered that the cisco 1701 series of routers does NOT have a PCMCIA slot, and the NPE-G1 on my cisco 7200 VXR, instead has a compact flash adapter, not the full PCMCIA.
While I do have a RSP 4+ with the PCMCIA slots, I don’t have a chassis or power supply so I can’t do anything with it anyways. Unless I find the pinouts, and make my own harness to power it up, which I guess is always possible.
So close, but it went nowhere. But I thought it was interesting enough to take a look at such a tiny storage solution from the turn of the 21st century.
Panelists:Jack Browne, Murray Goldman, Thomas Gunter, Van Shahan, Billy D. Walker.
Members of the management, design, manufacturing, and marketing teams responsible for Motorola’s 68000 family of microprocessors and peripheral products discuss the evolution of their activities from the 1970s through the 1990s. The 68000 microprocessor line was critical to emergence of the workstation class of computer systems as well as to Apple Computer’s line of personal computers across the 1980s.
Murray Goldman, the executive who lead this segment of Motorola, describes the background for and strategy surrounding the 68000 effort. Thomas Gunter, who directed the 68000 program, provides a detailed technical accounting of the developments. Jack Browne, who led the marketing function, describes the importance of customer interactions. Bill Walker, who led the manufacturing function, details the hurdles faced in fabricating the 68000 family. Van Shahan, a member of the design team, lends important perspectives on the changes that the 68000 helped bring about from the era of centralized computing to decentralized and personal computing.
Visit computerhistory.org/collections/oralhistories/ for more information about the Computer History Museum’s Oral History Collection.