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.
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.
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:
Source & binaries are here:
And my cross compiler toolchain is here:
I saw this awesome link over at archive.org’s software Library featuring the Amiga
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!
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 dumped my source tree over on sourceforge, as I’m more so interested that this builds using MinGW.
It’s really cool! And as an added bonus, it can now run in ‘Variable’ speed, meaning as fast as your machine can emulate the 68040.
From the announcement:
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!
(this is a guest post from Tenox)
I have recently received a large box with Apple Unix 3.0 documentation. Scanned and published here on archive.org:
The latest additions are these documents:
- Apple A/UX 3.0 Essentials
- Apple A/UX 3.0 Installation Guide
- Apple A/UX 3.0 MacX User Guide
- Apple A/UX 3.0 Networking Essentials
- Apple A/UX 3.0 Programming Languages and Tools Vol 1
- Apple A/UX 3.0 Programming Languages and Tools Vol 2
- Apple A/UX 3.0 Roadmap to A/UX
- Apple A/UX 3.0 Setting up Accounts and Peripherals for A/UX
- Apple A/UX 3.0 Toolbox: Mac ROM Interface
- Apple A/UX 3.0 X11 User’s Guide for A/UX
To my knowledge only 2.0 version of these were floating around.
This should go nicely with the latest release of Shoebill Emulator.
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.
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…
Well I was shuffling files back and forth into Shoebill, and with the advent of Ethernet support, I decided I wanted to build an AppleTalk network. This endeavor seems to have taken a life of it’s own.
So, the first thing I did was tear into minivmac, as I figured it would be the easiest to modify, as ‘mini’ is in it’s name. But it’s more geared to LocalTalk. From it’s readme:
It does this by converting the LocalTalk packets between SDLC frames in the virtual machine to LocalTalk Over Ethernet (LTOE) packets. These LTOE packets will be sent out the host machines Ethernet interface and will reach any other machine on the LAN. LTOE packets are not routable and not recognized by EtherTalk devices.
Which is pretty creative, but I want to talk to A/UX, Windows NT and Cisco routers. So this isn’t going to work out for me.
The next other ‘big’ names in Macintosh emulation are Basilisk II and SheepShaver. Both of which are from Christian Bauer which is a sizable download (or so I thought) and has a very confusing release versions for Windows. So I went ahead and tried BasiliskII, which only does some native networking via a TUN/TAP & bridge solution (which is really popular solution for plenty of UNIX based stuff), which personally I don’t really care for. The Windows version does support SLiRP, but for some strange and annoying reason it always crashes when I try to download anything big. As a matter of fact, the Windows version crashes, a lot!
While digging around for various builds of Basilisk II, I found the defunct sourceforge page, which is thankfully still up. And there I found the 0.8 and 0.9 release source code, which weighs in at a tiny 350kb in size. This is something I could probably dive into. So I went ahead and tried to build it on a Debian 7 x86 VM. And much to my surprise, after altering configure to accept GCC 4.7, and forcing it to turn X11 on (I don’t know why it kept failing to detect it), I was able to build a binary in no time. Even better, it worked!
So the first few goals were simple, I wanted to take 0.8 and remove it’s dependency on X11,and make it use SDL 1.2. Why not SDL 2.0? Well 2.0 is more about 3d space, and even to render a flat framebuffer it uses streaming textures. Which is too heavy for me, so I’m sticking with 1.2. I took a bunch of code from SDLQuake, and after a while of bashing it around, I was able to open a window, and capture some ouput from the framebuffer. With even more bashing around I got it to work correctly. I did make some small tweaks though, it only supports 8bit depth. But I’m interested in networking, so 256 colours is fine by me. Now that i could see what I was doing, I was able to then re-compile on OS X, and I was greeted with the Mac Boot screen. The harder part was Windows, as the system code written by Lauri Pesonen who did an excellent job of porting BasiliskII to Windows, but to say their code took 100% advantage of the Win32 API would be an understatement.. And I wanted something more pure to being SDL so I really couldn’t use much of that code. And what code I could find it was for far later versions. However with enough pushing I did finally get BasiliskII to boot up on Windows. I was once more again bitten by the fact that open on Windows defaults to being in ASCII mode.
The next thing to add was SDL input for the keyboard and mouse. And at this point googling around for an example of an input loop for SDL that is appropriate for an emulator I stumbled uppon the fact that there already was a SDL support built into the more current version of Basilisk II. But for some strange reason I kept going ahead, and incorporated some of the code into my 0.8 branch. And then I could finally send some keystrokes, move the mouse, and click on things! Things were looking up!
While looking at the SDL code, I did see they also have audio support, so I went ahead and borrowed the skeleton framework from there, although the initialization didn’t work at all as BasiliskII had drifted in how it hooked into the native sound support. So I once more again turned to SDLQuake, and I was able to initialize sound, and Even get QuickTime to play the old Quadra quicktime video, which was the first QuickTime thing I’d ever seen, back when they were still making Quadras.
So now with video and sound in place, it was finally time to tackle the networking. At first this seemed quite easy to do, and using SIMH for inspiration I was able to quickly replace the tun/tap code with some pcap code to open the interface, send packets, and receive packets. One more again I started on Linux, made it build on OS X, although my MacBook air doesn’t have anything I can really inject packets into so I don’t know if it actually works. The bigger test for me was on Windows with a GNS3 network, and with a few more minor changes I was happily sending AppleTalk to both Shoebill and Windows NT.
The next thing I wanted to tackle was SLiRP support. Ironically to bring SLiRP to Shoebill I used the SLiRP from the github of Basilisk II. At this point I figured this would be very simple, and I could wrap up later that day. It ended up taking me three days. Once more again my build would crash all the time, just like the later Basilisk II builds. Using Internet Explorer 4.0.1 would seemingly crash the whole system within seconds with faults in SLiRP’s slirp_select_fill, and slirp_select_poll functions. Now if you don’t call these functions SLiRP doesn’t process it’s TCP state and you end up with barely functioning UDP to only SLiRP which isn’t great beyond DHCP and DNS. First I tried semaphores which only made things worse as the nature of Basilisk II’s threaded nature just made the requests stack up deadlocking within seconds. I tried a mutex, timed mutexes and various other locking methods insdide of SLiRP and Basilisk II to no end. Netscape would kind of work, but IE would crash the whole thing out after a few pages. Then a better solution hit me as I was playing with the system clock on the Windows build. There is a 60Hz timer that calls a 1Hz timer once every 60 ticks. What if I had the clock drive SLiRP? And to my amazement not only did that work, but it worked great until I hit another problem that I had with Shoebill (that needs to be fixed now that I found away around it here). There is a static buffer that passes data between SLiRP’s callback when it is going to send a packet to BasiliskII and when Basilisk II then feeds the packet to MacOS. With enough traffic it will overwrite part of itself as they are on two different threads. Once more again I tried semaphores, which of course is the wrong tool here as if something is stacking waiting for it to unstack is just crazy, and more mutexes. The mutexes kind of worked but performance was horrible, as in 1992 dialup speed horrible. And I didn’t want to simulate a 1992 internet experience 100%
So the obvious solution as a queue. I took a simple queue implementation, added the ability to peek, changed it to accept a packet structure and I was set. Now I only needed a mutex when I queued items, and dequeued them. But I could hold 100 packets easily.
So with all that in place I can finally download files greater than 10MB, and even with Internet Explorer!
So the next was to make Pcap dynamically loaded, which for C++ is a bit of fun with __cdecl, GetProcAddress and all that fun. But I had it working after a bit so now if the user doesn’t have WinPcap installed they don’t get an error message, and I don’t have to maintain two builds. Nobody likes doing that kind of stuff. Ever.
There is still plenty of things broken afterall I’m using an ancient version of Basilisk to base this off of. I’ve also removed a bunch of features as I wanted to make this more of a ‘core’ product with again a focus on networking.
Will this interest the majority of people? Probably not. But for anyone who wants to actually download a file this may be somewhat useful.
Where to go from here?
Well there is still a lot of OS specific stuff in the code that I want to convert to SDL. I’d like to build from a 100% more generic code tree rather than having private files here and there. The CPU optimization programs that re-read GCC’s assembly output don’t do anything. I want to try it through an older version of GCC and see if there is any difference in speed. I also recently received the source code to vc5opti.cpp and I’d like to try that to see if it speeds up the Windows Visual C++ based build. Long term I’d love to patch in the UAE CPU code from the newer versions that have a far more solid 68030/68881 and 68040 emulation. The price of standing on so many tall shoulders is that when I fall off I don’t know if the CPU exceptions I see are faults in the CPU emulation, Basilisk II or just plain crashes in MacOS which was certainly not the most stablest thing once you mixed in multimedia and networking. It was par with Windows 3.1, which honestly both of them were ‘saved’ with help from the older generation, ala BSD Unix for MacOS, and the VMS team for Windows.
So after all this I’m ready to release some binaries, and code. Although the last thing I wanted to do is add more confusion by calling this Basillisk II v0.8.SOMETHING … A quick google search on Basilisk gave me this:
As for some reason I actually never did look up what a Basilisk was. So seeing that this project is basically the same thing I chose Cockatrice.
There are plenty of bugs, and plenty of things not working, but it works well enough to do things, and that is a credit to everyone who worked on Basilisk II before me.
(note this is a guest post by Tenox)
In previous posts from ASV series I have explained why I got hooked on Atari System V UNIX and what I had to do to get a decent resolution out of Atari TT. Having built the VGA monitor adapter, the next challenge was to replace the internal SCSI hard disk with a flash storage of some sort. I really don’t like spinning hard disks and especial the old ones.
I have mentioned that there are two surviving ASV disk images. The better one was made out of a rather large old, loud and obnoxious Maxtor. I’m definitely not having this monstrosity inside of my beloved Atari!
So how can you replace an old SCSI hard disk with a modern flash device? There actually are several different ways.
If you have the money you can go industrial route, which is a SCSI disk replacement for various machinery and embedded systems produced by ReactiveData. You can buy one of these for a little over $1000 USD. The good part is that they substitute a specific real hard disk model and are exceptionally good in quality of emulation. However, spending a lot of money on my TT and TenoxVGA already, this really wasn’t an option without getting a divorce.
Another approach is to use SCSI to IDE bridge combined with IDE to CF adapter or possibly SCSI to SATA bridge and SATA SSD disk. These are widely used by Atari / Amiga / Mac 68k community. The most popular bridge come from a company called Acard. I actually had one of these at hand, AEC-7220U which I used for TOS/GEM work.
Did it work? As you can guess – of course it didn’t! The initial boot loader errors out unable to read disk capacity.
Atari ST/TT, somewhat similarly to 68k Macs require a hard disk driver, present on the hard disk itself. There are several 3rd party implementations, some of them, like HDDRIVER maintained up to present date. Unfortunately these drivers are TOS specific and obviously don’t work with Atari Unix. The system comes with it’s own hard disk driver which seems to be obsolete and with limited hardware support.
The next step was to research and try out some other SCSI to IDE bridges in hope one would just work. And surprisingly there are several to choose from.
The second on the line was I-O Data R-IDSC21-E/R. No longer produced and supported, however still fairly popular. Usually regarded as the ultimate bridge with most fancy options bells and whistles. It has most jumpers and modes of all tested devices. For instance ATA PIO and DMA modes. Unfortunately this didn’t help at all and same error was observed.
Another device tried was Yamaha v769970. This bridge was conceived to allow use IDE CDROM and Hard Disks with Yamaha samplers. No longer produced and obsolete, it’s somewhat most easy to set up, robust and stable. It’s actually my favorite bridge for day to day use, except for ASV where it just doesn’t work.
More recent kid on the block is an integrated SCSI2IDE + IDE2CF in one device called Aztec Monster. Recently designed and currently produced in Japan (you can buy one on eBay) is a fairly decent choice, which I recommend to every one. I had a lot of luck with these, except for ASV of course…
I also looked in to SCSI to SATA bridges, like this one, but they have additional issues, like need to convert LVD to SE on one end and SATA to IDE to CF on the other. Little bit too complex for what I wanted.
Being out of luck I started researching if it would be possible to build an open source version, which can be easily diagnosed and fixed. Doing so I found out that there in fact is one open source SCSI adapter called SCSI2SD.
I was bit skeptical in the beginning but then I though that being open source it can be debugged and fixed if it needs to be. So I immediately ordered one.
Once it arrived, I plugged it in, applied the image to the card and BAM! It worked! The system booted fully and worked flawlessly!
Over time SCSI2SD proven stable and flawless. One feature that Mac users will appreciate:
--apple Set the vendor, product ID and revision fields to simulate an apple-suppled disk. Provides support for the Apple Drive Setup utility.
In the next article I will write about my first steps in the system post boot and then bringing it to a more or less usable state. Stay tuned!