<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	
	>
<channel>
	<title>
	Comments on: 86Box PS/2 model 60 emulation	</title>
	<atom:link href="https://virtuallyfun.com/2023/01/19/86box-ps-2-model-60-emulation/feed/" rel="self" type="application/rss+xml" />
	<link>https://virtuallyfun.com/2023/01/19/86box-ps-2-model-60-emulation/</link>
	<description>Fun with Virtualization</description>
	<lastBuildDate>Fri, 20 Jan 2023 13:02:50 +0000</lastBuildDate>
	<sy:updatePeriod>
	hourly	</sy:updatePeriod>
	<sy:updateFrequency>
	1	</sy:updateFrequency>
	<generator>https://wordpress.org/?v=7.0</generator>
	<item>
		<title>
		By: Zir Blazer		</title>
		<link>https://virtuallyfun.com/2023/01/19/86box-ps-2-model-60-emulation/comment-page-1/#comment-319570</link>

		<dc:creator><![CDATA[Zir Blazer]]></dc:creator>
		<pubDate>Fri, 20 Jan 2023 13:02:50 +0000</pubDate>
		<guid isPermaLink="false">https://virtuallyfun.com/?p=12237#comment-319570</guid>

					<description><![CDATA[Reading about IBM PC history, I always found strange that the PS/2 series didn&#039;t had a BIOS Setup built-in ROM, which would end up becoming a rather big convenience in third party BIOSes from Phoenix and AMI for PC clones (And these could even work in the original IBM PC/AT). But hey, IBM didn&#039;t thought highly about the Reset Button, either...

My understanding is that in the MCA based PS/2 models, you had an original Reference Disk that shipped with the system, which was pretty much the equivalent of the BIOS Setup plus Firmware-level Drivers for first party (IBM) MCA expansion cards, which could configure resources like MMIO, IRQ and DMA Channel. IBM keep releasing updated versions of the Reference Disk with support for newer PS/2 systems and MCA cards.
The system configuration data went into a battery-backed 2 KiB SRAM chip, that served as a capacity expansion for the RTC SRAM, which fulfilled the role of storing BIOS settings in the IBM PC/AT in a mere 64 Bytes. However, if for some reason the system configuration data was lost, like due to a dead battery, you had to insert the Reference Disk again to reconfigure the system, since MCA PS/2 systems required to be fully configured during POST or otherwise they refused to boot.

Now, the problem was when you added in third party MCA cards. Those also required to be configured during POST since otherwise the PS/2 would not boot, but they weren&#039;t supported out-of-the-box by the IBM Reference Disk. Instead, what you had was a procedure where you customized your system Reference Disk with those third party Drivers (Sounds very similar to slipstreaming hotfixes or Drivers into a Windows install ISO), then you used that customized Reference Disk to configure your system. At that point, your Reference Disk was unique for your specific PS/2 system.
However, if for some reason you lose this disk and you need to reconfigure the system (Changing Hardware setup, dead battery, whatever), you had to get another Reference Disk, the disk with the Firmware Drivers of your MCA Card, then customize again the Reference Disk, to be finally able to fix your system. And the more third party MCA Cards you had, the more convoluted the process was. Now, imagine a business where you had a fleet of PS/2 computers with slight configuration differences, each one requiring to keep track of its own customized Reference Disk for potential recovery... Seems like a logistical nightmare.

Buy hey, the good thing is that PCI may have learned a thing or two of MCA early attempt at Plug and Pray (ISA PnP was several years later). It uses an always-visible Vendor ID and Device ID identifier unique for each device model much like MCA Cards do with the 4 hex characters string, but the resource configuration is totally generic by nature, so you don&#039;t need explicit support for each different PCI Card type to be able to configure the card basic resources, completely fixing the need for the customized PS/2 Reference Disk.]]></description>
			<content:encoded><![CDATA[<p>Reading about IBM PC history, I always found strange that the PS/2 series didn&#8217;t had a BIOS Setup built-in ROM, which would end up becoming a rather big convenience in third party BIOSes from Phoenix and AMI for PC clones (And these could even work in the original IBM PC/AT). But hey, IBM didn&#8217;t thought highly about the Reset Button, either&#8230;</p>
<p>My understanding is that in the MCA based PS/2 models, you had an original Reference Disk that shipped with the system, which was pretty much the equivalent of the BIOS Setup plus Firmware-level Drivers for first party (IBM) MCA expansion cards, which could configure resources like MMIO, IRQ and DMA Channel. IBM keep releasing updated versions of the Reference Disk with support for newer PS/2 systems and MCA cards.<br />
The system configuration data went into a battery-backed 2 KiB SRAM chip, that served as a capacity expansion for the RTC SRAM, which fulfilled the role of storing BIOS settings in the IBM PC/AT in a mere 64 Bytes. However, if for some reason the system configuration data was lost, like due to a dead battery, you had to insert the Reference Disk again to reconfigure the system, since MCA PS/2 systems required to be fully configured during POST or otherwise they refused to boot.</p>
<p>Now, the problem was when you added in third party MCA cards. Those also required to be configured during POST since otherwise the PS/2 would not boot, but they weren&#8217;t supported out-of-the-box by the IBM Reference Disk. Instead, what you had was a procedure where you customized your system Reference Disk with those third party Drivers (Sounds very similar to slipstreaming hotfixes or Drivers into a Windows install ISO), then you used that customized Reference Disk to configure your system. At that point, your Reference Disk was unique for your specific PS/2 system.<br />
However, if for some reason you lose this disk and you need to reconfigure the system (Changing Hardware setup, dead battery, whatever), you had to get another Reference Disk, the disk with the Firmware Drivers of your MCA Card, then customize again the Reference Disk, to be finally able to fix your system. And the more third party MCA Cards you had, the more convoluted the process was. Now, imagine a business where you had a fleet of PS/2 computers with slight configuration differences, each one requiring to keep track of its own customized Reference Disk for potential recovery&#8230; Seems like a logistical nightmare.</p>
<p>Buy hey, the good thing is that PCI may have learned a thing or two of MCA early attempt at Plug and Pray (ISA PnP was several years later). It uses an always-visible Vendor ID and Device ID identifier unique for each device model much like MCA Cards do with the 4 hex characters string, but the resource configuration is totally generic by nature, so you don&#8217;t need explicit support for each different PCI Card type to be able to configure the card basic resources, completely fixing the need for the customized PS/2 Reference Disk.</p>
]]></content:encoded>
		
			</item>
	</channel>
</rss>
