28 Jan
2008
28 Jan
'08
3:54 p.m.
On Mon, 28 Jan 2008, Jim Leonard wrote:
That was a normal feature of MDA
INT 10h, function 0Fh returns in AL with the numeric value of what video
mode is in use. 2 = B&W CGA 3 = color CGA 7 = MDA
IFF sufficiently compatible (Toshiba T300 was NOT), then 2,3 mean B800h
and 7 means B000h
In the early days, it was possible to call BASIC subroutines. But, I
don't think that they kept the same addresses for long.
The publisher (Vertex) wanted it much more secure than that (paranoid
idiots). It was a "special version" that they hoped to peddle to IBM.
It clearly stated on the startup screen that it was for IBM PC ONLY,
but PC-WORLD used it for their testing.
So, I used the BASIC floating point accumulator for passing an argument
back from a function. The publisher tested whether it would run on a
generic clone with copy of IBM's BIOS (but without BASIC ROMs)
By the time that I got rid of the publisher, I used DOS calls, BIOS calls,
and VERY little direct hardware access (video RAM, and a little twiddling
with the FDC)
Unfortunately, the third time that my company moved (in 1988), the two
totes with EVERYTHING from that never really finished program disappeared.
I hadn't done anything very fancy - checking the processor, whether
certain BIOS calls worked, entry locations, the presence (and CRC'd
content) of ROMS, and checking a BUNCH of the segment 40h BIOS memory
locations.
Since one of my requirements is manipulating the PC
speaker to sound an
arbitrary tone of arbitrary duration -- something that is not provided
by the BIOS or MS-DOS -- should I worry about "grossly incompatible"
machines? For example, does the Victor 9000 even *have* a speaker (or
8253 timer?)?
PROBABLY not similar circuitry. The Victor 9000 did almost nothing the
same way as PC.
Some minor
glitches may still show up. For example, the Corona and the PC
CGA had different ideas what to do about the intensity attribute bit for
reverse video.
That was also an issue with the AT&T PC 6300/Olivetti M24 if
you were
using a monochrome monitor. It was monochrome CGA, but the monitor
would do things like _underline_ the text based on the attribute. But sometimes
you can work around it. For example, Toshiba 300 will work
with DOS and BIOS calls, but their "CGA" video memory was at B000h (the
normal location for MDA). But THAT was the only change needed to get
PC-WRITE to run on them.
Is there any way to test for that? I don't recall a
BIOS call to
determine the base segment of video memory, other than querying DOS
(BIOS?) for the machine capabilities for either CGA or MDA... Any code that
presupposes the presence of the BASIC ROMs will fail on
EVERYTHING except IBM.
Very true. But I'm not using any of that (indeed, is
there any way to
use the BASIC ROM for anything other than BASIC?) In
approximately January 1982? PC-WORLD had a comparison of "compatibles".
As expected, the version of XenoCopy that was hard coded to only work on
the IBM PC (as part of publisher's attempt to peddle it to IBM) would only
work on the IBM PC, and they dubbed it "the acid test".
To be fair,
didn't that test only check for a string in the BASIC ROM?
(ie. something that XenoCopy didn't actually use for functionality) XenoPhobe,
which was a crude compatibility tester that
is not still around
That's a shame; I'd love to run it on my various
compatibles and see
what it displays. I'd also like to poke around the documentation (or
source) to see what you were checking for and how. So, bottom line -- should I not waste my time with
"MS-DOS compatible"
and just go straight for BIOS calls? I'm leaning toward yes (all
opinions still welcome)...
Working with the "NON-PC-compatible" MS-DOS machines, such as DEC Rainbow,
TI Proffessional, Toshiba T300, Sanyo 550?, HP 150?, Tandy 2000,
Victor 9000, etc. would require major additional work for EACH one that
you support.
Unless you are willing to fall back to ONLY MS-DOS calls (MOV AH,2
MOV DL, 7 INT 21h to beep), etc. stick with "clones".
--
Grumpy Ol' Fred cisin at xenosoft.com