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.