| How's this work? [message #88559] |
Mon, 25 August 2003 17:41  |
jaseinblack
Messages: 6
Registered: July 2003
Karma: 0
|
Junior Member |
|
|
Hi all,
I downloaded this from the Commodore Knowledge Base:
http://www.floodgap.com/retrobits/ckb/display.cgi?69
10 printchr$(147)
20 poke55,138:poke56,228:clr
30 a$="ibm":print"a$ = ";a$
40 b$="macintosh"
50 print:print"b$ = ";b$
60 print:print"a$ + b$ = ";a$+b$
70 poke55,.:poke56,160:clr:list
It prints out that a$ + b$ = COMMODORE 64.
Now I know that it gets the string COMMODORE 64 from the startup text in
ROM, and that the POKEs in line 20 move the top of basic to the location of
the end of that startup text.
I assume that the variable space starts at the top of BASIC RAM and works
downwards, so variable RAM contains the string COMMODORE 64. But why do a$
and b$ retain their values of IBM and MACINTOSH but the concatenation a$+b$
returns COMMODORE 64?
I guess that when the variables are written to RAM it gets written to the
RAM underneath the BASIC ROM.
I think I must be nearly understanding it but I'm missing something! Anyone
know what?
Cheers
Jase
|
|
|
|
| Re: How's this work? [message #88561 is a reply to message #88559] |
Mon, 25 August 2003 18:38  |
Michael J. Schülke
Messages: 166
Registered: July 2003
Karma: 0
|
Senior Member |
|
|
jaseinblack wrote:
> I assume that the variable space starts at the top of BASIC RAM and works
> downwards, so variable RAM contains the string COMMODORE 64. But why do a$
> and b$ retain their values of IBM and MACINTOSH but the concatenation a$+b$
> returns COMMODORE 64?
Because a new string is created in memory to store the result of the
concatenation. This new string happens to be in exactly the place of the
"COMMODORE 64" from the welcome message. The concatenation is stored
there, but
> when the variables are written to RAM it gets written to the
> RAM underneath the BASIC ROM.
PRINT then tries to read the result back, but gets the contents of the
ROM instead.
> I think I must be nearly understanding it but I'm missing something! Anyone
> know what?
I think that's it; I haven't single-stepped through the process to
check, though.
Regards,
Michael
|
|
|
|
| Re: How's this work? [message #88563 is a reply to message #88559] |
Mon, 25 August 2003 19:28 |
Linards Ticmanis
Messages: 253
Registered: April 2012
Karma: 0
|
Senior Member |
|
|
jaseinblack wrote:
> Now I know that it gets the string COMMODORE 64 from the startup text in
> ROM, and that the POKEs in line 20 move the top of basic to the location of
> the end of that startup text.
>
> I assume that the variable space starts at the top of BASIC RAM and works
> downwards, so variable RAM contains the string COMMODORE 64. But why do a$
> and b$ retain their values of IBM and MACINTOSH but the concatenation a$+b$
> returns COMMODORE 64?
The variables heap (including numerical variables and string POINTERS)
grows from the end of the program UP. The string CONTENTS heap grows
from the end of BASIC memory downwards. If the twain shall ever meet
during an allocation, garbage collection is run to throw out unneeded
string content leftovers. If not enough could be removed to make space
for the new allocation, you get an OUT OF MEMORY ERROR.
So this program puts string POINTERS (variable name, length, address of
contents) in normal ram, but it is fooled into allocating string
CONTENTS in the ROM area.
You know how it gets the "Commodore 64": As you said, from ROM, where
the interpreter is fooled into building its new string a$+b$. It writes
the string into RAM under ROM but then reads back ROM instead, since it
doesn't know anything about ROM in the first place.
Now why do the other strings stay as they are? Because they are literal
strings in the program. To avoid wasting string content space for exact
duplicates of stuff already in the program text, in the case of literal
strings nothing is stored into the string content heap, and the string
pointer simply points to that place inside the BASIC code where the
string appears. Replace "ibm" with, for example "ib"+"m", to see the
difference (there should be none visible with a sane RAM configuration,
but there is one in this case, since now the BASIC code doesn't contain
an exact copy of the necessary string contents, so an allocation in the
string content heap - fooled into the ROM area - is necessary.)
--
Linards Ticmanis
The Master said, "The business of laying on the colors follows the
preparation of the plain ground."
|
|
|
|
| Re: How's this work? [message #88575 is a reply to message #88559] |
Mon, 25 August 2003 23:53 |
henk
Messages: 3
Registered: July 2003
Karma: 0
|
Junior Member |
|
|
"jaseinblack" <no@ta.com> wrote in message news:<2tv2b.1691$O57.482515@wards.force9.net>...
> Now I know that it gets the string COMMODORE 64 from the startup text in
> ROM, and that the POKEs in line 20 move the top of basic to the location of
> the end of that startup text.
>
> I assume that the variable space starts at the top of BASIC RAM and works
> downwards, so variable RAM contains the string COMMODORE 64. But why do a$
> and b$ retain their values of IBM and MACINTOSH but the concatenation a$+b$
> returns COMMODORE 64?
>
Along with what's already been said about writing to then reading ROM,
I'd point out that when you assign a string constant to a string variable,
the variable points to the constant, ie the variable contains a pointer to
the location of the constant in the BASIC code.
bogax
|
|
|
|
| Re: How's this work? [message #88616 is a reply to message #88563] |
Tue, 26 August 2003 17:08 |
jaseinblack
Messages: 6
Registered: July 2003
Karma: 0
|
Junior Member |
|
|
"Linards Ticmanis" <ticmanis@coli.uni-sb.de> wrote in message
news:bie63l$1ntqu$1@hades.rz.uni-saarland.de...
> Now why do the other strings stay as they are? Because they are literal
> strings in the program. To avoid wasting string content space for exact
> duplicates of stuff already in the program text, in the case of literal
> strings nothing is stored into the string content heap, and the string
> pointer simply points to that place inside the BASIC code where the
> string appears.
Aha! I get it now. Thanks to all who replied :-)
Jase
|
|
|
|
| Re: How's this work? [message #89569 is a reply to message #88559] |
Sat, 06 September 2003 14:21 |
Anton Treuenfels
Messages: 105
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
In addition to what's already been pointed out, I'd like to note that "ibm"
has 3 characters, "macintosh" has 9, and "COMMODORE 64" has 12.
So line 20 moves the top of BASIC to a location that the C64 normally reads
as ROM but writes as RAM. The variables A$ and B$ are created and (since
they are literal strings) their descriptors point into the program text. In
line 60 their concatenation is created. This is not a literal string, so it
is written to RAM (the top of it, since this is the first non-literal
string). Its descriptor (on the temporary string stack, by the way) points
to a location twelve bytes below the top of BASIC. The PRINT routine uses
that descriptor, but reading where it points picks up the contents of ROM
rather than RAM.
In line 70 things are restored to normal and variables cleared, so that
should eliminate the contents of A$ and B$ if I read this correctly. Maybe
lines duplicating lines 30 and 50 should appear after line 60 and before
line 70 to emphasize the "mystery".
"jaseinblack" <no@ta.com> wrote in message
news:2tv2b.1691$O57.482515@wards.force9.net...
> Hi all,
>
> I downloaded this from the Commodore Knowledge Base:
>
> http://www.floodgap.com/retrobits/ckb/display.cgi?69
>
> 10 printchr$(147)
> 20 poke55,138:poke56,228:clr
> 30 a$="ibm":print"a$ = ";a$
> 40 b$="macintosh"
> 50 print:print"b$ = ";b$
> 60 print:print"a$ + b$ = ";a$+b$
> 70 poke55,.:poke56,160:clr:list
>
> It prints out that a$ + b$ = COMMODORE 64.
>
> Now I know that it gets the string COMMODORE 64 from the startup text in
> ROM, and that the POKEs in line 20 move the top of basic to the location
of
> the end of that startup text.
>
> I assume that the variable space starts at the top of BASIC RAM and works
> downwards, so variable RAM contains the string COMMODORE 64. But why do
a$
> and b$ retain their values of IBM and MACINTOSH but the concatenation
a$+b$
> returns COMMODORE 64?
>
> I guess that when the variables are written to RAM it gets written to the
> RAM underneath the BASIC ROM.
>
> I think I must be nearly understanding it but I'm missing something!
Anyone
> know what?
>
> Cheers
>
> Jase
>
>
|
|
|
|
Members
Search
Help
Register
Login
Home
