Today I discovered the cause of a long-time frustration I've had trying to modify NETSRV.MAC to add services.

I've been trying to add an RSH server listener to NETSRV.   But every time I would edit the file with VI (my Elvis V2.0 1996 port), the resulting NETSRV executable would fail to RECEIVE for all services.  Always.   ALWAYS ALWAYS ALWAYS.   Reverting back to the original untouched (ca. 2006 NETSRV.MAC from the Panda distribution) source and compiling, the resulting NETSRV.EXE would run just fine.   Changing ANYTHING and recompiling would result in the failure.

Comparing the untouched and a file created by simply saving a new copy from within the editor, there was a one-byte-off count to the file sizes.

Running the ported  UNIX diff on those files showed the following:

$diff -u ns4.mac ns4a.mac
--- ns4.mac Fri Jan 21 14:52:51 2022
+++ ns4a.mac Fri Jan 21 15:45:37 2022
@@ -1602,7 +1602,7 @@
MOVX T3,^D10 ; in decimal
NOUT% ; output local port number
- HRROI T2,[ASCIZ/#;PERSIST:30/] ; wait 30 seconds for synchronize
+ HRROI T2,[ASCIZ/#;PERSIST:30/] ; wait 30 seconds for synchronize

No difference show.  There must be an embedded control character.   But when I load NS4.MAC into vi, the line is as-shown. 

I started to look at the binary contents of the file:

$cmp -l ns4.mac ns4a.mac | head -10
47946 26 43
47947 43 73
47948 73 120
47949 120 105
47950 105 122
47951 122 123
47952 123 111
47953 111 123
47954 123 124
47955 124 72

Aha.  There's a CTRL-V (Octal 026) in NS4.MAC that isn't in NS4A.MAC.

The other characters shown are:

43    Hash/Pound sign (#)

73    Semicolon (;)

120 105 122 123 111 123 124     Octal codes for ASCII: PERSIST

So there's an embedded CTRL-V at the beginning of the ASCIZ string in the HRROI line.

Elvis is dropping that character when loading the file for editing!

I found the offending Elvis code in io.c:

  /* maybe strip control characters */
if (beautify && nread > 0)
    for (i = j = 0; i < nread; i++)
        if (iobuf[i] >= ' ' || iobuf[i] == '\t' || iobuf[i] == '\n' || iobuf[i] == '\f')
            iobuf[j++] = iobuf[i];
nread = j;

So it is the Elvis beautify setting causing the character drop.   I never use the beautify setting.  But it is inexplicably set in my elvis.rc file.

This isn't what the beautify setting does in BSD vi or the VIM clone.


Regardless, removing the set beautify in my elvis.rc and I'm good now.


Due to a failed upgrade of Joomla (the content-management software for Retrosys), a re-installation of the software and a database restoration has occurred.  There has been no loss of public or private content.


  September 24, 2018 UPDATE

I've been sent a 3Com EtherLink II (3c503) ethernet adapter to check out with the working Mach386 distribution.

I've successfully installed the hardware and, after setting the card jumpers and reconfiguring the BIOS to accommodate this legacy ISA card, it has proven to work well.

The configuration quirks of the 3c503 and Mach386 currently allow for one of the following card configurations to be utilized:

  1. Address 0x2e0, IRQ 5, BNC Connector
  2. Address 0x2a0, IRQ 2, AUI Connector
  3. Address 0x280, IRQ 2, BNC Connector
  4. Address 0x300, IRQ 2, AUI Connector

The memory must be set for 0xDC000 or 0xD8000.  The selection will be detected automatically.

As with the WD/SMD 80x3 ethernet cards, the motherboard BIOS settings may need to be changed.   The changes required would be to reserve the IRC to Legacy ISA assignment, and to reserve the memory block to prevent it from being used for RAM addressing.

The address, IRQ and Connector settings are hardcoded, and could be changed by modifying the driver and rebuilding the kernel.

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);
         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)
                          if (iq != (struct iso_node *) 0 && ip != iq)
                          if (ip->iso_count != 0) {
                                   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.