emulator-sun-2

Since I was playing with the 68000 based GCC ’87 I know it was going to be more geared to SUN workstations, certainly of the early 80’s vintage as they would be the most ‘affordable/cheap/donated’ to FSF (Or so I’d imagine).

Naturally the go to emulator is TME, however this time while searching around for the install scripts and stuff I found lisper‘s (heeltoe.com) emulator-sun-2, a greatly cut down and SUN-2 focused emulator that emphasizes ease of use.

Wait, what? SUN-2, and ease of use? Why yes, not only that, as it uses SDL 1.2 it also means it’s much easier to compile. After an hour of messing around with it, I had it running on Windows. After a few minutes I had it running on my ARM based Acer NovaGO.

At it’s core is the m68k 68010 emulation from Karl Stenerud‘s Musashi core which is a great choice for the SUN-2 as it’s a 68010 based machine. Some fun notes from web.cuzuco.com/~cuzuco/sun2/ include:

  • CPU is a Motorola 68010 running at 10MHz
  • Maximum physical memory is 4 Megabytes
  • Maximum virtual memory is 16 Megabytes
  • All I/O is via a Multibus (an Intel design)
  • Main disk is a SMD, the largest size is 380Mbyte
  • Has a SCSI adapter, but the disk is slow and small (42Mbyte)
  • Sun was just finishing NFS
  • alludes to future AT&T UNIX System VI and VII
  • Display supported dual heads and a resolution of 1152×900
  • List price as tested: $44,900
  • Sun was still private, had 400 employees and sold 1500 units

You can read about the debut of the SUN-2 in the UNIX/WORLD Magazine, VOlume 1, Number 5 dated October 1984 in archive.org. It starts on page 86.

I started to integrate sigurbjornl’s patches for networking but I think I need to work through SunOS 2.0’s weird VAX 4.2BSD arp issues (anyone have the source code to SunOS 2.0?!). I’ll probably update it with UDP or some fixed ARP thing to remove that or just let the SUN-2 talk to a VAX with 4.2BSD so they can be weird, together.

I’m also pretty sure my old Cockatrice III sort of debugged SLiRP thing broke the packed structs to let it work properly when compiled with Microsoft C, so I’ll have to break down and either try to fix that, or update and borrow the vastly updated SLiRP from SIMH.

For Windows users who want to play along the bundle is on the terribly named page “Ancient UNIX/BSD emulation on Windows” as SUN2.zip.

GCC from ’87 on the 68000

Years ago I found the ‘first’ released version of GCC, and had built it for the VAX. And things were… fun.

While digging around on bitsavers for new and interesting things, I saw some newer stuff from MIT, and stumbled into the GNU directory and rediscovered the early GNU software depot.

And I re-built the early GCC to target the 68000 which I’d imagine primarily was for the SUN target.

simple program

Using a simple program I can run it through the pre-processor, and the compiler to get the following assembly:

assembly from ’87 GCC

Then it’s a matter of running it through the cross assembler, uuencoding it, and sending it to the target.

I used the cross assembler from the AtariST cross ‘project’, to get an object file. I fired up MachTen, pasted my object file to the VM, and uudecoded the object.

And yeah, much to my surprise the object file linked fine, and I got my native EXE.

It’s not much of a cross toolkit, and honestly it’s kind of useless… but I thought it was maybe worth a bare paragraph to show the other available target available for the 1987 release of GCC.

Also on the MIT archive is TRIX, the MIT Unix work alike that almost became the GNU Kernel, until Mach stole their hearts, and basically lead them on a wild goosechase.

I haven’t bothered uploading binaries or patches or anything yet, I don’t know if people are interesting in such a fringe thing……

Running TME on Linux Subsystem for Windows (v1?)

I know in all the trade news everyone is excited that the newest Linux Subsystem for Windows will provide a native kernel. I would imagine it’s going to run along the lines of containers which means using the Hyper-V stuff. So good bye VMWare?

Anyways I want to run SunOS 2.0 which means no graphics are needed, but what I do need is a pty. I’m a n00b so I don’t know how to generate them myself, but I did see that I can piggyback on a ssh session. So first you need to enable & run sshd, which instructions are here, Although with Ubuntu 18.02 LTS there is further steps listed here. If everything is okay, you can SSH into your Windows machine, getting the Linux subsystem.

Some notes on building:

First let’s get the emulator and patches for SunOS 2

wget http://people.csail.mit.edu/fredette/tme/tme-0.8.tar.gz tar -zxvf tme-0.8.tar.gz wget http://www.heeltoe.com/download/sun2/diffs-20111125 cd tme-0.8 patch -p1 < ../diffs-20111125

Using GCC 5 or 7 (probably everything post version 3, the -Werror will cause building TME to error out.

I just removed the following block from configure

if test "x$enable_warnings" = "xyes" -a "x$GCC" = "xyes"; then CFLAGS="${CFLAGS-} -Wundef -Wall -Werror" CXXFLAGS="${CXXFLAGS-} -W" fi

Now you can run configure & make. I follow the general wisdom, which involves disabling shared libraries. Otherwise you can play with the dynamic linker. Yuck.

sh configure --disable-shared make

It doesn't like to build in parallel, so be prepared to wait.

And yes, building fb-xlat-auto.c & fb.c does take a long while. Also make sure to have bison & flex installed.

Using Debian 9/GCC 6.3.0 I do get a bomb compiling module.c

module.c: In function 'tme_module_init': module.c:93:3: error: 'lt_preloaded_symbols' undeclared (first use in this function) LTDL_SET_PRELOADED_SYMBOLS();

In this case I just copy the definition from libltdl/ltdl.h and put it into module.c It'll complain about it being a duplicate, but it'll compile. I don't understand that either.

Now we need to set the variable LTDL_LIBRARY_PATH to pickup the config for each hardware component.

export LTDL_LIBRARY_PATH=$HOME/tme-0.8

Ok and now let's get ready to install SunOS 2.0

$ mkdir sunos2 cd cd sunos2/ wget https://web.archive.org/web/20060720001131/http://www.soupwizard.com/sun2/sunos/sunos_2.0_sun2.tar.gz tar -zxvf sunos_2.0_sun2.tar.gz mv sunos-2.0-sun2/tape1 . wget http://people.csail.mit.edu/fredette/tme/sun2-multi-rev-R.bin perl $HOME/tme-0.8/machine/sun/tme-sun-idprom 2/120 8:0:20:02:02:02 > my-sun2-idprom.bin

Now we can configure the emulator. One thing to take note of is what pts device has been created once you SSH'd into Windows.

$ ls -l /dev/pts/ total 0 crw--w---- 1 jsteve tty 136, 0 May 13 15:08 0 c--------- 1 root root 5, 2 May 13 10:47 ptmx

So in this case it's /dev/pts/0 for me, as I'm the first (and only) thing connected.

Now you need to edit the config. This is the one that I'm using:

mainbus0: tme/machine/sun2 multibus my-sun2-idprom.bin cpu0 at mainbus0: tme/ic/m68010 obio0 at mainbus0 obio: tme/generic/bus size 8MB obmem0 at mainbus0 obmem: tme/generic/bus size 16MB ram0 at obmem0 addr 0x0: tme/host/posix/memory ram 4MB rom0 at obmem0 addr 0xef0000: tme/host/posix/memory rom sun2-multi-rev-R.bin rom0 at obmem0 addr 0xef8000 clock0 at obio0 addr 0x2800: tme/machine/sun2/clock tod0 at obio0 addr 0x3800: tme/machine/sun2/tod zs0 at obio0 addr 0x2000 ipl 6: tme/machine/sun2/zs mbio0 at mainbus0 mbio: tme/generic/bus size 8MB mbmem0: tme/generic/bus size 8MB mainbus0 mbmem at mbmem0 addr 0x00000 sc0 at mbmem0 addr 0x80000 ipl 2: tme/bus/multibus/sun-sc scsibus0 at sc0: tme/scsi/bus console0 at zs0 channel A: tme/host/posix/serial device /dev/pts/0 break-carats sd0 at scsibus0: tme/scsi/disk id 0 type acb4000 disk0 at sd0: tme/host/posix/disk file my-sun2-disk.img st0 at scsibus0: tme/scsi/tape id 4 type emulex-mt02 tape0 at st0: tme/host/posix/tape command tape0 load tape1/01 tape1/02 tape1/03 tape1/04 tape1/05 tape1/06 tape1/07 tape1/08 tape1/09 tape1/10 command mainbus0 power up

Now we are almost ready! Create a 1GB disk image with dd:

dd if=/dev/zero of=my-sun2-disk.img bs=1M count=1024

Now we are ready to go. From the ssh connection just type in 'cat > /dev/pts/0' and now everything we type in will be on the console. Now from a normal bash session type in '$HOME/tme-0.8/tmesh/tmesh SUN2-MULTIBUS' If everything goes well the bootpromp text will pop up on your SSH session.

SUN-2/120 on Windows!

And if everything has gone right, we are now at the firmware prompt, ready to install SunOS 2.0!

Instructions from retrocomputinggeek.com gives a pretty good walk through of configuring a 1GB disk, and the installation. Although as a hint use the -as flags when booting SunOS for the install. And after booting the miniroot, follow the instructions on heeltoe regarding doing the 1st tape of the install.

>b st() Boot: st(0,0,0) Boot: sd(0,0,1)vmunix -as Size: 368640+57344+66652 bytes Sun UNIX 4.2 Release 2.0 (GENERIC) #1: Mon May 20 15:32:06 PDT 1985 Copyright (c) 1985 by Sun Microsystems, Inc. mem = 4096K (0x400000) avail mem = 3575808 Ethernet address = 8:0:20:2:2:2 sc0 at mbmem 80000 pri 2 sd0 at sc0 slave 0 sd0: sd1 at sc0 slave 1 st0 at sc0 slave 32 zs0 at virtual eec800 pri 3 pi0 at virtual ee2000 root device? sd0* using 100 buffers containing 366592 bytes of main memory #

After that it's a matter of working out which tar file goes where. Is there even an install process? I just untarred the rest of the tapes in the /usr directory.

For the impatient, tme-0.8-linux-x86_64_bin.tar.gz and
tme-0.8-SunOS-2.0.tar.gz. As always read the 404 page.

I think I’m chasing a struct packing issue

i386 breaking on the AASTINKY texture

On the i386 a texture info lump loads up just fine. However on a big endian G5…

OS X 10.2.8 on the G5 on the same AASTINKY

…It clearly has problems. Although notice that the positions and sizes are the same, as they ought to be.

Notice how originx is 24, which should be the width. This code was running with GCC 1.30/1.40 hammered x68000 GCC. Although I have been unable to get the much vaulted gcc-1.30.atari.tar.bz2 to do anything useful, well until tonight, when I found this file: GNU_HEAD.ARC.

That’s right, it’s the gcc-1.23 release headers for GCC on the Atari ST. Now I know other places people have been saying I should use MINT or some GCC8 port. And I wanted something to run on bare TOS, and I cross compiled the simple Infocom interpreter but it just crashes out after a few commands. It’s hardly stable.

3 bombs and an exit under GCC 8.0

Which is just a damned shame, as it was easier to just download someone else’s work.

Anyways, I now can build the old gcc-1.30 libc however… the linker that I’m using that works for GCC 2 links away and it looks like a working program but it doesn’t do anything. I have a feeling the linker drifted in those years between GCC-1.30 and GCC-2.something when it was adapted. Certainly by the time of 2.5.8. So yet more endian ghosts to chase down if I try to adapt that linker.

Cross compiling to the Atari ST

This was a lot harder than it should have been. And not because of gcc or surprisingly ancient binutils.

I didn’t have much to go on, as ancient threads like this, or this end up unanswered or without any good conclusion. I guess it’s not surprising that all the attention is to MiNT & MINIX rather than the native platform. But I was not deterred.

The reason why this was so freaking hard was how so much of key parts of gcc for the ST have been purged and what remains being scattered to the winds. Amazingly the hardest thing to source is the include files. There is a GCC 1.30 file on all the usual GNU mirrors but to save a few kb it has no headers, instead it wants you to reuse the ones from the 1.25 binary distribution. Which is gone. There survives a pl95 binary and source package, but again no includes. Instead I got lucky with all three for pl98. Which has a lot of GCC2 hooks so I cheated on getting the 1.30 hello world by using the 2.5.8 pre-processor.

It’s kind of annoying how all these seemingly tiny files get purged to save a few kb. Just as I can’t for the life of me find the old original GNU libc.

Speaking of files, ZOO has to be the worst compressor ever. Not only is it just overall worse than ZIP, but there are 2 incompatible compression methods, like the introduction of LZD, which any of the good versions of UNZOO can’t deal with. And sure there is zoo210.tar.Z but despite being able to build it on multiple platforms it never does anything useful. All these ancient fileformats sure don’t help anything. And sure there is a MS-DOS version that the MS-DOS Player can run, but get ready for 8.3 filename renaming.

The one good thing that came out of this experience is that since I am building form i386 to 68000 I found that this setup uses the G++ linker which has endian swapping. So maybe I can complete the chain for Mint and MachTen.

I even got the 1987 Infocom interpreter running. Although I don’t know what the deal is, it seems the larger the GCC based program is the higher chance it’ll just crash on exit or force the next program to crash. Building anything native under emulation was an impossibility.

In the same effort, I’ve had the same luck with sozobon. It took way too long to find a working dlibs. I don’t know why people couldn’t either package them together or at least in the same directory. It took far longer just to find the libs… But it was still fun to get that one running as well.

It’s a far more manual process to compile as I have to invoke each stage manually, but at least I’m finally able to get things going.

One of the bigger issues is that I would always find libraries in this olb file format, that the linker from Sozobon wouldn’t recognize. And almost every attempt of trying to build the G++ linker would also fail on. It wasn’t until I was able to get the pl98 include files that I could finally get a linker to actually recognize this … seemingly different for no apparent reason format to actually link. After then I managed to finally find a build of this dlibs that would actually link with Sozobon, which naturally didn’t use olb at all.

So yeah that was an adventure.

I haven’t cleaned it up at all, and really wouldn’t expect anyone else to care, but all my mashed together work (source & binaries!) is here: MinGW-AtariTOS.7z

UPDATE

I started browsing more cd.textfiles.com and amazingly found a ‘home made CD-ROM set’ of Atari software, and buried in the gigabytes of stuff was 4 of the 5 disks of the original GCC-1.23! Namely the source & includes to the first GCC library. I didn’t think this article was going to get any traction, let alone downloads. So many people downloaded the above download.

Anyways I started to put together a better package on sourceforge since it’ll do the multiple GIT’s and nicer downloads.

Download crossAtariST

The default download set is for GCC-1.30, with the headers & lib, along with source. It’s crazy small which just goes for how this old stuff is, and how impact full for losing a few kb.

Also the shell that you use apparently makes a BIG difference. The shell that I was using EmuCON doesn’t show any output from the GCC 1.x libs. However other shells most certainly do. I’ll have to do another update regarding shells/emulation.

Found more system16 source

It gets a little confusing as they are all version 0.82 the real way to tell them apart is the date

What is cool about these versions is that they do have some audio capabilities, although they are so old that they do rely on sampled sounds for:

  • Alien Syndrome
  • Altered Beast
  • Golden Axe
  • Shadow Dancer
  • Shinobi
  • Wrestle War

But it’s from 1999 and that was the state of emulation.

0.82 is basically where the project had left off, and was of course supplanted by MAME. There was preliminary work on AfterBurner 2, although there is from the looks of it a bad/partial ROM dump to blame for the most part. It’s unplayable but it sort of runs the demo.

0.82 does however emulate a strange version of OutRun. Namely that it lacks shifter support all together. So hold down the accelerator and take off!

Notable things is the inclusion of Neill Corlett’s Starscream for 68000 emulation, Neil Bradley’s Mz80, Jarek Burczynski’s YM2151. Which reflects many components of the era that would find their way into MAME.

Which of course speaks to another thing, that tracking down ROMs for these ancient pre-mame emulators is getting impossible with vague names, and no timestamps.

Btw, there is two excellent pages where you can get all the roms supported
by this emulator, these pages are :
http://www.davesclassics.com by Conjurer
and
http://www.emuviews.com by JoseQ

Which naturally, are lost to the mists of time.

I’ve been able to run it under DOSBox, Qemu and VMWare. For VMWare, be sure to enable Sound Blaster emulation, and set the BLASTER environment variable to:

SET BLASTER=A220 I5 D1 H7 P330 T6

The video mode for the start screen doesn’t render on VMWare or Qemu, so in that case I just start it with the following batch file

system16 %1.gcs -notitle -old2151 -noarcade %2 %3 %4 %5 %6

And away it goes!

I don’t have the FPS stats as it’ll crash when going to the menu to exit, and I didn’t hack up the source that much at the moment (caught another flu…). But Qemu 0.90 feels a LOT more fluid playing outrun than VMWare or DOSBox on my 2006 Mac Pro. Although on my 32 core Xeon monster it plays great on everything. I guess if you have at least 3Ghz and your CPU is less than 8 years old it’ll be fine for running nested emulation along with emulating 2 68000’s a z80, and a ym2151. Or just run a native build of MAME! Or if you really want low lag Outrun, use Cannonball!

And thanks again to Thierry Lescot for letting me redistribute this

Playing old 68000 tracks via sc68

First thing, what makes these tracks from sc68 & sndh unique is that it’s not simple music notes, like MIDI, but rather each track actually includes the native 68000 program to play the track, and it interfaces directly to the hardware. This means that sc68 actually has to emulate enough of the Atari ST & Commodore Amiga to play music. I’ve got to say, it’s pretty impressive!

I’m using WinAmp to act as the player, so this way I just need to download the plugin from sourceforge at the moment the latest is sc68-2.2.1.exe.

On install I un-selected the winamp-3 component. I’ve tested it with 2.24 and 5.8, both working just fine.

With the plugin installed, you are good to go!

Now where to get music?

As it turns out, the sc68 project has a ‘massive’ 25MB file, sc68files_20031118.tar.gz containing some 1,775 files!

Likewise the SNDH project has downloads on their page
http://sndh.atari.org/download.php that currently sits at 75MB, and has 4,925 files!

sc68 plugin doing it’s thing

If you look at the code, you can find that it does in fact emulate a 68000 along with peripheral chips and music chips. Just as the SNDH format is 68000 ASM.

So there we go, an obscure music format that actually involves emulation!

68000 and i386 C Compiler Version III on Windows

While looking around for simple compilers to see how easy it is to modify their assembly output syntax, I ran across this tiny file, cc68iii3.zip which bills itself as:

This compiler consists of various modules that build up a
front end — these modules are common to all versions of
this compiler — consisting of parser, analyzer and optimizer,
of modules that are specific for the target processor,
namely *68k.c (for the 68000) and *386.c (for the i386),
and of assembly language output modules that are further
dependent on the (syntax of the) target assembler.

Well isn’t that interesting! So instead of doing something 68000 based, I setup the i386-gas compiler, and tried it with MinGW. And amazingly a hello world program worked!

C:\temp\ccc\cc\infocom> type hello.c
void main(){printf("Hello World!\n");}
C:\temp\ccc\cc\infocom> ..\c386gas hello.c hello.s

C:\temp\ccc\cc\infocom> gcc hello.s -o hello

C:\temp\ccc\cc\infocom> hello
Hello World!

C:\temp\ccc\cc\infocom> type hello.s
        .file   "C386GENERATED"
        .version        "C386 V 1.0"
        .optim
c386_compiled.:
        .text
L1:
        .byte 72,101,108,108,111,32,87,111,114,108,100,33
        .byte 10,0
        .align 2
_main:
pushl %ebp
movl %esp,%ebp
pushl $L1
call _printf
popl %ecx
leave
ret
.globl _main
.globl _printf

C:\temp\ccc\cc\infocom>

Well that was unexpected, but great! So I thought I’d modify the simple Infocom interpreter to build with this. I came up with this as a block for gnumake to read in a Makefile

%.o:    %.c
        $(CC) $(CFLAGS) -E $<  -o $*.i
        c386gas $*.i $*.s
        as $*.s -o [email protected]
        rm -f $*.i $*.s

The key substitute is $* which is the 'root' of the file being passed in. Although it's lame doing it this way but it works in a nice automatic enough fashion.

The compiler must be K&R only as it doesn't like standard includes, so I built file.c/io.c/term.c using GCC but all the rest were able to be built just fine. And even better it works!

Infocom '87

Although I'd never recommend using something like this in a place that matters. If anything GCC 1.x is probably a better choice, but it's still kind of neat.

Messing with the Monitor

The 68000 Microprocessor (5th Edition) Hardcover – Nov 25 2003
by James L. Antonakos (Author)

So I was trapped in the Library for a bit, and spied this book. It’s not every often in 2019 you are going to find books about the 68000, as I’m sure any good library will have removed stuff like this, and have it pulped ages ago. But the amount of current technical books in English here is pretty damned slim to none, so I was all to happy to pickup this book for a week.

The poor thing has been checked out 4 times in the last 15 years. I guess the kids don’t know what they are missing.

Anyways what was interesting in this book is that it has a CD-ROM, and on there is some lesson code from the book, along with an assembler that outputs to S-records of all things, and a small emulator that is meant to be compiled under MS-DOS. It was trivial to isolate the passing of DOS interrupts from Unix/MinGW and get the simulator running on something modern.

In Chapter 11 there is a brief walkthrough on building a board, which sounds like fun although I’m sure in 2019 finding parts will be.. challenging, along with a simple monitor program.

The built in assembler can happily assemble the monitor, but it’s geared for talking to the obsolete hardware as specified in the book. I just made a few small changes to instead have it’s console IO hook to the simulator’s TRAPs and I had the monitor running!

I then took the echo test program, and modified it to run at a higher location in memory, along with exiting via the RTS instruction, so that it will exit when you press Q back to the monitor. Then for the heck of it I further extended the monitor so you can Quit it, and return to the simulator.

Is this useful? I’m pretty sure the answer is absolutely not.

The CD-ROM is tiny, I thought it would be packed with goodies, but it’s 250kb compressed.

The68000MicroprocessorFifthEdition.zip

If anything people using this book will probably have lost the CD-ROM and want the programs.

  • ISBN-10: 0130195618

And my horrible changes here.