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:

https://raw.githubusercontent.com/sdenel/How-to-install-SimpleScalar-on-Ubuntu/master/Install-SimpleScalar.sh

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…

win32-amigados_hello.7z

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.

Cross compiling to the Amiga with Sozobon

To start this fun voyage, I used HCC, the first usable port of Sozobon C to the Amiga I could track down.  From it’s description:

Amiga port of Sozobon, Limited’s C Compiler. Can completely compile
itself, supports 32 bit ints, and optimizer can ‘registerize’ variables.
Includes compiler, optimizer, tool for creating interface code for Amiga
system calls, startup code, C library, include files, and library routines
that work with Motorola FFP format. Uses assembler A68k, linker BLink, and
provided run-time shared C library CClib.library.

And isn’t that great?  It even supports 32 bit integers!  I had to massage things in Visual C++, as there was some weird instances of return codes missing, and the optimizer not actually mallocing it’s memory, but just blindly using pointers.  As always if you can see what is going on in a debugger it’s not too hard to make some wild guesses and get it running, and if you get lucky it may even work too…

Running the compiler

With the compiler and optimizer running (it is actually needed to run to further massage the assembly output into something the Amiga a68k assembler can read), it was time to look at an assembler.  For the heck of it, I did try a68k, and to my amazement it did actually work, once I had updated the file output call.

hcc\hcc -L hanoi.c
hcc: version 2.0 Copyright (c) 1988,1989,1991 by Sozobon, Limited.
Amiga Version 1.1 by Detlef W³rkner.
hanoi.c:

top\top -v hanoi.s h2.s
top Version 2.00 Copyright (c) 1988-1991 by Sozobon, Limited.
Amiga Version 1.1 by Detlef W³rkner.
hanoi.s:
Peephole changes (1): 8
Peephole changes (2): 1
Peephole changes (3): 0
Instructions deleted: 3
Variables registered: 0
Loop rotations : 0
Branch reversals : 0
Branches removed : 4

a68k\a68k -q100 h2.s
68000 Assembler - version 2.61 (January 11, 1990)
Copyright 1985 by Brian R. Anderson
AmigaDOS conversion copyright 1989 by Charlie Gibbs.

Assembling h2.s
PASS 1 line 59
PASS 2 line 59
End of assembly - no errors were found.
Heap usage: -w2047,80
Total hunk sizes: 94 code, 10 data, 0 BSS

linking

wow wasn’t that fun! I haven’t seen the source code to the BLINK linker, so I just end up using a native linker, BLINK.

Towers of Hanoi

Towers of Hanoi

Much to my amazement, the a68k assembler functions just fine as a cross assembler, and I only had to copy the object file into the emulator, and I could happily link.

The syntax for BLINK was a little strange, mostly because I really don’t know what I’m doing.

BLink LIB:HCC.o+hanoi.o LIB LIB:HCC.lib+LIB:stubs.lib TO hanoi SC SD VERBOSE

Now to try something bigger, like the ancient 1987 vintage InfoTaskForce.  I had to add in the include files from the DICE compiler, and surprisingly, in no time, it was all compiled, and assembled the only step remaining was to run the BLINK linker.  This time it was slightly different as now we had a bunch of object files:

BLink LIB:HCC.o+fileo.o+funcso.o+infocomo.o+inito.o+inputo.o+interpo.o+ioo.o+jumpo.o+objecto.o+optionso.o+pageo.o+printo.o+propertyo.o+supporto.o+variableo.o LIB LIB:HCC.lib+LIB:stubs.lib TO infocom SC SD VERBOSE

Running that as a single line (or better in a command file) got me my executable.

Linking

Linking

And it linked without any unresolved externals.

InfoTaskForce cross compiled on Windows, linked on AmigaDOS 2.0

InfoTaskForce cross compiled on Windows, linked on AmigaDOS 2.0

Running under WinUAE

And even better, it worked. Here it is running Planetfall!

I can’t imagine it being all that useful for anyone, as Sozobon C is K&R C, and well this is for the Commodore Amiga, not exactly a mainstay in this day & age.

HCC_Sozobon_win32cross.7z This link will take you to the sourceforge page, and the archive contains both source, and executables.  As mentioned I didn’t see any Amiga linker that has source code, it seems everyone use BLINK, and the team that write BLINK went on to re-write all the ‘c’ commands in AmigaDOS from BCPL/asm into C.

***

Addendum

I just discovered vlink after writing this, and now I can link a working executable under Windows 10! Since I made zero changes to vlink, and I’m not charging money, I am free to redistribute this so I’ve updated my archive, and included it.

Scripted Amiga Update & hosting at archive.org

I saw this awesome link over at archive.org’s software Library featuring the Amiga

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!

In addition is support for the Amiga 1000 velvet prototype, and even now has the ability to have an AMAX (Macintosh emulation) cartridge port.

R-Type on SAE

R-Type on SAE

I’d highly recommend the internet archive link, you can jump right into some great Amiga action with nothing to download or install!

WinUAE 3.3.0 released

WinUAE 3.3.0 (06.06.2016)
=========================

New features:

- New optional "indirect" UAE expansion trap system, fully compatible
  with OS 4.x, virtual memory and some debugging programs.
- PC Bridgeboard disk drive raw image support. (ipf, ext adf,...)
- Monochrome video out emulation, including A1000 color/mono video
  out software control (BPLCON0 COLOR bit).
- Dark palette fix option to correct colors of badly ported Atari ST
  games (Midnight Resistance etc..)
- Official CSPPC/BPPC flash updater can be used to install full ROM
  image without having existing ROM image file.
- Custom input events can execute Amiga-side commands and scripts.
- Windows clipboard to emulated Amiga keyboard paste support.
- Variable refresh rate optimized vsync mode (G-Sync/FreeSync).
- Black frame injection is supported in variable refresh modes.
- IVS Trumpcard Pro/GrandSlam SCSI emulation.

OS4.x supported UAE expansions:

- Directory harddrives, including on the fly insertion/removal.
- CDFS CD mounting.
- Clipboard sharing.
- uaegfx RTG.
- uaehf.device hardfiles.
- Virtual mouse driver/magic mouse/tablet mode.
- uaenet.device.
- uaeserial.device.
- uaescsi.device.
- uae.resource.
- uaenative.library.

Thanks to all who donated.

NOTE: Performance is not (and can't be) as fast as with m68k AmigaOS,
especially with directory harddrives, due to slower, much more
complex UAE to/from native code context switch trap system.

Updates:

- Game Ports panel input customization is finally very intuitive.
- On the fly input device insertion/removal improvements.
- Many input device handling updates and fixes.
- Faster screenshot/capture in after filtering mode.
- Continuous screenshot mode.
- CD32 Akiko chip low level emulation compatibility improved.
- Nero .nrg CD image support.

Bug fixes:

- Hardware RTG emulation rendered same frame twice in some situations
  causing slow performance.
- Amithlon partition type (0x78/0x30) support works again.
- Some storage devices failed to mount as a harddrive.
- AGA subpixel scrolling glitches.
- Miscellaneous custom chipset emulation fixes.
- AGA mode HAM6 colors were not 100% accurate.
- Some programmed custom chipset display modes crashed.
- Direct3D mode DirectX9 not installed warning corrupted memory.
- Fullscreen + paused + enter GUI: GUI was invisible.
- Display panel gamma value calculation fixed.
- CDFS automount didn't mount CDs with empty label.

Download WinUAE 3.3.0 [installer] [zip-archive] [zip-archive, 64-bit version] [PPC core plugin, WinUAE 3.0 or later]

Download WinUAE extension packages [1.5.1+ Direct3D Pixel Shader filters](Latest DirectX required) [Improved drive sounds] [Portaudio library]

Download translation DLL: [Default (English)]

Captain Blood reverse engineering project

I found this the other day, and I thought it was pretty damned impressive.

Fractal viewer in C#

Fractal viewer in C#

Kroah has taken the time to reverse how the fractals worked in Captain Blood.  From bringerp.free.fr:

The procedural terrain generator uses 1D fractional brownian motion (fBm) with random mid-point displacement. Up to 10 curves are displayed on screen.

When a new curve appears at the horizon, 7 vertices are computed. Then mid-point displacement with fBm are applied to thes 7 initial points. This results in a discrete curve of 512 samples.

The random number generator and the fBm Hurst parameter H are adapted according to the current terrain type (flat, canyon…). This gives very different visual landscapes (plains, moutains, desert…).

No more fractal computation is done on the discrete curve. When a curve is drawn, only 256 of the 512 samples are used (according to the position of the Oorxx).

The view is 256 pixels wide, so if the visible part of the curve is larger than the 256 samples, the curve will be drawn zoomed with pixels linearly interpolated between the samples. Otherwise the curve will be drawn shrinked without any interpolation and using only some of the 256 samples.

The raytraced fractal landscape is computed from these 10 curves.

It’s pretty amazing to think that there was that much behind the game.

I played this back in 1988 on the lowly Commodore 64, but the Amiga version was simply amazing.  Such was technology back then.

UAE 0.8.29 on Windows

Captain Blood on UAE 0.8.29

Captain Blood on UAE 0.8.29

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:

#cpu_type=68030/68882
cpu_type=68040
cpu_speed=real
sound_channels=stereo
sound_bits=16
sound_frequency=44100
gfx_center_vertical=true
gfx_center_horizontal=true
gfx_color_mode=32bit
floppy0=df0.adf

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 dumped my source tree over on sourceforge, as I’m more so interested that this builds using MinGW.

Ported UAE 0.7.6 to MinGW!

0.7.6

0.7.6

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.

For the 2/3 people who care, I put the binary & source tree on sourceforge here. UAE 0.4 & UAE 0.1 are also available for download, plus all the source code I’ve been able to find.

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

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: crux@informatik.rwth-aachen.de (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.

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:


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