Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.sys.ibm.ps2.hardware > #71481 > unrolled thread

Decompiling the Reference Diskette and associated programs

Back to article view | Back to comp.sys.ibm.ps2.hardware

Contents

  Decompiling the Reference Diskette and associated programs "Josh Rodd" <joshua.at.rodd.dot.us@rodd.us> - 2026-07-30 17:57 +0000
    Take me to the PROM Re: Decompiling the Reference Diskette and associated programs Louis Ohland <ohland@charter.net> - 2026-07-30 20:07 -0500
    Re: Decompiling the Reference Diskette and associated programs Kevin Bowling <kevin.bowling@kev009.com> - 2026-07-30 19:59 -0700
      Interesting Re: Decompiling the Reference Diskette and associated programs Louis Ohland <ohland@charter.net> - 2026-07-30 23:53 -0500
        Catching the Night Train Re: Interesting Re: Decompiling the Reference Diskette and associated programs Louis Ohland <ohland@charter.net> - 2026-07-30 23:58 -0500
        Re: Interesting Re: Decompiling the Reference Diskette and associated programs Kevin Bowling <kevin.bowling@kev009.com> - 2026-07-30 23:08 -0700
          Re: Interesting Re: Decompiling the Reference Diskette and associated programs Louis Ohland <ohland@charter.net> - 2026-07-31 08:26 -0500
            Re: Interesting Re: Decompiling the Reference Diskette and associated programs Kevin Bowling <kevin.bowling@kev009.com> - 2026-07-31 10:41 -0700

#71481 — Decompiling the Reference Diskette and associated programs

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.

[toc] | [next] | [standalone]

#71485 — Take me to the PROM Re: Decompiling the Reference Diskette and associated programs

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.

[toc] | [prev] | [next] | [standalone]

#71486

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?

[toc] | [prev] | [next] | [standalone]

#71487 — Interesting Re: Decompiling the Reference Diskette and associated programs

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.  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?

[toc] | [prev] | [next] | [standalone]

#71488 — Catching the Night Train Re: Interesting Re: Decompiling the Reference Diskette and associated programs

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.  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?

[toc] | [prev] | [next] | [standalone]

#71489 — Re: Interesting Re: Decompiling the Reference Diskette and associated programs

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.  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?

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

[toc] | [prev] | [next] | [standalone]

#71490 — Re: Interesting Re: Decompiling the Reference Diskette and associated programs

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.  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?
> 
> 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 
> 

[toc] | [prev] | [next] | [standalone]

#71491 — Re: Interesting Re: Decompiling the Reference Diskette and associated programs

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.  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?
>>
>> 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

[toc] | [prev] | [standalone]

Back to top | Article view | comp.sys.ibm.ps2.hardware

csiph-web