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.
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.
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.
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
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.
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.
And it linked without any unresolved externals.
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.
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.
DooM is without a doubt one of the most popular PC games of all time. And thanks to it being written in C is also an incredibly portable game. One platform that mysteriously was lacking DooM was the SHARP x68000.
After a bored day of playing with the source to Mariko’s GCC 1.42 / 1.30 that targets the x68000, I thought I would take a stab at trying to compile DooM. Since I’m using such an ancient version of GCC the first stumbling block is that DooM is FULL of C++ style comments, which older K&R & ansi based compilers of the late 1980’s simply cannot handle. So the first phase was to convert all the comments.
In order to convert the comments, I came across this great tool, uncrustify. The pain is that it doesn’t seem to take wildcards, but you can use make to have it do your work for you, or just a batch file…
uncrustify.exe --replace -c 1.cfg cl_main.h
you get the idea.
The key thing is the configuration file that tells uncrustify what to do. To convert C++ comments to C is quite simply:
cmt_cpp_to_c = true
And away we go. Having learned the ‘null’ lesson of Quake 2 the hard way, I started out with a working copy from Windows, via GCC 1.40 for Windows/RSXNT. I figured that by having a ‘known good’ build with the a very close compiler level would be a good start as I don’t want to fight too much with the compiler. After it was running with minimal changes, it was time to start the real fun.
Starting the actual port aka platform issues
The first error I hit was:
Error: Couldn’t realloc lumpinfo
For some reason the SHARP/Hudson LIBC has issues doing a realloc. I have no idea why. Over on nfggames Neko68k had mentioned that he had a disk image with a working version of GCC, that uses different includes/libraries that was able to get further. I wasted some time by trying to bypass the Sharp LIBC malloc function by calling the HumanOS’s malloc directly which did get further but ran into issues when switching from usermode to supervisor mode to directly access the hardware. Once when he shared his disk image, I was able to see how his GCC setup worked, and more importantly linked, so I could alter the GCC cross compiler I was using, and get much further in terms of progress. I could then get from failing malloc to this:
And from there after trying different assemblers, flags, and all kinds of other things we could finally get null DooM running on the x68000 via 68030 emulation on XM6 TypeG.
DooM comes to life
From there, Neko68k was able to do something amazing, add in system support! Which to be honest would have taken me forever to do, I was more impressed that I was even able to get the null version running, but Neko68k blew me away with this:
There is no correct palette setup at this point, there is all kinds of issues but you can see the startup logo being painted!
Then with a lot of improvements, and an added keyboard driver it was starting to look like DooM!
And then Neko68k had a major breakthrough with the video, timer and keyboard, and we now have a playable port!
Issues while cross compiling
Around this time I had noticed that when I built a cross compiled version the video for me was garbled. After some investigating it turns out that m_swap was not being compiled correctly but rather the endian order was being reversed!
I tried re-building, re-configuring my host setup, and I still had the same issue. I tried downloading GCC 1.42 and building an i386 SYSV to AT&T 3b1 cross compiler as it too is 68000 based, and I got the same issue. Maybe it’s a bug in GCC 1.x cross compilers? I don’t know, but since the procedure is small enough, it was easier to just have the native GCC produce an assembly version which I just assemble and link without issue.
Behold! DooM on the x68030!
Yes, there is no audio, but wow it’s playable! I do need to map the keyboard better in the emulator, but the key layout in the source is fine.
For anyone who cares you can follow more of the porting adventure here:
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
Hello x68000 from GCC 1.30 Tool#2(X680x0)!
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.
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.
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!
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:
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 ?
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:
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)
unsigned int sr = m68ki_init_exception();
unsigned int newPC = cpu_read_long(nr<<2);
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.
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.
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.
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:
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
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.
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.
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:
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
Key, No Pin
Key, No Pin
Coin Counter 2
Coin Counter 1
Video Analog Green
Video Analog Red
Video Composite Sync
Video Analog Blue
Player 2 Start
Player 1 Start
Player 2 X-Dir
Player 2 Up
Player 1 Up
Player 1 X-Dir
Player 2 Y-Dir
Player 2 Down
Player 1 Down
Player 1 Y-Dir
Player 2 X-Clk
Player 2 Left
Player 1 Left
Player 1 X-Clk
Player 2 Y-Clk
Player 2 Right
Player 1 Right
Player 1 Y-Clk
Player 2 Button 1
Player 1 Button 1
Player 2 Button 2
Player 1 Button 2
Player 2 Button 3
Player 1 Button 3
1 Player 2 Button 4
Player 1 Button 4 1
1 Player 2 Button 5
Player 1 Button 5 1
2 Player 2 Button 6
Player 1 Button 6 2
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:
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.
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!
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!
And even the intro animation is OK
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.
to reveal the screwdriver slot to let you hold the stick in place as you unscrew the ball.
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.
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:
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.
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.
While I was looking for System16 stuff, I found the first version of MAME to include the UAE 68000 core starting in release MAME 28, although System16 emulation itself didn’t appear until MAME 33b3, but not playable until MAME 33b4.
So what does it mean? Well at the time the UAE core was the way to go. However from looking at the MAME source, the UAE core that they were using from System16 was already generated, while UAE still included the build68k program to parse the tables, and generate the 68000. Instead they were editing the outputted C. UAE wasn’t GPL until version 0.7(something), 0.7.6 for sure, so I don’t know why they weren’t using it from the source.
Eventually starting in MAME 35b2, the core was replaced with MUSASHI , so Among their reasons for dumping the early UAE CPU core was this laundry list:
New 68000 C core. For testing purposes, this is also being used in the DOS
version instead of the asm core. [Karl Stenerud]
1. Faster. This code is, barring ram fetch time, almost twice as fast as the existing C core in MAME. I’ve done extensive speed profiling on both engines. The only problem now is the slow memory access in MAME due to bankswitching et al.
2. Emulation more correct. I found many bugs in the MAME engine (and many, many more in mine for that matter) when I pitted them head-to-head. I have run random instructions from each opcode class at least 10 million times, comparing the resultant CPU states, and have left it running random instructions for 1 billion iterations. In every case, I have adhered to the specs defined in M68000PM/AD REV. 1.
3. Disassembler is correct. The current M68000 disassembler in mame has a tendency to disassemble instructions that have an invalid EA mode.
4. Cycle counting is 99.9% correct. The only instructions which don’t have correct cycle counts are divs, divu, muls, mulu, and they’re not worth counting correctly. (I’m not about to waste emulation time counting 0-1 and 1-0 sequences).
5. > 32 bit friendly. I’ve taken care to ensure maximum portability without sacrificing speed. The result is conditional compiling dependant on your architecture. I’ve also implemented and tested a compatible solution for architectures that lack 8, 16, or 32 bit signed storage types.
6. The code is carefully laid out to be readable.
Also in MAME 35b4 added in was emulation of the NEC uPD7759 chip for speech, fleshing out the System16 emulation.
To compile these ancient versions, and inbetween I was using my Candadian cross DJGPP GCC 4.12 Win32 cross compiler. For Allegro I’ve always found it builds far easier using GCC 188.8.131.52, a vintage compiler from back in the day I could just run in DOSBox.
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.