From: Ethan Dicks (ethan.dicks_at_gmail.com)
Date: 2008-06-15 04:08:44
On Sat, Jun 14, 2008 at 11:13 AM, Rhialto <rhialto@falu.nl> wrote:
> On Sat 14 Jun 2008 at 01:09:01 +0000, Ethan Dicks wrote:
>> is a CR ($0D). On the C-64 and VIC-20, this always seems to
>> return what the player typed and no more. On a BASIC 2.0
>> PET... input loop grabs what the player typed, all the spaces
>> to the right of what the player typed, *and* all of the memory
>> garbage between $83E8 and $83FF
>
> Do you mean that this happens before the user types 40 characters in the
> last line? What you describe sounds like the screen editor thinks that
> the bottom line is a 80-character line, and that it connects the next 40
> bytes in memory to it to form the full 80-character line.
Yes. I have done some more experimenting and found that $D5
(right-hand window or line margin) was set to 80, not 40 while I was
calling for input. I forced it to 40 before calling $FFCF and things
now work much better. I still don't know why the table would get
out of whack - the application clears the screen by printing a
"CLR" character, so the ROMs should reset the table at the same
time, then it's all just calls to $FFD2 and $FFCF - no funny
screen manipulation except for occasionally doing some printing
on the top line (by printing "HOME", then setting the column by
fiddling the right zero-page var in the way that "PLOT" does on
the C-64 and the VIC-20).
> Obviously the last line can't really be the first of a double line, so I
> would look in the area of either the line continuation table, or in
> handling the edge cases of that table. I'm not sure if the last line
> actually has an entry in that table, or not, since in theory it could do
> without (but handling the edge case may be easier if it does exist).
> I can't say I have ever seen this behaviour. Logically it should also
> happen in BASIC programs, unless BASIC contains a special workaround or
> some such. Maybe comparing the different screen editor and/or BASIC
> versions (which should otherwise be fairly similar if not identical)
> would provide a hint.
Well... for comparison... once I got around another (unrelated) bug
with 40-column BASIC 4.0 machines (i.e., 4032), I found that it
happens there, too, unless I force $D5 to 40 before gathering input.
It does _not_ happen on the 8032, but that makes sense, since all
lines are 80 columns.
>> Does anyone here know of any BASIC-centric 'gotchas' with CHRIN
>> on PETs vs C-64s? I've probably done 50 times as much assembly
>
> I have used a trick of opening files with the screen or keyboard as
> input device, and INPUT#ing from them has some useful properties. I
> can't recall all details though.
I've done that before from BASIC to trap the user. Here, I was just
looking for any known significant differences between 40-column PETs
and VIC-20s and C-64s with $FFCF behavior.
I stared at a disassembly of the 8032 as I went through "live" code
on a VICE-simulated 3032. The code in the editor ROM that is
called by a jump to $FFCF is remarkably similar between BASIC 2.0
and BASIC 4.0 for 80 columns. That's how I started snooping around
$D5 - it seemed to be one of the few locations that could affect this.
For now, I have a workaround - since the bottom line can never wrap,
forcing the input to 40 columns on 40-column machines is certainly
acceptable enough to get me past this for further testing.
-ethan
Message was sent through the cbm-hackers mailing list
Archive generated by hypermail pre-2.1.8.