Anyone in need of bash?

I found this post the other day, and thought it was interesting.

Date: 13 Apr 91 18:17:44 GMT
Organization: University of Helsinki
Lines: 18

I've recently ported bash to minix-386 (nice, but takes about 300kB of
RAM). It's been "tested" by me using it all the time (good editing and
history - couldn't live without it any more), but I won't make any
guarantees. If anybody is interested in cdiffs against bash-1.05, please
mail me (I'll post if there is enough interest).

The port definitely needs GCC, and 386-minix. ST-minix will probably
work as well (I've sent it to one ST-minixer), after changeing a #define
LITTLE_ENDIAN to BIG_ENDIAN. If the port already has been done by
someone else - just ignore this message.

Linus Torvalds

PS. I've hacked the kernel to accept gcc-compiled programs directly
without going through gcc2minix, but I haven't tested it very much yet
(bash works though, so most things probably will). Changes are trivial,
mail me if interested. (And yes - it accepts old minix format too - you
don't have to recompile everything :-)

Naturally it’s about the impending birth of Linux.  First he needed to get GCC running under Minix 386, but I didn’t know at the time that he had patches floating around to allow Minix to directly run the GCC A.OUT format executables.

Scary to think that if Minix had allowed submissions and ‘bloat’ that Linux would have never been.

On the other hand, much like 386BSD the backpressure of having some kind of free BSD/UNIX system which did take in submissions was overwhelming, with the false start of 386BSD going the route of Minix and in that first critical year not pulling in any of the additional patches, while Linux grew by leaps and bounds.  By the time the AT&T vs BSDi lawsuit hit, well the game was already in Linux’s favour, even with it’s already fragmented distro base.

Re-building old GCC distribution tars AKA patching backwards

AKA for everyone but me, who never read the readme.  For some reason I got pointed back to my old GCC 1.27 on MS-DOS article, and wanted to see when the 386 really did first appear, and after a bunch of messing around it was shipped in GCC 1.25

Sat Jul 16 14:18:00 1988 Richard Stallman (rms at

* *386*: New files.

So there we are, July 16th 1988!

But looking a the ‘old-releases/gcc-1‘ directory there is no gcc-1.25.tar file! So how to get there from here?  Well the simple answer is to take gcc-1.27, and reverse patch it down using the patches in the patches directory.  The only catch of course is to read prior patches to the reverse to see if any files need to be renamed, otherwise there will be failures… specifically in the file gcc.diff-1.25-1.26

So normally I’ve always patched going up, but with the magical -R flag, you can go backwards!  So taking 1.27 you can go to 1.26 by running

patch -p1 -R < ../gcc.diff-1.26-1.27

And this will take 1.27 and downgrade it to 1.26.  As mentioned above the renames for going from 1.26 to 1.25 needs to be done in reverse:

Before installing these diffs, rename files as follows:

mv typecheck.c c-typeck.c
mv decl.c c-decl.c
mv parse.y c-parse.y
mv parse.h c-parse.h

so do the opposite, and then you can reverse diff.

For anyone who cares I put up the tar files on sourceforge here.

Building MAME 0.1 for MS-DOS / DJGPP

So as promised, a while back I had built a GCC / Binutils 2.8.1 cross compiler toolchain suitable for building old Allegro based programs, such as MAME.  Of course the #1 reason why I’d want such a thing is that being able to do native builds on modern machines means that things compile in seconds, rather than an hour + compiling inside of DOSBox.

Why not use a more up to date version of both GCC/Binutils?  Well the problem is that the pre EGCS tools ended up with macro and inline assembly directives that were dumped along the way so that later versions simply will not assemble any of the later video code in Allegro, and a lot of the C needs updating too.  And it was easier to just get the older tool chain working.

It took a bit of messing around building certain portions inside of each step of the tools, but after a while I had a satisfactory chain capable of building what I had needed.

So for our fun, we will need my cross DJGPP v2 tool chain for win32, MAME 0.1, Allegro 3.12 and Synthetic Audio Library (SEAL) Development Kit 1.0.7 .

Lib Allegro is already pre-built in my cross compiler tool chain, all that I needed to add was SEAL, with only one change, 1.0.7 is expecting an EGCS compiler, which this is not, so the -mpentium flag won’t work, however -m486 will work fine.

Otherwise, in MAME all I did was alter some include paths to pickup both Allegro and SEAL, and in no time I had an executable.  And the best part is checking via DOSBox, it runs, with sound!

MAME 0.1 on DOSBox PACMAN hiding

Thankfully MAME has been really good about preserving prior releases, along with their source tree, and it’s pretty cool to be able to rebuild this using the era correct vintage tools, and I can’t stress how much more tolerable it is to build on faster equipment.

More cross compiler assertion fun

undefined reference to `___eprintf'

Got this fun one in dwarf.c (and probably many others) while building an ELF toolchain from Linux to run on Windows to target.. Linux.  Anyways I think this is a symptom of Canadian Cross compilers.

So a little digging and ___eprintf turns out to be from the assert.h as macros for assert depend on this being in libgcc.a .. And yeah, MinGW uses something else.  So just copy the assert.h from MinGW, and re-build and away it works.

int main(){printf("hi!\n");return 0;}
.file "stdin"
.version "01.01"
main.section .rodata
.string "hi!\n"
.align 4
.globl main
.type main,@function
pushl %ebp
movl %esp,%ebp
pushl $.LC0
call printf
addl $4,%esp
xorl %eax,%eax
jmp .L1
.align 4
.size main,.Lfe1-main
.ident "GCC: (GNU)"

time in parse: 1.155000
time in integration: 0.000000
time in jump: 0.000000
time in cse: 0.000000
time in loop: 0.000000
time in cse2: 0.000000
time in flow: 0.000000
time in combine: 0.000000
time in sched: 0.000000
time in local-alloc: 0.000000
time in global-alloc: 0.000000
time in sched2: 0.000000
time in dbranch: 0.000000
time in shorten-branch: 0.000000
time in stack-reg: 0.000000
time in final: 0.000000
time in varconst: 0.000000
time in symout: 0.000000
time in dump: 0.000000

Well, wasn’t that fun?

Cross Compiling 386BSD 0.1pl23 from Windows 10

I bumped the version to *current year*

Oh yes, this will be a thing!

Sure I can cross compile Linux, but what about 386BSD?  This had long been a thorn in my side, as the GCC/Binutil toolchain that is used in this early era is not GNU pure, they had been modified in all kinds of ways.  One of which was a builtin memcpy that doesn’t work the same as a normal memcpy, and the other being that the C compiler & pre-processor rely in YACC to build the tokens.  I had been using bison before, however even though bison didn’t generate any errors it build the compiler wrong enough that the majority of the kernel wouldn’t compile.

As it stands right now, the only things that do not compile is locore

to post process the kernel, symorder is used along with dbsym, although neither do any processing to the kernel file itself, so they aren’t needed to get a working system.

386BSD Release 0.1 by William and Lynne Jolitz.
Copyright (c) 1989,1990,1991,1992 William F. Jolitz. All rights reserved.
Based in part on work by the 386BSD User Community and the
BSD Networking Software, Release 2 by UCB EECS Department.
386BSD 0.1.2018 (GENERICISA) 02/02/18 15:01

Other than that, yeah it’s great, compile a kernel in under 15 seconds.

Anyone that cares, the initial release is here: 386bsd01.7z


GCC 1.27 & MS-DOS

Inspired by Building and using a 29-year-old compiler on a modern system, i thought I too could get this ancient version of GCC working.  At the time I never had bothered with the older version as I had always assumed that there were many fixes and adaptations to GCC  for it to run on MS-DOS via GO32/DJGPP.  However after doing this, its obvious that GO32/DJGPP was rather built around GCC’s stock output, which would sure make a lot more sense.

And it turns out that the target machine being an i386 Sequent running BSD is the best match, both in turns of underscores, and debugging format.  At first I had tried the AT&T SYSV i386 target, however it couldn’t link anything from the standard libraries that DJGPP has as they all have a leading underscore.  After starting to mess with internal macros to turn things on and off, and re-define how various portions of assembly are emittied, I found the Sequent target and went with that and everything was fine, and using the existing build infrastructure for GCC 1.39 I now could actually run hello world!

gcc_v1 -v -E hello.c -o hello.i
gcc version 1.39
cpp_v1 -v -undef -D__GNUC__ -DGNUDOS -Dunix -Di386 -D__unix__ -D__i386__ hello.c -o hello.i
GNU CPP version 1.39
gcc_v1 -v -S hello.i -o hello.s
gcc version 1.39
cc1_v1 hello.i -quiet -version -o hello.s
GNU C version 1.27 (80386, BSD syntax) compiled by GNU C version 5.1.0.
gcc_v1 -v -c hello.s -o hello.o
gcc version 1.39
as -o hello.o hello.s
gcc_v1 -v -o hello hello.o
gcc version 1.39
ld -o hello C:/dos/xdjgpp.v1/lib/crt0.o hello.o -lc

go32 version 1.12.maint3 Copyright (C) 1994 DJ Delorie

hello from DJGPP v1/GCC 1.39!

Wasn’t that great?  Then going through my ‘test’ programs I went to try to build the infocom interpreter, and that is when things went off the rails.

funcs.o: Undefined symbol __udivsi3 referenced from text segment
options.o: Undefined symbol __divsi3 referenced from text segment
options.o: Undefined symbol __divsi3 referenced from text segment
print.o: Undefined symbol __divsi3 referenced from text segment
print.o: Undefined symbol __udivsi3 referenced from text segment
support.o: Undefined symbol __divsi3 referenced from text segment
gcc_v1: Program ld got fatal signal 1.

I’ve had some issues with GCC and these ‘built in’ functions before.  This was an early major stumbling block back in the x68000 GCC days, where after a lot of searching I was able to find 68000 versions of various math routines that were in the native Hudson Soft assembler to link in.  While GCC 1.x does have a libgnu/gnulib to include these functions it warns you over and over to not use GCC to build them, but rather the native CC.  But the problem is that I don’t have a native CC.

But I managed to save myself after googling around by finding srt0.c from 386BSD.  Namely these two:

.globl ___udivsi3
movl 4(%esp),%eax
xorl %edx,%edx
divl 8(%esp)

.globl ___divsi3
movl 4(%esp),%eax
xorl %edx,%edx
idivl 8(%esp)

I ended up having to removing a single underscore, but now I could link infocom, and even better it runs!

Wanting to try something far more exciting, I went ahead and tried to build DooM.  However GCC 1.27 has an issue with m_fixed.c  I fired up GDB to at least take a look, although I’m not sure where the fault lies.

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.

Breakpoint 1, 0x752c5ad5 in msvcrt!_exit () from C:\WINDOWS\System32\msvcrt.dll
(gdb) bt
#0 0x752c5ad5 in msvcrt!_exit () from C:\WINDOWS\System32\msvcrt.dll
#1 0x752bb379 in msvcrt!abort () from C:\WINDOWS\System32\msvcrt.dll
#2 0x0045805c in final (first=0xe066a0, file=0x75312688 &lt;msvcrt!_iob+128&gt;, write_symbols=NO_DEBUG, optimize=0)
at final.c:653
#3 0x00403198 in rest_of_compilation (decl=0x722718) at toplev.c:1296
#4 0x0040fbce in finish_function () at c-decl.c:3272
#5 0x004040c0 in yyparse () at c-parse.y:224
#6 0x0040239d in compile_file (name=0xe00def "C:/dos/xdjgpp.v1/tmp/cca02992.cpp") at toplev.c:837
#7 0x00403a33 in main (argc=11, argv=0xe00f90, envp=0xe01598) at toplev.c:1556

With the code being:
if (! constrain_operands (insn_code_number))
abort ();

So I assume some error with constrain_operands? Not that it makes it any better.  However I know this one file compiles fine with 1.39, and since we are on the i386 another alternative is just to used the assembly version that was hiding in the readme..

DooM mostly built by GCC 1.27

And much to my amazement, it works!  Keeping in mind that this is using an a.out tool chain, along with the last DPMI enabled GO32 extender.

Considering the compiler dates back from September 5th, 1988 it’s really great to see it running.

I’ll have to upload source (GCC 1.27/DooM) & binaries later.  But I imagine it should also run on EMX/RSX for a Win32 version.

BASIC language subset/dialect in C++

This one came to me from Peter, a set of C++ macros and define sets that implement a subset of BASIC.

YES, that is correct, BASIC.  It even has line number!  Let’s look at a simple hello world!

type hello.bas
#include “

BEGINBASIC(int,main,(int argc, char* argv[]))
10 PRINT “Hello, world!”;
20 GOTO 40;
30 PRINT “I am not printed”;
40 END;

It’s compiled with GCC like this:

c++ -pipe -xc++ -fpermissive -w -o hello.exe hello.bas

And then run it!

Hello, world!


From the docs in the main .cc file:

Implemented a BASIC language dialect/subset, with the following restrictions:

  •  All variables and statements must be allcaps
  • All lines must begin with a line number from 1 to 32767
  • All lines must have a trailing semicolon
  • One statement per line (except IF-THEN)
  • “THEN” must NOT be followed by a “GOTO” nor “GOSUB”!
    • Implemented keywords:
    • IF <C-style expression with “==” in case of equality> THEN <label>
    • GOTO <label>
    • GOSUB <label> / RETURN
    • STOP [optional errorlevel/return value]
    • END [optional errorlevel/return value]
    • LET <variable>=<expression>
    • PRINT <strings and/or variables in arbitrary order>
    • INPUT <one or more variables>
    • DIM <array variables with number of elements, p.ex. “NP(42)”>
    • FOR/NEXT loop (NEXT’s argument is mandatory, exactly one variable)
    • PRINT interprets comma as semicolon, except on the ENDS
      • thus PRINT does NOT interpret comma as tab injection
        basically, PRINT is some kind of writeln()
        but can be tricked: if CHR$(0) is inserted somewhere, it won’t print
        the remaining part including the trailing newline!
        variables are all float types, predeclared, and their names at most 2 chars long
    • (numerical) arrays can be used, must be declared before their first usage
    • Array numberings: DIM A(8) means that A(0) till A(7) are declared this way

So it’s not 100%, there is no strings, not even a REM (conver to C++ comments) so it’ll be a while until you can build more traditional basic programs.

Simple Mandelbrot set in BASIC

I used “mingw-i686-7.1.0-win32-dwarf-rt_v5-rev0” to test this on Windows.

You can download ptsvubas from it’s site here:

NetHack in your browser via Moxie CPU

I saw this many years ago, but for some reason never finished writing about this. Moxie was a virtual CPU designed to be as simple as possible for the GNU toolchain to target.

Perhaps one of the more interesting things was a port of RTEMS to the Moxie CPU, and a port of Nethack to that architecture. And of course there was a javascript simulator environment allowing me to easily embed it into this post.

So yes, it’s a virtual CPU, OS & Game, running in java-script and on the page.

Porting Catacomb3D to MS-DOS (DJGPP v1/GO32).

Catacomb 3-D for GO32

No really, it’s Catacomb 3-D: The Descent.  First ported to 32-bit SDL by NotStiller.  Me being the person I am, I fixed a slight bug regarding binary files on Windows, and MS-DOS, then cleaned up some of the C++ syntax (yuck!) making it far more C89 friendly.  And of course, hot off the heels of DooM for GO32 DPMI, I was able to get it to build and run using GCC 1.39 and GO32.

I know most people really won’t care, but I found it kind of interesting.  I should try to see if it’ll run on actual hardware, just as a comparison of tightly optimized Borland C++ / Assembly vs 100% pure C on DJGPP.  The best tech of 1991 for sure!

At current I just put the source up, you can git it here.

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