======================== February 28, 2018 UPDATE ======================== I discovered on the 26th that if you attempt to unmount an ISOFS filesystem while it's busy, the kernel will panic. This afternoon, I tracked the problem down to "flush" code in the isofs driver: *** isofs_node.c.ORIG Wed Feb 28 18:59:56 2018 --- isofs_node.c Wed Feb 28 18:50:12 2018 *************** *** 201,232 **** --- 201,234 ---- /* * stupid fs-specific flush routine */ isoflush(vfsp, vp) struct vfs * vfsp; struct vnode * vp; { union iso_ihead *ih; struct iso_node *ip, *iq; iq = VTOISO(vp); loop: for (ih = iso_ihead; ih != &(iso_ihead[INOHSZ]); ih++) { for (ip = ih->ih_chain[0]; ip != (struct iso_node *)ih; ip = VTOISO(ip->iso_forw)) { if (ip->iso_fs != vfsp) continue; if (iq != (struct iso_node *) 0 && ip != iq) continue; if (ip->iso_count != 0) { + #ifdef CAUSES_PANIC_WHEN_BUSY dnlc_purge_vp(ISOTOV(vp)); binvalfree(ISOTOV(ip)); + #endif CAUSES_PANIC_WHEN_BUSY if (ip->iso_count != 0) return (EBUSY); goto loop; } } } return (0); } I don't understand why, despite the vnode being "busy," there was an attempt to force that purge and free of the node. There won't be any pending write data to flush, since ISOFS mounts are read-only. I've #ifdef'd out those two lines and unmounting an ISOFS while the vnode is in use now errors with EBUSY as expected. Mach 2.6 doesn't have umount "force" capability, so it wouldn't be useful to attempt a rude unmount. The ISOFS driver code is incomplete, based on comments in the code itself. This may just be a problem characteristic of this new ISOFS functionality having just been introduced into 2.6MSD when it was released by Mt Xinu. ======================== February 18, 2018 UPDATE ======================== A new interesting problem discovered today. I suddenly noticed that the SMC WD80x3 ethernet driver is not discovering the card's MAC hardware address correctly. It was only reporting the first three bytes correctly--the last three were always zeroes. This was discovered when I was trying to bring up a second Mach386 machine as a testbed for new kernel and other software builds. I first suspected a hardware problem, and swapped cards. The same thing was occurring. Worse yet, I checked the main development machine... and it was occurring there as well. The problem is only noticed now because trying to use two Mach386 machines on the same network caused a MAC conflict between them. They both were using the MAC ID of 00:00:c0:00:00:00. tcpdump(1) verified that the incorrect MAC ID was being used on ethernet traffic. I couldn't be sure that I had actually seen the MAC addresses correctly determined under Mach386. My recollection was that I only ever paid attention to the MAC was when utilizing the SMC EZsetup software and sending out test packets from the DIAGNOSE utility. So I booted up DRDOS and checked out the DIAGNOSE utility. I saw the correct MAC id being sent onto the network. This verifies that the network cards are not at fault. I turned my attention to the Mach386 kernel. I began booting older kernels that I've built, presuming that I had made an errant change. All showed the same MAC problem. Then I tried the last custom-built kernel from 1993, which I built from updates from Mt Xinu. This one failed as well. I then reverted to the latest Mt Xinu floppy distribution kernel. I must take care when running this kernel, as it has differences in the disk drivers and disk labeling software. It can be destructive to try to fsck(8) a large filesystem with it. I avoided letting fsck(8) get run. This Mt Xinu kernel probed the MAC address correctly. OK, back to the kernel sources then. Obviously something happened to the if_ns8390.c driver code for the SMC 80x3 cards. Long story short, I found the following code in the driver: if (((u_char) inb(hdwbase+IFWD_LAR_0) == (u_char) WD_NODE_ADDR_0) && ((u_char) inb(hdwbase+IFWD_LAR_1) == (u_char) WD_NODE_ADDR_1) && ((u_char) inb(hdwbase+IFWD_LAR_2) == (u_char) WD_NODE_ADDR_2)) { ns8390info[unit] = dev; sp->card = wd8003_card; dev->name = wd8003_card; sp->nic = hdwbase + OFF_8390; /* enable mem access to board */ sp->board_id = wd80xxget_board_id(dev); *(sp->address) = inb(hdwbase+IFWD_LAR_0); *(sp->address + 1) = inb(hdwbase+IFWD_LAR_1); *(sp->address + 2) = inb(hdwbase+IFWD_LAR_2); *(sp->address + 3) = inb(hdwbase+IFWD_LAR_3); *(sp->address + 4) = inb(hdwbase+IFWD_LAR_4); *(sp->address + 5) = inb(hdwbase+IFWD_LAR_5); return TRUE; } /* checks the address of the board to verify that it is a WD */ And keeping the story short... That call to wd80xxget_board_id(dev) is where the trouble occurs. Once that function returns, the inb(...) calls to obtain bytes from the card are returning a value of zero. I haven't investigated the fault further. But I've worked around the problem for now. I've moved that board_id function call to *AFTER* assigning the MAC address bytes with the inb() functions. I will spend time at a later date to fully determine the problem and resolution. It may be an issue of CPU speed/timing; Back in the early 90's, I likely ran a 486DX2 50 or 100mhz machine for Mach386. Today, I'm running it on a Pentium III 800mhz and a Celeron 500mhz machines. ======================== 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.5MSD 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 know this because I have constantly Adding, removing or changing drives and cards in the machine. 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. 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. ======================== February 12, 2018 UPDATE ======================== I've fixed the SCSI Tape End-Of-File read problems. The st.c driver has some very bizarre code interpreting the SCSI status blocks. With that said, I found two issues: 1. When a short-record was read, it was not setting bp->b_resid to the correct shorter length in certain cirumstances; and 2. When a tapemark was read, bp->b_resid was not being set to indicate no bytes read. I've tested the my changes extensively and I'm satisfied that SCSI Tape functionality is working as it should now. Current device probe configurations (in order): Device Type CSR/Port PIC Memory ------ --------------- -------- --- ------- hd Hard Disk 0x1f0 14 - HD Drive 0 0x104 14 HD Drive 1 0x1f0 14 fd Floppy 0x3f2 6 - sd SCSI Controller 0x330 11 - pc586 PC Network - 9 0xd0000 Alternate 1 - 5 0xc0000 Alternate 2 - 12 0xf0000 wd SMC 80x3 Net 0x280 3 0xd0000 Alternate 1 0x2a0 5 0xd0000 Alternate 2 0x2e0 10 0xd0000 Alternate 3 0x300 10 0xcc000 3c501 3Com 3C501 Net 0x300 9 - Mouse Mouse Driver 0x23c 4 - com Serial Port 1 0x3f8 4 - Serial Port 2 0x2f8 3 - Serial Port 3 0x3e8 5 - Serial Port 4 0x2e8 10 - lpr Parallel Port 0x378 7 - wt Wangtek Tape 0x300 5 - Alternate 1 0x288 5 - Alternate 2 0x338 5 - ======================= February 11, 2018 UPDATE ======================= o Today I have successfully recovered the relinkable kernel distribution, built, and booted a new kernel. This is important as it means that the portions of the kernel provided in source form can be modified and a new kernel generated. The important source files provided are: i386at: adaptec.c Adaptec AHA 1540/1542 SCSI controller driver autoconf.c Device configurables: Port, IRC/PIC, Memory com.c Serial port 8650/16450 UART driver conf.c Device driver linkages to the kernel hd.c MFM/IDE/ATA controller (DOS/WD-compatible) if_ns8390.c NS8390 (Western Digital and compats) network driver if_par.c Parallel Network Interface if_pc586.c PC 586 and compatibles network driver lpr.c Parallel port driver sd.c SCSI Disk driver st.c SCSI Tape driver qd.c AST Async Cluster Adapter driver I've changed the default configuration options for the NS8390/WD80x3 network card as follows: Detection Port IRQ/PIC memory #1 0x280 3 0xd0000 #2 0x2a0 5 0xd0000 #3 0x2e0 10 0xd0000 #4 0x300 10 0xcc000 Options #1 and #4 allow use of the hardware jumpering on the card for those combinations. The others can be set via the SMW EZSETUP utility for setting the "soft" jumper configuration. With the recovered and buildable kernel distribution, I will not be able to debug and fix the SCSI Tape "last tape block" problems described previously. o Included in the relinkable kernel distribution are a kernel driver and mount_isofs command to mount and read ISOFS/CD9660 CDs. The CD device must be one that is settable for 512-byte block and SCSI- interfaced. I've tested this code works in a new kernel. o So far no issues with NFS or any other networking facility. o Today I also successfully mounted an NFSv2 filesystem from a FreeBSD 11.0 server onto Mach386: # mount mod5:/tiny /nfs # df /nfs Filesystem 1024-blocks Used Available Capacity Mounted on Mounting a Mach386 NFS filesystem on FreeBSD 11.x is also working. The mount_nfs "-o mntudp" option is needed on the FreeBSD side to allow it to communicate with the older NFS protocol used by Mach386. o From my recovered dumps from 1996, I've updated my working recovery system with all the latest Mt Xinu-distributed updates. I will pursue generating update-floppy images to bring a freshly-installed system, from the distribution floppies, to these latest-available binaries. o I've ported the 2.11BSD patched date(1) command to allow manually setting a date beyond Y2K. The kernel is already using a 32-bit time_t, so it is still restricted to the Y2038 limitation, however I have not discovered any Y2K bugs other than the date(1) command; the kernel is Y2038-compliant. o With respect to the SCSI tape problems I've encountered: I been doing testing with the oldest drive I have: Tandberg Data TDC3600 150MB QIC drive using DC6150 tapes. The driver appears to be returning the last block twice. That is, when EOF is reached, it sends the previous block one more time before reporting EOF to the calling process on a subsequent read. I've verified this with a tape recorded on another operating system. I believe I've ruled out controller, SCSI version (SCSI-1 vs SCSI-2), and the drive. Three different drives of different media type and greatly different generations (QIC vs DDS vs DLT) all exhibit the driver problem. I continue to track down the exact symptom and conditions (Unix block size Vs. Pysical device block size, etc.) before I will start debugging the st.c and adaptec.c drivers for this issue. Later Note: OK, here's what's happening. I wrote a tape on this same hardware with FreeBSD 8.1. I wrote a tarball to disk containing the FreeBSD kernel: # ls -l kernel.tar -rw-r--r-- 1 root 11784704 Feb 11 21:58 kernel.tar I then used dd(1) to write that to a DLT III tape (via a DEC TZ87 tape drive this time) using a 10,240 block size. That was 1,150 blocks plus one partial block of 8,704 bytes at the end. I read the tape back to verify the block count and written data. I then copied that kernel.tar to USB and moved it over to another machine for reference. I booted Mach386 again on this hardware. Under Mach386, I read the tape with dd(1) using 10,240-byte blocks: mod43 11 # dd if=/dev/st0 bs=10240 of=DLT.tap 1151+1 records in 1151+1 records out Note the extra block. It should have read 1150+1 records. I copied the USB kernel.tar file across the network to Mach386, named 'kernel.tar'. Notice the differences in sizes: -rw-r--r-- 1 root 11794944 Feb 11 21:57 DLT.tap -rw-r--r-- 1 root 11784704 Feb 11 21:58 kernel.tar That is a difference of 10,240 bytes, the blocksize being read via dd(1). To verify what's happening, I performed the following: 1. Read the first 1150 blocks from tape into a file: mod43 56 # bs=10240 count=1150 of=t1-1150 1150+0 records in 1150+0 records out 2. Read the next ONE block ONLY to see what comes next: mod43 57 # dd if=/dev/nrst0 bs=10240 count=1 of=t1151 0+1 records in 0+1 records out There's the expected partial block. The next read should return EOF. 3. Read the next ONE block ONLY to see what comes next: mod43 58 # dd if=/dev/nrst0 bs=10240 count=1 of=t1152 1+0 records in 1+0 records out Instead of EOF, a full 10,240-byte block was returned by the driver. 4. Try another read to see what happens: mod43 59 # dd if=/dev/nrst0 bs=10240 count=1 of=t1153 0+0 records in 0+0 records out THERE's the previously-expected EOF now. What we have now are the following files: -rw-r--r-- 1 root 11794944 Feb 11 21:57 DLT.tap -rw-r--r-- 1 root 11784704 Feb 11 21:58 kernel.tar -rw-r--r-- 1 root 11776000 Feb 11 22:05 t1-1150 -rw-r--r-- 1 root 8704 Feb 11 22:07 t1151 -rw-r--r-- 1 root 10240 Feb 11 22:07 t1152 -rw-r--r-- 1 root 0 Feb 11 22:07 t1153 Files t1-1150 and t1151 concatenated together compare exactly to kernel.tar. So blocks returned by the driver up to and including the second-to-last block are correct. The very last block returned, when EOF should have been returned, is a full block of data that the driver sent back when EOF was encountered on tape. It's not until another subsequent read, from that point, is an EOF returned. The problem could be in the adaptec.c base SCSI driver, or in the st.c SCSI Tape code. Both contain code specific to Tapes. adaptec.c contains the kernel/Driver BTE and b_resid determinations. The st.c also contains some data transfer to the device as well. A few printf's will help debug this issue. Since it occurs, without fail [pun], on all tested tape drives (both fixed and variable block devices), it should be easy to determine the fault. My suspicion is the logic for handling the EOF and/or short-read tape blocks is where the bug lies. Fortunately, tape drivers are no stranger to me. ======================= February 9, 2018 UPDATE ======================= Receipt today of a working Adaptec AHA1542B controller has provided me the means to test and utilize SCSI support in Mach386. Preliminary testing shows that the late-1992 Mach386 vmunix kernel works well for SCSI disk. SCSI tape seems to have an issue wherein it is writing an extra tape record when a tape device is closed after writing. This first SCSI Disk testing was performed with a Seagate ST15150N Barracyda 4 drive. This drive is 4,294 Mbytes formatted, This is exactly the 4GByte disk-size limit of the 32-bit Mach386 kernel. The BSD UFS filesystem limit is 2GByte. Full testing of this drive and the 4GB limit will occur in the next few days. A 2GB (Max, for the BSD UFS architecture) can be created and mounted: # df /mnt2 Filesystem 1024-blocks Used Available Capacity Mounted on /dev/sd0h 1969518 2 1772564 0% /mnt2 The SCSI Tape testing was first performed with a Seagate STD2401LW DDS-4 tape drive utilizing a DDS-1 tape. Various DDS tape drives were actually tested, but I settled on this DDS-4 drive once I realized that the extra block being written (and read) from the tape was not specific to a particular drive. Additional drive testing with a Quantum 4000 (TH5AA-YF) DLT tape drive indicates the same sort of problems. Additionally, preliminary testing there shows that at 20480-byte block size, the 20480th byte of the first block is being written or read back incorrectly as that byte fails comparison to the original data. There are definitely problems with the st.c SCSI tape driver. Today I also successfully mounted an NFSv2 filesystem from a FreeBSD 11.0 server onto Mach386: # mount mod5:/tiny /nfs # df /nfs Filesystem 1024-blocks Used Available Capacity Mounted on mod5:/tiny -785220319 -1208500253 423279934 154% /nfs Compare that to the server's reporting of that filesystem: # df /tiny Filesystem 1K-blocks Used Avail Capacity Mounted on zpool1/tiny 12099681569 938983394 11160698174 8% /tiny It will be interesting to see what issues arise ======================= February 8, 2018 UPDATE ======================= I've gotten networking working now. I'd been having great difficulty with Mach386 in getting a working setup with the supported networking cards. The only supported cards are the Western Digital/SMC 80x3 and 3Com 3c502 and 3c503 (EtherLink II) cards, all of which are ISA-bus cards. Despite the documentation showing supported IRQ/PIC configurations with IRQ 2 (actually IRQ 9 in more modern hardware) and IRQ 5, it turns out that the source for autoconf.c has all configuration options hardcoded to IRQ 2/9. As it turns out, the motherboards I have will not work setting these networking cards to IRQ 2/9. The cards would successfully transmit packets, and the on-board LEDs would indicate receipt of a packet, but the Mach386 kernel would never see an interrupt and thus would never be able to load the packet from the card. After obtaining and failing to get a number of WD8003 and WD8013 cards working, and ultimately discovering this issue, I hand-edited the vmunix kernel file. Having located the autoconf storage for the configurations, I changed the IRQ configuration options for these cards to IRQ 3, booted that modified vmunix, and I have ethernet connectivity now. There are some additional issues I'm working out with NFS, but I expect these to be resolved in short order. I will be pursuing SCSI functionality very soon now as well once I receive working Adaptec AHA1542B cards I've ordered. Additionally, I'm well underway in writing a sysload(8) replication program that runs on modern UNIX. This replacement will be the basis for a utility to generate new distribution media to facilitate updating binary systems and generating a new release with the latest binaries I have availab.e I'm also working on getting the reconfigurable kernel generation files working that will allow easier device configurations (rather than using a binary editor as I've just done for the networking card configuration). More to come... ======================= February 3, 2018 UPDATE ======================= I have found my last root dump and usr tar archives from 1996 which includes the latest updates I was able to sup(8) from Mt Xinu in 1993. I will be assembling additional distribution additions with the updated binaries and files. Included in these updates from Mt Xinu are working SCSI support, additional userland and GNU utilities and the Mt Xinu MSD 2.6 rebuildable/reconfigurable kernel. I have also located the January 21, 1991 distribution floppies. However, there are a number of unreadable floppy sectors in various locations of this set which renders the entire distribution useless. Since the distribution sets are effectively sequential chunks of compress(1)'d data, the loss of a block of data in any of the floppy sets renders that set incomplete and a working installation from it is impossible. ================ February 1, 2018 ================ These files contain the floppy images and scanned documentation for the Mt XINU Mach386 binary distribution for "MACH and BERKELEY UNIX for i386". This is the full 3.5" floppy distribution, and includes the Mach 3.0 CMU product as well as the Mach 3.0 DUI (DOS server). The build/release date of this product is March 23, 1992. The usefulness of this software is questionable, for a number of reasons: o Mt XINU only provided media for the base system. All further updates, bug fixes and additional functionality, were provided electronically only. There are many bugs and issues in the base system, and no source is available. o Mach386 only supports a very limited list of hardware, primarily ISA bus-based hardware and early IBM-PC disk size limitations. o There are no source repositories of Mach 2.6 software, upon which Mach386 is built. Neither the source nor the binaries have been found. Mt XINU stopped selling software in the mid 1990's, and no known archives exist. There was at least one later release of Mach386, dated August 6 1992, that would have had later software fixes and updates. The following are included in this binary product distribution, as received from Mt XINU in 1992: MtXinu-Mach386-Advertising_Brochure-1992-OCR.pdf This is a color advertising brochure describing the Mach386 product. MtXinu-Mach386-Release_Notes-March_23_1992-OCR.pdf This addendum describes known problems with this distribution. MtXinu-Mach386-Installing_and_Operating_Mt_XINU_Mach386.pdf This yet-to-be-scanned document provides the installation and operation procedures of the distribution. MtXinu-Mach386-Mach_3.0_and_DUI_Package-Manual-November_13_1992-OCR.pdf This document provides Mach 3.0 and the Mach 3.0 DUI package installation and operation instructions. CMU-Mach_3.0-Setup_for_Mach_3.0-Mary_R_Thompson-April_1_1993-OCR.pdf This is a copy of a paper written by Mary R. Thomson, of Carnegie Mellon University, describes set-up and booting of the Mach 3.0 kernel on a Mach 2.5 base-installed system. MtXinu-Mach386-Product_Description-August_6_1992.txt Mach386 Product Description for a later August 6, 1992, release. The following 1.44MB 3.4" floppy images have been imaged. They comprise the full Mt XINU Mach386 distribution dated March 23, 1992: MtXinu-Mach386-Bootstrap-For_Base_MB920331020.FD1440.dsk This is the installation bootstrap floppy image. MtXinu-Mach386-Filesystem-For_Base_MB920331020.FD1440.dsk This is the installation bootstrap filesystem. MtXinu-Mach386-MB920331020-Base_System-Floppy_01_of_10.FD1440.dsk MtXinu-Mach386-MB920331020-Base_System-Floppy_02_of_10.FD1440.dsk MtXinu-Mach386-MB920331020-Base_System-Floppy_03_of_10.FD1440.dsk MtXinu-Mach386-MB920331020-Base_System-Floppy_04_of_10.FD1440.dsk MtXinu-Mach386-MB920331020-Base_System-Floppy_05_of_10.FD1440.dsk MtXinu-Mach386-MB920331020-Base_System-Floppy_06_of_10.FD1440.dsk MtXinu-Mach386-MB920331020-Base_System-Floppy_07_of_10.FD1440.dsk MtXinu-Mach386-MB920331020-Base_System-Floppy_08_of_10.FD1440.dsk MtXinu-Mach386-MB920331020-Base_System-Floppy_09_of_10.FD1440.dsk MtXinu-Mach386-MB920331020-Base_System-Floppy_10_of_10.FD1440.dsk These floppies contain the base system distribution. MtXinu-Mach386-MN920331034-Networking-Floppy_1_of_2.FD1440.dsk MtXinu-Mach386-MN920331034-Networking-Floppy_2_of_2.FD1440.dsk These floppies contain the Networking userland binaries, libraries, development (header) files and on-line documentation. MtXinu-Mach386-MD920331030-On_Line_Documents-Floppy_1_of_2.FD1440.dsk MtXinu-Mach386-MD920331030-On_Line_Documents-Floppy_2_of_2.FD1440.dsk These floppies contain the Mach386 on-line documentation (man pages, etc). MtXinu-Mach386-MX920331007-X_Window_System-Floppy_1_of_9.FD1440.dsk MtXinu-Mach386-MX920331007-X_Window_System-Floppy_2_of_9.FD1440.dsk MtXinu-Mach386-MX920331007-X_Window_System-Floppy_3_of_9.FD1440.dsk MtXinu-Mach386-MX920331007-X_Window_System-Floppy_4_of_9.FD1440.dsk MtXinu-Mach386-MX920331007-X_Window_System-Floppy_5_of_9.FD1440.dsk MtXinu-Mach386-MX920331007-X_Window_System-Floppy_6_of_9.FD1440.dsk MtXinu-Mach386-MX920331007-X_Window_System-Floppy_7_of_9.FD1440.dsk MtXinu-Mach386-MX920331007-X_Window_System-Floppy_8_of_9.FD1440.dsk MtXinu-Mach386-MX920331007-X_Window_System-Floppy_9_of_9.FD1440.dsk These floppies provide X11 Window System binary and support and documentation distribution. MtXinu-Mach386-M3921131020-Mach_3.0+DUI-Floppy_1_of_6.FD1440.dsk MtXinu-Mach386-M3921131020-Mach_3.0+DUI-Floppy_2_of_6.FD1440.dsk MtXinu-Mach386-M3921131020-Mach_3.0+DUI-Floppy_3_of_6.FD1440.dsk MtXinu-Mach386-M3921131020-Mach_3.0+DUI-Floppy_4_of_6.FD1440.dsk MtXinu-Mach386-M3921131020-Mach_3.0+DUI-Floppy_5_of_6.FD1440.dsk MtXinu-Mach386-M3921131020-Mach_3.0+DUI-Floppy_6_of_6.FD1440.dsk These are the add-on Mach 3.0 and DUI distribution files. The floppies are direct images of each of the distribution floppies. They were extracted using the UNIX dd(1) command as follows: # dd if=/dev/fd0 bs=512x18 of=imagename.DSK The distribution floppies utilize standard PC-compatible 1.44MB 3.5" recording format that the DOS and Windows 'FORMAT' command produces. They can be written directly to formatted floppies with the same dd(1) command method: # dd if=MtXinu-Image.dsk bs=512x18 of=/dev/fd0 or other equivalent means on other platforms. All of these floppy images have been verified and test-installed on a basic 500mhz i386 system using an IDE/ATA disk (BIOS-configured for 1023/16/63 Cylinder/Head/Sector limits). An ongoing attempt to obtain an ISA Western Digital/SMC WD80x3 ISA ethernet adapter continues to be pursued to determine if networking support can be employed. This particular distribution has broken SCSI support, and is not fixable since the electronic updates from Mt Xinu are no longer available to update the distribution. I personally used this Mach386 (with updates from Mt Xinu) from 1991 through 1998. Despite its development-quality short-comings, it proved to be robust enough to manage for me as a professional platform and as a personal platform back in the days of network communications through dial-up mail-based USENET and early CERFnet connectivity. If there are any questions or if you have access to additional Mt XINU Mach386 or MACH 2.5/2.6 source or other Mt XINU information, please contact me. Scott G. Taylor bub7734 at gmail dot com