Msg: 7051 *Conference*

04-02-97 20:10:14

From: RON WIESEN

To : RICHARD HANSON

Subj: FEEDBACK: DEVELOPER ROM2 FINDINGS

Developer ROM2 findings message - 1st of (few I hope)
 
Got developer ROM2 installed - been working through the five addendum sheets on
it.  Mostly focused on disk access features now AS THEY APPLY TO THE PDD2
rather than a PDD1 which I don't own.  Looking for quirks, restrictions,
limits, "assumed" requirements, and whatnot - found a few, most are no big
deal.
 
Greatest quirk is for the CMD command "FILES".  I think FILES "assumes" two
things: (1) a boot diskette is present and (2) the boot file name is "typical"
in that it arrives "first" in the numeric/alpha sorted list of file names which
is the response given by the drive.  Consequently FILES "omits" this "first"
file name and lets all others show on the LCD.  Where I use a boot diskette
with such a "typical" boot file name, FILES shows the correct "nnnnnn Bytes
free" and omits the boot file name but shows "all regular" file - that's fine.
But where I use a data diskette, FILES "assumption" is wrong and there are two
consequences: (1) the one file name that is "first" by numeric/alpha sort is
omitted and (2) the "nnnnnn Bytes free" of available diskette volume is
incorrectly calculated.  Probably, a character of the omitted file name gets
used "numerically" in the calculation of volume.
 
I recall messages from Comet_ a while back where he had no luck with the
Cleuseau command syntax RC$="string":CALL911.  All I find restrictive for this
is that it doesn't work as a "direct" statement from BASIC.  It does work where
BASIC interprets it during RUN condition from: (1) a named .BA file or (2) the
unnamed or so-called "unsaved" .BA file (a.k.a. Suzuki).
 
GOOD NEWS/BAD NEWS - Regarding LFKYR of my prior message, the GOOD news is: (1)
LFKYR identifies the developer ROM2 as the normal ROM2 (can't tell them apart)
and (2) consequently defines BASIC F7 key for CALL911 (on LABEL line F7 shows
ROM2 but it's a canard) which is a valid definition that befits both ROMs.  The
BAD news is that an additional ROM ID specific to the developer ROM2 isn't
required.  Thus, I don't "grow" LFKYR's list of IDs any closer to maximum - and
I'm reluctant to go public with just IDs for SuperROM and ROM2 (and an ID for
UR-II soon).  Maybe I should let it go unmaxed with just 3 IDs.