From Newsgroup: comp.sys.ibm.ps2.hardware

Friends,

One of the major annoyances with using genuine IBM PS/2s (or even
emulated ones) is dealing with the Reference Diskette. I decided to
tackle this by first taking an inventory of what, exactly, the Reference Diskette even is, what it does, and what the various programs on it do,
with a goal towards eventually replacing it with a far more compact
program, a much more compact representation of ADFs, and an ability to
run from things other than a diskette (such as a ROM BIOS, or, in the
most extreme cases, something hand-typed into ROM BASIC). Part of the
goal here is to make a PS/2 usable when it does not have a usable
diskette drive; currently, the only other way to set up such a system is
to perform RIPL from a Token Ring card.

I decided to start my focus on the Type 2 PS/2 Model 80, since (a) I
have the most personal experience with that machine's hardware, its
BIOS, and its ABIOS; and (b) it has some of the most thorough emulation
in 86Box. The Mod 50/60 has some problems in 86Box (relating to memory
sizing), and the Type 1 and Type 3 aren't 100% accurate.

So far I have found version 1.06 and 1.21 of the Reference Diskette. (My
Type 2 machine came with 1.21 back in the day, but that really just
meant that I went to the library at the local IBM office and pulled one
of the hundreds of Guides to Operations off of the shelf and ended up
with that version.)

Some preliminary analysis so far:

1.06 is byte for byte identical to PC-DOS 3.30. That's going to motivate
me to work on analysing the 1.06 refdisk first, since I don't have to
worry about DOS being different in some subtle way. (1.06 had the cute "tutorial" on it, complete with pixel art of a Mod. 70 and 80 chassis.)

1.21 is a bit odder. It has a PC-DOS revision that is newer than 4.01:
it has some bugs fixed regarding printer handling and supports multiple
EMM modes. It definitely contains code that is not in the MS-DOS 4.01
source release. The DOS on it will be worthy of future analysis just to
figure out what it is, because it's not PC-DOS 5.00 either, and it's not Multitasking MS-DOS 4. Maybe some OS/2 expert can tell me if there was
ever an "oddball" DOS found in an OS/2 beta release.

On a different topic... how hard is burning a PROM set (well, EEPROM
these days) for a PS/2? The end goal here is to eventually cram a
reference diskette inside the ROM.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.sys.ibm.ps2.hardware

Burning a PROM is SIMMple for a single EPROM, more complexified for a Even/Odd, and I can't ever remember trying a 4 EPROM set.

Are you looking for the 8580 Type 2 system?

https://ardent-tool.com/8580/Planar_T2.html

ROM Images

15F6597 / 15F6600 - 07 Oct 1987, rev. 0, 2x 27C512 (U157 / U158)

Is your question how to divide a BIOS into separate Even and Odd BINs?

Josh Rodd wrote:

On a different topic... how hard is burning a PROM set (well, EEPROM
these days) for a PS/2? The end goal here is to eventually cram a
reference diskette inside the ROM.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.sys.ibm.ps2.hardware

On 7/30/26 10:57, Josh Rodd wrote:

Friends,

One of the major annoyances with using genuine IBM PS/2s (or even
emulated ones) is dealing with the Reference Diskette. I decided to
tackle this by first taking an inventory of what, exactly, the Reference Diskette even is, what it does, and what the various programs on it do,
with a goal towards eventually replacing it with a far more compact
program, a much more compact representation of ADFs, and an ability to
run from things other than a diskette (such as a ROM BIOS, or, in the
most extreme cases, something hand-typed into ROM BASIC). Part of the
goal here is to make a PS/2 usable when it does not have a usable
diskette drive; currently, the only other way to set up such a system is
to perform RIPL from a Token Ring card.

I decided to start my focus on the Type 2 PS/2 Model 80, since (a) I
have the most personal experience with that machine's hardware, its
BIOS, and its ABIOS; and (b) it has some of the most thorough emulation
in 86Box. The Mod 50/60 has some problems in 86Box (relating to memory sizing), and the Type 1 and Type 3 aren't 100% accurate.

So far I have found version 1.06 and 1.21 of the Reference Diskette. (My
Type 2 machine came with 1.21 back in the day, but that really just
meant that I went to the library at the local IBM office and pulled one
of the hundreds of Guides to Operations off of the shelf and ended up
with that version.)

Some preliminary analysis so far:

1.06 is byte for byte identical to PC-DOS 3.30. That's going to motivate
me to work on analysing the 1.06 refdisk first, since I don't have to
worry about DOS being different in some subtle way. (1.06 had the cute "tutorial" on it, complete with pixel art of a Mod. 70 and 80 chassis.)

1.21 is a bit odder. It has a PC-DOS revision that is newer than 4.01:
it has some bugs fixed regarding printer handling and supports multiple
EMM modes. It definitely contains code that is not in the MS-DOS 4.01
source release. The DOS on it will be worthy of future analysis just to figure out what it is, because it's not PC-DOS 5.00 either, and it's not Multitasking MS-DOS 4. Maybe some OS/2 expert can tell me if there was
ever an "oddball" DOS found in an OS/2 beta release.

On a different topic... how hard is burning a PROM set (well, EEPROM
these days) for a PS/2? The end goal here is to eventually cram a
reference diskette inside the ROM.

That sounds cool. There are some machines where slots are at a premium
so it would be ideal there. For those where it isn't, maybe easier to
extend something like the McIDE which I think has boot hooks, and it
could all reasonably fit in an external flash boot ROM BIOS, including
all system types and all ADFs?
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.sys.ibm.ps2.hardware

Kevin, how do we access the larger BOOT ROM that is on the McIDE?

So... the system boots from the original ROMs on the sysboard, then once
POS has configured the system, then the control is passed to the flash
on the McIDE?

I suppose an analogy could be accomplished with an updated ethernet NIC
which supports the bigger flash ROMs?

Kevin Bowling wrote:

That sounds cool.-a There are some machines where slots are at a premium
so it would be ideal there.-a For those where it isn't, maybe easier to extend something like the McIDE which I think has boot hooks, and it
could all reasonably fit in an external flash boot ROM BIOS, including
all system types and all ADFs?

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.sys.ibm.ps2.hardware

The RPL mechanism exists. I'm unaware of any existing MCA ethernet
adapter that supports a large flash ROM.

Instead of RIPLing off an Ethernet network, how about a new ethernet NIC
that has one purpose. That is to act like the RPL server or whatever so
we can run a refdisk off of it.

Louis Ohland wrote:

Kevin, how do we access the larger BOOT ROM that is on the McIDE?

So... the system boots from the original ROMs on the sysboard, then once
POS has configured the system, then the control is passed to the flash
on the McIDE?

I suppose an analogy could be accomplished with an updated ethernet NIC which supports the bigger flash ROMs?

Kevin Bowling wrote:

That sounds cool.-a There are some machines where slots are at a
premium so it would be ideal there.-a For those where it isn't, maybe
easier to extend something like the McIDE which I think has boot
hooks, and it could all reasonably fit in an external flash boot ROM
BIOS, including all system types and all ADFs?

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.sys.ibm.ps2.hardware

On 7/30/26 21:53, Louis Ohland wrote:

Kevin, how do we access the larger BOOT ROM that is on the McIDE?

So... the system boots from the original ROMs on the sysboard, then once
POS has configured the system, then the control is passed to the flash
on the McIDE?

I suppose an analogy could be accomplished with an updated ethernet NIC which supports the bigger flash ROMs?

Kevin Bowling wrote:

That sounds cool.-a There are some machines where slots are at a
premium so it would be ideal there.-a For those where it isn't, maybe
easier to extend something like the McIDE which I think has boot
hooks, and it could all reasonably fit in an external flash boot ROM
BIOS, including all system types and all ADFs?

The BIOS hook is standard adapter option ROM.

McIDE has an interesting mode where a jumper JP1 allows it to boot on an unconfigured system: https://theretroweb.com/expansioncard/documentation/mcide-user-manual-v1-1-h1-0-6754aa5ae18c6582768777.pdf
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.sys.ibm.ps2.hardware

MAJ Tom discovered the "fencing off" of certain address ranges during
boot. So this using 0xC000 is not a chance coincidence, but the result
of IBM engineering.

Note that this requires a remote system, could that include a flash ROM
with FAT12 file system?

"Virtual serial floppy drive
The virtual serial floppy allows the computer to boot any floppy
diskette (e.g., a reference diskette), even when a floppy drive is not connected to the computer. The virtual serial floppy drive requires two computers, one that receives the data, and one that hosts the virtual
floppy drive. The two computers are connected via a null modem cable.

Once the two computers are connected via serial cable, on the sending
computer open the serdrive.exe utility and specify the diskette image to
use (e.g., c:\serdrive reference_disk.ima ). Boot the receiving
computer, pressing F6 when XUB is detecting the attached drives. If
you wish to boot from the virtual floppy, press F2. To exit the serial
drive utility, press ctrl+c on the host computer. You can optionally
specify another diskette to attach.

Details regarding additional options are available online."

"JP1
JP1 is not used in normal operation. When the adapter is not configured, connecting this jumper will force the ROM to respond at address 0xC000,
which would cause the machine to boot from the BIOS even without having configured it. You could then use the virtual serial floppy to boot a reference disk, allowing you to configure a machine with a missing or defective floppy drive."


Kevin Bowling wrote:

On 7/30/26 21:53, Louis Ohland wrote:

Kevin, how do we access the larger BOOT ROM that is on the McIDE?

So... the system boots from the original ROMs on the sysboard, then
once POS has configured the system, then the control is passed to the
flash on the McIDE?

I suppose an analogy could be accomplished with an updated ethernet
NIC which supports the bigger flash ROMs?

Kevin Bowling wrote:

That sounds cool.-a There are some machines where slots are at a
premium so it would be ideal there.-a For those where it isn't, maybe
easier to extend something like the McIDE which I think has boot
hooks, and it could all reasonably fit in an external flash boot ROM
BIOS, including all system types and all ADFs?

The BIOS hook is standard adapter option ROM.

McIDE has an interesting mode where a jumper JP1 allows it to boot on an unconfigured system: https://theretroweb.com/expansioncard/documentation/mcide-user-manual-v1-1-h1-0-6754aa5ae18c6582768777.pdf

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.sys.ibm.ps2.hardware

On 7/31/26 06:26, Louis Ohland wrote:

MAJ Tom discovered the "fencing off" of certain address ranges during
boot. So this using 0xC000 is not a chance coincidence, but the result
of IBM engineering.

Note that this requires a remote system, could that include a flash ROM
with FAT12 file system?

As a feasibility, yes. As the McIDE is implemented, it would need a
revision to have a flash instead of an EPROM, maybe moving from the CPLD
to an FPGA to accommodate more logic, and then possibly dealing with
level conversion as a side effect of that move.

"Virtual serial floppy drive
The virtual serial floppy allows the computer to boot any floppy
diskette (e.g., a reference diskette), even when a floppy drive is not connected to the computer. The virtual serial floppy drive requires two computers, one that receives the data, and one that hosts the virtual
floppy drive. The two computers are connected via a null modem cable.

Once the two computers are connected via serial cable, on the sending computer open the serdrive.exe utility and specify the diskette image to
use (e.g., c:\serdrive reference_disk.ima ). Boot the receiving
computer, pressing F6 when XUB is detecting the attached drives. If
you wish to boot from the virtual floppy, press F2. To exit the serial
drive utility, press ctrl+c on the host computer. You can optionally
specify another diskette to attach.

Details regarding additional options are available online."

"JP1
JP1 is not used in normal operation. When the adapter is not configured, connecting this jumper will force the ROM to respond at address 0xC000, which would cause the machine to boot from the BIOS even without having configured it. You could then use the virtual serial floppy to boot a reference disk, allowing you to configure a machine with a missing or defective floppy drive."

Kevin Bowling wrote:

On 7/30/26 21:53, Louis Ohland wrote:

Kevin, how do we access the larger BOOT ROM that is on the McIDE?

So... the system boots from the original ROMs on the sysboard, then
once POS has configured the system, then the control is passed to the
flash on the McIDE?

I suppose an analogy could be accomplished with an updated ethernet
NIC which supports the bigger flash ROMs?

Kevin Bowling wrote:

That sounds cool.-a There are some machines where slots are at a
premium so it would be ideal there.-a For those where it isn't, maybe >>>> easier to extend something like the McIDE which I think has boot
hooks, and it could all reasonably fit in an external flash boot ROM
BIOS, including all system types and all ADFs?

The BIOS hook is standard adapter option ROM.

McIDE has an interesting mode where a jumper JP1 allows it to boot on
an unconfigured system: https://theretroweb.com/expansioncard/
documentation/mcide-user-manual-v1-1-h1-0-6754aa5ae18c6582768777.pdf

--- Synchronet 3.22a-Linux NewsLink 1.2