On Tue, Jun 06, 2023 at 12:34:58PM -0700, Fred Cisin via cctalk wrote:
On Mon, 5 Jun 2023, Tom Gardner via cctalk wrote:
> Hi:
> Doing some research for historical purposed – no litigation at all –
...
In talking about the PC ROM, much of the discussion is conflating the BIOS
with the BASI*C ROMs.
The 5150, as released in August 1981, had SIX ROM sockets. It had one 8K
ROM for the BIOS, four 8K ROMs totaling 32K for BASIC, and one empty
socket, which usually stayed empty. A company calling itself MBI sold an
accessory ROM for that socket thatr added some trivial features.
We did not have the extra ROM sockets for the BASIC
In 1981, IBM immediately released the "PC Technical Reference Manual"
which included schematics, and source code for the BIOS ROM. The
Wikipedia article on the Columbia incorrectly states that IBM released the
specification, but not the code; NO, the manual had the full source code
for the BIOS.
I gave my copy of that to someone on this list in Toronto a few years ago.
Source code for the BASIC was not released.
If you look at the source code, each "section" documenting the BIOS
interrupts started with a block of comments detailing the documentation
for using that interrupt. Those comments, in the beginning of each
interrupt source code were plenty to serve as specification for writing a
BIOS that PC-DOS would run on.
Yep.
But, that wasn't always good enough. Instead of calling DOS with
MOV AH, 2
MOV DL, 42h
INT 21h ; call DOS output
to put a 'B' on the screen, you could
MOV AH, 0fh ; ?was that the right function?
MOV AL, 42h
INT 10h ; call BIOS video
which was faster.
Or you could do a far call to the memory location of INT10h, instead of
using the Interrupt Vector Table. That would require that not only INT
10h had to be compatible, but it would also have to be at the same memory
location, which is asking for more compatabilty.
Or, you could call the memory location of funtion 0Fh of Int10h, instead
of the memory location of Int10h, instead of using the interrupt vector
table, which is asking for more compatability.
Or, you could ignore DOS and BIOS, and poke the character into video
memory (Segment B000h for monochrome, segment B800h for CGA)
DOS calls, calling BIOS calls was considered too slow for commercial
software, if you were going to write the whole screen, so virtually all
commercial software did direct memory access, and often bypassing DOS and
BIOS for other actions, as well. THAT was where major incompatability
occured.
Yep! The problem was, yes you could do dot per dot graphics using the INT calls
but that was very slow. ;) SO of course developers went for the bare metal.
I wrote a tiny function for the first compiler we could get which
was small model only, that stuffed the DS onto the stack and took
a segment argument. A co-worker then wrote some graphics routines by
passing the graphics segment, doing some graphics, then in the return
the original DS was restored as part of the function.
Of course, when the newer compilers came out it was obsolete. ;)
PC-DOS required that the BIOS functions exist, and that the Interrupt
Vector Table point to them. Some commercial software products expected
the BIOS functions to be at the same physical address (not just pointed to
by the IVT), and therefore required that the BIOS be a closer copy than
just compatible.
Yep.
When I released XenoCopy in 1983, I contracted with a publisher. They
wanted to try to peddle licensing to IBM itself. For that, they insisted
that I make a version of XenoCopy that would not run on anythying other
than the real genuine IBM 5150 PC. I did that by accessing a location in
the BASIC ROM. Once they found that they could not peddle it directly to
IBM, all subsequent versions of XenoCopy that I wrote were compatible with
almost anything that claimed compatability. When my royalties started to
become later and later, I had to involve lawyers, and shut down the
publisher, and then publish and market it myself.
Yikes!
MS-DOS 1.25 differed from PC-DOS in that
IBMBIO.COM and
IBMDOS.COM were
named IO.SYS and MSDOS.SYS. PC-DOS had small programs
BASIC.COM and
BASICA.COM that added disk IO and a few other items to the ROM [Cassette]
BASIC.
BASICA.COM ("Advanced BASIC") was the full set, "BASIC.COM"
was
the minimal form for machines with inadequate RAM, with abbreviated error
messages, etc. MS-DOS had
GWBASIC.COM which was the equivalent of the
full BASICA, but not requiring the ROM BASIC.
Yep I worked a bit with GWBASIC and in the end I had our graphics routines
out-pacing the COMPAQ ones. ;)
Compaq RENAMED "GWBASIC.COM" to "BASICA.COM" (although it was a much
larger file containing the entire BASIC, not just adding disk
enhancements), so that batch files that mentioned "BASICA" would call it
and still run.
Yes we did that too.
In 1983 or 1984?, PC-World magazine ran an article comparing compatability
of the clones. They "tested" based on which software would run, such as
"Flight Simulator". They used version 1.00 of XenoCopy, which
deliberately would only run on real genuine IBM 5150 PC, although the
versions of XenoCopy being sold by that time would run on ANYTHING
that had compatability with INT13h, Int1Eh, Int10h, and had the text
screen memory at B000h or B800h. They referred to XenoCopy as "the acid
test of compatability"
- Diane
--
db(a)FreeBSD.org db(a)db.net
http://www.db.net/~db https:/@Octodon.social/@Dianora