Building OSKit

Way back in the late 90’s from the University of Utah there was this fantastic project that promised to bring Operating System construction to mere mortals but taking existing PC operating systems, Linux, NetBSD, FreeBSD and break them down to their best components, and then interlink them using COM allowing you to glue the best parts together like lego.

And the project was called OSKit.

It was fantastic for something unknown at the time for creating so called ‘bare metal programs’ that didn’t have a real operating system, but rather could use operating features like LIBC, or the EXT2 filesystem. It was almost that level of ‘MS-DOS’ like feeling from protected mode, but being able to take more stuff with you.

Take the following humble program, hello.c:

#include <stdio.h>
#include <oskit/clientos.h>
#include <oskit/startup.h>
#include <oskit/version.h>

int main()
{
#ifndef KNIT
	oskit_clientos_init();
#endif
#ifdef  GPROF
	start_fs_bmod();
	start_gprof();
#endif
	oskit_print_version();
	printf("Hello, World\n");
        return 0;
}

Compiling this, and linking it is pretty straightfoward:

i586-linux-gcc -c -o hello.o -DOSKIT -MD -DHAVE_CONFIG_H  -DOSKIT_X86 -DOSKIT_X86_PC -DINDIRECT_OSENV=1 -I. -I../../examples/x86 -I../../examples/x86/more -I../../examples/x86/shared  -I- -I../../oskit/c -I../../examples/x86/shared -I../.. -I../.. -nostdinc -Wall  -O2 -g  hello.c
i586-linux-ld -Ttext 100000  -L../../lib \
        -o hello ../../lib/multiboot.o hello.o          \
        -loskit_clientos -loskit_kern -loskit_lmm \
        -loskit_c ../../lib/crtn.o

And of course transforming the ELF into a multiboot executable that GRUB can load:

/oskit/bin/mkmbimage hello

And now you are ready to boot, on say Qemu?

I was kind of surprised it never really took off, maybe it was too far ahead of it’s time. The most notable project I’ve seen that used it was OSKit-Mach, although they later on abandoned OSKit.. I’m not sure why but I would suspect the lack of updates post 2002 would have something to do with it.

Building this was… Interesting as I recall this being somewhat difficult, and I know I’ve probably made it more difficult, but I thought it would be ‘fun’ using the tools of the time. And 1999 has us at Debian 2.2r0. Which thankfully is on archive.org and is a mere 3 CD-ROMS for the i386 binaries. Installing that into VMWare wasn’t so difficult, and swapping CD images around I was able to get enough installed to start building things. For those of you who don’t want to install Debian, here is my pre-compiled Linux on Linux toolchain: i586-linux2.tar.gz. It’s i386 on i386, so you will need to be able to run i386 ELF exe’s. For OS X users that haven’t installed Catalina, you can try OSX-Linux-2.00-i586-gcc2723.tar.gz

I should point out, that although things have to be patched around for older versions of OSKit, 20020317 does build fine using GCC 2.95.2 (20000220) from Debian 2.2r0. So if you want to build in a VM, then you really don’t need any of this. But I’m strange, and I have my WSL2 Debian 10 to think about. So the easiest way to build GCC 2.x is with GCC 2.x so why not start in Debian?

First let’s prep our destination directory, and populate it like a good little cross compiler:

rm -rf /usr/local/i586-linux2

mkdir -p /usr/local/i586-linux2/i586-linux/include
(cd /usr/include;tar -cf - .)|(cd /usr/local/i586-linux2/i586-linux/include;tar -xf -)
mkdir -p /usr/local/i586-linux2/lib/gcc-lib/i586-linux/2.7.2.3/
cp /usr/lib/crt*.o  /usr/local/i586-linux2/lib/gcc-lib/i586-linux/2.7.2.3/
mkdir -p /usr/local/i586-linux2/i586-linux/lib
cp /usr/lib/*.a /usr/local/i586-linux2/i586-linux/lib

With that out of the way, we can build the ‘patched’ binutils that was on the old OSKit archive, I used this binutils-990818-patched.tar.gz

./configure --target=i586-linux --prefix=/usr/local/i586-linux2
make install

Next I’m going to build GCC 2.7.2.3 as OSKit mentions to use 2.7 and I figured why not the last of the line? It seemed like a good idea to me.

./configure --target=i586-linux --prefix=/usr/local/i586-linux2
make LANGUAGES=c libgcc1.a
make LANGUAGES=c
make LANGUAGES=c install

Building is a little weird, as I build the libgcc1.a first, then ONLY the C language, then install that. OSKit is written in C, and I didn’t feel like even looking at dependencies for C++/ObjectiveC

Unix person, I’m not a great one, so a quick hack to get the new GCC onto the path:

PATH=/usr/local/i586-linux2/bin:/usr/local/i586-linux2/lib/gcc-lib/i586-linux/2.7.2.3:$PATH
export PATH

And now I can build stuff!… I then tar’d if up and copied it to my WSL instance, and now I can cross compile fine (a big plus of WSL2 is that you can install the 32bit support, and run old EXE’s! Take that Apple!)

Next up is OSKit, I’m using the last version from 2002, oskit-20020317.tar.gz.

Now it’s worth noting that a few things need to be edited, the ‘OSKit on UNIX’ thing won’t build cleanly and I didn’t investigate as Qemu is a thing now. So disable it in the modules.x86.pc file. Then run configure like this:

sh configure --host=i586-linux --prefix=/oskit --build=i586-linux --enable-modulefile=modules.x86.pc

Despite using the host, build or target setting it doesn’t pick up prefix of our cross compiler, so you have to manually edit Makeconf

Be sure to change the tool exports to look like this:

export CC       = i586-linux-gcc
export LD       = i586-linux-ld
export STRIP    = i586-linux-strip
export AR       = i586-linux-ar
export RANLIB   = i586-linux-ranlib
export OBJCOPY  = i586-linux-objcopy
export NM       = i586-linux-nm

And finally remove -fno-strict-aliasing from OSKIT_FFLAGS, and now you can build!

The bonus is that it’ll build well under a minute on a modern machine.

As mentioned above you should now be able to take the hello world example kernel, and transform it to a multiboot, and boot it via grub.

Again this was such an exciting project I’d hate for it to just suddenly die in absolute obscurity. Maybe it’ll inspire others to try “assisted bare metal” programs, there was a DooM OS, among others in the era.

It was 25 years ago today

32bit computing arrived to the masses. Although it’s incredibly frail by modern standards, Windows 95 did deliver on the promises of OS/2. Depending on your apps, and drivers of course. Although OS/2 did have int13.sys to pass disk calls to a special v86 machine which then used the disk BIOS to make disk access possible, Microsoft and IBM stopped short there, not going all the way letting OS/2 use MS-DOS device drivers. Windows 95, however could.

This was always the winning strategy of Windows, is that it relied on the incredible OEM driver support for MS-DOS. Of course this would also be a catastrophic weakness. From my personal experience being able to leverage ancient MS-DOS drivers also helped squeeze as much as possible out of existing hardware. Case in point, the NDIS2 drivers for the AT&T Starlan 1mbit cards worked fine under Windows 95, additionally you could lost just the lower level drivers, and 95 could then load it’s protocols on top of that stack allowing you to have a TCP/IP network over that 1mbit Starlan stack letting you telnet into your 3b2 (or setup SAMBA, and doing file/print sharing).

If anything the biggest flaw of Windows 95 was not installing TCP/IP by default. However unlike many OS’s of the time, Windows 95 did include LAN and dialup stacks. There was plenty great about OS/2, but it’s refusal to integrate networking into the operating system hamstrung things like named pipes, peer, and larger apps, as you would have to buy and license a stack of stuff to bring OS/2 up to where it should be, while NT and 95 were complete out of the box.

Windows 95 was an excellent bridge OS for the era, until OEMs finally got around to writing drivers for Windows NT. Once the mainstream could finally take that leap, and leave MS-DOS far behind. But that didn’t really happen until Windows XP.

That being said, the favorite thing is to run Windows 95 in a browser. I found https://copy.sh/v86/ the fastest and best, as it loads a short 6MB compressed core image, and you are instantly teleported to the 95 desktop.

Try it out, play some solitaire and enjoy!

Free386 (386|DOS-Extender – RUN386 compatible)

I just found this late last night. The world can always use another DOS Extender, and here we go, out of Japan with Free386!

  • Version: 0.61
  • Date: 2016/12/28
  • Author: [email protected]
  • Machine: PC/AT(DOS/V)
  • Machine in Japanese: FM-TOWNS, PC-9801/PC-9821
  • Compatible: MS-DOS and XMS and VCPI (with HIMEM.SYS and EMM386.EXE)
  • Language: NASM (Full assembly language)
  • Licence: PDS (Free386.com and Free386’s source files)

You can find it here: https://github.com/nabe-abk/free386

Poorly machine translated readme as follows:


From the futon, I thought i’d publish the “Free386” of dos-extender that I had made before to GitHub.

If you want to publish it anyway, NASM and alink also included together and if there is a DOS environment, i thought that anyone can assemble it is out of luck. I found a bug in alink when generating flat mode.exe/.com file. It’s around here that i started to go crazy in a lot of ways(laughs)

Patching alink was done on Linux. I then used TOWNS-gcc to generate alink.exp, but i used the MP header format that TOWNS-gcc generates. We found a bug that the EXP file cannot run on its own. If this is not corrected, it is not possible to distribute including the development environment because it does not usually have the EXP execution environment. When I checked, there was a bug in how to allocate memory, and when the memory capacity started to exceed 8MB, i was allocating memory space that does not exist in the back.

In fact, Free386 at the time was a lot of files that didn’t work properly, and i was worried because it became unstable, it was a mistake in the allocation of memory that is not. However, to examine this, i created a tool to dump memory maps and paging (i.e., it’s included), it was quite a bit of a hassle.

Now, when the memory allocation bug is fixed, almost all DOS generic EXP files and many TOWNS software now work. However, towns-OS’s biggest mystery system is the CoCo/NSD driver around the moss, and the software written in F-BASIC386 does not start. When you come this far, you want to move it.

So we start editing the CoCo/NSD driver. After a little research, I immediately found out the following.

  • CoCo.EXE resides in DOS memory (real memory).
  • NSDD resides in extended memory.

This means that CoCo is presumed to load nsd files into extended memory and manage that information. Now the question is how to get that management information. Is there information in coco memory that resides like SYSINIT? I thought.

For now, to check the area, Free386, i attached the ability to dump the register status before and after the int service was executed by hooking up the interrupt. We analyzed \hcopy\deldrv.exp, which has the ability to remove the specified NSD driver, as “we need to find the NSD driver and the structure seems simpler” in the mechanism.

------------------------------------------------------------------
Int = 0000_008E  CS:EIP = 000C:0000_1ADC   SS:ESP = 0014:0001_0B88
 DS = 0014        ES = 0060        FS = 0014        GS = 0014
EAX = 0000_C003  EBX = 0000_0001  ECX = 0000_0000  EDX = 0000_66EC
ESI = 0000_0246  EDI = 2074_6E00  EBP = 0001_0C48  FLG = 0000_0046
CR0 = 8000_0021  CR2 = 0000_0000  CR3 = 0002_9000    D0 S1 P1 C0  
------------------------------------------------------------------
*Ret:*
 DS = 0014        ES = 0014        FS = 0014        GS = 0014
EAX = 0000_0003  EBX = 0000_0010  ECX = 0000_0000  EDX = 0001_0C18
ESI = 0000_0246  EDI = 2074_6E00  EBP = 0001_0C48  FLG = 0000_0006
CR0 = 8000_0021  CR2 = 0000_0000  CR3 = 0002_9000    D0 S0 P1 C0  
------------------------------------------------------------------

Information like this comes out a lot in turn. If you look at the changes in coco’s residency and other changes in behavior, you can see that int 8eh/AX=Cx0x is a CoCo service. At the same time, log int 8eh and make a resident.com file (included) run386. I also looked at the behavior of the EXE and explored the commonalities of both of them, and i thought, “How would I design the mechanism if I were you?” We looked up coco services from the perspective of “**.

Then we traced to a service that provides driver resident information called int 8eh/AX=C103h. Using this information, the NSD driver in extended memory could be correctly pasted into memory and implemented on the selector. To verify, I ran deldrv.exp using Free386 and was able to uninstall the NSD driver correctly.

Great. End.

…… I wish I had solved it in that way.

TOWNS-OS is an OS of a mysterious structure, and even though there is a BIOS (TBIOS) of 32bit Native mode for graphicprocessing, some services such as timers use the BIOS of FM-R compatible 16-bit operation as it is. It has an incomprehensible structure to use it from the 32bit program side while managing resources, such as a 16-bit timer BIOS.

In terrible cases, each time the processing and interrupt of real-mode resources such as timers and keyboards, switch the CPU to real mode, if during those real-mode BIOS processing, interrupt the PROCESSING of the BIOS, such as FM sound source or VSYNC occurs, it seems to return to protected mode once.

NSD driver called forRBIOS (for Real BIOS) is the intermediary for this incomprehensible structure. Just as DOS-Extender acts as an intermediary for 32-bit programs and MS-DOS, it acts as a real-mode BIOS and a 32bit program intermediary.

In a RUN386 environment, when forRBIOS.NSD is built in, interrupt vectors such as int 8eh are rewritten so that the NSD driver gets the interrupt. **Where is this information? ** That was a mystery that was left behind. However, RUN386 is a . No matter how much the INT log is done until you run EXP, it doesn’t look like it. If you look at the memory of the coco that is resident, there is no information that seems to be it.

If you’re not going to initialize the resident NSD itself. I thought, i patched the entry of the resident forRBIOS, and when the service routine was called, i tried to use the rough business of falling into an infinite loop was bingo.

Finally, you can now run exp files generated by F-BASIC386 and so on. The analysis results are recorded in the doc. By the way, when you run a program that does not require forRBIOS (written in High-C, etc.), the whole process is slower than when you initialize forRBIOS. I really think this is the specs of TOWNS-OS (laughs)

This is the first time in more than a decade since the development was suspended in 2001, and the DOS-Extender, which is compatible with RUN386, was made.

What is with the price of retro Japanese software?

So I was lucky enough to get to Beep before it close, and I picked out a couple of FM Towns titles (and a junker!), and I thought ‘Return to Zork’ would be a good title, something to compare the MacOS & MS-DOS versions against.

Although slightly faded, it does come in this nice box, which reminds me of the NEOGEO… which is probably an apt comparison.

The artwork has faded, although the CD-ROM inside was still sealed, never before opened. I picked this up for an eye watering ¥3,480 but flipping the box over revealed the launch price of an astonishing ¥12,800! I’m not sure what the exchange rate from 1994 was, but even at a generous 100:1 JPY to USD that’s half the price of the old multimedia kits which included the drive, sound card and so many came bundled with Return to Zork.

Another random title I grabbed was even more insane!

¥ 14,800 for Silent Möbius: Case: Titanic!

I need to get a RGB monitor & keyboard to see if this thing even works, meanwhile I fought with UNZ to get it running, and the mouse tracking is totally broken unless you change the DPI scaling, credit to this post in the UNZ ‘BBS’.

One thing is sure, the voice acting in the Japanese version is so terrible.

As people complain about ‘AAA’ games, and paying $60, just look at this! $134 USD for some cartoon boat game thing.. Although I’ve never heard of Silent Möbius or played it, I just saw it was available for the x68000 and PC-98. So I guess it’s one of those Lowest Common Denominator games.

One interesting thing about the FM TOWNS is that they have that ROM DOS with CD-ROM drivers, and their apparently blanket licensing for PharLap 386. Although while I was wasting time looking at cartoon rabbits, someone else scooped but the 386 BASIC kit. Darn.

But in the Return to Zork world, the ‘made.exe’ is in fact a Pharlap 386 EXP, meaning that it runs in 386 protected mode, so you don’t have to struggle with emm386, himem.sys and trying to get a ludercus 580-600kb of conventional memory. Seriously it was such a chore to get this running the manual has a big section on setting up a boot disk. It’s a shame they didn’t license a DOS extender for the US PC platform, although I can see why they chose that route on the FM Towns (and I believe PC98), as there is a RTZ9821 directory there which includes an EXP. Shame it was never relased state side as a patch, as it would have been a GREAT user change. Well that or a Win32 executable.

If you wish to make an apple pie from scratch, you must first invent the universe.

Back in 1995 I bought this rather expensive, and ambitious book simply called: Developing Your Own 32-Bit Operating

And while it is a LONG read, it really is the embodiment of Apple pie from scratch. Rather than rely on open and available tools, the author Richard Burgess instead goes on to write his own assembler, compiler, and then onward to a simple message passing RTOS.

No doubt the price he paid for eschewing popular GNU tools, and having a non BSD/GPL license for the time is that it was quickly relegated to history as the inevitable rise of Linux took place.

Recently while reading a comment about PC-MOS/386 v5.01 final, I came back to MMURTL, which is now in the public domain.

For those wishing to look, not only is the source code and a few patches available on the site ipdatacorp.com, but so is a PDF of the 1st edition of the book.

While MMURTL may not have caught on in the marketplace of ideas, it’s still astounding to look at the volume of work produced, that even though open source tools and starting points were available (The book easily could have been using CMU Mach 3.0) instead it’s all written from scratch by a single person.

TheGrue is doing further work doucmented on the BBS, along with work on github.

386BSD 0.0 on sourceforge

I didn’t realize that I never uploaded this over there. After a discussion on the passing anniversary on the TUHS mailing list I had to dig out my installed copy.

I had forgotten just how rough around the edges this was, as it’s missing quite a few utilities from the Net/2 tape, and isn’t complete enough to come up in multiuser mode, but it is capable of booting up.

Although 386BSD itself was really short lived with its effective short death in the subsequent release it paved the way for an internet only release of a BSD Unix by just 2 people. And it closed up the glaring hole of the lack of a free i386 port of Net/2.

The natural competition was Mach386, which was based around the older 4.3BSD Tahoe, and the up and coming BSDI, which had many former CSRG people which were also racing to deliver their own i386 binary / source release for sale.

One thing about this era is that you had SUN apparently forced out of the BSD business instead to work with the USL on making SYSV usable, leaving NeXT as the next big seller of BSD. The commercial world was going SYSV in a big way, and the only place that was to have a market was on the micros. And for those of us who wanted something open and free 386BSD paved the way realizing the dream of the Net/2 release. A free Unix for the common person, the true democratization of computing by letting common people use, develop and distribute it independently of any larger organization.

It’s almost a shame that GNU had stuck with the unrealized dream of a hierarchy of daemons, instead of adopting the BSD kernel with a GNU userland, on top of that tendy micro kernel Mach.

The landscape radically changed with the infamous ad proudly proclaiming “It’s UNIX”.

While USL was happy to fight both BSDI and the CSRG they never persued Bill Jolitz. And after the internet flame and lawsuit dragged on, neither of the splinter groups NetBSD or FreeBSD caught up, although both did reset upon the release of the 4.4BSD Lite 2 code.

I zipped up Bochs along with the disk here: 386BSD-0.0-with-bochs.7z

Mach 2.5 Independence day

With apologies to a very 90’s movie

Ever since I got my hands on the Mt Xinu disk images, I’ve been working to see if the old Mach kernels on the CSRG CD-ROM set are actually buildable and runnable. And the TL;DR is that yes, they are.

The CD has 3 Mach kernels, the MK35 kernel, a kernel that appears to be something called X147, and a release of Mach 3.0. While X147 has hardware support for the SUN-3 and most of the files for the VAX, only MK35 has hardware support for the i386. The MK35 kernel has incomplete Makefiles and other dependencies, while X147 lacks i386 support. The good news is that it’s possible to use portions of the missing config & Makefiles from X147 to fill in for MK35, as it’s possible to copy the platform code from MK35 along with the i386 specific config into X147, yielding 2 working kernels.

Now this leads to the next few issues. The hardware support appears to be code ‘donated’ from various OEMs from Intel, Olivetti, Toshiba, OSF, and the CSRG. Dates vary from 1987 to 1991.

I started with the MK35 kernel as it was smaller, and since it was tagged as an ‘Intel only release’ of Mach, I figured that this one had the best chance of actually working.

boot:
442336+46792+115216[+38940+39072]

And this is as far as it got on it’s first attempted boot. The Qemu VM would immediately reboot. Since I had installed Mt Xinu on VMware I went ahead and tried it there, and it said that there was a critical CPU exception and that it was shutting down. Bochs did the same thing, as did PCem. Since nothing was being printed to the screen it must be failing in the locore.s which is split into several assembly modules. I put in a hlt at various points and kept rebuilding and rebooting to see if it would halt or if it’d reboot. Thankfully VM’s are cheap and plentiful, I can’t imagine how tedious this would be on actual hardware. Eventually I found out that right after the paging bit in CR0 was flipped the VM would reboot. Now I had something.

        / turn PG on
        mov     %cr0, %eax
        or      $PAGEBIT, %eax
        mov     %eax, %cr0

        mov   %edx, %cr3 

I had tried not flipping the page bit, not flipping cr3, no matter what I tried it would triple fault and reboot.

I had to break down and beg for help, and as luck would have it, someone who knows a heck of lot more about the i386 than I could ever hope to know took a glace at the above code and immediately noted:

I looked at start.s. And it immediately jumped out at me as being very fishy. What they do is enable protected mode *and* paging, but only then load CR3. That’s something which may well work on some CPUs, but it’s against the rules. You could try just swapping the instructions around, first load CR3, then CR0. The next question is then if that code executes out of an identity-mapped page; if yes then just swapping the instructions should do the trick, if not then there is a bigger issue.


 Background: Old CPUs, especially 386/486, will decode and pipeline several instructions past the protected mode switch (mov cr0, eax). The jmp instruction is there to flush that pipeline and make sure all further instructions are executed with the new addressing mode in effect. But old CPUs did not enforce that and it was possible to execute the jmp from a non-identity-mapped page, and I guess it was also possible to execute instructions between the move to cr0 and the jmp, at least most of the time. That tends to break on modern CPUs (probably P6 and later) and definitely in emulation/virtualization. The move to cr0 effectively flushes the pipeline and if the next instruction is not in the page tables, poof, there goes the OS.

Could it really be that simple?

        mov     %edx, %cr3

        / turn PG on
        mov     %cr0, %eax
        or      $PAGEBIT, %eax
        mov     %eax, %cr0

        / mov   %edx, %cr3 

I commented out the cr3 line and just pasted above the cr0 pagebit flip.

The first boot of Mach 2.5 MK35

Amazingly the kernel booted. Behold the first boot of Mach/4.3 which very well could be the first boot independent of the CMU and I’d venture the first boot from the source on the CSRG CD-ROM set. I tried to tell Mach to use the disk as prepared by Mt Xinu, but naturally it’s incompatible.

The next thing to do was create a root diskette, which thankfully the CMU folks left the needed files in the standi386at directory. I was able to build the disk, and using VMware I could boot into single user mode. I went through the ‘unpublished’ documentation I was able to mirror, and was able to get lucky enough to have Mach prepare the hard disk, format the partitions, and I used tar to transfer the root diskette onto the hard disk. I thought it ought to be possible to boot from the boot disk, have it mount the hard disk, and re-mount the boot disk, and copy the kernel. Sounds reasonable right?

This is where the incredibly stale platform code showed it’s head once more again as the floppy driver in MK35 is amazingly useless. It seems that the emulated hardware is too fast? But all reads from the floppy using the hard disk as root failed. Instead I removed a bunch of files from the disk, and copied over gzip & a compressed copy of the kernel to disk, along with the boot.hd program, and was able to copy them to hard disk using that modified root diskette. Luckily Mach has support for a.out binaries, and this stuff being so old it’s all statically linked. My Mt Xinu build of gzip runs fine on the Mach kernel, so I could decompress the kernel and install the bootblocks.

This is where the next weird issue would happen, which is that Mach was quite insistent on mounting everything under this /RFS directory. It appears that RFS was CMU’s answer to NFS… Which needless to say didn’t ignite the world on fire. I was later able to find that I could disable the RFS code, re-configure, rebuild and re-transfer a kernel and with a bit of fighting with mount I was able to mount hd0d/hd0e. Sadly during the install process there was no visible option to specify slice sizes so I’m stuck with a 10MB root.

With this much luck in hand I thought it may be interesting to see if Mt Xinu could mount the Mach disk. Turns out that it can without any issues. So I went ahead and wiped the Mach disk, and transfered Mt Xinu over to the Mach disk, and rebooted with that. And it “works”! Although of course there is some caveats.

The first being the aforementioned floppy support is broken. The next one being that the serial support also suffers from basically losing interrupts and leaving the system waiting. The kernel debugger still works, and you can see it in the idle loop, along with the other threads waiting. This means my favorite method of using uuencode and pasting to the terminal won’t work, MK35 locks up after 35kb, and X147 made it as far as 150kb. Keep in mind that they are using the same i386/i386at platform directories.

So I’m quite sure that there is other issues hiding in the code, maybe obvious ones like the cr3/cr0 thing. On the other front I’ve been starting at looking at doing some porting of the Tahoe/Quasijarus userland with varying success. I have already started to rebuild some binaries with a substitute crt0.o as there is no source for anything included in the Mt Xinu distribution outside of the Mach 3.0 kernel.

For those who want to play along I have uploaded VMDK’s and the source tarballs.

For people using Qemu I find that a serial terminal is FAR nicer to use than the console. Also I’m unsure of how hard the 16MB ISA DMA window is being hit, but X147 seems okay with 64MB of ram, while M35 really needs to be 50MB or less..

qemu.exe -L pc-bios -hda Mach25-MK35.vmdk -serial telnet:127.0.0.1:42323,server,nowait -m 16

This puts the serial port into TCP server mode, so you can simply telnet into the serial port. As always change the memory are your own discretion.

I’m not dead

It’s just been really busy with this move, unpacking and the usual losing things, finding things and breaking things.

In the middle of it all, I found something online, that I want to at least do some proper article thing about… As it’s been really exciting, and goes back to the first month I started this blog.

Outside of NeXTSTEP, the other i386 commercial version of Mach 2.5 surfaced, the Mt Xinu version!

Even better, a few years ago, I had stumbled onto the source code for 2.5 buried on the 4th disc of the CSRG set, and with a LOT of luck and persistence I can confirm that the sources are complete enough to build.

loading vmunix.sys
rearranging symbols
text	data	bss	dec	hex
389088	45564	101364	536016	82dd0
ln vmunix.sys vmunix; ln vmunix vmunix.I386x.STD+WS-afs-nfs

However, as luck always has it, start.s in the i386 code does something weird at the 3GB mark causing a triple fault on any kind of modern emulation/virtualization setup.

    / Fix up the 1st, 3 giga and last entries in the page directory
    mov     $EXT(kpde), %ebx
    and     $MASK, %ebx

    mov     $EXT(kpte), %eax
    and     $0xffff000, %eax
    or      $0x1, %eax

    mov     %eax, (%ebx)
    mov     %eax, 3072(%ebx)        / 3 giga -- C0000000

    mov     $EXT(kpde), %edx
    and     $MASK, %edx

Not all that sure why, but at least on Bochs, I can see the triple fault.

00036527018d[CPU0  ] page walk for address 0x0000000000101122
00036527018d[CPU0  ] page walk for address 0x00000000e0000011
00036527018d[CPU0  ] PDE: entry not present
00036527018d[CPU0  ] page fault for address 00000000e0000011 @ 0000000000101124
00036527018d[CPU0  ] exception(0x0e): error_code=0002
00036527018d[CPU0  ] interrupt(): vector = 0e, TYPE = 3, EXT = 1
00036527018d[CPU0  ] page walk for address 0x00000000c0161370
00036527018d[CPU0  ] PDE: entry not present
00036527018d[CPU0  ] page fault for address 00000000c0161370 @ 0000000000101122
00036527018d[CPU0  ] exception(0x0e): error_code=0000
00036527018d[CPU0  ] exception(0x08): error_code=0000
00036527018d[CPU0  ] interrupt(): vector = 08, TYPE = 3, EXT = 1
00036527018d[CPU0  ] page walk for address 0x00000000c0161340
00036527018d[CPU0  ] PDE: entry not present
00036527018d[CPU0  ] page fault for address 00000000c0161340 @ 0000000000101122
00036527018d[CPU0  ] exception(0x0e): error_code=0000
00036527018i[CPU0  ] CPU is in protected mode (active)
00036527018i[CPU0  ] CS.mode = 32 bit
00036527018i[CPU0  ] SS.mode = 32 bit
00036527018i[CPU0  ] EFER   = 0x00000000
00036527018i[CPU0  ] | EAX=e0000011  EBX=0015f000  ECX=00161dc1  EDX=0015f000
00036527018i[CPU0  ] | ESP=0000efbc  EBP=0000efbc  ESI=00193fb8  EDI=00009d84
00036527018i[CPU0  ] | IOPL=0 id vip vif ac vm RF nt of df if tf SF zf af PF cf
00036527018i[CPU0  ] | SEG sltr(index|ti|rpl)     base    limit G D
00036527018i[CPU0  ] |  CS:0028( 0005| 0|  0) 00000000 ffffffff 1 1
00036527018i[CPU0  ] |  DS:0020( 0004| 0|  0) 00000000 ffffffff 1 1
00036527018i[CPU0  ] |  SS:0010( 0002| 0|  0) 00001000 0000ffff 0 1
00036527018i[CPU0  ] |  ES:0020( 0004| 0|  0) 00000000 ffffffff 1 1
00036527018i[CPU0  ] |  FS:0000( 0005| 0|  0) 00000000 0000ffff 0 0
00036527018i[CPU0  ] |  GS:0000( 0005| 0|  0) 00000000 0000ffff 0 0
00036527018i[CPU0  ] | EIP=00101122 (00101122)
00036527018i[CPU0  ] | CR0=0xe0000011 CR2=0xc0161340
00036527018i[CPU0  ] | CR3=0x00000000 CR4=0x00000000
00036527018i[CPU0  ] 0x0000000000101122>> add byte ptr ds:[eax], al : 0000
00036527018d[SIM   ] searching for component 'cpu' in list 'bochs'
00036527018d[SIM   ] searching for component 'reset_on_triple_fault' in list 'cpu'
00036527018e[CPU0  ] exception(): 3rd (14) exception with no resolution, shutdown status is 00h, resetting

Mach 3.0 doesn’t do this, so I’ll have to dig far deeper into start.s which is kind of really beyond me.

Building a boot disk … is involved. 😐

rm -rf /usr/src/mach25-i386/obj
mkdir /usr/src/mach25-i386/obj
cd /usr/src/mach25-i386/standi386at/boot
make fdboot
/home/user/mkfs /dev/rfloppy 2880 18 2 4096 512 32 1
dd if=/usr/src/mach25-i386/obj/standi386at/boot/boot.fd of=/dev/rfd0d
/home/user/fsck -y /dev/rfloppy
cd /usr/src/mach25-i386/
make
mount /dev/floppy /mnt
cp /usr/src/mach25-i386/obj/STD+WS-afs-nfs/vmunix /mnt
sync
umount /mnt
/home/user/fsck -y /dev/rfloppy

So, I’m not all that dead. For anyone super impatient, you can download my VMDK here, which runs on Qemu & VMware, it includes a serial terminal on COM1 so you can use a real terminal, and if you are like me, uuencode/uudecode files in & out of the system. As always read the 404 page for the current username/password.

PCem v15 released!

The new dynamic recompiler appears to be much more faster, although if you want maximum performance, make sure to set your video card to the fastest possible performance.

I was doing my typical DooM thing, and the performance was abysmal. But I did have an 8bit VGA card selected, so what would I really expect? Interestingly enough in ‘low resolution’ mode it performed quite well, but setting it to the artificial ‘fastest PCI/VLB’ speed it was performing just great.

PCem v15 released. Changes from v14 :

  • New machines added – Zenith Data SupersPort, Bull Micral 45, Tulip AT Compact, Amstrad PPC512/640, Packard Bell PB410A, ASUS P/I-P55TVP4, ASUS P/I-P55T2P4, Epox P55-VA, FIC VA-503+
  • New graphics cards added – Image Manager 1024, Sigma Designs Color 400, Trigem Korean VGA
  • Added emulation of AMD K6 family and IDT Winchip 2
  • New CPU recompiler. This provides several optimisations, and the new design allows for greater portability and more scope for optimisation in the future
  • Experimental ARM and ARM64 host support
  • Read-only cassette emulation for IBM PC and PCjr
  • Numerous bug fixes

Thanks to dns2kv2, Greatpsycho, Greg V, John Elliott, Koutakun, leilei, Martin_Riarte, rene, Tale and Tux for contributions towards this release.

As always PCem can be downloaded here:

Cross compiling to the Atari ST

This was a lot harder than it should have been. And not because of gcc or surprisingly ancient binutils.

I didn’t have much to go on, as ancient threads like this, or this end up unanswered or without any good conclusion. I guess it’s not surprising that all the attention is to MiNT & MINIX rather than the native platform. But I was not deterred.

The reason why this was so freaking hard was how so much of key parts of gcc for the ST have been purged and what remains being scattered to the winds. Amazingly the hardest thing to source is the include files. There is a GCC 1.30 file on all the usual GNU mirrors but to save a few kb it has no headers, instead it wants you to reuse the ones from the 1.25 binary distribution. Which is gone. There survives a pl95 binary and source package, but again no includes. Instead I got lucky with all three for pl98. Which has a lot of GCC2 hooks so I cheated on getting the 1.30 hello world by using the 2.5.8 pre-processor.

It’s kind of annoying how all these seemingly tiny files get purged to save a few kb. Just as I can’t for the life of me find the old original GNU libc.

Speaking of files, ZOO has to be the worst compressor ever. Not only is it just overall worse than ZIP, but there are 2 incompatible compression methods, like the introduction of LZD, which any of the good versions of UNZOO can’t deal with. And sure there is zoo210.tar.Z but despite being able to build it on multiple platforms it never does anything useful. All these ancient fileformats sure don’t help anything. And sure there is a MS-DOS version that the MS-DOS Player can run, but get ready for 8.3 filename renaming.

The one good thing that came out of this experience is that since I am building form i386 to 68000 I found that this setup uses the G++ linker which has endian swapping. So maybe I can complete the chain for Mint and MachTen.

I even got the 1987 Infocom interpreter running. Although I don’t know what the deal is, it seems the larger the GCC based program is the higher chance it’ll just crash on exit or force the next program to crash. Building anything native under emulation was an impossibility.

In the same effort, I’ve had the same luck with sozobon. It took way too long to find a working dlibs. I don’t know why people couldn’t either package them together or at least in the same directory. It took far longer just to find the libs… But it was still fun to get that one running as well.

It’s a far more manual process to compile as I have to invoke each stage manually, but at least I’m finally able to get things going.

One of the bigger issues is that I would always find libraries in this olb file format, that the linker from Sozobon wouldn’t recognize. And almost every attempt of trying to build the G++ linker would also fail on. It wasn’t until I was able to get the pl98 include files that I could finally get a linker to actually recognize this … seemingly different for no apparent reason format to actually link. After then I managed to finally find a build of this dlibs that would actually link with Sozobon, which naturally didn’t use olb at all.

So yeah that was an adventure.

I haven’t cleaned it up at all, and really wouldn’t expect anyone else to care, but all my mashed together work (source & binaries!) is here: MinGW-AtariTOS.7z

UPDATE

I started browsing more cd.textfiles.com and amazingly found a ‘home made CD-ROM set’ of Atari software, and buried in the gigabytes of stuff was 4 of the 5 disks of the original GCC-1.23! Namely the source & includes to the first GCC library. I didn’t think this article was going to get any traction, let alone downloads. So many people downloaded the above download.

Anyways I started to put together a better package on sourceforge since it’ll do the multiple GIT’s and nicer downloads.

Download crossAtariST

The default download set is for GCC-1.30, with the headers & lib, along with source. It’s crazy small which just goes for how this old stuff is, and how impact full for losing a few kb.

Also the shell that you use apparently makes a BIG difference. The shell that I was using EmuCON doesn’t show any output from the GCC 1.x libs. However other shells most certainly do. I’ll have to do another update regarding shells/emulation.