For OpenVMS, in addition to the console ports OPA0 and TTA0, Avanti can configure up to 25 additional serial ports through five virtual 5-port serial cards. The configuration and resource limits are source-checked. Current runtime qualification covers the retained-firmware OpenVMS cases recorded in the compatibility audit, including bidirectional pending-read exchanges on all five ports of a configured card; it does not establish sustained or concurrent traffic on every card.

Note:The modified Digiboard interface is not a supported Digital UNIX or Tru64 UNIX device. Historical investigation found no established guest-driver mapping for its six I/O windows and shared interrupt. Do not add it to a UNIX configuration; the former statement that it causes unpredictable behavior was not independently reproduced.

The serial cards are not supported by the Avanti configuration utility. Generate and save the rest of the configuration there, make a backup, close the utility, and then add the card manually. The following sample demonstrates the card block. The full-file example later in this chapter is a historical syntax illustration, not a current ready-to-run configuration.

isa0 = digiboard
{ serial0 = i16550
 { tn = telnet
   { port = 9010;
action = """C:\Program Files\Common Files\MigrationSpecialties Shared\putty.exe"" telnet://127.0.0.1:9010";
   }
 }
 serial1 = i16550
 { phys = ext_serial
   { device = "\\.\COM1";
   }
 }
 serial2 = i16550
 { phys = ext_serial
   { device = "\\.\COM2";
   }
 }
 serial3 = i16550
 { phys = ext_serial
   { device = "\\.\COM30";
   }
 }
 serial4 = i16550
 { phys = ext_serial
   { device = "\\.\COM31";
   }
 }
}

This example defines an emulated Digiboard card containing five serial ports, TXA0 through TXA4. TXA0 is a telnet port. TXA1 through TXA4 illustrate physical COM-port mappings; those particular host devices were not part of the current runtime qualification and must exist on the target Windows host.

Up to five serial ports can be defined on each card, running from serial0 thru serial4.  Up to five Digiboard cards can be defined, running from isa0 thru isa4, for a total of 25 additional serial ports.  However, isa2, isa3, and isa4 conflict with pci13, pci12, and pci11 respectively.  That means that isa2 can only be used if pci13 is not used, etc.  This limits the number of Digiboard cards to four for most systems (where one disk controller and one NIC are required).

The sections within “serial = i16550 { … }” follow the same configuration rules as the regular serial ports, so they can be telnet server ports or mappings to host COM devices. Physical-device operation depends on the Windows driver, hardware, and matching serial settings and has not been qualified for arbitrary COM devices.

OpenVMS uses SYS$YSDRIVER for the emulated card, but the card is not discovered without the release-appropriate firmware and guest setup described in the following topics.

Each card requires 10 license units, including its five ports whether they use virtual or physical connections. Card identifiers must be complete unsigned decimal names isa0 through isa4, with no duplicate numeric position; each card similarly permits at most one serial0 through serial4. Leading zeroes identify the same position, not an additional device. Missing numbers, signs, trailing text, overflow and positions outside these limits are rejected.

Normally omit iobase and irq. The address is determined by the ISA card number, not declaration order: isa0 uses I/O base 256 (hexadecimal 100) and IRQ 15; isa1 uses 512 (200) and IRQ 14; isa2 uses 768 (300) and IRQ 10; isa3 uses 1024 (400) and IRQ 9; isa4 uses 1280 (500) and IRQ 5. Each card occupies 48 contiguous I/O bytes. These defaults do not overlap one another or the two base UARTs. The configuration utility omits an explicit iobase=0 when saving; it does not provide a card editor or [+] dialog.

For compatibility with an existing guest setup, an explicit iobase override is retained. Use a decimal multiple of 8 from 8 through 65488, with all 48 bytes free; zero means automatic assignment. An explicit irq must be 1 through 15, except reserved cascade IRQ 2; irq=0 means automatic assignment, never IRQ 0. Cards cannot share an IRQ or overlapping I/O bytes with another card or either onboard base UART, even when that UART has no configured host connection. Base serial0 occupies hexadecimal 3F8 through 3FF on IRQ 4, and serial1 occupies 2F8 through 2FF on IRQ 3. Invalid settings prevent startup. Other guest hardware reservations must also be respected when choosing overrides.

Migration: back up an older hand-edited configuration before correcting rejected names or resources. Keep each port's telnet or physical-device settings with its intended card and port. Prefer removing conflicting overrides to use automatic allocation; otherwise choose distinct free ranges and IRQs. If card numbers, addresses or interrupts change, update the firmware ISACFG entries and OpenVMS startup commands using the new emulator log, and verify the resulting guest device names before resuming use. The five-card maximum still requires pci11, pci12 and pci13 to be unused; for example, isa0 through isa3 can coexist with a NIC in pci6 and a SCSI controller in pci11. This remains an OpenVMS-only feature.