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.
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
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.
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.
Now for me, GCC 7 didn’t build the source cleanly. I had to make a change to the file config-host.mak and remove all references to -Werror. Also I removed the sound hooks, as we won’t need them. remove the following lines:
Now you can build Qemu. it’ll happily build in parallel so feel free to build using the -j parameter with how many cores you have. I have 32, so I use
Now telnet to your localhost on port 4441 and you will see the console doing it’s BIOS initialize and eventually drop to the OK prompt.
One trick I’ve found is that from the Open Firmware prompt you can find out what partitions are recognized from the firmware. If it see’s partitions then there is some hope that the image you have is valid enough to boot. In the last few days I’ve found quite a few AIX images, which are lacking the partition table, and unable to boot.
simply type in boot cdrom:2 to kick off the installer. It may take a minute or so for the installer to kick off.
If all goes well, you’ll see the BIOS reload itself, then after a minute you’ll be prompted to press 1 to select the console
It doesn’t echo, don’t panic!
Next select your language. I’m doing English.
Next it’ll ask about installation type. Default ought to be fine.
Because this will destroy the contents of the disk (which doesn’t matter as it’s blank) it’ll prompt for confirmation.
After this it’ll begin the installation. Depending on how fast your disk & CPU is this will take a while.
For me, the installation took about 11 minutes. This is using my Xeon E5-2667 v2. It took 17 minutes on my 2006 Mac Pro, with X5365’s it .
After it’s done, right around the 96% time it’ll reboot back to the BIOS
Once you are back at the OK prompt, you can now boot disk:
it’ll look like it’s hung for a minute, then it’ll start booting from disk!
Once the OS is booted up, you select the terminal type. I’m using putty but I’ll select the vt100. Of note the function keys are selected by hitting escape and then the number key. So F3 is ESC 3.
I’m just going to finish the install, as we can always run smitty to mess with the system more, but right now I’m just interested in a base install of the BOS (Base Operating System, and IBM ISM).
A few moments later, you’ll get dumped to the login prompt.
By default there is no password, so just login as root, and there you go, your very own virtual AIX 4.3 system.
# uname -a
AIX localhost 3 4 000000004C00
So there you go! All thanks to Artyom’s hard work!
So I woke up to this incredible news. Jason Scott at the most excellent archive.org had just uploaded the old Infocom source code to github. It’s from the infamous ‘found hard disk’ that has been mentioned going back to the failed game ‘The restaurant at the end of the universe’.
So looking at the repos here, you can see the latest ones are all Infocom. It’s best to get them all via git for reason below:
The reason being of course that if there are multiple versions they are stacked. Now why is this important? Who cares? it’s all in ZILL which there is no compiler for, as the TOPS-20 tools are still lost?
The source for the Final version won’t build with ZILF. However the Revision 37 source will!
$ git checkout 281bd3417faada8011397244d4bfaad562cb7bfc
Note: checking out '281bd3417faada8011397244d4bfaad562cb7bfc'.
You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.
If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:
git checkout -b <new-branch-name>
HEAD is now at 281bd34... Revision 37 (Original Source)
Ok, now let’s trash the directory! (you did backup the repo first, right?)
ZILF 0.8 built 3/19/2017 1:34:17 PM
[warning MDL0417] C:\temp\zilf\zilf-0.8\planetfall\MISC.zil:509: ROUTINE: only 3 routine arguments allowed in V3, so last 2 "OPT" arguments will never be passed
in INSERT-FILE called at planetfall.zil:14
in IFILE called at planetfall.zil:25
[warning ZIL0208] C:\temp\zilf\zilf-0.8\planetfall\SYNTAX.zil:143: preaction routine mismatch for 'V?ZAP': using PRE-ZAP as before
[error ZIL0113] C:\temp\zilf\zilf-0.8\planetfall\MISC.zil:150: SETG: argument 1: bare atom argument must be a variable name
[error ZIL0113] C:\temp\zilf\zilf-0.8\planetfall\MISC.zil:315: SETG: argument 1: bare atom argument must be a variable name
[error ZIL0113] C:\temp\zilf\zilf-0.8\planetfall\MISC.zil:317: SETG: argument 1: bare atom argument must be a variable name
[error ZIL0113] C:\temp\zilf\zilf-0.8\planetfall\MISC.zil:319: SETG: argument 1: bare atom argument must be a variable name
[warning ZIL0504] C:\temp\zilf\zilf-0.8\planetfall\PARSER.zil:244: treating SET to 0 as true here
[warning ZIL0502] C:\temp\zilf\zilf-0.8\planetfall\VERBS.zil:156: RETURN value ignored: block is in void context
[warning ZIL0204] C:\temp\zilf\zilf-0.8\planetfall\VERBS.zil:1879: no such global variable 'WHERE', using the local instead
[warning ZIL0505] C:\temp\zilf\zilf-0.8\planetfall\COMPTWO.zil:3035: COND: clauses after else part will never be evaluated
[warning ZIL0308] <top level>: too many parts of speech for 'PORT': Object (C:\temp\zilf\zilf-0.8\planetfall\GLOBALS.zil:78), Adjective (C:\temp\zilf\zilf-0.8\planetfall\GLOBALS.zil:224), Direction (C:\temp\zilf\zilf-0.8\planetfall\GLOBALS.zil:11)
[warning ZIL0306] C:\temp\zilf\zilf-0.8\planetfall\GLOBALS.zil:224: discarding the Adjective part of speech for 'PORT'
[warning ZIL0308] <top level>: too many parts of speech for 'BRUSH': Object (C:\temp\zilf\zilf-0.8\planetfall\GLOBALS.zil:548), Adjective (C:\temp\zilf\zilf-0.8\planetfall\GLOBALS.zil:549), Verb (C:\temp\zilf\zilf-0.8\planetfall\SYNTAX.zil:283)
[warning ZIL0306] C:\temp\zilf\zilf-0.8\planetfall\GLOBALS.zil:549: discarding the Adjective part of speech for 'BRUSH'
Volume in drive C is BOOTCAMP
Volume Serial Number is 903B-72D4
Directory of C:\temp\zilf\zilf-0.8\planetfall
04/17/2019 08:32 PM 247,803 planetfall.zap
04/17/2019 08:32 PM 162,476 planetfall_data.zap
04/17/2019 08:32 PM 1,336 planetfall_freq.zap
04/17/2019 08:32 PM 40,495 planetfall_str.zap
4 File(s) 452,110 bytes
0 Dir(s) 238,542,704,640 bytes free
Wrote 121952 bytes to planetfall.z3
Sure it said 4 errors, but it compiled! Using a z3 or higher interpreter we can load up Planetfall
At first glance it may look the same, but check the serial number. 190417. That’s today!
I’ve had this 2006 MacPro for quite a while. I’ve taken it home as didn’t have a ‘good’ home machine as I have my better stuff in the office. Anyways the machine is far obsolete with 10.7 being the last official release supported, and although you can treat it like a hackintosh and go much further, Apple is making their binaries tuned heavy enough that all the spectre/meltdown patches broke the old Xeons.
So I installed Windows 10, and found I can go all the way to 1809 without any issues. I put in a GT 1030 with DDR5 RAM and it can even game to extent, although the 13 year old 2Ghz processors were certainly holding it down. Upgrade processors have always been available when I had this machine but they were expensive, and I wasn’t sure if they’d work. Well I picked up a pair of Xeon x5365 for $88 RMB each and pulled the plug.
I thought the thing to do was a quick benchmark of before and after. I was getting a whopping 167! That means if Cinebench scales to 100% efficiency I get a core score of 41. While my ‘newer’ machine’s E5-2620 v2 was scoring 52, and the current E5-2667 v2 is scoring 77.
It took two hours, but I finally got these 2 Xeon x5365’s installed giving me a score of 560, or a score of 70 per core. Nice!
If you are expecting to run new and exciting software that requires SSE4/SSE4.1/SSE4.2 and the infamous POPCNT and LZCNT instructions you will be disappointed. Sorry Apex Legends fans. This also means that VMware Player is capped to version 12.
Another thing worth noting is that it’s worth looking at the TDP of the various sSPEC of Xeons. I was lucky and I was able to source the SLAED variation which has half the idle TDP of the SLAC3 variant.
So yeah, this is basically as far as this thing can go CPU wise. Although I have 16GB of RAM, apparently it can go to 32GB, which means buying all new memory modules. I guess I can do a better video card. I’m hoping that I can run more stuff at once, I was hitting a point with all 4 cores were maxed to 100% way too much.
I was going to show off the new CPU’s but apparently the pictures didn’t come out and I wanted to get this upgrade over with, as I had mentioned it did take 2 hours. The plastic retainer in the memory cage, and that stupid cover for the processors was the hardest PITA to remove. I probably spent at least 30 minutes pulling that damned thing off. I never removed the CPU shield before and 13 years, 3 nations, 2 continents worth of dust was unreal. Maybe it’s just as well the pictures didn’t come out, as it was pretty disgusting in there. It’s also no wonder the old CPU’s were running hot.
I wonder if this machine counts as being vintage now? Apple’s sliding scale of support is a weird thing.
What is cool about these versions is that they do have some audio capabilities, although they are so old that they do rely on sampled sounds for:
But it’s from 1999 and that was the state of emulation.
0.82 is basically where the project had left off, and was of course supplanted by MAME. There was preliminary work on AfterBurner 2, although there is from the looks of it a bad/partial ROM dump to blame for the most part. It’s unplayable but it sort of runs the demo.
0.82 does however emulate a strange version of OutRun. Namely that it lacks shifter support all together. So hold down the accelerator and take off!
Notable things is the inclusion of Neill Corlett’s Starscream for 68000 emulation, Neil Bradley’s Mz80, Jarek Burczynski’s YM2151. Which reflects many components of the era that would find their way into MAME.
Which of course speaks to another thing, that tracking down ROMs for these ancient pre-mame emulators is getting impossible with vague names, and no timestamps.
Btw, there is two excellent pages where you can get all the roms supported by this emulator, these pages are : http://www.davesclassics.com by Conjurer and http://www.emuviews.com by JoseQ
Which naturally, are lost to the mists of time.
I’ve been able to run it under DOSBox, Qemu and VMWare. For VMWare, be sure to enable Sound Blaster emulation, and set the BLASTER environment variable to:
SET BLASTER=A220 I5 D1 H7 P330 T6
The video mode for the start screen doesn’t render on VMWare or Qemu, so in that case I just start it with the following batch file
I don’t have the FPS stats as it’ll crash when going to the menu to exit, and I didn’t hack up the source that much at the moment (caught another flu…). But Qemu 0.90 feels a LOT more fluid playing outrun than VMWare or DOSBox on my 2006 Mac Pro. Although on my 32 core Xeon monster it plays great on everything. I guess if you have at least 3Ghz and your CPU is less than 8 years old it’ll be fine for running nested emulation along with emulating 2 68000’s a z80, and a ym2151. Or just run a native build of MAME! Or if you really want low lag Outrun, use Cannonball!
And thanks again to Thierry Lescot for letting me redistribute this