Previous 1.6

Loading…

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.

Darwin 0.3 single user mode test drive

So I asked around for some old Darwin CD’s and I got lucky!

Darwin 0.3 Front

Volume 1, Summer of 1999!  Although the back doesn’t really give it justice:

Darwin 0.3 back

As you can guess, when they talk about binary and installers, it’s for the PowerMa computers of the era, and not x86.

So once more again, I was able to rebuild a kernel, and build some of the OS.  There isn’t really anything to see, it’s not even slightly usable.  However at the boot loader type in

-s

hit enter, and it’ll boot up in single user mode.

Darwin 0.3 single user mode

Darwin03_qemu090_24_4_2017.7z

There is no games, nothing fun to do, I didn’t even build a compiler.  It’s just enough to show that it’ll boot up.  If you manually conifgure the loop back you can ping yourself, launch inetd you can even try to telnet in, but control break is .. broken, and there is no NetInfo running so no passwords.

Of course for anyone finding this site today there are more newer, and capable images on my sourceforge page:

aapl-darwin/files/qemu-images/

Darwin 0.1 + Rhapsody DR 2 booted!


Following up from yesterday, here we go!

Rhapsody 1.0 booting

So I finally got it running, after some inspiration from NCommander over at nextcomputers.org forums, that the Darwin 0.1 kernel is in fact build-able, I went ahead and took a stab at it.  While he was trying to start from OPENSTEP, I tried it from something as close as I could to the target, which was Rhapsody DR2.

Back in the days of the NeXT / Apple merger, there was hope that OPENTSTEP could become the next great OS for the Apple Macintosh.  It had been a while since NeXT had the OS running so things had rotten somewhat, as time had passed on.  However, the first and most viable platform would of course be the x86.  Back in 1993 while feeling increased pressure in the hardware space, NeXT was forced to start porting away from their black m68k based hardware, and this was an opportunity to get their software running on different platforms.  And sadly in 1993, the NRW aka NeXT RISC Workstation that was in development with dual m88000 processors was killed along with all hardware projects. In the end it didn’t matter as much as the only processor from the early 90’s that has a vibrant future is the i386.

So back again to this transitional time before OS X 10, there were developer versions of this OS seeded out that required you to have an intel machine as OPENSTEP was being ported to the PowerPC machines that Apple was selling.

So on May 14, 1998, the last public version for the Intel processor was released, DR2.

However, two interesting things happened along the way to what would become OS X Server 1.0 .  The first is that Apple gave up on the ‘yellow box‘ portable API, and to satisfy the GPL requirement to release changes to source code, Apple would go one further and release the source code to many of the internal system utilities, along with the kernel in what was known as Darwin.

This was a big deal for many of us, as the cost of getting the source code to any UNIX was incredibly prohibitive, and OS’s like Linux, NetBSD/OpenBSD/FreeBSD were picking up steam, OPENSTEP being awaken from it’s cryonic hibernation but with the promise of being free and open software was pretty great!  Back in the day it sure looked promising!

Obviously, things didn’t work out as everyone had hoped as Apple either straight up ignored anyone on the outside, or they hired people who showed promise, made them sign NDA’s and were basically never heard from again.

So the recently recovered source code to Darwin 0.1 corresponds with the release of the PowerPC only OS X Server 1.0.  However, as we all found out, Darwin will still built and maintained on Intel, as it was a very secretive plan B, in case something went wrong with the PowerPC platform.  Being portable had saved NeXT before, and now it would save Apple.

So with this little background, and a lot of stumbling around in the dark, I came up with some steps, that have permitted me to build the Darwin 0.1 kernel under DR2.

However, it was not perfect, and the biggest glaring issue was due to the software that was recovered, the layer known as driverkit, (driverkit-139.1-1.tar.gz) turns out to be from another, later release of Darwin, the 0.2 release, which the only thing surviving is the driver kit. Â It doesn’t build cleanly, and In order to get it to build I had to break the mach PCI bus. Â This means that yes, PCI devices will not load at runtime, only at boottime by sald.

After a lot of fighting, I was able to produce a system that could boot into both single user and multiuser mode, although it was unable to load drivers so there was no networking, and no UI.

In a fit of boredom, I built a bunch of the command line tools for Darwin, and a few libraries, and then went to see why the driverkit had a problem finding the reason why KernBus was undefined, or even with some attempts at helping all the methods were unknown, I stumbled onto the fact that during compilation it will generate new headers, and in those headers are the correct interface for driverkit to call into the KernBus.  So, I was able to quickly rebuild driverkit, then re-link into the kernel and now I could load drivers!  Thrilled with this much, I did something more aggressive, I made a dump of my install ‘target’ and then restored it onto an image of my dev VM.  And much to my amazement it booted up to the graphical login.  I now had PCI working correctly.

Darwin 0.1

This kind of thing is not for casual users, but if you install DR2 into a VM, you ought to be able to then use this ISO image, and follow these instructions, and you will then have a DR2 OS from 1998 with the OS X 1.0 kernel from 1999 running. The biggest difference I’ve noticed is that the newer kernel can use 512MB of RAM, a nice bump up from 192 which was the prior limit.

Obviously, there is a lot more work to be done, it’d be nice to find some source to an IDE or other block controller and modify it to work with the massive disks of today, along with the filesystem code to handle partitions larger than 2GB.

Maybe it will be possible to port in the driverkit to XNU, so we can get things like existing drivers, and SMP, massive filesystems etc.. It’s great to see we are going the right way.

For fans, here is a qemu 0.90 image+exe that can run Darwin 0.3 into single user mode.

EDIT and for people still hitting this, here is a multiuser bootable image.  I’ll keep updating on the source forge page.

Sourcecode to Darwin 0.1 located!

Over on the NeXT Computers forum, the source code has been uploaded and shared to all!

Rob Blessin uploaded the source!

So naturally I mirrored it as soon as I found out, dumped it into CVS, so I can load it up in CVS2WEB, and src2html.

And I setup a quick mirror over on my vpsland site (as always 404 error gives the correct password). It’s source code only, so no binaries.

As an edit, it was source only, but I’ve made binaries, and even Qemu images.

Darwin 1.4.1 installs on Qemu 2.7!

Darwin 1.4.1 on Qemu

Darwin 1.4.1 on Qemu

I tried the x86 version from Apple’s Darwin web site.  For those who don’t know Darwin was (is?) an open source version of the OS X kernel and userland.  This was on parity with the OS X 10.1 release.  It was notoriously picky about hardware back in 2001, let alone anything today, and much to my amazement it installed fine on Qemu 2.7.

Source code to the packages should be about here. and the ISO is still on Apple’s site here.

I found the source to Mach 2.5

And an i386 port dating back to 1989!

Browsable CVS source is on my ‘unix’ site.

Or for anyone who cares, you can download the compressed MACH_CSRG_CD.7z .

I haven’t tried to build it, but I also see SUN2/3 hardware support, lots of bug fixes from NeXT, but no NeXT hardware support.  Also the VAX platform is in there as well.

*EDIT as an update from the future, I ended up getting disk images to Mach/386 and using that as a build system I was in fact able to build the Mach 2.5 i386 images!

Read about that adventure in Mach 2.5 Independence day.

I just played with NeXTSTEP 0.8

NeXTSTEP 0.8

NeXTSTEP 0.8

And I have to say, it’s pretty impressive!  Previous flies on my system, having owned a cube, I can say that the 68030 on this is WAY faster.  And I’ve always read about 0.8, and kind of figured it was basically lost to the winds of time.  It’s really cool to see it boot up!  And the emulated disks are so much faster than the magnetic optical drives of the day.

It’s amazing to think that in 1988, the current world of iThings had just started.

I was looking back at old posts

And I saw my old look at Mach+Lites.  And of course there was a qcow disk image associated with some ancient version of Qemu which I can’t run on Wine on OS X.  So I figured with a bit of fun I’d update the disk image to work with Qemu 1.7.0.

Luckily Qemu 0.15.1 works just fine for it’s qemu-img.  So a quick

qemu-img convert -f qcow -O vmdk mach.img mach.vmdk

and I had my image.  I’m not sure of what the NE2000 parameters that Mach can use to enable the network, but I do recall it was easier to just rebuild Qemu around them.  However this time, I switched to the Mach kernel that utilized Linux device drivers to get a working network.

I updated the hard disk file here.

Screen Shot 2013-12-27 at 12.16.18 AM

For the two or three people who care about BSD evolutionary dead ends.

A tale of two kernels.

Back in the early 1990’s Microkernel’s were all the rage. Everywhere you would go you’d hear all about Pink, Taligent, Windows NT, and the grand daddy of them all Mach.

Probably the most well known debate about microkernel vs monolithic kernels was the Tanenbaum vs Torvalds debate that raged on comp.os.minix back in 1992. You can read the entire thing here : ( http://www.oreilly.com/catalog/opensources/book/appa.html ). It was interesting in the sense that even Ken Thompson of UNIX fame even chipped in. Tanenbaums’s major points were that a microkernel is more inherently portable than a monolithic kernel, and that microkernels could be more reliable, and easier to maintain. Of course more than 10 years later we can see that Linux still flourishes, and that outside of Windows NT & OS X no mainstream OS relies on a microkernel. Even OS X treats mach more as a call library than a traditional microkernel, since all of the exe’s in Darwin / OS X are Mach-O format, not COFF/ELF,A.OUT, etc etc.

Mach started out as a project from CMU derived from the UNIX source code, to try to re-invent the lower levels of UNIX into something that would scale easier to multiprocessors, support for threads, and the holy grail of them all, expand it’s portability. Sadly the first few versions of Mach are barred from distribution due to their inclusion of encumbered UNIX source code. However when the university of Utah picked up Mach, and released Mach4 (UK22, info here http://www.cs.utah.edu/flux/mach4/html/Mach4-proj.html ), including full source. Also they provided Lites, a BSD server that can run atop Mach, giving the user a ‘UNIX’ system, as it were.

Lites

Lites

So digging through some network groups, and testing stuff, I finally slapped together the pieces, and built a Mach/Lites system on NetBSD 1.1 . And how does it perform? It’s significantly slower than NetBSD is. You can tell that the amount of context switching involved in Mach as a program makes a call the microkernel, which in turn validates & passes it to the server, which further validates, runs the process, then sends the results back to the kernel, which then passes it back to the program. I’ve heard in a worse case scenario a 500% reduction in speed. You can always read more info on the fine wiki article here ( http://en.wikipedia.org/wiki/Mach_kernel ).

Lots of people will argue that microkernel’s have simply failed, and that it’s simply an example of what seemed like a good idea being pushed too hard once it was found to fail. It a lot of ways it reminds me of ADA.

So for now I’m going to provide a Qemu image of Lites running on Mach 4. unzipping the file will provide you with a lites.cmd file which for windows users you can just run directly. Things to note are:

-The version of Qemu that I’ve bound requires libpcap to be installed.
-Mach4 can only address 16mb of ram, due to DMA issues across the 16mb line.
-I’ve enabled user mode networking so that
-the cmd file sets up local port 23 to be redirected to the VM. This will allow you to telnet in simply by ‘telnet localhost’. You may want to use putty for better terminal handeling
-The included Gcc 2.4.5 is ancient. Outside of building a simple irc client, I wouldn’t expect much.
-The boot process is broken, and it’ll parse through the rc scripts twice. Just let it do it’s thing, and it’ll drop to a login prompt.

Logging into Lites/NetBSD

Logging into Lites/NetBSD

Other than that it behaves just like a NetBSD 1.1 machine.

Notice that grub boots the kernel /Mach.UK22 . When Mach boot’s it’ll load up the files emulator & startup. The ‘emulator’ is the Lites microkernel. Once it’s loaded it’ll start mach_init which just symlinks to /sbin/init and the normal NetBSD bootup will commence.

You can download my image directly here as MachUK22-lites-nat.zip.

Using modern (2022) qemu I run it like this:

qemu-system-i386.exe -hda lites.vmdk -net none -device ne2k_isa,iobase=0x300,irq=5,netdev=ne -netdev user,id=ne,hostfwd=tcp::42323-:23 -serial none -parallel none

Next time we’ll play with SLS Linux.