I found this fun page over on retroweb.maclab.org What is interesting is that it encorporates PeerJS and WebRTC to allow for a virtual network, letting you play multiplayer AppleTalk. Just enable the network, and scan for other users.
It’s pretty cool, in a zero config kind of way!
And for coolness it’ll embed in a snazzy picture of a Mac Plus. Although you can magnify the screen, so you don’t have to squint so much.
For anyone who is interested in classical 680×0 based NeXT emulation, I build the latest snapshot of Previous for Windows. You can find it here: Previous-1.6_build_767.7z
When I had a cube, I was like everyone else, without a working magnetic optical disc. And I was a (and still am) a diehard 3.3 fan, but it’s still fun loading up version 0.8 under emulation.
The problem was several fold, from the drives turning out to be VERY sensitive to dust, the NeXT’s sucking air through the MO drive, trapping quite a bit of dust in the drives, mechanisms breaking, the optics being sensitive to heat, and of course our old friend, bad capacitors. The build disk application warns it can take upwards of 3 hours to create a MO of the operating system. They clearly were not fast either. I think it took 30 minutes under emulation.
At the end of the day, I guess it didn’t matter. Optical discs came and went in the 80’s , and re surged with CD’s and re-writable discs up until this decade. Now we’ve pretty much gone either all solid state, or only large capacity disks with moving parts.
Oh well, I was looking for sample code, to see if there were other driver examples for the driverkit. I didn’t think there was anything far back when NeXTSTEP was a black box, 68030 thing, but it never hurts to look.
It is cool that TCP/IP won out in the protocol wars. It’s very convenient to have a current 2017 desktop, being able to communicate with operating systems nearly 30 years old. Especially when it comes to things like NFS, making it even better for mapping drives, and sharing data.
And much to my surprise, with the bad reputation the SLiRP code has, I’m able to mount my Synology’s NFS share just fine from my virtual cube.
mount -t nfs -o fs,mnttimeout=1,retry=1,rsize=512,wsize=512,retrans=1 192.168.1.3:/volume1/Data /mnt/data
I had just added some parameters to lower retry times, and resize the blocksize to be much smaller than a single packet so I don’t have to worry about any issues with MTU resizing. Maybe it’s not optimal, but being able to copy data in and out is all I want to do, and it’s been reliable.
Oh yeah, since it was burred in the messages, for people who like old dmesg’s
Remote debugging enabled
msgbuf at 0x73fe000
NeXT Mach/4.3 #5.1(XM13): Thu Dec 1 13:03:37 PST 1988; /sources/projects/mk-0.8.26e0.8/RELEASE (photon)
physical memory = 15.99 megabytes.
available memory = 14.97 megabytes.
using 16 buffers containing 0.12 megabytes of memory
odc0 at 0x2012000
od0 at odc0 slave 0
od1 at odc0 slave 1
SCSI 53C90 Controller, Target 7, as sc0 at 0x2014000
IBM DORS-32160 !# as sd0 at sc0 target 2 lun 0
Disk Label: NeXT_0_8
Disk Capacity 2063MB, Device Block 512 bytes
en0 at 0x2006000
en0: Ethernet address 00:00:0f:00:22:09
dsp0 at 0x20000d0
np0 at 0x200f000
sound0 at 0x200e000
root on sd0
master cpu at slot 0.
setting hostname to NeXT_0_8
network_init.gethostbyname fails, errno=2
network_init failed: no network
Network Server initialised.
Yes, I know there are others. Newer versions of GCC too!.. but I was more so curious to see if I could do it. I know there were GCC 1.x ports to the Amiga but I can’t find source anywhere. And for some reason the Amiga and Atari ST seem to have never been mainlined into GCC. I would have thought 1990-1992 they would have had far more users than say SUN-2/SUN-3.
I’ve just tested a hello world type executable. I’m more so amazed that it linked and executed, ‘file’ detects the objects as
x.o: raw G3 data, byte-padded
But at least the executables look right:
hi: AmigaOS loadseg()ble executable/binary
I had to hack all kinds of crap compiling eamiga.c
and eamiga_bss.c as neither generated correctly, and both had all kinds of missing and undefined things. I’m sure on bigger projects it’d just explode, but right now I’m just amazed the linker could pick up my object, plus the 21 year old objects + libraries from that aforementioned ancient GCC port.
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.