NeXTSTEP 3.1 in Previous

Hi, all.

Is anyone successful with running 3.1 in Previous?  I keep getting some odd problems, such as the ones you see here.  This system was upgraded from NS3.0, which was upgrade from NS2.2.

This first one is what I see after selecting English and the US keyboard.


This second one is what I see when I log in as root.


This third one is what happens when I press the power button on the login screen.


Anybody have a clue about how to fix these, or if they are maybe bugs in Previous?  (I do not suspect that these are bugs with Previous.)  Thanks.

does this happen also if you're running the whole thing in greyscale-mode?

I do have a genuine set of NS 3.1 (boot-floppy and CD-ROM). if you like I could provide you images of these so you can try with a fresh install instead of an upgrade...

Hey Mike.  I imaged my NeXTSTEP 3.1 CD-ROMs, and I got the following MD5 checksums from them:

adfef37e096bfdf0f554e5e85fccecb7 NeXTSTEP 3.1/Developer-3.1.iso
fe8880f99a78dad49614c6656e6f833b NeXTSTEP 3.1/Install-3.1.iso
Does that match yours?

I do not have the floppy image, but would prefer to be able to do clean installs; could you email that one to me as well?

It has been so helpful for you to provide me with the floppy images, because I do not have a way to image them myself.  I should've done it 10 years ago when I still had a floppy drive!

I don't have NS 3.1 Developer, only User. I got a different MD5:

a3515580315cc322dbeb237a125d2134

but I also used a slightly different command to create the ISO:
sh-3.2# dd if=/dev/disk5 of=/Users/mikeboss/Desktop/NS31.iso bs=2048

I think if you use /dev/diskX you get a "raw" dump which might explain the different md5. You can tell by dividing the filesize of the iso by 2352. If it goes in evenly it's a raw dump.

Most ripping tools won't use raw mode unless there's multiple sessions involved (like bin/cue) or CD audio tracks.

If you use /dev/rdiskX it will rip in normal mode. The filesize will be evenly divisible by 2048 then. Update: I was sure that worked but I got it wrong. /dev/rdisk doesn't work. /dev/diskXs0 does.

The blocksize has no effect on the resulting image. It's just the read/write buffer.

Interesting.  Mine image's size (386654208) is evenly divisible by 2048, not 2352.

My CD does not show a part number; it simply says "RELEASE 3.1 FOR NeXT COMPUTERS."

On the inside of my CD case (behind where the CD goes) is a small sticker that reads "AEM0012992."

I have one more thing I can try: I booted NS3.3 with my NS3.1 hard disk and CD-ROM mounted.  I am running BuildDisk from the 3.1 CD, and it's installing.  I'll see if that builds a working install.

Edit: it does build a working NeXTSTEP install: it builds a 3.3 install!

I'm not sure what my options are now: I have tried upgrading from 2.x, booting from floppy, and running BuildDisk right from the CD.  I have also tried installing 3.1 to all 3 emulated computers.

Has anyone else had success with 3.1 in Previous?

I really suspect that I have a bad CD. :(

Yeah I remember trying BuildDisk with NS4.0 in the hope it would let me "clean" install it to a new disk and finding out that it only clones the running system.

I only have 3.1 for Intel so I can't help you out here.

Most single-session isos will be evenly divisible by 2048 but occasionally you can find one that was dumped raw. In this case I usually convert them with binchunker or a similar "bin to iso" tool.

I re-ripped the 3.1 CD-ROM using dd if=/dev/disk5s0 and MD5 is exactly the same as yours.

could you provide me an up-to-date binary of previous (for OS X)?
I then will try to install NS 3.1

Here's the binary I've been using...

https://dl.dropboxusercontent.com/u/13208710/NeXT/previous.app.tgz

not working for me, it keeps asking for some libraries

/usr/local/lib/libSDL-1.2.0.dylib
/opt/local/lib/libpng15.15.dylib

Yeah, I think my environment might be a little different from yours.  I forget how those 2 libraries got installed in those locations; maybe someone else can help with how to install them.  If they don't install in those locations, you can of course link them there.

ok, downloaded libSDL-1.2.0.dylib from some place on the internets: seems to be the right file. found libpng15.15.dylib hidden inside FS-UAE but now I get this:

Dyld Error Message:
 Library not loaded: /opt/local/lib/libpng15.15.dylib
 Referenced from: /Users/USER/Desktop/previous.app/Contents/MacOS/Previous
 Reason: no suitable image found.  Did find:
   /opt/local/lib/libpng15.15.dylib: mach-o, but wrong architecture

BTW, found a nice collection of boot-floppies ->

http://www.shawcomputing.net/resources/next/hardware/boot_floppies/boot_floppies.html

Great find! I really like shawcomputing.net and his Rhapsody Resource Page: http://www.rhapsodyos.org

okay, I'm seeing the same behavior (Workspace Manager Error, empty requester etc.) with NS 3.1 as you do.

That's weird. I wonder what's up with 3.1?

Yeah, it's really weird.  I guess I'm giving up on 3.1 in Previous, and I think it's 3.1's fault, not Previous's fault.

Quote from: "eagle"Yeah, it's really weird.  I guess I'm giving up on 3.1 in Previous, and I think it's 3.1's fault, not Previous's fault.

well, if it's running on black hardware... I'm in the process of installing 3.1 on one of the cubes. will make an image of it and afterwards I'll test it in previous.

Mike, keep me posted about that -- that's a great idea.

okay, now with the image I created from a disk containing a fresh install (on a turbo-cube). of course the installation process ran fine on black hardware  :P

no dice! NS 3.1 hangs with "root on" as long as the emulated machine is a cube. when running as a slab it's booting but I'm getting the "Workspace Manager Error".

That's a bummer.  I guess there must be something wrong with Cube emulation.  Did you try both the 68030 and 040 Cube models?

Quote from: "eagle"That's a bummer.  I guess there must be something wrong with Cube emulation.  Did you try both the 68030 and 040 Cube models?

it seems there's something wrong with the slab too (Workspace Manager Error). of course I ran both types of cubes.

I can confirm that 3.1 is now working in Previous 0.4.  I have it installed, along with the Developer tools.

Sweet :)

Quote from: "eagle"I imaged my NeXTSTEP 3.1 CD-ROMs, and I got the following MD5 checksums from them

Code Select Expand

adfef37e096bfdf0f554e5e85fccecb7 NeXTSTEP 3.1/Developer-3.1.iso
fe8880f99a78dad49614c6656e6f833b NeXTSTEP 3.1/Install-3.1.iso
Does that match yours?[/code]

It matches mine dumped on a certain version of Mac OS X.
However, I have also dumped the another copy of the developer CD on another (earlier) version of Mac OS X, and it produced a different md5 sum:21452083306da756485ceab8ac99269b NeXTSTEP 3.1/Developer-3.1.isoThe only difference is that the first dump (the one that matches yours) contains an extra 300kB of NULs at the end.

Since I've dumped an original OpenSolaris CD on the same version of Mac OS X, which came out as equal to the dump of the same CD on opensolaris mirrors, PLUS 300kB of NULs at the end, I am wondering whether it's correct to have these 300kB of NULs at the end or not, and whether this is a bug in this particular version of Mac OS X. Which would imply that both my first dump of the developer CD and your dump contain an extraneous 300kB of NULs at the end.

I have not investigated this.

And the extra NULs probably don't cause any harm.

Quote from: "mikeboss"I don't have NS 3.1 Developer, only User. I got a different MD5:

a3515580315cc322dbeb237a125d2134

but I also used a slightly different command to create the ISO:
sh-3.2# dd if=/dev/disk5 of=/Users/mikeboss/Desktop/NS31.iso bs=2048

Yes, this is the correct MD5 sum of the raw dump.

I have noticed that some images can have padding appended to them depending on how they are ripped.

As such I think it's a good idea to also include the filesize with the hash when verifying dumps. I've been able to match some checksums by adding or removing padding from dumps, but knowing how much padding is there depends on knowing the filesize. I've had little success guessing it.