For more information see https://www.retrotechnology.com/herbs_stuff/s_sd_vfii.html#sale
This document copyright Herb Johnson as edited from content by Bart Hirst. 

Bart Hirst, Dec 28-29 2025

[Bart acquired a VF II in Dec 2025 as a controller for a set of S-100 cards and chassis he acquired and worked on
in 2024. He said "I bought this rig from Todd George (with help from glitch picking cards out) at festivus 2023.  I worked a little bit on it in early 2024, got sidetracked on other projects, and picked it back up in mid December of this year." He contacted me in late Dec with his results, as below. - Herb

Hi Herb, you were right to question [how I did] the patching.  ChatGPT 5.2 patched SBC548N.IMD for me.  I can take no credit.  I sort of glossed over it, because in my mind I was thinking it did some search for “7D 7D 7C 7C 01 02” and replaced it with the 6 bytes for my configuration “03 03 02 02 01 02”, but as you pointed out, not that simple! I had to backtrack and ask the AI what it did, and [so I'll tell you what it told me. Also,] I've attached the before & after IMD files so you can see which 6 bytes it changed.

[First,] here's the hardware in the box: VG is Vector Graphic brand. 

    VG ZCB Z-80 Single Board Computer (serial port 4/5)
    VG Bitstreamer II (serial port 2/3 plus others, vanilla VG "S" monitor ROMS output to 2/3 by default)
    Tanner Computers 64K Static RAM {2716 ROM or 2K RAM chips]
    The VFII [board].

The [boot] ROM doesn't access anything but the VF II card - thus needing no patching or reassembly.  The file is provided in the github as "V2BOOTX5.HEX".  I converted V2BOOTX5.HEX to BIN, wrote it to a 2716 and dropped [the ROM]  into the Tanner board at [ROM/RAM IC location] X31 [which is addressed at 0F000H]. [That boots double-density diskettes.] I also have V2BOOTX at 0F200H [to boot single density diskettes]. 

About changes to send bootstrap error messages to the Vector Graphic console port. 
I didn't consider that, or make any changes to the bootstrap loader.

----------AI Commentary below here----------

The way I worked it out [with the AI] was basically:

1) Use getstart.txt to learn what the “known good” defaults look like, and what they need to become.

2) Find where those defaults are actually used in the boot image (in this IMD, it’s hard-coded instructions, not a CIOTB table).

3) Only change bytes that are clearly I/O-port operands (i.e., the byte after a Z80 I/O opcode like DB or D3).

------------------------------------
Here’s the exact reasoning path [according to the AI].

1) Start from the known default ports in getstart.txt

getstart’s patch example shows the SBC-200 default console is:

    status port 7D; data port 7C; [bit status/control] masks 01/02

…and for your Bitstreamer Serial A  you want:

    [ports] status 03, data 02; same [as the default] masks 01/02

So we know we’re looking for code [in the IMD image] that does console polling [and data] with 7D/7C.

2) Recognize the Z80 opcodes that “contain [reference] the port number” [as an operand]

On Z80, these are the two big [often used, 8080 compatible] ones:

    DB nn = IN A,(nn) (read from an I/O port)
    D3 nn = OUT (nn),A (write to an I/O port)

So the “port” is literally the next byte after DB or D3.

That means if you see bytes like:

    DB 7D ? the 7D is definitely [likely] a port number operand (not data)
    DB 7C ? same
    D3 7C ? same

That’s why your diff shows “just one byte” at each spot: you’re only changing the operand, not the opcode.

3) Find the console routines by looking for an unmistakable pattern [of port access as just described]

Console status polling for an 8251/USART-ish port almost always looks like:

    IN A,(status_port) ? (DB 7D in the default build)
    AND mask ? (E6 02 or E6 01)
    RET / branch loop

So a dead-simple way to locate the exact bytes is to search for patterns like:

    DB 7D E6 02 (read status, test bit 1)
    DB 7D E6 01 (read status, test bit 0)
    and then also look nearby for DB 7C (read data) and D3 7C (write data)

That’s how you “land” in the actual CONSTAT / CONIN / CONOUT code without needing [source code] labels.

4) Why it ended up being 4 bytes [changed], not 6

Because this particular shipped boot image doesn’t use a nice 6-byte CIOTB table; instead it has two copies of the status-port read (used by two different routines) and then one data-port read and one data-port write.

So the only values that need changing are the 4 immediate port operands:

    status reads: DB 7D ? DB 03 (appears twice)
    data read: DB 7C ? DB 02 (once)
    data write: D3 7C ? D3 02 (once)

The masks (E6 01 / E6 02) were already correct, so there was nothing to change there.

5) The “safety check” that makes this patch low-risk, [is that] for each byte you change, confirm:
a) the byte before it is DB or D3 and b)  the surrounding bytes look like code (poll/AND/branch), not random tables

That’s exactly why patching these operands is safer than “blindly replace every 7C/7D you see”. [end]

[Actual changes to the .IMD file, notes by Herb Johnson]

A binary file-compare of the two IMD disk images, and a dump of the original file where changed, reveals:

1. C:SBC548N.IMD: 226,255 bytes
2. C:SBC548N_vector_bitstreamer_serialA_02_03.IMD: 226,255 bytes
Offsets: hexadec.

 1EB5:	7D	03
 1EC2:	7C	02
 1EC7:	7D	03
 1ED6:	7C	02

4 difference(s) found. [end compare. Dump of the original codes is:]

Offset      0  1  2  3  4  5  6  7   8  9  A  B  C  D  E  F

00001EB0   AE 23 18 F6 DB 7D E6 02  C8 3E FF C9 CD A4 B4 28   ®#.öÛ}æ.È>ÿÉͤ´(
00001EC0   FB DB 7C E6 7F C9 DB 7D  E6 01 C8 3E FF C9 CD B6   ûÛ|æÉÛ}æ.È>ÿÉͶ
00001ED0   B4 CA BE B4 79 D3 7C C9  3A 03 00 E6 03 CA A4 B4   ´Ê¾´yÓ|É:..æ.ʤ´

 DB 7D E6 02 C8 is "in 7DH, CPi 02H, RZ" 
 DB 7C E6 7F C9 is "in 7CH, CPI 7FH, RET"
 ... and so on.