This is beyond super cool! Video has always been something of the realm of ‘high end’ machines, back when QuickTime became a thing it was lauded at running in a postage stamp sized window with absolutely incredible artifacting. And that was running with a Quadra (68040) back in the day, the transition from 68000 to PowerPC really helped with video on the desktop with much faster clocks and better caching.
The idea of video on any of the compact black & white Macs, even the ultra high end SE/30 68030 based Mac seemed something out of fantasy. But thanks to modern processors, massive storage and the ability to front process the video, it is now possible to do playback on a B&W mac!
This is some super cool ‘impossible’ tech for the low end macs!
This is nothing short of incredible!
Of course the ‘downside’ is there is no audio.. And it’s directly blitting to the 512×342 B&W display so if you are not running on a 1 bit original display it’s not going to work or just blast seemingly junk to the screen.
Maybe if big 80’s media wasn’t so slow, or massive SCSI disks didn’t cost as much as a car we could have been enjoying an almost Brazilian future of black and white movies on tiny CRT’s.
Well this is a ‘small’ update, but with a big change, the audio is for the most part working great now thanks to this fix from rakslice. Namely changing SDL to MSB:
desired.format = AUDIO_S16MSB;
And another MinGW tweak, and yeah it’s GREAT!
Even stuff like RealAudio work now! I’ll add some self hosted video later as it’d just get struck from anything public.
Also since the RealAudio player is timebombed for installing, I added some lazy offset to remove however many billions of ticks from the clock letting you jump in some random point in the past when it won’t care.
I guess the final if any justification for a bump would be rebuilding with GCC 8.1.0 on MinGW. I somehow butchered the slirp.h to make it too MinGW’ish so it won’t clean build on Linux or OS X, but I have re-butchered a private branch and it works.. I just need to merge and clean but I’m not in the mood at the moment.
I could be crazy but it “feels” faster.
At any rate, I found that System 7 is more agreeable to running Return to Zork, just use some toast image mounter from within MacOS, and it’ll run!
Also there is some ULONGLONG weirdness going on, so I had to backout Peter’s changes for larger disks. No doubt some standard type thing change in GCC 8.
I don’t know if the picture portrays it, but yes the killer feature of version 2.0 is that you can now use 3 NeXTdimension cards in the virtual cube! Time to party like a millionaire!
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.
1.0a
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.
Oops!
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.
telnet
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.
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:
startup errors
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.
null DooM running on the x68000
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!
 .dc.l $00000000,$40f00000
instead of:
.dc.l $40f00000,$00000000
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.
Downloads
For anyone who cares you can follow more of the porting adventure here:
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
I’d highly recommend the internet archive link, you can jump right into some great Amiga action with nothing to download or install!
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 am happy to annouce the release of Previous v1.4! Simon did lots of work on emulating the NeXTdimension and he considerably improved timings and efficiency of Previous. Furthermore there is now a mode to accelerate the emulation beyond the performance of real systems. Other improvements and bugfixes are listed in the readme.
Emulating the NeXTdimension board was something i thought would not be feasible. But thanks to the i860 emulator from Jason Eckhardt and the work of Simon, who improved and completed parts of it, it finally came true. I hope you enjoy it!
I’ve been busy at work, but I did get some stuff done on this over the weekend, and just wanted to push this version out while there is some momentum.
The big fixes are in SCSI to support the dynamic scatter gather buffers so you can format big (lol) disks. Â Then again I only tested a 2GB disk but it’s working fine as far as I can tell.
I also hard coded SCSI id #6 as a CD-ROM. Â It only reads HFS partitioned images, and only can boot from a handful of those. Â From some SCSI CD emulation packages with passthru it performs just as poorly, so it’s not just me. Â I tested with the ‘blessed’ Win32 build 142, with ForceASPIÂ in a Windows XP VM with emulated SCSI CD. Â There is a lot more ‘magic’ going on with the cdenable.sys driver on the Windows side, which mounts ISO’s without any hesitation.
This also includes my latest networking fixes as I moved more of the networking code to use queues, forced the 60Hz timer to hit the network card so it won’t stall anymore, and added in that timer patch, that more than doubled my LAN download speeds.
I’ve also added a simple PCAP filter as I noticed that my LAN was quite chatty, and I figured all this traffic wouldn’t be good as an emulator really shouldn’t be processing stuff it doesn’t need to. Â Something like this:
(((ether dst 09:00:07:ff:ff:ff) or (ether dst ff:ff:ff:ff:ff:ff) or (ether dst fe:fd:00:00:16:48)))
09:00:07:ff:ff:ff is the AppleTalk broadcast address, ff:ff:ff:ff:ff:ff is the typical all hosts broadcast, and I’m still generating a MAC based on PID which is good enough for me.
Feel the need for speed!
So while before downloading 124MB on my LAN took 8 minutes, now it’s about a minute.
I’ve updated the sourceforge page with source, Win32, Linux i386 and OS X (10.8) builds. I’ll add a 10.6 x86/PowerPC build later. Â On the sourceforge page I also added a utilities section with a simple ISO image with various utilities to get you started, including the A/UX partitioning tool to partition & format a virtual disk, a tool to try to mount ISO’s (remember HFS has the only hope right now), QuickTime, Flash, Internet Explorer and some other stuff.
Also, thanks to Peter, it’s also available on github, so my horrific edits are open for the world to see…
