Category: UAE

I’m starting with a much older version of UAE, as I wanted something basic to start with. I’ve wanted to do this for a while, but finally today I sat down with an ancient version of LibVNCServer 0.7, that doesn’t require me to spend hours tracking down all the cmake dependencies and other stuff, instead I could waste the day doing what I wanted to do, which was to remove the SDL display from UAE 0.4, and set it up so I can connect to it remotely.

I’ve always wanted to make some kind of multi-user server out of some stuff, and after seeing how some people do some crazy container bridge to do something like Basilisk II to X11 to VNC, out to some HTML5 viewer, I think it may be easier to just bake the VNC component directly into the emulator, almost in the way that Qemu does it, however for now I’m going to usurp the SDL code I added entirely.

It may be fun to also try something like DooM, and or Quake/QuakeWorld/Quake II.. But for me at least, this was the first big step.

More works needs to be done before I share it though, things like keyboard, and mouse input. Also it seems to crash from time to time while either disconnecting or connecting the VNC client. Naturally it runs best under GDB ……..

Behind it all is the Scripted Amiga Emulator. What is more interesting is that there has just been a MASSIVE update/rewrite to the project and it is now boasting far more features!

Looking at the features page, there has been quite a number of updates since the last version. The big ones (to me) is that the CPU core has been rewritten, and now supports not only the 68000, but the 68010, 68020, and 68030 (only with fake MMU). OCS, ECS and now AGA as well! Preset models include the 1000,500,2000,500+,600,3000 and 1200. IDE disk files can even be mounted for the 600 & 1200!

This one should have been much easier to build, it has support for SDL built in, however the include files are a nested mess, and configure fails part of the way in the process leaving the source kinda messy. But a few hours over a couple of days, and here we are.

This version doesn’t run at warp speed, has sound, and is great. It wants a config file though. You can find the specs in the readme, but something like this:

works fine. This later (and seemingly last) branch of UAE incorporates lots from WinUAE, except for the JIT. It’s dated 2008, so it does include support for the 68030, 68040, and the 68881 and 68882. It doesn’t have MMU support, so things like Linux/AMIX/NetBSD/Enforcer are out of the question.

I can’t find any source of the 0.5 versions, and I had issues with 0.6.x but with enough mashing of stuff around I did manage to get 0.7.6 to compile, then leaning more on the xwin.c source file I was able to get the SDL output working for 32bit depth (does anyone even have 8bit displays anymore?). I suppose with this version working I can go back and take a stab at resurrecting 0.6.x

What is cool is that 0.7.6 (perhaps earlier versions of 0.7?) switched from a non commercial license to the GPL 2.0 license.

I managed to ‘fix’ the keyboard in this version so that not only does it not type too fast, but it’ll remember “sticky” keys like shift, control & meta. So now you can actually use the CLI, and change disks. Double clicking is an impossibility as it simply runs far too fast. I compiled in audio support but didn’t bother with the SDL end, as it would sound like noise with it running so fast.

I also updated UAE 0.4, with the fixed keyboard code, and it’s usable now as well, with the same caveat that it simply is just too fast. UAE is from an era where a 100Mhz computer was a luxury item. Now some $5 computer, you could pack in breakfast cereal has a 1Ghz processor.

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]
Differences:

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 2.7.2.1, a vintage compiler from back in the day I could just run in DOSBox.

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.

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
Sundberg.
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 custom.cc 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, disk.cc 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: custom.cc now tells the graphics
code the line number and whether it needs to be doubleed before drawing
it.
Added Andre Beck's MIT-SHM patch.
Remove warnings for newcpu.cc.
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 ersatz.cc 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
dynamically.
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.
(Silents-Demo)

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.

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

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.

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: [email protected] (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 sunsite.unc.edu:pub/Linux/Incoming. 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.
Regards,
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 amibm.zip 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
MSDOS PC

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.

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.

I’ve never used the PowerPC stuff before, I had a 68030 accelerator in my Amiga 2000 going back some 15 years ago, and I never could justify the cost for the board vs a new PC as the Amiga was so super fringe back then.

So while I was on the path of running some ancient Linux on the UAE Amiga 3000 emulator but without any real luck. So for the heck of it I figured I’d give NetBSD a whirl. Much like Linux, the first platform other than the i386 to get some mainstream love.

While 4.4 BSD had been adding support for the m68k via the HP 9000-300 series based workstations, the Amiga was something that was sold retail, and could be put in the hands of hackers, rather than lab rats..

So yeah, NetBSD started to integrate Amiga patches as of NetBSD 0.9 as it says from the install notes:

This version is strictly for the kernel hackers among you, there’s no sense in `normal’ users trying to install it, possibly killing their other partitions, facing kernel panics and not knowing what to do. Please keep that in mind, if you feel like going on…

So maybe I’ll try to bring it back to life some time now that I can at least run NetBSD 1.0 .. Or maybe I’m getting ahead of myself.

Installing NetBSD 1.0 on the Amiga is somewhat straight forward, providing you are doing this from a new Amiga.. First just create a small-ish (15MB? lol) partition for AmigaDOS, and make sure it is bootable. The work partition should be big enough to hold the compressed packages of NetBSD, I went with 60MB, while NetBSD 1.0 is a mere 15MB, well compressed of course. After that you’ll want to create a ‘root’ partition of say 65MB, a 32MB swap partition and a giant /usr partition. I created a 384MB virtual hard disk, so my remainder is 209MB which is more than enough. From there you have to make sure that they are not set to auto mount, and edit the filesystem type to be the following:

Where the ‘other’ is of course the /usr partition. Then with that in hand it is a simple matter of loading the boot loader from within AmigaDOS. The one weird thing I found is that while this part goes all fine, later on under NetBSD you can only mount AmigaDOS partitions read only, so how do you get a new kernel back onto the Amiga side? I suppose a working network, and a 2nd machine.. Which would make sure, and of course NetBSD was built with the idea that everyone was collaborating over the internet so people would have net access.

So basically from within AmigaDOS you kick off the bootloader, kernel, and shove in a ‘root filesystem‘ diskette. Next thing you know we are going through the install where it’ll pick up the partition tags, format the disk, and go ahead and install.. Again another ‘trick’ is the partitioning scheme where NetBSD maps in the AmigaDOS partitions into NetBSD space. My install looks like this form the NetBSD side:

NetBSD slices

It may not seem too obvious but back here the ‘a’ partition is the root, ‘d’ is the AmigaDOS operating system partition while ‘e’ is the work partition where our install was saved. From there it really is NetBSD and it just acts like any other NetBSD. So of course I could prattle endlessly about this, how historic it is that NetBSD on the Amiga shows that the older hp300 port could not only be adapted to new platforms, but even eventually extended to support the 68040 processor which had a different and incompatible MMU.

For those of you are are impatient, you too can run NetBSD 1.0! You can find a pre-installed image here. And just use the prior exe & config from the WinUAE beta that included MMU support. Just alter the config so that it picks up the NetBSD disk.

NetBSD 1.0

The only catch I’ve seen so far is that trying to bring up the ethernet adapter hangs the system. Sadly I don’t have any fix for this as of yet…. (edit: yes beta 4 and beyond work fine!)