Joined: 28 Jun 2017
|Posted: Tue Jul 18, 2017 3:04 am Post subject: NeXTStep 3.3 running with VESA VBE 2.0 graphics!! (crucial)
after some investigation, I've found a method how NeXTStep 3.3 can
use the VBE20DisplayDriver, and successfully run in 1280x1024x16bpp.
As Morgon explained on Feb 12, 2009 in
NeXTStep 3.3's kernel lacks the ability to set up VESA VBE modes.
The more, it uses an older driver model than Openstep and thus
cannot make use of the latter's drivers.
Although I had once purchased an Openstep package, I never installed
it on x86 (only on a sst5, as I missed NeXTStep's SPARC edition).
NeXTStep was my very first Unix installation, the S3 or Matrox display
drivers on x86 worked fine. No need to switch to Openstep.
The S3 and Matrox graphics boards are gone (almost). Several threads
in this forum deal with the VESA VBE driver included in Openstep
User's latest patch. A good thing, for recent hardware and / or
software emulators. When I examined my Openstep software package
(for first time this millenium ;-), I discovered an Openstep 4.2 CD.
A friend with a fast academic internet connection had even loaded
it's latest patches in 2001. Sorry for my ignorance ...
Installation of Openstep 4.2 and User Path 4 were straightforward.
Difficulties in setting up the VESA VBE driver had been reported. I
didn't encounter any, on the first reboot, the driver initialized in
1280x1024x16bpp (both the VGA and the VESA driver were selected in
Configure.app - surprisingly, no resource conflicts were detected).
Integrating this driver into NeXTStep 3.3 is a three-step-procedure.
I did it with disk images in a software emulation (VirtualBox 5.0.2),
but it should be applicable to real hardware as well (disk handling
more laborious here, though). As cited above, the latest available
Mach 3.3 mk-171.14 1999/07/13 kernel cannot handle Openstep drivers
(fails due to missing functions). What if NeXTStep 3.3 instead used
Mach 4.2 mk-183.34.4 1999/01/26?
It's not a matter of just adding /mach_kernel 1117920 bytes 99/03/23
and Openstep 4.2' /mnt/private/Drivers/i386 directory into a running
NeXTStep 3.3 system. The proper kernel initialization seems to depend
upon the boot loader files located in Openstep's /usr/standalone/i386
directory. With only it's /mach_kernel and drivers copied on the
NeXTStep drive, the kernel boots from the *old* 18.104.22.168 loader. Drivers
load as well, but graphics modes and hence the WindowManager fail to
initialize. Just adding Openstep' /usr/standalone/i386 directory won't
overcome this, it seems that the boot sector points to the *physical*
location of these files, similar to Linux' LILO or GRUB loaders (even
in DOS =< 7.0, the location of it's kernel files is crucial). Small
boot code in a disk's start sector cannot handle sophisticated file
system structures, this seems obvious.
As I did not know about NeXTStep's boot sector tools (must exist) and
their configuration, I started a brute force approach:
1.) Made a copy of the Openstep 4.2 disk image. Mounted this as a
second disk in an Openstep session. Deleted all files from this
second image, except /mach_kernel, /mnt/private/Drivers/i386 and
2.) Mounted a NeXTStep 3.3 image as a second disk, or as a virtual
drive in Linux ("mount -t ufs -o ufstype=nextstep <image> <mountpt>").
Created tarballs from the entire's disk content, except the files /
directories mentioned above.
3.) Unpacked these tarballs onto the nearly emptied second Openstep
disk (in either NeXTStep or Openstep, the Linux 22.214.171.124 kernel can
just mount their filesystem read-only). Make sure that the owner
of the files in /me is set accordingly (the Workspace Manager
cannot save changes if they are owned by root). Reboot.
If everything went correctly, the kernel should now initialize the
configured VESA mode, as with Openstep 4.2 (in fact, the boot process
now relies on pure Openstep code, until NeXTStep 3.3' WindowManager,
daemons and apps are started). When the WindowManager really starts -
enjoy! Your may consider to correct data in the /NextLibrary/Receipts
folder, i.e. to remove references to no-longer existent NeXTStep 3.3
drivers, and to add OS42MachUserPatch4.pkg there, to indicate that
the system is running the very latest kernel (cosmetical).
I have created a compressed version of my 337 MB image file, it's "raw"
format should be supported by several emulators. Some helpful files are
joined (a minimalistic dummy ISO image to speed up booting, VirtualBox
.vmdk file, Readme), if someone was interested. Thanks to Openstep's
Am79C970 driver, networking now works in VirtualBox sessions, at
reasonable speed (faster than Apple's System V Unix). Running a
VESA-enabled NeXTStep 3.3 on real hardware would be interesting.
The described procedure reminds me of a proposal Lars Erdmann had made.
He develops and maintains USB drivers for OS/2. Alas, for Warp4 only,
which uses a more complex kernel than Warp3. I prefer the latter, and
Lars' drivers won't load here. He thus asked me to start Warp3 with a
Warp4 kernel (and his drivers). This is impossible, a "You are using
the wrong version of the operating system." message was displayed.
With Openstep's kernel, I was more optimistic. In fact, Mach 4.2
reveals as quite tolerant. Old operating systems are fascinating!