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.