[Coco] Coco Digest, Vol 166, Issue 29

[Pere]

Hi Art,
I am afraid you are right, I cannot asume the installed DOS version despite 
the program
will only work for dos11, dos12 and dos12a
I will use the byte at $FFFF because it seems clearly related to the 
machine.

Just to mention. As the program needs to modify data located at $E000-$FEE2, 
it is
mandatory to work in MAP1 (all RAM) all the time, well this is how it goes 
for Dragon and CoCo2.
Anyway, after doing the poke &HFFDE,0 on the CoCo3 it seems to work well.
If it were back to ROM  mode, it could not find the Objects and Locations 
data because
that space is used by the Super Extended Basic ... and it is working, so it 
seems that
the CoCo3 does always work on RAM (whatever the selected map is)

thanks a lot for your unvaluable help!
cheers
pere
------------------------------------------------------------------------------------------------------------------
Previous message (by thread): [Coco] The Hobbit ported to 6809 (Dragon64 and 
coCo2 64k)
Arthur Flexser flexser at fiu.edu
Sun Aug 21 18:43:26 EDT 2016
The check you are doing at $C008-9 will fail if the CoCo has Disk Basic 1.0
(or a 3rd party modified Disk Basic based on that version, such as ADOS).
You should check for the 1.0 value (see Disk Basic Unravelled) as well.

The poke to $FFDE will do no harm on the earlier CoCos, so might as well do
it unconditionally, unless that will mess up things for the Dragon.

To check for the CoCo 3 (if you actually need this additional test), try
this:  Prior to doing the $FFDE poke, look at someplace within the Super
Extended Basic range to see if the value matches the CoCo 3 one.  You need
to do this BEFORE going to ROM mode, or the value won't be there.

There are also places within Color Basic that have values unique to the
CoCo 3, where the test for a CoCo 3 could be done in ROM mode, like where
the DLOAD command code used to be on the earlier CoCos.

(Or, as I see Brett has just suggested, check the interrupt vectors.)

Art