========================
February 17, 2018 UPDATE
========================

Thanks to Amazon.com, my Mach386 development system is working again.
After ordering 40 1000uf 6.3v electrolytic capacitors from them at
11:30pm last night, they arrived at 12:00 (noon) today. 12 hours and
30 minutes after ordering, and another two hours replacing all 24
capacitors on the motherboard, and it is working solidly again.

I took my time on the capacitor replacement. I replaced three to four
at a time, and tested the motherboard at each interval. The motherboard
came alive again after the second set, which was a group of capacitors
just along the Slot-1 CPU itself. I continued replacing all the capacitors
in groups ensuring that, had I made any mistakes soldering, it would
be easy to locate and resolve. I did not have to rework any replacements
or otherwise make corrections on the board.

While I was awaiting the board repair, I began trying to understand and
document how to install Mach386 to a disk, or add a new disk drive to an
existing Mach386 system, which is greater than 4GB. There are a number
of issues with large drives and this older UNIX operating system. The
issues exist not only for IDE/ATA drives but the same problems exist for
SCSI drives.

The fundamental problem is that while Mach386 disk drivers will happily
use whatever configuration they're told, they obtain the disk geometry
from a Mach VTOC stored on the drive. To get this VTOC created, one
must use a combination of the utilities fdisk(8), badblocks(8), vtoc(8)
and diskutil(8) to get a drive set-up for Mach to use. The trick lies
in getting a working VTOC written with a geometry different than what
BIOS or the device itself has reported.

The Mach386 kernel drivers are not able to readjust a disk's geometry
dynamically. So there are a number of reboots that must occur. In
particular, immediately after changing the geometry for the fdisk
partition, the VTOC partition and then again after generating the Mach
partitions.

Mach partitions are very similar to disklabel(8) partitioning and while
reported by disklabel(8), are not the same. The earlier (pre-March 1992)
Mach386 systems did not use VTOC. VTOC was introduced after that time
both in floppy distributions as well as sysload(8)/online updates. Once
VTOCs are employed, the disklabel(8) facility should not be used and
will even cause problems if partitioning is changed via disklabel(8).

I did manage to add an additional ATA 10GB drive today and partition, format
and copy filesystems from a SCSI disk. This was, however, not easy
and very time consuming primarily due to the empirical learning and under-
standing of the process to change geometries to within the 4GB limit.
I plan to continue determining how to best perform this process and
will document it.

I really wish I could find Mach 2.6MSD sources, especially to these
disk utilities.

========================
February 16, 2018 UPDATE
========================

Today, after some heavy searching, I've found sources to a number of
utilities customized by CMU. In particular, I've found the CMU-modified
sources for the version of csh(1) in MACH 2.5. This is important, because
there is at least one bug ("cd ../.." at root will crash csh). I've found
the problem, fixed it, and rebuilt csh. The problem is resolved now.
Additionally, the binary sizes are so close that it gives me confidence that
the found csh source code really is that which was used in Mach 2.5:

root@mod43:/ 5 # ls -l /usr/build/obj/usr/cs/bin/csh/csh /bin/csh
-rwxr-xr-x 1 mtxinu 122904 Jan 27 1991 /bin/csh
-rwxr-xr-x 1 root 122912 Feb 16 16:56 /usr/build/obj/usr/cs/bin/csh/csh
root@mod43:/ 6 # size /usr/build/obj/usr/cs/bin/csh/csh /bin/csh
text data bss dec hex
118752 4128 15692 138572 21d4c /usr/build/obj/usr/cs/bin/csh/csh
118752 4120 15752 138624 21d80 /bin/csh

Work continues with the distribution-generation utility for sysload(8).

LATE update:

Suddenly, after many weeks of working on Mach386 using my lone ISA-based
computer, the system suddenly became unstable and generally wouldn't boot
or even begin the BIOS POST test.

Examination of the motherboard revealed why: Almost every one of the electrolytic
capacitors on the motherboard had suddenly swelled, with many having almost popped
the can off. There was no physical leakage onto the motherboard, however. All of
this literally occurred within a 12-hour period; I specifically examine them periodically.

While I have a spare motherboard and CPU, it only has one ISA slot. I need
at least two ISA slots to accommodate the Adaptec SCSI and the SMC 80x3 ether
boards being used for Mach386.

I've ordered new capacitors from Amazon at a very good price, and they're
expected by tomorrow evening--free next day shipping with my Amazon Prime.

========================
February 14, 2018 UPDATE
========================

I've completed a sysload(8) replacement that facilitates extracting the contents
of Mt Xinu's Mach386 media on a FreeBSD machine. It functionally duplicates all of the sysload(8)
options and operations, with the exception of the -u (update from a remote server)
functions. I have no information on the protocol or operation of such a server.
The replacement sysload(8) fully duplicates the Text-base User Interface presented
by the Mach386 utility.


I will next be writing a utility to generate the distribution images. This will
allow creating new floppy images with the latest available binaries for installing
Mach386 onto a machine with all updates available.

========================
February 13, 2018 UPDATE
========================

I've discovered (realized, really) an NFS issue. However this is not
specific to Mach386.

Because I am mounting mammoth-sized NFS filesystems currently, while I
look for and recover additional Mach386 data from my old media, I began
encountering segfaults and other strange behaviour in some programs.
I just realized that this is due to the filesystem itself. Many
programs simply aren't able to work with the filesystem, particularly
when creating temporary files... Like ex/vi does.

Lesson re-learned.