Hack 1.0.3 for Xenix (i386)

Hack

I figured that since I could build hack for some ancient 4BSD flavors that I should be able to build hack for good old fashioned Xenix.

And it all seems to work as it should!

I used the source from here, and only had to do a few small modifications to get it to compile and run on Xenix via GCC 1.37.1 .

You can download my binary, and source mods.

I’ve managed to keep this instance of Xenix up for 19 hours, I was thinking about doing some kind of public access to this system, but I don’t know if people would even be vaguely interested..

But if you want access, I can set you up.

Although all that is of interest is ‘dungeon’, fortune, hack, robots, and ircII …

 

Good news on the QEMU fronts!

First I found this blog post about building Qemu with CLANG instead of GCC, and I didn’t  even run it through google translate, but I had a feeling that it must work because there is simply too much text there for something that doesn’t work… Although it is with the TCG interpreter…

Qemu 1.1.0-1 on OS X 10.6.8 via clang!

And sure enough it works! (well so far I’ve only booted the IBM PS/1 MS-DOS 4.00 image I had handy. But that is good news for me as I’m planning on shifting away from running Windows all the time, and it was annoying having this powerful mac pro, but not being able to run / play with Qemu.

The move the clang would make sense as I under stand it Apple is moving away from GCC at any rate.

Also on the road to a non TGC build of Qemu I did find out the compiler included on the 10.6.3 DVD works while the later IOS update one does not…

Using built-in specs.
Target: i686-apple-darwin10
Configured with: /private/var/tmp/llvmgcc42/llvmgcc42-2336.1~3/src/configure –disable-checking –enable-werror –prefix=/Developer/usr/llvm-gcc-4.2 –mandir=/share/man –enable-languages=c,objc,c++,obj-c++ –program-prefix=llvm- –program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ –with-slibdir=/usr/lib –build=i686-apple-darwin10 –enable-llvm=/private/var/tmp/llvmgcc42/llvmgcc42-2336.1~3/dst-llvmCore/Developer/usr/local –program-prefix=i686-apple-darwin10- –host=x86_64-apple-darwin10 –target=i686-apple-darwin10 –with-gxx-include-dir=/usr/include/c++/4.2.1
Thread model: posix
gcc version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.1.00)

GCC for update for IOS 5 … which doesn’t build a working Qemu exe

Using built-in specs.
Target: i686-apple-darwin10
Configured with: /var/tmp/gcc/gcc-5646~6/src/configure –disable-checking –enable-werror –prefix=/usr –mandir=/share/man –enable-languages=c,objc,c++,obj-c++ –program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ –with-slibdir=/usr/lib –build=i686-apple-darwin10 –with-gxx-include-dir=/include/c++/4.2.1 –program-prefix=i686-apple-darwin10- –host=x86_64-apple-darwin10 –target=i686-apple-darwin10
Thread model: posix
gcc version 4.2.1 (Apple Inc. build 5646)

While the one that does come on the 10.6.3 DVD works fine.

Next up for all those of you on Windows or Win32 i386 platforms, rainbow has kindly provided a Win32 build of Qemu, which you can download from his site!  Ive booted MS-DOS on it from within VirtualBOX and it seems to work fine!

One thing I’ve noticed about 1.1.0 is that it cannot read low density 3 1/2″ disks!!!!

DJGPP 1.03 saved thanks to shovelware + cd.textfiles.com

I can’t stress enough just how awesome cd.textfiles.com is for finding ancient stuff!

I’m not sure why I started on this quest but I was looking for some old finicky DOS extender, and started hunting for Go32, the first DOS extender used by DJGPP.  And for the heck of it, I wanted to find the first version, which I pretty much had assumed was lost to the mists of time.

However the CD-ROM shareware collection called MegaROM-1 actually had a ‘full’ copy of one of the first versions of DJGPP, 1.03.

Installation is pretty straightforward, however you have to use pkunzip for all the various old ‘methods’ of storing data in zip files, I found infozip leaves things out..

Also DJGPP 1.03 uses a LOT of environment space.. which is more so a problem for people running real MS-DOS on real machines.. (there are some!)…

Hello World!

It runs in DOSBox, but there is no doubt some stack corruption as trying to run things like dos edit result in:

Packed file is corrupt

But at least we can run more than one copy, or use a native editor.

GO-32 from this era is *NOT* DPMI compliant, nor is it VCPI compliant.  And its based on GCC 1.39, which was a popular level with things like 386 BSD, although it seems early Linux used GCC 1.40 ..  The tool chain by default outputs the GNU a.out format, but relies on modifying the linker that was separately included in G++.  Later versions of GO32 included VCPI support, and near it’s end of life version 1.10 added support for DPMI which greatly simplified things like hooking IRQ’s and doing DMA.

For those who want to play, without the pkzip fun, I’ve slapped it into a single 7zip file.  It’s not even a megabyte.  But it was 1991, when 4MB of ram seemed like an incredible amount of memory!

25 years of GCC!

In 1987 the first announcement went out that Stallman had introduced perhaps the most important piece of GNU software ever:  GCC.

I haven’t been able to locate the 1.0 release or even the 0.9 beta (*Edit as an update, yes I’ve found it, and installed it!), as close as I could find was 1.21 from May 1st, 1988. Even at this time, GCC supported the following CPUs:

  • m68k
  • ns23k
  • spur
  • vax
Amazingly GCC at this point is pretty snappy, and very ANSI compliant unlike PCC.  At this point it still relies on native assemblers, linkers, librarians it still was pretty versatile. Back then there was no auto configuration tools you have to link configuration scripts by hand but even on VAX BSD it builds somewhat straightforward (providing you read the documentation)..

GCC 1.21 on 4.2 BSD

I don’t know if it serves any practical value but I went ahead and built a source package for GCC 1.21, along with a 4.2 BSD binary package.. I suspect it’d only be an interest to a select few.. Although if anyone has 1.0 or 0.9 I’d be interested!

By 1991 GCC 1.40 supported not only the i386, but Linux kernel.. And as they say the rest is history.

And finally a video summation of all the changes to GCC…

 

On the way to building Qemu 1.0…

Well one of the fun things is that Qemu now relies on glib.  But in order to build glib it needs pkg-config. And of course you can believe that pkg-config requires glib in order for it to work.  Good lord, nothing like circular dependencies!!!

So what to do?  First things first libffi will be needed to build glib.  It doesn’t seem to have any crazed dependancies so that built ok.  Also something I’ve been missing in a lot of ‘native’ MinGW builds is to add:

–prefix=/mingw

to the configure strings to get things in a location where the system will find them.  For some reason MinGW doesn’t walk /usr/local .. I guess because its not UNIX. With libffi built then you can configure/build glib like this:

export LIBFFI_CFLAGS='-I /mingw/lib/libffi-3.0.10/include'
export LIBFFI_LIBS=-lffi
export lt_cv_deplibs_check_method="pass_all"
export CFLAGS='-O0 -g -pipe -Wall -march=i486 -mms-bitfields -mthreads'
export CPPFLAGS='-DG_ATOMIC_OP_USE_GCC_BUILTINS=1'
export LDFLAGS=”-Wl,--enable-auto-image-base”
./configure --prefix=/mingw --with-pcre=internal --disable-static --disable-gtk-doc --enable-silent-rules

Then it is a simple matter of building out pkg-config then rebuilding glib in a ‘sane’ fashion.  This all comes form the MinGW wiki which has great information on how to do things like bootstrap glib!

And don’t forget to install python! Even Qemu needs it now!

And add it to /etc/profile so it will be in your path…

  export PATH=”.:/usr/local/bin:/mingw/bin:/bin:/c/python27:/c/python27/dlls:$PATH”

Solaris 11 came out today

They blew the 11/11/11 launch date.  I guess Oracle really just doesn’t care about magical numbers or whatever.

I guess for the two or three people who even run this stuff (no doubt to run Oralce and it’s draconian licensing) you can find out all about it here.

It appears they still keep the Fortran stuff around for it…  Oh and this release is x86_64 only.  Sorry 32bit users.

Installing gcc (and I imagine everything else) revolves around the pkg command… In this case ‘pkg install gcc-3’ will download and install gcc 3.  While ‘pkg install gcc-45’ will install GCC 4!.  Don’t forget to install system/header or you won’t have things like stdio.h!!

Another GCC tidbit, is that you can build 64bit binaries with GCC 4.5 by supplying the -m64 flag!

While Solaris 11 installs somewhat quickly in VirtualBox (but wow does it take forever to boot), it is bare minimum…

Also for those who want it, here is lynx & ircII for Solaris Oh and a Quake World Server.  At least wget is in the base, but I don’t see why lynx isn’t.

Quake & QuakeWorld for MS-DOS update

So after a year+ of inactivity I’ve spent some time with Quake (netquake) and QuakeWorld for MS-DOS.  I had modified it to support the WatTCP stack for MS-DOS, allowing you to play over the internet with any MS-DOS PC with a packet driver.

After a good bit of prodding and playing with DJGPP I’ve updated everything to include some new tweaks for a malloc ‘bug’ (Quake assumes the memory is clean, which under DJGPP it isn’t) some limit increases (zone to 1MB, and increases in max edicts, models & sounds), and forcing the sound to 22050Hz.  The source code is now here.  As much as it pained me, I built it with this DJGPP under MS-DOS (On Qemu) and I’m keeping it here, as gcc 3 & 4 are incapable of building a working WatTCP or Quake.

Another big fix for QuakeWorld is that it now can run in 640×480, 800×600, and even 1024×768 if your video card is VESA 2.0 compatible!!!

Basically you can just replace the default exe’s in a Quake1 install and go from there.  If you do not have quake at all, you can always look for the shareware version.  QuakeWorld will require the commercial version for what it is worth. I’ve found it runs best with 32MB of ram.  I don’t know if that is even an issue in this day & age.  Quake1 will run in 16, but I have a feeling QuakeWorld runs in VM (thanks to CWSDPMI) and it does say it is using 32MB … Because I clear the ‘zone’ before Quake runs there may be a 30 second to 1 minute pause.  This is to be expected, just hold tight.

QuakeWorld at 640x480

QuakeWorld at 800x600

QuakeWorld at 1024x768

You can download either Quake.exe or Qw.exe.

Thanks to [hci]maraakate, for the hints on what to update where, and of course the testing on a ‘real pc’!`

QuakeWorld for OS/2 2.0

Not sure why its suddenly working…. but I suspect it may be either updates to both OS/2 base OS & TCP/IP or…. it is because I’m using the QuakeWorld server code that matches the client…. Anyways I’ll upload a binary and the rest later as it is super late.  But for those of you who want to see it…

Yes it really is an OS/2 exe built with EMX!

I’ve updated the sourceforge page to include an exe, and a copy of the updates that I’m using to OS/2.. Oddly enough my OS/2 install with Virtual PC no longer works… The NIC isn’t found anymore, must be some update?  I’ve got 6.0.192.0, although I know for a fact that this image used to work…

Broken driver

Further update, turns out I’m retarded the AMD PCNet driver is for VMWare/Qemu … Virtual PC emulates a DEC 21140a, which I downloaded a NDIS2 driver from Intel which works great.  I do have to turn off hardware assisted virtualization otherwise OS/2 won’t boot at all from the hard disk..  I’m not sure if it is because I’m now on an AMD computer, or if it is the matched QuakeWorld server/client but it works fine… in Qemu & Virtual PC.

Super small 64bit OS

it doesn’t do much, but it does work!.. I saw it mentioned here, and the source archive can be downloaded here.

So I went through the steps of  building a 64bit cross tool to build it.. Although Qemu won’t boot the kernel directly, and it uses GRUB which isn’t so bad but I haven’t made a transparent boot system for it just yet…  Maybe I can use a CD-ROM ISO image…

C:\temp\trunk4>build
C:\temp\trunk4>del *.o kernel.bin kernel.ld
C:\temp\trunk4>x86_64-pc-elf-cpp -Iinclude -P -C -DLINKER_SCRIPT -o kernel.ld kernel.lds
C:\temp\trunk4>x86_64-pc-elf-gcc -Iinclude -Xassembler --divide -c -o startup.o startup.S
C:\temp\trunk4>x86_64-pc-elf-gcc -Wall  -nostdlib -nodefaultlibs -mcmodel=large -Iinclude -c -o kmain.o kmain.c
kmain.c: In function 'kmain':
kmain.c:17: warning: unused variable 'n'
kmain.c:15: warning: unused variable 'str'
C:\temp\trunk4>x86_64-pc-elf-gcc -Wall  -nostdlib -nodefaultlibs -mcmodel=large -Iinclude -c -o idt.o idt.c
C:\temp\trunk4>x86_64-pc-elf-gcc -Iinclude -Xassembler --divide -c -o isr.o isr.S
C:\temp\trunk4>x86_64-pc-elf-gcc -Wall  -nostdlib -nodefaultlibs -mcmodel=large -Iinclude -c -o pic.o pic.c
C:\temp\trunk4>x86_64-pc-elf-gcc -Wall  -nostdlib -nodefaultlibs -mcmodel=large -Iinclude -c -o console.o console.c
C:\temp\trunk4>x86_64-pc-elf-ld -nodefaultlibs -z max-page-size=0x1000 -o kernel.bin -T kernel.ld startup.o kmain.o idt.o isr.o pic.o console.o
C:\temp\trunk4>x86_64-pc-elf-objdump -S kernel.bin  1>kernel.asm

The ‘warnings’ are all my fault… As I wanted a string not the 1,2,3,4…

Grub boot flags

 

And here we are in 64bit long mode!

So for the two or three people who care, my archive is here… I may move crap around, but at the same time building a 64bit cross compiler was a real chore.. More so because that x86_64-elf bare targets didn’t exist until some time around 4.3.2 which… is involved to build.