On Wed, Mar 25, 2020 at 12:24 AM Peter Noeth <[email protected]> wrote:
> Does that include bug fixes from v1.7? > > I sent Ken a PM back a while ago describing a bug I found, but got no > response. > > The problem occurs when transferring a BASIC program from VirtualT to the > PC in ASCII format. The bug concerns any BASIC program that uses embedded > ASCII characters with the value greater than 127d directly in PRINT > statements. When these characters are used (for example, the downward > pointing triangle, 167d A7h), the ASCII character value is not preserved in > the saved output file, but instead a BASIC keyword is substituted. > > For example (+ character is really 167d, input with the keyboard sequence > [CODE]_ ): > A program containing the line: > 11510 PRINT@280,"++"; > > is saved in the ASCII format output file as: > 11510 PRINT@280,"GOTOGOTO"; > > I am not sure if the keyword GOTO is the actual substitution, as I am away > from my "development" computer and can verify, but it illustrates the basic > problem. Likely, as BASIC keywords are probably represented as values > higher than 127d, and the routine in VirtualT to save a file on the PC in > ASCII format is not setting a flag to track the occurrences of the " > character pairs and interpret any characters within as ASCII characters and > not BASIC keywords. > > I guess the question becomes, what do you want it to do? What does the Model 100 ROM do when you save that program as ASCII? If it keeps those bytes as binary for VT to do the same behavior it would have to understand whether it's detokenizing a token, a string, the contents of a REM statement or possibly even hidden machine language packed into hidden program lines. -- John.
