Mariko’s x68000 GCC 1.42 on Windows

Yes, I probably need a better hobby.

D:\proj\142\gcc-1.42_x68000>gccnew.exe -v -c x.c
gcc version 1.30 Tool#2(X680x0)
hcpp.exe -v -undef -D__GNUC__ -Dmc68000 -Dhuman68k -DHUMAN68K -DMARIKO_CC -Dmariko_cc -D__mc68000__ -D__human68k__ -D__HUMAN68K__ -D__MARIKO_CC__ -D__mariko_cc__ x.c C:\Users\jason\AppData\Local\Temp\x.cpp
GNU CPP version 1.30 Tool#2(X680x0)
hcc1.exe C:\Users\jason\AppData\Local\Temp\x.cpp -quiet -dumpbase x.c -fhuman -version -o C:\Users\jason\AppData\Local\Temp\x.s
GNU C version 1.30 Tool#2(X680x0) (HAS Ver 3.XX syntax)
compiled by GNU C version 5.1.0.
default target switches:
x.c: 5: Message:ì┼ôKë╗é═ìséφéΩé─éóé▄é╣é±
run68 has.x -e -w -u -i . C:\Users\jason\AppData\Local\Temp\x.s -o x.o
D:\proj\142\gcc-1.42_x68000>run68 ..\hlkb\hlk301.x x.o CLIB.L
D:\proj\142\gcc-1.42_x68000>run68 x
Hello x68000 from GCC 1.30 Tool#2(X680x0)!
D:\proj\142\gcc-1.42_x68000>ver

Microsoft Windows [Version 10.0.10586]

I’ve gotten the compiler to build natively as a win32, however the assembler & linker are x68000 programs that I run via run68.  libgcc.a is missing so there is no floating point support at all.  I have to figure out how to generate it.  Right now it’s using the SHARP/Hudson libraries on the C Compiler PRO-68K ver2.1 disks.

I don’t think this will be of value to anyone, but for the hell of it, you can download my incredibly rough port here.

gcc142_x68000.7z You really want this one instead: gcc-1-30-x68000

Linking doesn’t work by default, so you have to manually link, as what I did above.

Motorola 68000 Oral History Panel

Clocking in at just under three hours, I haven’t watched it, so no review I just found out about it.

Published on 2 Aug 2016

Moderated by Dave House, on 2007-07-23 in Austin, Texas, X4145.2008
© Computer History Museum

Panelists:Jack Browne, Murray Goldman, Thomas Gunter, Van Shahan, Billy D. Walker.

Members of the management, design, manufacturing, and marketing teams responsible for Motorola’s 68000 family of microprocessors and peripheral products discuss the evolution of their activities from the 1970s through the 1990s. The 68000 microprocessor line was critical to emergence of the workstation class of computer systems as well as to Apple Computer’s line of personal computers across the 1980s.

Murray Goldman, the executive who lead this segment of Motorola, describes the background for and strategy surrounding the 68000 effort. Thomas Gunter, who directed the 68000 program, provides a detailed technical accounting of the developments. Jack Browne, who led the marketing function, describes the importance of customer interactions. Bill Walker, who led the manufacturing function, details the hurdles faced in fabricating the 68000 family. Van Shahan, a member of the design team, lends important perspectives on the changes that the 68000 helped bring about from the era of centralized computing to decentralized and personal computing.

Visit computerhistory.org/collections/oralhistories/ for more information about the Computer History Museum’s Oral History Collection.

Lot Number: X4145.2008
Catalog Number: 102658109

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!

Ported System16 0.53 to Windows

To be honest, it was about 30 minutes worth of work to jump from Allegro 2.11 to Allegro 4.2.  I’ve never used it before, but the only ‘gotcha’ was how they handle the main to WinMain for linking.

At the end of your main procedure, you need to place the following code:

END_OF_MAIN()

And that is it! No semicolon either!

Last night I was playing with Musashi, and actually had the ‘demo’ program loading up the Altered Beast program, and running.  I just put in the memory areas to let it have read only to the ROM space, read write to the memory addresses, and write only to the IO ports.  It was enough for it to lock up in an endless loop like this:

E 3990: 4a38 f01c           : tst.b   $f01c.w
E 3994: 67fa                : beq     3990

Well some digging around and I found these vague hints:

Some special bytes:
F018: if bit5 is set 1, the screen is not updated
F01C: Timer ?
TimerA=&RAM[0xFF][0xF01C];
TimerB=&RAM[0xFF][0xF01E];

So it looks like it’s waiting for a shared memory value to be set to a ‘1’, so I setup the IRQ to include this nice hack:

offset=0x00FFf01c-0x00FF0000;
WRITE_BYTE(g_ram, offset,1);

And we were away.

So I thought I’d try to make the big step, as System16 v0.53 uses an ancient version of the UAE Amiga emulator, somewhere between 0.4 and 0.6, I think.  Anyways I was hoping to expand more and more functionality, and one thing SEGA did love to do was add more and more processors into their designs with some boards sporting up to three 68000 processors.  And Musashi can support multiple processors so, it seemed like a good fit.

So I amputated the UAE code, and tried to see how many functions System16 calls out from UAE, and it isn’t that much.  Most calls involve setting up emulation, and executing a single instruction. System16 handles all the memory access, Interrupts, and I/O.  So a few hours of bashing away I got it to link, and was greeted with a nice black screen.  I did remember that when I was first playing with the code, that even though the CPU was executing instructions nothing would be drawn without the external interrupt.  So I googled around and found another emulator, Virtual Jaguar, that also uses the Musashi 68000 CPU core.

So I could take the old UAE way of executing an interrupt from this:


void inline Exception(int nr, CPTR oldpc)
{
MakeSR();
#ifdef DEBUG_INT
TraceOn();
printf("Exception %0x, valeur = %0x, pc = %0x\n", nr, oldpc, m68k_getpc());
printf("Valeur de r�gistre SR = 0x%0x\n", regs.sr);
#endif
if(!regs.s) {
regs.a[7]=regs.isp;
regs.s=1;
}

regs.a[7] -= 4;
put_long (regs.a[7], m68k_getpc ());
regs.a[7] -= 2;
put_word (regs.a[7], regs.sr);
m68k_setpc(get_long(regs.vbr + 4*nr));

#ifdef DEBUG_INT
printf("VBR=%08x , NR=%d , I=%04x \n", regs.vbr, nr, regs.vbr+4*nr);
if (strace) printf("int jump 0x%0x\n", regs.pc);
#endif

regs.t1 = regs.t0 = regs.m = 0;
}

To this:


void inline Exception(int nr, CPTR oldpc)
{
unsigned int sr = m68ki_init_exception();
unsigned int newPC = cpu_read_long(nr<<2);

m68ki_stack_frame_3word(m68k_get_reg(0L, M68K_REG_PC),sr);
m68k_set_reg(M68K_REG_PC,newPC);
}

A quick recompile, and it was running!

Now with that in play, I went ahead and dumped all the old code, and the old Allegro, and went through re-building with Allegro 4.2 on Windows.  It didn’t take that long, I was really impressed!  At the same time I didn’t improve on anything in the slightest.

System16 v0.53 on Windows

System16 v0.53 on Windows

This is only a proof of concept, the fun hasn’t even started yet.  If you want a ‘solid’ emulator, go with MAME.  This isn’t anywhere near ready but it is interesting that it is running.  There is much more work to do with this, especially adding a Z80, and YM2151.

You can download the Win32 executable here.  You’ll need your own Altered Beast ROMs, it’s an ancient set, nothing that any recent download will map to.

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.

More fun with the System16, kinda, sorta?

So, Ive been playing around with emulators, and for some reason I think it’d be awesome to have a real one.  So I check ebay, and yeah there is a few, Altered Beast, Shinobi, and even an Outrun, and a couple of Hang Ons!  Wow this is so cool, then I check the prices, and shipping and yeah it’s REAL expensive, REAL quick.  And even back when I did own an Altered Beast board, I never got it hooked up as it was ‘too hard’.

So, I’m about to give up on the whole thing, then I spot this Altered Beast board, for sale for a mere €50!  And the shipping isn’t too insane either!  But looking at the PCB board in the picture, and I can tell something is not quite right:

€50 board!

€50 board!

Now for those who don’t know, this clearly is not a System16 board.  However it certainly does have a 68000, and z80 processor!  Could this be some 2nd tier manufacturing job? Or perhaps it’s one of these infamous bootleg boards?

For comparison, here is a real SEGA System16 board

A real System16 board

A real System16 board

As you can see, they really look nothing alike.  Also the other give away is that the far cheaper €50 board is JAMMA compatible.  All the old SEGA boards are not.

What the heck is JAMMA anyways?  You see that edge connector?  That is where you would plug in the power, coin catchers, the player buttons, and the speakers to.  Even in the old days, recycling cabinets was a thing, and having modular boards was a ‘good thing’.  But SEGA didn’t want you to swap out their boards with anyone elses, so they used their own system.  But it’s just a wiring thing, there is nothing digitial locked down, no encryption either (look at HDMI!).  So you can use an adapter, to interface from SEGA to JAMMA.

Anyways, I went ahead and placed the order.

Now doing some more research, and the monitors used in 1980’s arcades were RGB+Sync driven.  Which are ancient, and of course, HEAVY. But a little bit of searching led me to the to the GBS 8200 v4.0.

GBS 8200 v40

GBS 8200 v4.0

AKA known as the “GBS8200 CGA/EGA/YUV/RGB To VGA Arcade Game Video Converter”.  Well this certainly looks perfect!  I mean from the description alone, it’ll do what I want.  Even better they make them a few KM from here, and I could get one for ~ $20 USD.  Perfect.

Next up is the power, I decided to get a “JAMMA” power supply.  A bunch of searching, and this one was the cheapest one I could find, and again shipping wasn’t too bad, but not great either.  The supply was again around $20 USD, but shipping was $15. OUCH.

MD-9916A JAMMA switching power supply

MD-9916A JAMMA switching power supply

I figured having the ability to screw in would be a ‘good thing’.

Naturally, I need the cables to wire this mess together, so I ordered a “JAMMA Cabinet Wire Wiring Harness Loom” for about $15 USD.  Naturally mine is all in Chinese since I went cheap.  But it’s OK, I have a multi meter so I can test continuity.

Finally I saw a QANBA N1 arcade style joystick in a local mall for $230 HKD.  That is less than HALF the price of the ones I see online in the USA, Europe, or Canada.  So at least that is nice.  Now with all the parts, I just have to wait for the board to arrive.  And wait, and wait.  Nothing updated on ebay, then suddenly I check a few days later, as it’s been two weeks by this point, and it turns out that it’s been sitting in the post office in Hong Kong for a week!  If only they let me know…  SF Express, and FedEx have come without issues.  Oh well, now I have the board!

I can now finally flip it over to reveal:

Graphics board

Graphics board

It’s all 74L TTL logic chips, EEPROMS, and some PALs as well.  There are NO custom SEGA chips at all.  If anything this is what is inside of the SEGA ASIC’s on the System16 board.  Whoa.

Ok, so this is certainly a bootleg board.  A quick search of MAME shows that they have a Datsu ROMset, so maybe this is one?  Nothing on the boards say Datsu, however it does say ALTER/S, and it shows being QA’d on 11/11/88.

Now it’s time to cable this thing up!

But first JAMMA boards are typically key’d so you cant put the adapter in backwards.  There is no key on this board, so I need to check the voltages to make sure I don’t flip it backwards.

JAMMA Standard Pinout

** Solder Side Parts Side **




GND A 1 GND
GND B 2 GND
+5v C 3 +5v
+5v D 4 +5v
-5v E 5 -5v
+12v F 6 +12v
Key, No Pin H 7 Key, No Pin
Coin Counter 2 J 8 Coin Counter 1
Coin Lockout K 9 Coin Lockout
Speaker (-) L 10 Speaker (+)
NC M 11 NC
Video Analog Green N 12 Video Analog Red
Video Composite Sync P 13 Video Analog Blue
Service Switch R 14 Video Ground
Tilt/Slam S 15 Test
Coin B T 16 Coin A
Player 2 Start U 17 Player 1 Start
Player 2 X-Dir Player 2 Up V 18 Player 1 Up Player 1 X-Dir
Player 2 Y-Dir Player 2 Down W 19 Player 1 Down Player 1 Y-Dir
Player 2 X-Clk Player 2 Left X 20 Player 1 Left Player 1 X-Clk
Player 2 Y-Clk Player 2 Right Y 21 Player 1 Right Player 1 Y-Clk
Player 2 Button 1 Z 22 Player 1 Button 1
Player 2 Button 2 a 23 Player 1 Button 2
Player 2 Button 3 b 24 Player 1 Button 3
1 Player 2 Button 4 NC c 25 NC Player 1 Button 4 1
1 Player 2 Button 5 NC d 26 NC Player 1 Button 5 1
2 Player 2 Button 6 GND e 27 GND Player 1 Button 6 2
GND f 28 GND

This is the standard pinnout of a JAMMA harness. Importantly you can see it’s Ground than +5v.  So looking at the 68000 processor to check it’s pinnout:

D4 1 64 D5
D3 2 63 D6
D2 3 62 D7
D1 4 61 D8
D0 5 60 D9
AS 6 59 D10
UDS 7 58 D11
LDS 8 57 D12
R/W 9 56 D13
DTACK 10 55 D14
BG 11 54 D15
BGACK 12 53 GND
BR 13 52 A23
VCC 14 51 A22
CLK 15 50 A21
GND 16 49 VCC
HALT 17 48 A20
Reset 18 47 A19
VMA 19 46 A18
E 20 45 A17
VPA 21 44 A16
BERR 22 43 A15
IPL2 23 42 A14
IPL1 24 41 A13
IPL0 25 40 A12
FC2 26 39 A11
FC1 27 38 A10
FC0 28 37 A9
A1 29 36 A8
A2 30 35 A7
A3 31 34 A6
A4 32 33 A5
 You can see it’s power input is on pin 14.  Likewise, the ground is on pin 53.  Also looking at the edge connector, you can see the two pairs of pins, which correspond to the double ground, and double +5v.
Connecting the harness

Connecting the harness

From there, it was a matter of connecting up the power supply, adding in the power to the video board, connecting the RGBS connector, and powering it up.  It was very cool to get a glimpse of Altered Beast!

Something is wrong

Something is wrong

And hello, it is a Datsu board.  I’ve tried to google about these boards, and all that I could find out is that they seemed to be popular in Italy.  They may have been made in Korea.  There was another variation called ‘Mutant Warrior/Super Warrior‘.  There was some posts about it in an Italian game forum mameitalia.net, and arcadeitalia.net . Google translate works fine enough to read, but they were in smaller places that couldn’t afford mainstream games, so enter the bootlegs.  And this makes sense, as the board I got was from rural France.

I maybe had a picture for 20 seconds, it was frozen, then the screen went black.  I power cycled, to nothing.  I tried it again to a green screen.  And again to a green screen.  At this point I think it’s died.  I let it rest for a few minutes, and try again.  Nothing.  I leave it powered up, and feel the processor, and it’s warm.  It’s doing something, so I think.  So I start to play with the video board, and as I change resolutions, I get an image!.. then it disappears.  Power cycling, and changing resolutions occasionally gives me an image.  I look more closely at the CPU board, and notice that it has 4 standoffs placed on each corner.  There is nothing in the middle, and over the past 28 years the board is sagging.

In order to fix the sag, I decouple the two boards, and spread them out.  I try it again, and it doesn’t show me anything. Eventually I play with all the video board settings, and manually set it to the RGBS input, and then the image stays!  The board is running.  I tweek some of the settings, and the pink goes away, and now it looks correct!

20160430_110924

LOGO

And even the intro animation is OK

Looks good

Looks good

OK, now it’s time to turn it off, and wire up the joystick.

The first step is to remove the joystick ball, and on the QANBA N1 you first flip it upside down, and remove the little cover.

Remove the cover

Remove the cover

to reveal the screwdriver slot to let you hold the stick in place as you unscrew the ball.

slot

slot

Now it pops off, and it’s really easy to remove the USB interface cables, and drag in the JAMMA cables.  Again use a tester to tone out what goes where. DO NOT FOLLOW MY COLORING GUIDE.  I’m pretty sure there is no colour standard, so just because mine is like this, yours will 99.9999% not be.  The only common thing is that each of these buttons needs a ground.

Joystick wired up

Joystick wired up

My harness has a common ground for P1 and P2, so I just tapped up the end and tucked it in the joystick body.  Now with wired up, I can put the joystick back together, and play!

And that is when I could finally see that something was wrong.  I was doing pretty well, then in the 2nd level I saw this weird thing:

An actual wall of text

An actual wall of text

The sprites are working fine, and the gameplay continues.  But eventually the wall of text effect went from the background to the foreground obscuring game play.

foreground tile corruption

foreground tile corruption

So no doubt something is bad on the board.  I need to get it looked at, and see about first dumping and checking the EEPROMS.  Next the RAM on the graphics board, may be suspect as well.  I think the CPU is fine since it runs OK, I’m just unable to really see pass the wall.

For the heck of it, I went and got some powered speakers, and hooked them up:

And it sounds so different from the SEGA version.  An inspection of the board shows that there is no YM2151, but rather a pair of YM2203’s and an OKI M5205 for the speech synths.

In retrospect, I probably should have gone with something like the arcade supergun.  I didn’t know it was a thing unfortunately.  My solution is more “traditional” , but it works.

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

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 does 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
inline. Define inline 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: [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 & 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.