Re: Proterm and the //E

[nparker@cie-2.uoregon.edu (Neil Parker)]

In article <4r49mf$l3j@news.vanderbilt.edu> lesherjt@vuse.vanderbilt.edu
(John Lesher) writes:
>Neil Parker (nparker@cie-2.uoregon.edu) wrote:
>:[...]
>:      IF  PEEK (64435) = 6 AND  PEEK (64448) <  > 234 THEN  PRINT "Mousetext
>:      is probably available."
>
>I thought of another possible trick, while puzzling over this in my spare
>time.  I remember some old programs which would "mirror" the text screen
>to the graphic screen.  All I'd have to do is check a certain bit on the
>hires screen, and I'd be able to tell between pre-Mousetext and Mousetext
>ROMs.  I'd also be able to tell between the old Mousetext ROMs (running
>man) and the new ROMs (inverse CR & horizontal lines).
>
>Can anyone tell me if this is possible, or did the "mirror" trick not
>really use the ROMs?

I presume you're thinking of things like the "imprint" program that came
on Beagle Bros' _Silicon_Salad_ disk, and the various "hi-res character
generator" programs (like Higher Text, DOS Tool Kit, etc.)?

Sorry...these programs don't work by reading the character ROM, or even by
tricking the hi-res display into reading the character ROM.  Instead, they
use their own software character sets.  The software looks up the ASCII
code to be drawn in its character set table, and draws the character's
pixels manually.  The character ROM never enters into the picture.

I'll say it again--as far as I know, there no way at all for software to
read the character ROM on a IIe, or even identify which character ROM is
installed.  You can make educated guesses based on the "What machine am I
running on?" test, but that's not a foolproof test because the user can
(for example) take the Mousetext character ROM out of an enhanced IIe and
plug the original non-Mousetext character ROM in its place.

As an aside, it's possible that there might be a way to examine the
character ROM on a IIGS.  The IIGS Firmware Reference has a listing of I/O
locations in the back, and one of them is labelled "Address for test mode
read of character ROM".  I've never figured out how to get this location to
do anything, nor do I know if it even does anything at all in production
models, but that label is certainly provocative.

(By the way, if anybody out there knows anything at all about that "Address
for test mode read of character ROM" thing, or about any of the other "test
mode" I/O locations listed in that table, I'd *love* to hear about it.)

>I thought of another to detect the difference between the two processors.
>
>lda #$ff
>inc          ;to accumulator ($1A or $3A opcode)
>cmp #$00
>beq _65C02_Present
>
>Instead of trying to use an error in the 6502, I just use an opcode
>not available to the 6502, which would be ignored on the 6502.

I wouldn't try anything like that unless I knew *for sure* that the 65C02
"inc" opcode was safe on a 6502.  Most undocumented 6502 opcodes do cause
some action to occur, and that action isn't always harmless...some
undocumented opcodes hang the processor, so that you have to press RESET to
continue.  I seem to recall reading somewhere that the behavior of
undocumented 6502 opcodes isn't even consistant...it depends on which
manufacturer the chip came from.

On the 65C02, all unused opcodes act as NOPs, but that doesn't help if
there's any chance the user could try to run your software on a 6502.

               - Neil Parker
-- 
Neil Parker, nparker@{cie-2,cie}.uoregon.edu, http://cie-2.uoregon.edu/~nparker

     "Evolution is vastly overrated."  -- Ambassador Delenn, _Babylon_5_