Openstep install hangs in previous.

Started by spitfire, April 28, 2021, 02:41:45 PM

Previous topic - Next topic


HI all,
 I'm trying to install a fresh installation of OpenStep 4.2 in previous.
I've made an empty 4gig disk and boot up of the m68K floppy along with a user CD image.

However once the first OpenStep screen appears it says "Initializing system" and then hangs forever..

Is this a previous bug? How are people installing OS4.2 under previous?
I dislike the build disk option as it never quite seems to match a fresh install.


Please give me some details: What system are you running on? Do you use a disk image that was supplied with Previous? If not, what is the exact size of the image (in bytes)? What machine is Previous configured to emulate? Is simulated ethernet connected during the boot process?
With those details I'll try to reproduce it.

Update: I never tested disks greater than 2 GB. But reading a few sites on the internet it seems that you run into problems with partitions > 2 GB. So please try again with an image that has less than or exactly 2 GB.

Update 2: When retrying with the smaller image please select "verbose test mode" from the Boot options dialog before starting the procedure. I may give us a hint about what is wrong (in case it still fails).


I figured it out!

Answer: Boot from floppy via rom monitor.

I booted to the rom monitor and booted from floppy manually - Everything came up in text mode and worked fine.

I'm guessing NeXT could never boot from floppy via keypress? I don't remember from my old system.
so previous can force boot to a floppy, and that confused the installer.

However, in the process I did nuke my ns3.3 disk. Previous really could use some UI I work...



I think profiles would be useful. I know that'd be a lot of UI work, but it would be useful.

So I'm still having one new problem. When openstep boots up the usual OPENSTEP image and loading progress system never displays. You just get a grey screen for a minute or two while everything loads.

This is.. Unusual. Looking through the rc boot files there's fbset commands that should display the progress bar, but nothing actually displays.

However, OS is a dog on black hardware, even in previous. So I might just do a fresh install of NS3.3 on a disk image and leave things at that.


You can save and load configuration files. That is a way to manage profiles.

I guess you use NeXTdimension? If you enable "Console on NeXTdimension" it will show the boot progress on the NeXTdimension display which I suppose you are using as main display. Please note that, as with real hardware, this won't work on a 68030 Cube or if NeXTdimension has too much RAM installed (16 MB will work).

For the speed issues: If you set CPU clock to "Variable" (System options > Customize) you get some extra speed (faster than a real NeXT). Of course that is limited by your system's performance and general timing restrictions in the emulator and guest system.


I just tested this on Previous configured for Turbo Cube (mono) and Turbostation colour.
I don't think this is a previous issue at all. Some weird openstep thing.

Checking the rc files you see "fbshow" commands that should print a progress bar along the way.
However booting from rom, or directly to SCSI disk, both with and without extended diagnostics still has none of the fbshow progress bars showing up.

I've tried all three of the "show display" options too.

At this point I'm not going to investigate any more, and just treat it as an OS quirk.

However I will try to throw in on previous development any way I can. Mostly trying to multithread it as best I can.


I just tested and it I also don't see a progress indicator while booting OPENSTEP. I did re-check the values in the NVRAM and they seem to be fine. OPENSTEP also sets them like Previous does. This really might be just some bug or "feature" of OPENSTEP.

Thank you for joining Previous development! For your goal to add multithreading I am afraid there is not much potential for improvements there. It is only CPU and DSP that theoretically could be separated. But they are connected so closely that it might not be possible to efficiently multithread them.

Most work needs to be done on networking (I'd like to have full autoconfiguration) and NeXTdimension (adding dither RAM, video output to a file).


Well that makes things clear then. It's not my fault.

Shame to hear about tight coupling wrt previous. I was hoping there would be some multithreaded wins to be had. But the Dimension board is accessed over a bus. So there should be some opportunities for decoupling and multithreading there. Certainly the i860 core could live in its own thread.

Also, I'm going to post this on the mach kernel upgrades thread as it's relevant. But I'll also post it here.

I (re)discovered libcpu last night. Looking through its source code one of the tests was a "next68k" test which loads a mach-o binary and JITs it from m68k to host cpu architecture.

Now I have no clue how to actually use this in practice. It requires LLVM to compile, and that won't compile on NS/OS. and I'm not brave enough to try cross compiling. So it's an odd duck.
Running improv and a few other m68K only apps on intel openstep would satisfy all my NeXT computing needs. Minus the physical hardware and that nice laser printer.

But libcpu might make for faster CPU emulation than hateri...


Quote from: spitfire on May 02, 2021, 12:06:58 PMCertainly the i860 core could live in its own thread.
It already does.