I turn on my '64 (or emulator :) ), hit RUN/STOP + RESTORE (this step, for
some reason, is important) then type:
...and watch the error routine do something interesting.
Now why does it _do_ that?
> Now why does it _do_ that?
Hm. If one writes an interrupt-driven routine which displays, moves
and checks a sprite's collission with background, we could have one
of the world's smallest space race crap games... hm indeed.
That is interesting, on my c64 I've been testing to see what some POKE
statements can do and I've come across some very interesting results...
>>I turn on my '64 (or emulator :) ), hit RUN/STOP + RESTORE (this step, for
>>some reason, is important) then type:
>>...and watch the error routine do something interesting.
>>Now why does it _do_ that?
>Very interesting.. how on earth did you figure that out?
I'm not sure, but here's a programmatic way to kick it off without the
>> begin program
>> end program
Screen positioning seems to have something to do with it. If you hit R/S-R
and then CRSR down one line, then enter Carl's POKE/SYS as above, it doesn't
work at all (or if it does, you get one question mark and then blanks).
Here's my take on how it works.
There's nothing magical about the entry point; sys42042 works just as
well as sys58251. (Disassemble the 58251 entry and it falls right into the
real error routine in BASIC.) The .xr contains 96, so we are looking for
our error text message at $a326+96 => $a386 (as we disassemble along). We
print a question mark, and then we try to do something with this error
message. Printing characters in BASIC doesn't go directly to CHROUT but
through a stub library. If you disassemble the BASIC interface to chrout
at $e10c, it has the possibility of getting fed back into the error handler
if the carry is set (Commodore doesn't make it easy, but you will eventually
get fed back into the indirect vector at $0300 if the conditions are right).
I didn't do the work to figure out what the value of .xr would be by now,
but I'm guessing it could account for the varying spacing by changing where
that spurious error message is sought.
I haven't done enough work on the disassembly to figure out if this guess
has any basis in fact, but this might give someone something to look into.
Cameron Kaiser * cka...@stockholm.ptloma.edu * posting with a Commodore 128
personal page: http://www.armory.com/%7Espectre/
** Computer Workshops: games, productivity software and more for C64/128! **
** http://www.armory.com/%7Espectre/cwi/ **
> Very interesting.. how on earth did you figure that out?
Many moons ago while I was teaching myself 6502, I was writing a program
that enhanced BASIC (yup, that old chestnut) and I needed to generate an
error message or two. Reading the ROM gives away the valid error messages,
but it was a little difficult to tell what would happen if I fed the error
routine invalid values. Since I didn't feel like thinking too much, I used
the POKE-SYS sequence above. Some of the effects were a little too colourful
for my liking, and I wasn't sure whether it was corrupting zero-page
somewhere, so I used R/S+RESTORE to clear the screen, and possibly a couple
of pointers here and there.
As you might imagine, I was a little surprised when I hit 96. I suspected
that 96 being RTS might have had something to do with it...
I've let it run for a couple of hours, and nothing special seems to happen,
but the pattern of ?s does seem to be the same every time I do it.
ICYWW, the (not very spectacular) BASIC enhancement that led me to this
weird discovery was published in Commodore Format (#50?). I went to Uni
after that and promptly forgot most of my 6502. :-(
On 25 Jul 2001 23:37:21 -0500, Cameron Kaiser wrote:
>Jason Petersen <pete...@yahoo.com> writes:
>>>I turn on my '64 (or emulator :) ), hit RUN/STOP + RESTORE (this step, for
>>>some reason, is important) then type:
>>>...and watch the error routine do something interesting.
>>>Now why does it _do_ that?
>>Very interesting.. how on earth did you figure that out?
>I'm not sure, but here's a programmatic way to kick it off without the
It's even simpler!
You just have to start your command on line 3!
What is going on?
Well, look at the routine here:
.C:e38b 8A TXA
.C:e38c 30 03 BMI $E391
.C:e38e 4C 3A A4 JMP $A43A
with this, Cameron, you were right: It's just the same as going
directly to A43A:
.C:a43a 8A TXA
.C:a43b 0A ASL A
.C:a43c AA TAX
.C:a43d BD 26 A3 LDA $A326,X
.C:a440 85 22 STA $22
.C:a442 BD 27 A3 LDA $A327,X
.C:a445 85 23 STA $23
.C:a447 20 CC FF JSR $FFCC
.C:a44a A9 00 LDA #$00
.C:a44c 85 13 STA $13
.C:a44e 20 D7 AA JSR $AAD7
.C:a451 20 45 AB JSR $AB45
.C:a454 A0 00 LDY #$00
.C:a456 B1 22 LDA ($22),Y
.C:a458 48 PHA
.C:a459 29 7F AND #$7F
.C:a45b 20 47 AB JSR $AB47
.C:a45e C8 INY
.C:a45f 68 PLA
.C:a460 10 F4 BPL $A456
.C:a462 20 7A A6 JSR $A67A
Now, what is going on here? The LDAs in A43D/A442 read $0490 as
address of the string to be output.
Since $A44E outputs CR, $A451 outputs a question mark on line 4. After
this, the look in A454-A460 outputs the contents at ($22) to the
screen until we get to a character where bit 7 is set.
Now, $22 points to $0490 which is line 3/column 24 of the screen! That
is, the routine starts to output the contents of the screen to the
screen! Since we get our string from 3/24 of the screen and we output
to 4/2, we're copying many spaces and some question marks again and
again to the screen (remember that by accident, $20 is PETSCII *and*
Screencode for SPACE; the same applies to the code for the question
mark!). Since not one screen code has bit 7 set, this routine never
stops (remember that this routine assume that there is not one string
bigger than 255 bytes, and it has no checking for this!). When the YR
"overruns" to zero, the regularity of the output is violatet (thus, we
have some "??" sometimes there).
What is the difference when we issue this command directly after
starting the machine? In this case, we have some text on the screen
which is used as source for the string to be output (remember that
after RESTORE, the only text is on line 2 which is not used as source
for the string to be output). This text has screen codes in the are <
$20, which interpreted as control commands for PETSCII. So, we get
some characters with bit 7 set on the screen, so the routine halts