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 <firstname.lastname@example.org> 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.