Date   : Tue, 30 Apr 2002 17:25:58 +0100
From   : "Richard Gellman" <r.gellman@...>
Subject: Re: Completely stuck on tube emulation

>Are your pushes and pops in the right order when you do a JSR/RTS/RTI? C82C
>and 80C8 sound quite reasonalbe. (Er.. I tried to do the RTS+1 adjustment
>there. But I might have got it wrong. Anyway, LSB/MSB the wrong way round
is
>what I'm getting at.)

Yep. I've compared such things with the info in "64doc" (that big document
on every insignificant opertion of the 6502...)
16-bit pushes/pops are in the right order, Program Counter incremented at
the right time, Stack pointer deceremented/incremented at the right time,
etc.

I did investigate that theory, and tried reversing the push/pop order, it
caused the whole system to stop working..

Also, although 81C8 is reasonable, C92C isn't, as this is in the "gap"
between the language ROM and the Tube ROM, which is blank.

>I would have assumed this was fine, though, because I vaguely remember this
>is how the OS picks up the address of text to output. So, if it were wrong,
>all the OS text would be messed.

Ah, but it happens when you type something that *doesnt* generate an error..
Remember, its already AT these locations when it encounters BRK, its not
that BRK causes a jump to these locations.

>Oh and it seems unlikely that such a bug
>would have gone unnoticed for this long... on the other hand, I don't
>suppose many programs construct return addresses themselves...

Its a standard method for handling BRKs actually..
A BRK instruction jumps to the OS thru the BRK vector at FFFE-FFFF, this
then jumps through the software vector in page 2, which then jumps through
the extended software vector at page D, which causes a jump to the BRK
handler within the current language ROM. This code then deals the BRK, and
then processes the stack and places a return address to cause RTI to jump
back to the BASIC input prompt (unless ON ERROR has been processed). This is
why if you assemble

BRK:EQUB errno%:EQUS "Some error":EQUB 0:LDA #65:JSR &FFEE:RTS

and execute it, the error message will be displayed, but the call to OSWRCH
will be abandoned, as the BRK handler returns control to the BASIC prompt by
way of "programming" the stack.

Just a little info for u :)

>Well, you did ask for "anything" :-)

Yup. Absolutely any ideas welcomed :)

-- Richard Gellman

<Serious bit>
This email is sent to you as personal communication or to a specific mailing
list ONLY, and does not contain any form of comercial advertsing (spam). By
replying to this email you legally agree that you will honour this in a
similar fashion, and you will not send any commercial email to this email
address, or subscribe this email address to any mailing list without prior
permission. Failure to adhere to this may result in criminal prosecution
under the misuse of information laws applicable in all countries.
<end of serious bit>