Re: BASIC listing..

From: silverdr_at_wfmh.org.pl
Date: Mon, 10 Jun 2013 21:07:16 +0200
Message-Id: <AC35409F-3F37-4097-8D43-CF6BA67D344F@wfmh.org.pl>
On 2013-06-10, at 19:55, Spiro Trikaliotis wrote:

>> Pointing to the last byte of the last line would do, wouldn't it? If
>> the PRG wasn't relinked, that is.. Why wouldn't it work if the
>> pointers were not rewritten by LINKPRG? HI byte of the last line's
>> next line pointer would be \0.
> 
> It would work on LISTing, but not on execution (at least, with the code
> of VIC20/C64 BASIC2).

I see - it was all about "BASIC listing" so far but...

> 
> Take something like this:
> 
> 0800 00 0C 08 0A 00 aa bb cc dd ee ff gg hh 00 xx yy
>                                         /\
>                                        080C
> 
> with aa .. hh being some BASIC command bytes that are not of interest
> here.
> 
> On listing, BASIC outputs the line number ($000A = 10) and then the
> command as specified by aa .. hh, until it reaches the $00 in $080D.
> Then, it goes back to $0801, reads the link pointer (to $080C), checks
> the high byte at $080D, and ends the listing.
> 
> On execution, things are different.

Right - here we talk about the NEWSTT routine and you are right, I see what you mean.

> The interpreter interprets aa .. hh,
> whatever they mean. Then, it sees the $00 as end of the line.
> 
> Next, it examines the following link pointer (xx, yy). For the
> interpreter to step here, yy must be $00 - otherwise, it will happily
> interpret the rest of the memory.

Correct but even if we talk about execution, as long as it is only a stub for spawning off ML code, it should do as well (unless a clean return is expected that is). But - anyway - since this trick doesn't work across the whole range of CBMs - there is no point in discussing it further. The only way to get the extra 16 bits seem to be what some programs already do and what made me start this thread.

Thanks.
-- 
SD!


       Message was sent through the cbm-hackers mailing list
Received on 2013-06-10 20:01:52

Archive generated by hypermail 2.2.0.