Previous 1.6

Posted on by

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.

9 thoughts on “Previous 1.6”

  1. Is there by any chance the source code for the ESP SCSI driver? I’ve performed a few attempts trying to find out why NeXTStep-OpenStep/SPARC is so unstable under QEMU, but haven’t tracked it down. After all it might be a race condition in the NeXTSTEP.

    • sadly no. all I’ve found is here. In the Darwin dump there is source to the EIDE driver, and lots of kernel printf’ing has basically led to the conclusion that yes, it does lose IRQ’s. Even more frustrating is that it happens on real hardware as well.

      Although the source to the driverkit is part of Darwin, the bus stuff is not. I suspect that either driverkit cannot handle IRQ’s being triggered this fast, or there is a silent and fundamental bug in driverkit that they didn’t figure out until dumping driverkit, and the C++ rewrite as IOKit…

      I picked up some Intel P4’s last night, and tried to install Darwin but I get a new and strange trap on those. I’ll have to haul out the other P4 that was losing interrupts and see how it behaves with Darwin 0.3 and see if there is anything I can possibly do.

      I started gutting a SCSI driver, to see if I can do a ‘ram disk’, then start poking the IDE disk in PIO mode. At this point I don’t care if it’s slow, not hanging after 2-3 read/writes would be preferable.

  2. MO disks are actually weirdly common on NEC PC-98s. PC-98 DOS 5 and 6.20 even support 540 MB or smaller SCSI MO drives natively as part of IO.SYS. No driver needed.

    • I’ve seen them in pictures, but oddly enough, every time I’ve been in Japan looking for old stuff, I’ve never seen any. I guess Yahoo auctions is the place, just like midi equipment, I never see it on person but wow so many online

  3. Dust being sucked into the MO drive was a known issue, the NeXT FAQ states the fix is to reverse the cube’s fan so it blows the other way. Problem solved, unless your MO drive is already dead through asphyxiation.

    • Yes, and they figured this out the hard way. If they knew this was going to be an issue, they would have never have put the fans in to suck air through the drives or had the air filters to start.

  4. Oh no, it looks like that link to your Previous 1.6 build is gone! I was a few days too late, I guess. Is there any chance of a reupload of your build?

    • It’s still there. The 404 page, and 404 error code is fake, it’s because some people like to report me for hosting stuff like Windows CE versions of NetHack which are ‘invalid win32’ exes…. so re-read the 404 page, and you’ll get the username & password and a corrected link to download.

Leave a Reply