On the i386 a texture info lump loads up just fine. However on a big endian G5…
…It clearly has problems. Although notice that the positions and sizes are the same, as they ought to be.
Notice how originx is 24, which should be the width. This code was running with GCC 1.30/1.40 hammered x68000 GCC. Although I have been unable to get the much vaulted gcc-1.30.atari.tar.bz2 to do anything useful, well until tonight, when I found this file: GNU_HEAD.ARC.
That’s right, it’s the gcc-1.23 release headers for GCC on the Atari ST. Now I know other places people have been saying I should use MINT or some GCC8 port. And I wanted something to run on bare TOS, and I cross compiled the simple Infocom interpreter but it just crashes out after a few commands. It’s hardly stable.
Which is just a damned shame, as it was easier to just download someone else’s work.
Anyways, I now can build the old gcc-1.30 libc however… the linker that I’m using that works for GCC 2 links away and it looks like a working program but it doesn’t do anything. I have a feeling the linker drifted in those years between GCC-1.30 and GCC-2.something when it was adapted. Certainly by the time of 2.5.8. So yet more endian ghosts to chase down if I try to adapt that linker.
So as promised, a while back I had built a GCC 220.127.116.11 / 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.
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!
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.
Stuff like this drives me crazy. Once upon a time everything was statically linked, there were no DLL’s, and all exe’s had a lot of the same code in them, and people realized that the majority of a hard disk could literally contain the same thing over and over. Not to mention that if you were to fix some bug in say, LIBC you would have to re-compile everything. So we entered the brave new world of dynamic linking where we now live in the proverbial DLL hell, that although we did save space, we have things where slight variations in the same DLL can break things in unforeseen ways. People have tried various things such as weak linking, Side by side assemblies, Frameworks, and all kinds of things to try to keep things together.
Honestly it’s just easier to go back, and statically link things, and just re-build as needed.
common culprits of MinGW based stuff always include:
The hard one is the pthread library. If you try to link it statically it’ll try to link everything else statically and not every DLL can link statically (SDL*keep reading). But GCC / Binutils does have the option to turn various features on and off through the link string
As you can see, everything after “-Wl,-Bstatic” will be linked statically, while everything after “-Wl,-Bdynamic” will go back to being dynamically linked.
Ok, that is great but what about SDL, you may ask. Well sure it’s a DLL, but even DLL’s come from somewhere. Download the source, build it yourself and you can directly link the objects that make up the DLL. In version 1.2.15 they live in the .libs directory.
And on Windows, if you get weird errors like:
SDL_dx5events.o: In function `DX5_DInputInit’:
SDL-1.2.15/./src/video/windx5/SDL_dx5events.c:183: undefined reference to `IID_IDirectInputDevice2A’
Just add the -ldxguid library and you can link this too. I’m sure once upon a time people may not have had DirectX 5 or higher, but this isn’t 1997.
And please at least test your programs with no path, so that way you are aware of what is needed for re-distribution.
It gets so old when people never test. And people freak out trying to download DLL’s from weird sites, and you know that never ends well.
Oh yeah, and a static version of DOSBox is 4MB.
I know that was massive a long long time ago, but today?
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:
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!
Around the time of the x68000 port of DooM, I was cutting down the DooM source for a null/portable version. I never could get it to actually run either using EMX or DJGPP 1.03, as I couldn’t get it to link to save my life with a constant never ending battle of unresolved symbols. After a while I just used what I had towards the x68000 version and concentrated on getting it up and running, and just shelved the null/portable effort.
Later on I wanted to get it running again as part of messing with another cross compiler, as DooM isn’t a trivial application to port and verify correct operation. And in the process of trying to get the null version to build and run on Windows using TDM GCC, I wanted to make sure it at least kept compiling with GCC v1.x.
Once more again I was able to compile individual files but unable to link. But this time, I just looked at the diffs for binutils, I thought it should be somewhat easy to get hosted on Windows. Although versions may point to binutils 1.0, I had to use binutils-1.9.tar.gz even though the diffs are against Mar 24 1991, and the source for 1.9 is dated April 17 1991.
My first effort gave me a linker that would happily link, but go32 would either refuse to run the executable, or just crash. I was going to give up again, but I found mention in another file that DJGPP actually uses the linker from G++, the C++ compiler which was a separate thing in the late ’80s and early’90’s. This time it worked, and I could link a trivial hello world style application!
Now that I finally had a cross linker actually working, I didn’t want to compile under emulation, so looking at the other diffs, they didn’t look too extensive. I went ahead ,and took DJGPP v1.06 and patched up the compiler & assembler to get a full cross toolchain. And in no time, I had a null version of DooM running on MS-DOS well at least tested on DOSBox.
This was fun, and all but I didn’t see any easy way to do fun things like hook interrupts so I could get the keyboard & clock like any good MS-DOS program. DPMI greatly eased this kind of stuff, so looking at the DJGPP history, DJGPP v1 version 1.10 actually adds preliminary DPMI support! And in the next version, DPMI was much more better supported, however the binary format had changed from a.out to COFF as part of the move to v1.11. I was able to take the memory, and DPMI portions from the final v1.12 libc, and manually build and run them against the v1.06 library / dev tools.
And much to my surprise, it actually worked! At least having the wrong format didn’t have any effect on how GO32 worked for me.
So feeling lazy, I snagged some of the support code from Maraakate’s revamp of DooM, just to make sure of the timer code, and the keyboard code, and again verified that I can build with the keyboard & timer ISR and I’m able to play the v1.9 shareware & commercial levels fine. I haven’t done a thing to clean up or update the DooM source itself against all the dozens of bugs and issues with Ultimate DooM, or other games like Chex Quest etc.
I’m sure 99% of people wouldn’t care but you can download it here:
Although I’m using DPMI to drive realtime events, if I looked further at the GO32 v1.06 environments I could either figure out how it operates it’s timer, or modify the extender directly to drive the PIC timer and keyboard as I need. But overlooking that, the vintage 1991 software is more than capable of running DooM.
I know it’s utterly pointless… But yeah GCC 2.8.1 + EMX 0.9d, hosted (running) on Win32. The main reason is that I wanted to be able use use my substantially faster Win64 machines to build stuff for OS/2. And since I have a 4 core (+4 hyper thread), I want to be able to use make with the -j 16 flag, and say compile QuakeWorld/2 in under two seconds.
I was able to get the binutils 2.6 derived stuff to compile, along with the ‘ancient’ binutils which is notably the linker that EMX depends on. I would imagine this ought to be able to compile PDOS, although my own simple attempt at InfoTaskForce met with spectacular failure. While it does compile fine using an older EMX 0.8h based release.
A long long time ago, back when I got a Pentium 100 the wonderful world of emulation was really starting to be possible with such a high powered CPU. First was the simple Game Boy emulators, then a Commodore 64 emulator, the incredible Amiga Emulator, the beginnings of SIMH (back when it was only a PDP-11 emulator), and then I found the SEGA emulator, System 16.
It was really cool being able to play 16bit arcade games on the desktop, although rather slowly. From there everyone knows the rise of MAME. But while looking around for a small 68000 C compiler, I came across the source code to an older version of System 16, 0.53 on archive.org. Naturally it’s for MS-DOS, as was everything back in the day. Also slightly interesting is the 68000 emulation, written by Bernd Schmitd of UAE fame. So for the heck of it, I set about getting Thierry Lescot’s System 16 building again. I’ve never used allegro before, so it was a bit of a fight to get a version of it to actually build. It turns out that I should have been building version 2.11 with tools of that era (why on earth was I using GCC 4, and binutils 2.18?) and instead stick with GCC 18.104.22.168 and some much older binutils. And in no time I had build the library, and it’s examples. With that done, I was able to re-build System 16 with GCC 4.1.2 and get a binary!
Back in the day, I actually did have an Altered Beast arcade board. Sadly it died in a move, someone near and dear just saw the PCB as “garbage” and tossed it. Sigh, but I did have ROM dumps, as I did a refresh of it forever ago. Anyways I still have the ROM files, so I guess that is nice.
Anyways I fired up the emulator and got what is known as the “jail bar” effect, which is from a bad ROM.
The System 16 splits it’s memory into a program space, a sprite memory bank, a tile memory bank, and RAM for stack and things like the palette. As you can see the program is certainly running, and the sprites are good. I did some poking around a bit later, and noticed that due to a logic bug, the texture ROMs are actually never loaded!
So a quick patch, and now we get Altered Beast up and running!
Well, now isn’t that great!
Not that I would imagine anyone would really care, I mean MAME is a thing, and even from the readme:
Altered Beast : No sound emulation
So it’s pretty quiet. Additionally the source is pretty restrictive:
These sources can’t be used for commercial purpose, any new version of the
emulator done with these sources must specify my name somewhere on the screen
et docs and I must be informed about any new release of the emulator.
Sadly that ancient line program only runs ELF binaries, so that won’t work to test.
As I mentioned gcc doesn’t work. I need to tear more into DJGPP
to see how they did it or just use it’s gcc driver to run this.
In the test directory I’ve mimic’d what a Linux 0.11 install does when compiling
a single file into an exe.
and it’ll compile hello.c into hello.
C:\aoutgcc>..\bin\cpp -v -I../include-0.12 -undef -D__GNUC__ -Dunix -Di386 -Dlinux -D__unix__ -D__i386__ -D__linux__ hello.c C:\Users\neozeed\AppData\Local\Temp\001.cpp
GNU CPP version 1.40
C:\aoutgcc>..\bin\cc1 C:\Users\neozeed\AppData\Local\Temp\001.cpp -quiet -dumpbase hello.c -version -o C:\Users\neozeed\AppData\Local\Temp\001.s
GNU C version 1.40 (80386, BSD syntax) compiled by GNU C version 5.1.0.
default target switches: -m80387