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.