Multiplayer Macintosh Plus via Javascript/

I found this fun page over on  What is interesting is that it encorporates PeerJS and WebRTC to allow for a virtual network, letting you play multiplayer AppleTalk.  Just enable the network, and scan for other users.

It’s pretty cool, in a zero config kind of way!


And for coolness it’ll embed in a snazzy picture of a Mac Plus.  Although you can magnify the screen, so you don’t have to squint so much.

MachTen 2.2

MachTen console

Not that I need another UNIX, but I came across this fine thing googling around for some Mach based OS’s running on the 68000, and well here is MachTen.  Perhaps the most notable thing about MachTen is that it is capable of running in usermode under MacOS.  Without a MMU.

# cc -v hi.c -o hi
gcc version 1.40
 /usr/local/PMtools/cpp -v -undef -D__GNUC__ -Dunix -D__MACHTEN__ -DMACHTEN -DTENON -D__unix__ -D____MACHTEN____ -D__MACHTEN__ -D__TENON__ -Dmc68000 hi.c /var/tmp/cc000093.cpp
GNU CPP version 1.40
 /usr/local/PMtools/cc1 /var/tmp/cc000093.cpp -fno-builtin-alloca -fno-defer-pop -quiet -dumpbase hi.c -version -o /var/tmp/cc000093.s
GNU C version 1.40 (68k, MIT syntax) compiled by GNU C version 2.3.3.
default target switches:
 as -mc68000 -o hi.o /var/tmp/cc000093.s
 ld -o hi -x /usr/lib/crt0.o hi.o -lc
# size hi
text    data    bss     dec     hex
11220   400     1672    13292   33ec
# ./hi

And yes, it even supports TCP/IP with it’s own TCP/IP stack.  It can even operate as a router of all things!  From a users point of view it is a little sparse, but it’s 4.3BSD, and thankfully includes the C compiler, so unlike of UNIX of the era on ‘small hardware’ this one isn’t crippled.

configuring TCP/IP

TCP/IP is configured through the MacOS via the control panel.  As you can see it can use AppleTalk, Ethernet and TokenRing interfaces.  For my simplicity, I’m just using SLiRP on the Ethernet, so it’s the old setup.  I re-compiled my BasiliskIII to redirect a port into the VM so I can telnet into it.

To install System 7.0.1 you need to set Basilisk II / Cockatrice III as a IIci. I went ahead and used this ROM.  The ROM however does expect there to be a FPU.

rom Mac-IIci.ROM
modelid 5
cpu 2
fpu true

Running however, I’ve been able to set the CPU to 3 or 4 (68030/68040) and it’s fine, I think the major thing is the modelid.  If I try this under System 8 which needs a 68040, then it’ll crash in spectacular ways.  You don’t need MacTCP as again MachTen is a 4.3BSD kernel with Mach 2.5, so it has it’s own.

MachTen also includes support for NFS!  This greatly eases getting data in & out of the system.  To mount my Synology I just need the following command:

mount -t nfs -o timeo=1,retry=1,rsize=512,wsize=512,retrans=1 /mnt/data

And I’m good to go!

Cross GCC from Windows to AmigaDOS

GCC 2.7 to AmigaDOS 2.04

GCC 2.7 to AmigaDOS 2.04

Yes, I know there are others.  Newer versions of GCC too!.. but I was more so curious to see if I could do it.  I know there were GCC 1.x ports to the Amiga but I can’t find source anywhere.  And for some reason the Amiga and Atari ST seem to have never been mainlined into GCC.  I would have thought 1990-1992 they would have had far more users than say SUN-2/SUN-3.

Some ‘fixes’ are described in this file:

Although it’s not 100%.

I downloaded the files mentioned on this GCC page, and started to massage stuff.  This was easier as GCC 2.7 & Binutils 2.8 both support Windows NT 3.5 (and much much higher!).

I may want to try to get an ancient Nethack to build, so I put it onto sourceforge…


I’ve just tested a hello world type executable.  I’m more so amazed that it linked and executed, ‘file’ detects the objects as

x.o: raw G3 data, byte-padded

But at least the executables look right:

hi: AmigaOS loadseg()ble executable/binary

I had to hack all kinds of crap compiling eamiga.c
and eamiga_bss.c as neither generated correctly, and both had all kinds of missing and undefined things.  I’m sure on bigger projects it’d just explode, but right now I’m just amazed the linker could pick up my object, plus the 21 year old objects + libraries from that aforementioned ancient GCC port.

Oh well I was entertained for a couple hours.

Dungeon 2.5.6 on MacOS

Years and years ago I had bought this copy of Language Systems Fortran for MacOS with the intention of using my Quadra to build Dungeon for MacOS.  Except I couldn’t figure out the first thing about MPW, and life was always busy and I never did figure it out.  Well after getting GCC to compile something on MacOS, I thought I’d dig up some images I made of the disks, and without the benefit of having the manuals anymore see if I could figure it out.

FORTRAN Dungeon 2.5.6 on MacOS

FORTRAN Dungeon 2.5.6 on MacOS

And much to my amazement it compiled without any real issues.  All the EOF markers in the files had to be fixed up, and gdt.f for some reason was mangled at the end, but it was trivial to repair.  I didn’t bother trying to integrate the gettime call, so the clock and any clock events don’t work correctly.  I guess I should make the seconds increment by 15 between calls, or something.  Oh well I don’t think anyone will really care.  I compiled it for the 68020 with 68881 hooks, although I doubt it even makes any calls.  It runs for me.

If anyone cares, the binary is here:dungeon-2.5.6-m68k-MacOS.sit

As always, you’ll have to read the 404 screen to get the download.

GCC 1.37 on MacOS

I didn’t even know there was such a thing!

But sure enough, the file GNUMPW.SIT, and the later gcc-1.37.1r15-all.sea.bin are the real thing!  The file GNUMPW unstuffs to GCC 1.37.1r7(All), although Stuffit 5 and higher won’t unpack the file, I’ve converted it unpacking with version 4 & repacking with 5.5.

The readme from r7 is dated November 2nd, 1990.  I found some history on this port on the archives of the GCC mailing list here.  The port was done by Stan Shebs, while working for Apple.  As he states the port started in 1989 and was first used in an abandoned m68k based project, and later a possible replacement for the Apple compiler for OS 7.

For this experiment I was using the r15 version, as I didn’t find anything out about the prior versions until after I had written this.

GCC on MacOS needs the MPW environment, which for me is incredibly awkward to work with. While some people may love it, it is very strange in that you have to highlight commands in the window, then hit clover+enter to run them.  Like a mainframe, you can input commands wherever in the screen.

The next hardest thing was finding a version of MPW that will work with this.  It needs the MPW C compiler for it’s includes, and libraries.  The 3.5 stuff didn’t seem to work for me, however doing a LOT of searching, and I did find a ‘toast CD-ROM’ image‘ of 3.1 that includes all the C, and Assembler tools that I need to build an executable.

I also don’t know why, but running make just shows me what needs to be done, it never actually makes anything.  I’m probably doing something wrong, but for such a long dead tool, trying to find out how to use it, or how do you interrupt a “stream” like manually running cc1 is beyond me.  I just have to force quit the emulator.

But beyond that, running make gives me the steps, and I manually select and run the steps, and I was able to get a program to run!



I know it may not look like much, but getting it to actually run something was quite monumental for me!

I thought for the hell of it, I’d try to build the InfoTaskForce 1987 interpreter, but it seems to get confused at the whole input method.

Planetfall on MacOS

Planetfall on MPW

There were some issues compiling input.c, as it didn’t like the external table, so I made it’s own local table.  It also didn’t like some pointer arithmetic, but making GCC happy only gives me a program that can’t recognize any verbs.  And from there it won’t quit, basically hanging the system.

I’m sure I’m doing something wrong, but at the same time it was interesting to see GCC on MacOS, during the whole GNU boycott of Apple for the ‘look and feel’ lawsuit against Microsoft.  No doubt it let a lot of people sell other C compilers on the Mac Platform during this window of time.

GCC requires a 68020 processor, as GCC’s native 68000 based target would be SUN-2 hardware.  While it can compile with the -m68000 flag, I haven’t tested with a 68000 based emulator to see if that’s even true.  In the off chance someone wants a combined MPW+GCC I made a disk image here: MPW 3.1 with GCC 1.37.img.gz.  Disk Copy 6.3 should be able to mount it OK, or any emulator that likes HFS disk images.

More fun with GCC 6.1

So after looking at the -Ofast flags in that utterly unfair GCC 1.4 vs GCC 5.1, and 6.1 , I thought I’d try to build Cockatrice III with it.  Everything went well, and I had a build in no time.

I always hated how I had to massively downsample the audio so I could at least hear things, so I thought I’d try to put them back to 44100Khz, 16bit stereo.  And while compiling, older GCC runs fine, while 6.1 throws this run error!

../SDL/audio_sdl.cpp:57:43: error: narrowing conversion of '-1404829696' from 'int' to 'uint32 {aka unsigned int}' inside { } [-Wnarrowing]
 uint32 audio_sample_rates[] = {44100 << 16};
makefile:104: recipe for target 'obj/audio_sdl.o' failed
make: *** [obj/audio_sdl.o] Error 1

Well it turns out that it’s getting truncated as the audio_sample_rates are defined as an unsigned int, but it really want’s to be a regular integer.  So I changed the type, and now I have high def audio!  While I was in there, I fixed some stupid typos in the keyboard so I can actually use vi in MacMiNT.

It’s still in 256 colors, I’m missing something fundamental as to why it’s not working but I just don’t have enough time to mess with it today.

For anyone who cares, the Win32 binary package is on sourceforge.

UAE’s 68000 core actually was once in MAME

I was kind of surprised to find it.

While I was looking for System16 stuff, I found the first version of MAME to include the UAE 68000 core starting in release MAME 28, although System16 emulation itself didn’t appear until MAME 33b3, but not playable until MAME 33b4.

So what does it mean?  Well at the time the UAE core was the way to go.  However from looking at the MAME source, the UAE core that they were using from System16 was already generated, while UAE still included the build68k program to parse the tables, and generate the 68000.  Instead they were editing the outputted C.  UAE wasn’t GPL until version 0.7(something), 0.7.6 for sure, so I don’t know why they weren’t using it from the source.

Eventually starting in MAME 35b2, the core was replaced with MUSASHI , so Among their reasons for dumping the early UAE CPU core was this laundry list:

  • New 68000 C core. For testing purposes, this is also being used in the DOS
    version instead of the asm core. [Karl Stenerud]

1. Faster. This code is, barring ram fetch time, almost twice as fast as the
existing C core in MAME. I’ve done extensive speed profiling on both
engines. The only problem now is the slow memory access in MAME due to
bankswitching et al.

2. Emulation more correct. I found many bugs in the MAME engine (and many,
many more in mine for that matter) when I pitted them head-to-head.
I have run random instructions from each opcode class at least 10 million
times, comparing the resultant CPU states, and have left it running random
instructions for 1 billion iterations. In every case, I have adhered to
the specs defined in M68000PM/AD REV. 1.

3. Disassembler is correct. The current M68000 disassembler in mame has a
tendency to disassemble instructions that have an invalid EA mode.

4. Cycle counting is 99.9% correct. The only instructions which don’t have
correct cycle counts are divs, divu, muls, mulu, and they’re not worth
counting correctly. (I’m not about to waste emulation time counting 0-1 and
1-0 sequences).

5. > 32 bit friendly. I’ve taken care to ensure maximum portability without
sacrificing speed. The result is conditional compiling dependant on your
architecture. I’ve also implemented and tested a compatible solution for
architectures that lack 8, 16, or 32 bit signed storage types.

6. The code is carefully laid out to be readable.

Also in MAME 35b4 added in was emulation of the NEC uPD7759 chip for speech, fleshing out the System16 emulation.

To compile these ancient versions, and inbetween I was using my Candadian cross DJGPP GCC 4.12 Win32 cross compiler.  For Allegro I’ve always found it builds far easier using GCC, a vintage compiler from back in the day I could just run in DOSBox.

Alien Syndrome

Alien Syndrome

Obviously with today’s machines, these ancient versions of MAME run fine on DOSBox!  It’s really amazing in the scope of emulators running emulators.

I found the source code to UAE 0.4

Kickstart in colour!

Kickstart in colour!

Wow what a change from UAE 0.1!  We now have colour, mouse and keyboard input, so we can finally interact with the machine.  Behind the scenes the biggest change of course was the ‘Heroic effort’ of rewriting UAE from C++ into C.  It certainly made reading the code much more easier as nothing is implicit, like it is in C++.

From the changelog between versions 0.3 and 0.4:

960203 filesys.c, action_read(): Slightly more efficient code (translate Amiga
address to real pointer).
Moved some common code in the generate_* functions in gencpu.c to a
separate function.
960202 Added an experimental fast disk option. Currently turned off by
default (it's not such a big win).
Attached sprite fixes (overlapping att. sprites looked bad, Katakis).
Add sleep(1) before resetting the console to text mode when using
SVGAlib: this might fix some screen corruption problems.
Add sprite/playfield priority checking to the most important case
(single playfield, no HAM).
In filesys.c, do_find(): open() returns -1 on error, not zero.
Return ERROR_OBJECT_WRONG_TYPE if do_find() is called for a directory
(fixes Champions of Krynn harddisk installation).
960201 Don't abort if sound driver not present, just set produce_sound to 0.
New files keybuf.c and keybuf.h to record keypresses in the right
order and without losing any. In cia.c, force 15 scanlines between
keypresses, just to be sure.
unixfs.device <em>does</em> work with Kick 1.3: just don't trust what Kick 1.3
sends in the startup packet. For now, disable more than one mount per
command line.
Started integrating Ernesto's new Mac sources.
Remove superfluous includes from some files.
960131 Added Ed's unixfs.device (great stuff).
Adding ULONGs to pointers is a bad idea on the Alpha if the ULONG value
really is signed. Add some casts to LONG in (pc_p + src) expressions
in genpu.c.
If DMACON is written and copper DMA is enabled, do a COPJMP1 at once.
Helps the "Interference" demo.
960129 More SGI fixes from Ed. Bugfixes and transdisk improvements from Marcus
Remove EXTRA_DEFINES from Makefile. Breaks some systems.
Move common sprite code from pfield_doline() and pfield_doline_slow()
to new function pfield_sprite(). The same sprite may appear more than
once on the same line, so don't shift out the bits of sprdata[] and
sprdatb[] while displaying it (Turrican I).
In xwin.c and svga.c, barf if LINUX_SVGALIB doesn't match the file
being compiled.
Make all .o files depend on config.h in the Makefile.
No need to exit if sound driver unavailable, but -S given.
Small debugger fix: Missing space in output.
Fix for the sprite logic: Specifically, use a state variable indicating
whether the sprite has been restarted after a VSYNC. Fixes most
Turrican problems.
960124 Added Denis Sablic's patch for sound run-time option.
Added Ed Hanway's patch for better Makefile, X mouse cursor blanking
and more SGI compilation fixes.
960123 Include options.h everywhere.
Handle 8 bit GrayScale visuals like PseudoColor.
Remove C++ leftovers from joystick code.
960122 When using the joystick driver, the button test must come after
handle_events() in vsync_handler().
960118 Removed all the remaining C++ comments. Changed all inline keywords to
<strong>inline</strong>. Define <strong>inline</strong> if not using gcc.
Make proper prototypes for everything. Compile with maximum warnings +
-ansi + -pedantic.
Remove CIA_cycle(), obsolete.
Reimplemented the STOP optimization in newcpu.c. Removed DualCPU
support in CPU emulator.
Real nasty bug in pfield_doline() fixed: sprxpos could be evaluated as
negative, with not-so-amusing results. (Need to rewrite this in
Oberon to get array bounds checking :-)
960117 Heroic effort: Rewrote the thing in C. This might help fix some
problems with users being unable to compile it.
Fixed a problem in hsync_handler(): Only call flush_line() for lines
in the display window, i.e. when we did a prepare_line() before.
Better code for relative branches: Don't use setpc(getpc()+x) calls,
increment regs.pc_p instead.
960116 Reimplemented the function to load the Kickstart ROM. Use stdio instead
of fstreams since this apparently does not work on the Mac. Detect 256K
Kickstarts. Detect corrupt ROM images (calculate checksum).
Added Ernesto Corvi's Mac port. Changed it around a bit, so it
probably won't compile.
960115 Reinstate config.h options for X screen depth, so that DrawPixel() can
be inlined in for speed. xlinebuffer is now incremented in
each call to DrawPixel() (for both X and SVGAlib) to get rid of some
address calculations.
960114 Fixed X generic pixel drawing routine for SHM.
Still trying to fix the harddisk emulation.
uae.device no longer breaks the debugger (can step through uae.device
functions now)
Bugs affecting performance: SPCFLAG_STOP never got reset, and DSKLEN()
would set SPCFLAG_DISK even if DMA was being turned off.
Made slow memory a run-time option.
Defer interrupts by one CPU instruction to give programs a chance to
read INTREQR ("Seeing is Believing" and "Substance" demos)
Added ScrollLock hack for X, too.
960113 SVGAlib version compiles again. Fixed SVGAlib mouse bug.
Fixed SHM bug: Maximum scanline is 313, not 312.
Sometimes, missed a side change and would read the wrong data.
Fixed. Apparently, this was the worst compatibility problem.
Implemented trace mode.
960112 Changed layout of class amigamemory a little so that gcc can generate
better addressing modes.
Finally wrote functions in gencpu to generate MOVEMs.
960109 Integrated Ed Hanway's patches for better X support and run-time
configuration of some options.
Got rid of the direct VGA memory access. (Need to do this differently).
Changed the method of drawing lines: now tells the graphics
code the line number and whether it needs to be doubleed before drawing
Added Andre Beck's MIT-SHM patch.
Remove warnings for
960108 Fixed exceptions in op_illg(): Need to decrement PC.
960107 Added an "uae.device" resident module at 0xF00000. This emulates a hard
disk (fixed size 8MB for now).
960106 Moved some common code from pfield_doline() and pfield_doline_slow() to
a separate function. This fixes a potential HAM bug (two static vars
for the same value).
Sound support for Linux. Works only with graphics off and the CPU
slowed down.
Better SVGAlib keyboard support.
960105 Added AvailMem(), AllocMem(), AllocAbs() and FreeMem() dummies.
The Hardwired demo times the multiplication instructions and prints
"This demo don't like Axel" if they are too fast. Apparently, Axel has
a 68040. Added a WANT_SLOW_MULTIPLY option to config.h.
Fixed the fast blitter emulation (seems to work now).
960104 Fixed all the ChangeLog entries from 95 that said 96 (oops??!)
pfield_may_need_update() should check whether bitplane DMA is on.
Added and ersatz.h. The purpose of these files is to
implement one or two Kickstart functions that are commonly called from
bootblocks. This should help support some games and demos that only use
the Kickstart as an initial track loader. So far, it's only good enough
for one program.
951223 More intelligent event handling in the CPU emulator. Slightly faster.
951222 Optimize CPU emulation by inlining cctrue(). Also, the real PC no
longer needs to be incremented each instruction. The real PC value
now has to be fetched by m68k_getpc().
Added direct screen access for SVGAlib, but it didn't help much. I'll
probably remove it again.
The gencpu executable is 2M smaller if it allocates memory
951216 custom_bput() enhanced a little. Now remembers the value that was
written in the other half of the register.
Apparently, the USEx bits of BLTCON0 are ignored in line draw mode.

At this point it really does work.  However a machine of 2016 compared to 1996 is just too fast.  As a result it is once more again unusable.  But it makes sense that code from this era would be built to run as fast as possible, however when it really can run fast, watch out!

I found this code while trying to find other older versions and found a post about uae-0.4.hqx, as the hqx suffix denotes that this was the Macintosh port, which thankfully included all the source, and it looks like it pretty much left the source to UAE intact.

It didn’t take much to modify the xwin.c module into a suitable module for SDL, and I was able to get it running on Linux, and with a simple re-compile onto Windows. I did amputate the filesystem sharing code.  I could fix it I guess, but considering the insane speed of 0.4, it really doesn’t matter.  If you want to test it, simply copy a 512KB kickstart to “kick.rom” and copy an ADF diskette image to df0.adf, and start uae.  Unlike 0.1 this will start right away.

Approaching Aster

It is really far too fast to actually play, just tapping enter after launching is enough to propel you into space in Frontier for example.  And  as you can see from the egg shape of Aster, older versions of UAE use a 1:1 pixel emulation which stretches, and distorts objects.  And it doesn’t correctly detect the screen margins.  I guess if it were 1996 it would be worth the time for something like SDL 2.0 where you can close the primary screen, and create another matching the needed resolution on the fly.

For anyone who cares to try my modified version of UAE-0.4 I’ve placed it on sourceforge.

If anyone has any old versions of UAE kicking around, especially any of the 0.5 releases I’d love to know.  Every old version I’ve found is here.

UAE 0.1, the unusable Amiga emulator

UAE 0.1 on Windows 10

Through some crazy search, I actually found the source to UAE 0.1, the fist public release.  It’s very simple, and at the same time arguably one of the most important emulators for it’s time as it did show that you really could emulate in software a powerful machine like the Amiga.  And with some minor work, I got it to compile on Windows, with GCC 5.1.0

As a comparison here is UAE 0.1 on Linux (Debian 8)

UAE on Linux

UAE on Linux

In case it looks like UAE is somehow corrupt on Windows, it is displaying the same thing, except on Linux the X11 it displays the same thing, which is simply runing the 512kb AmigaDOS ROM.  I like version 2 or 3 since they have the diskette animation, but the static image will display from version 1.

For those of you who care, I archived the source here: uae-0.1.tar.gz, along with an archive over on sourceforge for every old version I could find.

UAE 0.1 is coded in C++, which only needed minor cleaning up.  More so how ‘modern’ machines now use <iostream> instead of <iostream.h> and of course adding:

using namespace std

to get things like cout and friends.

From the ancient announcement:

From: (Bernd Schmidt)
Newsgroups: comp.emulators.misc
Subject: Amiga emulator available (not a hoax!)
Date: 30 Aug 1995 11:59:20 GMT

I have uploaded uae-0.1.tar.gz to The
file should move to pub/Linux/system/Emulators in a few months time.

"UAE" stands for "The Unusable Amiga Emulator".  It is a partial software
emulation of the Amiga hardware.  It is far from usable, since some vital
features are missing, and it is way too slow.  However, it should put an
end to arguments that it can't be done.  There is quite a bit of room for
improvements, I expect a full (usable) emulation can be done in about five
years time.  Don't complain, C64 emulators need a P90, too, to run at full
speed, and an Amiga is somewhat more complex.

Although this is not a hoax emulator, it can't do more than that: It can
currently just display the Kickstart logo.  I have not been able to get the
disk support working yet.  Maybe someone would like to help me, I am rather
busy with other projects.  The sources are there...

UAE runs on Unix systems with the X Window System.  I am developing it
using Linux, but I have also been able to get it to run on a HP Apollo and
a Sun Sparcstation.  You need a C++ compiler, or you have to make small
modifications to turn it into a C program (nothing major).  You also need
to transfer a Kickstart ROM image to your PC.

The following parts are emulated:
  - MC68000 CPU: Almost done, some rare instructions (ABCD, ...) are not
    emulated yet.
  - Blitter: If there's no bug, it ought to be complete.
  - Copper: Not much to emulate here
  - Timers: I think these are fully working, too.

Not done properly:
  - Playfield (display) hardware: Only black &amp; white graphics, no dual
    playfield support, no HAM.
  - Sprites: None.
  - Sound: None.
  - Mouse, Keyboard, Joystick: None.
  - Timing: The CPU and blitter cycles are counted, but I have not bothered
    yet to adjust the timing to match the characteristics of a real A500

  - Floppy disk: Broken.

I think the hardest parts are done, except the disk support, debugging and
speed improvements.

Just as a side note: Maybe it might be easier to turn this into an Atari ST
emulation first, and debug that.  I think the ST has considerably less
hardware complexity.  If some ST experts would like to work on that, please
feel free to contact me.

Otherwise, mail me if you have comments, bug reports or enhacements.


Bernd Schmidt

How is that for awesome?

Once it was released naturally there was the temptation to think it was nothing more than a hoax, as there had been another program that did just that display the ‘insert disk’ image and crash a PC.  People were of course very skeptical that the emulator was even legit.

: Although this is not a hoax emulator, it can't do more than that: It can

: currently just display the Kickstart logo. I have not been able to get the
ha ha ha!! a few lines of code to display an image from a ROM file???

i think so! :)

....its the famous joke emulator thats appeared on Unix instead of a

And the denial was quite strong!

: If you had read, it comes with ALL SOURCE CODE. Go check for yourself.

so?? Its quite easy to knock up a load of source code that looks like it
does useful things....or emulation tasks such as emulate a few simple
CPU inst.

: Next time, read the post.

oh, i did, i did....

At this point in 1995, Commodore was dead. A German outfit, Escom had bought them out, but did nothing with it.  We were in the post Commodore International days, and it was painfully obvious that the IBM PC of all things was the machine that was going to rule the roost.  As VESA added millions of colors, and fast 32bit slots, stereo sound hardware, MIDI synths, and for OS/2 users, yes a 32bit preemptive multitasking OS.  Even Windows NT was somewhat usable, and the behemoth that was Windows 95 was just launched.

And honestly if the Commodore HPPA project Hombre had panned out, could Commodore really port exec to a different CPU?  Would they just push out a custom Windows NT workstation much like SGi’s Visual Workstation (info)?  I’m pretty sure that UAE would have been the silver bullet to their emulation gap of how to preserve 68000 Amiga software on the HPPA.  However as a Windows NT machine, Commodore would be reduced to a ‘fancy av card’ that may have carried them on.  I don’t think Commodore could have survived making Amiga’s into the late 1990’s and beyond.

Even 21 years later it was still incredible to fire up the first public version of UAE and get the ROM 2.0 animation of the diskette.  I know from other changelog’s that the DMA was broken, and that is why it cannot read disks.  I don’t know if it’s worth trying to hack in, maybe for another day.

If anyone cares to mess with it, I’ve put the source/binary on my site, and sourceforge as always deal with the passwords by reading the 404 page.

When you start up UAE 0.1, it’ll start in the debugger.  You’ll be greeted with:

D0: 00000000 D1: 00000000 D2: 00000000 D3: 00000000
D4: 00000000 D5: 00000000 D6: 00000000 D7: 00000000
A0: 00000000 A1: 00000000 A2: 00000000 A3: 00000000
A4: 00000000 A5: 00000000 A6: 00000000 A7: 11144ef9
T=0 S=1 X=0 N=0 Z=0 V=0 C=0 IMASK=0
00f800d2: 4ff8 0400 41f9 00f8 0000 LEA.L $400,A7
next PC: 00f800d6

It’s a primitive, but effective debugger to step through a program.  But we didn’t come here to do that, but rather load up the ROM, and if you have a version 2 or 3 ROM watch the animation.  Simply type in f and hit enter, and it’ll “run forever”.  On my Xeon it takes about 20 seconds until the Kickstart logo is displayed in black & white.

It’s still very cool to see this early emulator in action, and see where many modern systems first got their 68000 core from.

System 16

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  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 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.

Corrupt tiles

Corrupt tiles

Notice the sprites

Notice the sprites

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!

Altered Beast title screen

Altered Beast title screen

demo play

demo play

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.

For anyone interested you can find the source & binaries out on sourceforge.