Category Archives: 68000

System 16

Posted on by
Reply

A long long time ago, back when I got a Pentium 100 the wonderful world of emulation was really starting to be possible with such a high powered CPU.  First was the simple Game Boy emulators, then a Commodore 64 emulator, the incredible Amiga Emulator, the beginnings of SIMH (back when it was only a PDP-11 emulator), and then I found the SEGA emulator, System 16.

It was really cool being able to play 16bit arcade games on the desktop, although rather slowly.  From there everyone knows the rise of MAME.  But while looking around for a small 68000 C compiler, I came across the source code to an older version of System 16, 0.53 on archive.org.  Naturally it’s for MS-DOS, as was everything back in the day.  Also slightly interesting is the 68000 emulation, written by Bernd Schmitd of UAE fame.  So for the heck of it, I set about getting Thierry Lescot’s System 16 building again.  I’ve never used allegro before, so it was a bit of a fight to get a version of it to actually build.  It turns out that I should have been building version 2.11 with tools of that era (why on earth was I using GCC 4, and binutils 2.18?) and instead stick with GCC 2.7.2.2 and some much older binutils.  And in no time I had build the library, and it’s examples.  With that done, I was able to re-build System 16 with GCC 4.1.2 and get a binary!

Back in the day, I actually did have an Altered Beast arcade board.  Sadly it died in a move, someone near and dear just saw the PCB as “garbage” and tossed it.  Sigh, but I did have ROM dumps, as I did a refresh of it forever ago.  Anyways I still have the ROM files, so I guess that is nice.

Anyways I fired up the emulator and got what is known as the “jail bar” effect, which is from a bad ROM.

Corrupt tiles

Corrupt tiles

Notice the sprites

Notice the sprites

The System 16 splits it’s memory into a program space, a sprite memory bank, a tile memory bank, and RAM for stack and things like the palette.  As you can see the program is certainly running, and the sprites are good.  I did some poking around a bit later, and noticed that due to a logic bug, the texture ROMs are actually never loaded!

So a quick patch, and now we get Altered Beast up and running!

Altered Beast title screen

Altered Beast title screen

demo play

demo play

Well, now isn’t that great!

Not that I would imagine anyone would really care, I mean MAME is a thing, and even from the readme:

Altered Beast : No sound emulation

So it’s pretty quiet.  Additionally the source is pretty restrictive:

These sources can’t be used for commercial purpose, any new version of the
emulator done with these sources must specify my name somewhere on the screen
et docs and I must be informed about any new release of the emulator.

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

NeoGeo dev update with Neo Thunder

Posted on by
Reply
neo thunder

Compiled and Linked under Windows 10

In a round about way I was looking at old NeoGeo hardware having seen the ‘NeoGeo X’ android device for sale.  In a round about way I stumbled onto this page detailing various homebrew projects.  I saw the Neo Thunder, which looked interesting, and more importantly included source code!

What was even better is that there was a download of the full toolchain + emulators to get it up and running!  I downloaded it, and hit the wall quickly as this was built with cygwin circa 2001, which means it will forkbomb any post Windows XP SP2 system.

Well, I couldn’t just let it die on the vine, so I turned back to my Canadian cross compiler build machine, and quickly built a m68k-elf tool chain.  As always, first build a native cross compiler for later building libgcc.a and friends.  I use a 32bit version of Linux with a downgraded MinGW environment so I can use Binutils 2.25.1 and GCC 4.1.2

For anyone who cares, this is my configure strings:


binutils
../configure --target=m68k-elf --prefix=/usr/local/m68k-elf
../configure --target=m68k-elf --prefix=/m68k-elf --host=i686-mingw32


gcc
../configure --target=m68k-elf --prefix=/usr/local/m68k-elf
../configure --target=m68k-elf --prefix=/m68k-elf --disable-libssp --build=m68k-elf --host=i686-mingw32

With a cross compiler built, the next problem was with the built in tools like bin2elf, fixcnv, gfxcc, and symify.  These were also built with cygwin, and failed to run.  With a LOT of googling however I did find the following link to “Fabrice Martinez’s NeoDev Neo Geo C development library for GCC’. 290 kb Année 7/26/2004 (LINUX)“, out on yaronet.com.

I patched up makefiles to my liking, and I could build all the libs, and all of the sample code (well except for the c++ one, because I couldn’t be bothered to build a c++ compiler).  Some of it runs, some doesn’t I’m not sure what is going on.  But for what it’s worth, Neo Thunder actually builds and runs (on mame!).

As always you can MinGW-M68K-ELF(neogeo).7z on my site.  Be sure to read the 404 page for the username password, as it auto-generates from time to time.  I don’t know if anyone will care, but it was kinda cool to track down the needed bits, and build out a working version of Neo Thunder.

Making MacMiNT self hosting

Posted on by
8
Compiled in 2015!

Compiled in 2015!

One thing that always bothered me about MacMiNT is that I never could compile JET or MacMint itself.  It requires the headers from MPW 3.2, or better known as the Macintosh Programmer’s Workshop, along with a single library again from MPW 3.2

MPW 3.3 won’t work, which is the only version I’ve had when I bought an extraordinarily heavy FORTRAN compiler for the MAC, Language Systems FORTRAN.  I tried to get dungeon to work with that, but no dice.

But thanks to macgui, they have links to the 3.2 headers & libraries!

It took me a little longer than I’d like to figure out how to build the cross libraries, as I kept running the script from the script directory, not from /mint as I should have (is there any documentation?!).  But I finally built the libmac16.olb and libmac.olb needed for MiNT programs to call the MacOS toolbox!

So now I’m able to compile Hoshi’s 1999 JET and MacMiNT!

For anyone interested, I’ve built a disk image here, that includes everything all ready to go.  It runs great on my latest build of Cockatrice, although I haven’t made any Win32 builds just yet….  I suspect it’ll run on emaculation’s build of Basilisk II it really should only need a 68000 with 8MB of RAM or so.  The disk image is 8MB, and uncompressed onto a hard disk takes up 35MB of space.

I’ve also made a small (100MB) mirror of the umich MiNT & MacMiNT install archives I could find right here.

Also, it runs dungeon,and with a lot of finagling, it’ll even run f2c dungeon! (needs a 68030 or higher).

For those who insist on running this on SheepShaver / Or PowerPC based machines, I’ve found that System 7 and an OldWorld ROM run it best.  System 8.0 and System 8.1 can run it (assuming they were installed as a PowerPC install), but System 8.5 and higher are not very cooperative when it comes to MacMiNT.

MacMiNT on SheepShaver MacOS 8.1

MacMiNT on SheepShaver MacOS 8.1

I suspect it must be the re-write of the nanokernel that PowerPC MacOS is based on.

Scripted Amiga updated to version 0.82

Posted on by
Reply
Captain Blood on the SAE

Captain Blood on the SAE

It’s really amazing to see this in action, and knowing it’s all in javascript of all things.  The Scripted Amiga Emulator now in version 0.83 fixes sound on Chrome, bringing back that Amiga experience with next to no pain.  By default it’ll boot up AROS and various demos or game demos, but you can substitute it with any 68000 compatible kickstart ROMs, and whatever diskettes you have lying about.

Even better the source code is up on github, and now under the GNU General Public License v2.0.

Click here, and give it a shot!  Any modern browser with good javascript support is all you need to get going!

NetHack 1.3d on the x68000

Posted on by
4

Ok, I know… why? But it’s more of a why not!

NetHack

NetHack

So I figured since I’ve had major issues trying to get DOOM to run, I’d try something bigger, like NetHack.  I figured its a good fit, it’s all ASCII based anyways, so how complicated can it be?

Actually it turned out to not be that complicated.  Thankfully having both run68’s source and NetHack source I was able to adapt enough of the system stuff to get it running. I decided to use this build of NetHack 1.3d that has been updated to compile with modern compilers, since the cross tools use GCC 4.6.2.  NetHack 1.3d synchronized PC hack, and UNIX based NetHack enough that I could start to build under MS-DOS, and then re-target it, as Human68k and MS-DOS share a lot of features (although Human68k has support for tasks, and shared memory.  It’s more like OS/2 although no memory protection… ).

I’ve gotten it to the point where you can save, load and quit.  Oddly enough the ANSI support in Human68k isn’t as good as ansicon so it actually runs better on run68.

So my next step will be to figure out more of the console controls on Human68k, and remove the ANSI support.

Ideally I’d love to figure out how to talk to the sound drivers on the x68000.  Add some music. Maybe sound effects, and graphics?

So for anyone who cares, my source directory, binaries and a xm6 disk image is all here. I’ve seen in the cvs tree on sourceforge that run68 has some support for BSD.  That’d be another interesting thing to add, common exe’s between windows/linux.  But console access first!

WinUAE 3.0.0 released!

Posted on by
7

The biggest feature of course is…

  • PPC CPU emulation. CyberStorm PPC and Blizzard PPC boards emulated using QEMU PPC core, on-board SCSI supported.

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

But for those who want to give it a shot, the installer is here, along with the PowerPC pluggin

All of the additional features are with the announcement here..

Tracking down the InfoTaskForce from 1987.

Posted on by
8

So like all zork obsessed people (I really should get help or something), I was trying to build a z-machine interpreter for the x68000, using Lydux’s cross GCC compiler.  And it was honestly looking like a LOT of work in the IO department.  Thinking that the older versions were more simpler, I went looking for the oldest open Z-machine, called the “The InfoTaskForce Infocom interpreter”, released by the InfoTaskForce.  Unfortunately I can only find version 4.01 searching for the source code.  Which still looks too complicated.  But looking the history file, the project started back in 1987.  So with that to go on a new google search got me this:

Infocom Adventure Executor Source Files (1987)(InfoTaskForce)[C].zip

From an TRS-80 dump of all things.  I don’t know what version this is other than the brief copyright mention:

/* (C)opyright 1987 InfoTaskforce. */

All of the files are dated 4/12/2001 so they obviously aren’t original. And the version string is:

echo ( “Interpreter: C Version 1.0\n” ) ;

So assuming this is correct, from the 4.01 history file:

REV_E – June 25, 1987.
———————-

REV_E is the first major overhaul to the interpreter.

* The source is now significantly lint free.

* TERMCAP support has now been added [#define TERMCAP option].

* Screen paging and word wrap has been added, along with a new
command line option which disables screen paging (-p).

* Random number generator seeding using time () added [#define
TIMESEED option].

* Attributes in the object list are listed as bits.

* A debuging version can now be produced as an inbuilt options
[#define DEBUG option].

* The coded requirement that 25k is always free in the system can
now be removed [#define ALLOCALL option].

* A new command line option was added to print the object/room list
as a tree (-r).

* interp.c has been re-written to improve efficiency [large
switches have been replaced with arrays of pointers to funcions].

There are now 14 machines on the porting list:

Machine C Compiler Operational Porting details

128K Apple
Macintosh Aztec C Version 1.06F 18/05/87

128K Apple
Macintosh Lightspeed C 2.01 29/05/87 Use “rb” & “wb” in all fopen()s

IBM PC/AT Microsoft C 4 30/05/87 Link with binmode.obj

DEC VAX 11/780 UNIX V7 cc 01/06/87

HP-9000 HP-UX cc 02/06/87

gould cc 03/06/87

Amiga Aztec C 04/06/87

Pyramid 9810 cc 04/06/87

Pyramid 90x cc 04/06/87

Osiris cc 05/06/87

DEC PDP-11/? UNIX V? cc 07/06/87 EXTENSIVE
mods to fix problems with signed chars.

VAX VMS cc 16/06/87 Add #define
times ttmes to fix multiply defined symbol problem. [infocom.h]

Version 1.00 – August 17, 1987.
——————————-

The REV_C interpreter of June 2, 1987 was officially archived as
Version 1.00 on August 17, 1987.

So this means it’s very 16bit & 32bit friendly, especially on BIG endian machines like the 68000 processor.

Luckily this older version is pretty trivial to compile, and get running.  But I was over thinking the build process and decided to strip the executable as GCC would kick out a 500kb file, which objcopy would extract a 81kb executable.  Stripping it brought the size down to a 50kb executable but it wouldn’t run in either xm6 or run68.  I ended up going in circles for a while trying to find fault in what is broken where until I manually compiled the interpreter, and omitted the strip step and suddenly had a working interpreter.

Now there is one issue, saving doesn’t work.  Something in the libc is having issues using fopen with a file to write.  Reading works perfectly fine though.  So to fix it, I went ahead and redid the save feature to use the HumanOS native _open/_write/_close functions and I’m able to now save & restore a game.

D:\proj\run68\test>run68.exe infocom.X minizork.z3
MINI-ZORK I: The Great Underground Empire
Copyright (c) 1988 Infocom, Inc. All rights reserved.
ZORK is a registered trademark of Infocom, Inc.
Release 34 / Serial number 871124

West of House
You are standing in an open field west of a white house, with a boarded front
door. You could circle the house to the north or south.
There is a small mailbox here.

West of House Score: 0/0
>restore
Filename: mz1.sav
Ok.

Living Room Score: 10/19
>inventory
You have:
A nasty knife
A rope
A sword
A brass lantern (providing light)
A brown sack
A glass bottle
The glass bottle contains:
A quantity of water
A leaflet

Living Room Score: 10/20
>

In this process I’ve also managed to build run68, and verified that it’s operating correctly, as both run68 and XM6 both failed to write to a file with fopen, and both work using the native calls.

Planetfall on a x68000

Planetfall on a x68000

I’m sure most people won’t care but I think it’s great having the ability to run a GCC generated C program in a relatively small interpreter.

If anyone cares, here is my updated cross compiler + run68 source along with tweaked Info Task Force 1.0 source.  Or a disk image that XM6 can boot up, and run some demo programs from Infocom of ages ago.

Run68 Human-68k emulator

Posted on by
Reply

I found this one by accident, but it’s more like DOSBox in that it runs 68000 executables with an emulated processor and emulated OS.  No SHARP ROMs or HumanOS diskettes needed.  It’s strictly text mode, but it’s enough to run executables produced by GCC.

Hello!

Hello!

The project is over on sourceforge, and unlike any other x68000 project this one is GPL’d.  The source code is remarkably tiny so I’d say for anyone looking for a way to sneak some C into something this may be an interesting ‘door’..

New build of Shoebill available.

Posted on by
5

The big change is the new 68881 maths FPU emulation.  It’s completely new code in this version.  As the author, Pruten mentions:

it should be the “most accurate” 68881 emulator (with regard to chip behavior) ever written, as far as I can tell. I can’t find another open source emulator that even attempts to emulate FPU exceptions, probably because Motorora’s documentation is terrible. Rife with typos and errors, and lacking descriptions for lots of edge cases. It’s also a superset of IEEE 754, so it’s tricky to get softfloat, a strict IEEE 754 implementation, to implement all the weird extra behaviors in the 68881.

On the flipside however:

It will also be much slower than the old version, since the new FPU uses integer-based softfloat. The transcendental instructions will be emulated by running whatever the best natively available function is, and then blindly copying the result to the dest FPU register. Since the FPU is the last big piece of shoebill that requires x86, this should allow it to compile on other architectures, like maybe PPC

I’ve only recently rebuilt the emulator with only the addition of the SLiRP code that I’ve been able to debug from Cockatrice III (who said that I was wasting my time?  At a minimum I ‘fixed’ up SLiRP to make it more stable), and kicked out a Win32 build (source/binary).

I’ve just had it running doing a simple shell script after disabling the UI.  So far it’s 15 hours of uptime…

  8:43am up 15:02, 3 users, load average: 0.00 0.01 0.01

Which is nice.
I should add, to disable the UI in A/UX it’s best to edit the inittab and change

co::respawn:/etc/loginrc

to

co::respawn:/etc/getty console co_9600

And now you’ll get a “text” login.

Text mode login for A/UX

Text mode login for A/UX

I guess the real test will be to see if it makes it through the night.

(edit)

And yes it did!

5:40pm up 1 day, 2 users, load average: 0.00 0.00 0.00

I’ll let it run a little longer but this is like a new record.  Although at the same time, I’m not hammering the poor thing.

# netstat -ni
Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll
ae0 1500 10.0.2 10.0.2.15 4232 0 3551 0 0
lo0 1536 127 127.0.0.1 157 0 157 0 0