Undefined symbol(s) in SRAND.O
__SRAND
Undefined symbol(s) in ECVT.O
__ECVT
Undefined symbol(s) in FCVT.O
__FCVT
I finally figured out what these are from..  The Sharp/Hudson floating point libraries. Link with FLOATEML.L, and the problem is solved.
DOH! Â Now to build libgcc.a without GCC ….
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)!
D:\proj\142\gcc-1.42_x68000>verMicrosoft 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.
gcc142_x68000.7z You really want this one instead: gcc-1-30-x68000
Linking doesn’t work by default, so you have to manually link, as what I did above.
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
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
For any aspiring software historians out there, this early version of Linux from September of 1991 will be of course VERY interesting!
Well sort of.
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
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 archvie.org a partial backup of the main site here:Â http://www1.las.es/~amil/ssystem/english.html
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.
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’
Stop.
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.
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.
More of a bookmark for me… lol
https://www.minnpost.com/business/2016/08/rise-and-fall-gopher-protocol
Back when Minnesota was at the centre of the online world. Â Then it wasn’t.
It was nearly 2 years ago since I last played around with Gopher.
My Gopher Site
As always my gopher site is gopher://gopher.superglobalmegacorp.com
clik! box
Ever since I got dynamips, the cisco router emulator to actually run code compiled by GCC, I wanted to do something more fun than a simple game of planetfall with a memory mapped file.  And to make a router more like a real computer, I’d want some kind of disk.  Now most cisco routers have PCMCIA slots, so remembering back in the day iomega sold the click! drive, a 40MB removable disk cartridge that has a PCMCIA interface!  Neat!
And even better, on eBay I managed to fine one. Â And much to my surprise when it arrived it was NIB, from 1999!
Contents of the box
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 clik! disk, compared to a two dollar coin
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.
Inserting the clik! disk into the drive.
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.
OOPS.
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.
Clocking in at just under three hours, I haven’t watched it, so no review I just found out about it.
Moderated by Dave House, on 2007-07-23 in Austin, Texas, X4145.2008
© Computer History Museum
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.
Lot Number: X4145.2008
Catalog Number: 102658109