From: Ethan Dicks (ethan.dicks_at_gmail.com)
Date: 2008-06-14 03:09:01
Hi, all, I have finally been able to put some time in on making progress with a couple of years-old bugs with my port of the Infocom C-64 Zmachine to the PET, and believe that one of my problems with the code running on a BASIC 4.0 machine is double-use of a zero-page location. I have, of course, attempted to identify all zero-page locations which are not used when BASIC is not running, but since the code makes use of CHRIN/CHROUT ($FFCF/FFD2), I think some of the code in the editor ROM is stepping on me. Way back in 1979 or so, someone gave me a paper copy of a really excellent 3-column zero-page and ROM entry-point map. There's a good chance it was based on work by Jim Strasma. I haven't seen my paper copy in over 10 years, and I've never run across anything like it on the 'net. If that description rings a bell to anyone, or if anyone has a really detailed zero-page map for BASIC 2.0 and BASIC 4.0, I'd love to see it. So I'm still searching for the details of my BASIC 4.0 issue, but I made significant progress on my BASIC 2.0 issue - namely an input scope problem. The input loop is pretty brainless... it loops on a call to CHRIN ($FFCF) until the returned character 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 (2001-32N or 3032, for example), for the first few input attempts *before the cursor is on the bottom line*, it works as expected. Once the cursor reaches the bottom line, the 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 (which tends to be stuff that's scrolled off the screen) *and* the first couple of dozen bytes of the top line of the screen (presumably from $8400-$8410 or so), typically to a total of 76 bytes. Does anyone know of any writeups on the behavior, especially differences in behavior across the C= 8-bit line, of calls to CHRIN? I've traced through the code a bit, of course, and nothing is leaping out at me yet. 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 programming on C-64s than on PETs, so it's entirely possible I am expecting CHRIN to behave the same when in fact there are documented differences. I've already whipped up a set of wrapper functions for the PET to act as kind of a C-64 Kernel "shim" so that source from the C-64 is easier to port to the PET, so adding a little more code to shim up CHRIN isn't a big deal. At least now that I know the nature of the bug, I've been able to navigate across Zork I on a simulated 3032 by ending all commands with a full-stop (i.e., "LOOK.") That way, at least, the parser stops parsing and follows what I type before attempting to interpret screen memory garbage. Thanks for any pointers to PET ROM details, -ethan Message was sent through the cbm-hackers mailing list
Archive generated by hypermail pre-2.1.8.