Posted By
Basman
on 2019-04-22
11:28:41
|  PRINT statement fills the RAM
Hello, what's up with the PRINT statement creating a string in RAM everytime? My program will have graphics and other stuff so I have little RAM.
The C64 doesn't do this. Is there an easy way to replicate the C64's PRINT instruction?
|
|
Posted By
gerliczer
on 2019-04-22
13:34:49
| Re: PRINT statement fills the RAM
And a very nice day to you too, my good Sir.
There is no easy way to replicate the C64's PRINT instruction as this is a different machine. The behaviour of BASIC is set in stone, so to speak.
However, I did a cursory comparison of the main code responsible for realising the PRINT instruction in both Commodore BASIC variants and couldn't find significant difference between them. Still, there might be some implementation details that change the operation. Could you share a short example that demonstrates the erratic behaviour?
On a different note, it might be the best time to advance yourself from Basman to Asmman. 
|
|
Posted By
Basman
on 2019-04-22
15:27:01
| Re: PRINT statement fills the RAM
Thank you gerliczer for your time.
Please run this program:
1 a$="x"
2 print"777777777777777777777777777777777777777777777777777777777777777"
Then look at the RAM starting from $FCBC. The string of 7's has been copied there. Strangely this doesn't seem to happen without the initial assignment a$="x".
I'm indeed trying to become Asmman  as some of the RAM is occupied by humble routines that I wrote. It's still a long way though.
|
|
Posted By
JamesC
on 2019-04-22
21:36:26
| Re: PRINT statement fills the RAM
On the 264 machines, strings are ALWAYS copied into RAM.
Test:
10 PRINT "ABC123"
RUN (ABC123 prints on the screen)
MONITOR
07F8 80 (this tells the Monitor to look at RAM under ROM)
H 1000 FCFF 41 42 43 31 32 33 (search BASIC RAM for the hex values of ABC123)
They will be found at 1008 and FCF8; no prior string assignment is necessary. The same occurs if you use the CHAR command to output a string to the screen.
|
|
Posted By
gerliczer
on 2019-04-23
00:23:20
| Re: PRINT statement fills the RAM
Let's see a little code in action.
LIST
5 PRINTFRE(0)
10 A$="X"
15 PRINTFRE(0)
20 PRINT"7777777777777777777777777777777
77777777777777777777777777777777"
25 PRINTFRE(0)
READY.
RUN
60557
60547
7777777777777777777777777777777777777777
77777777777777777777777
60547
READY.
It seems to me that even though the string really gets copied into the work area at the end of the available RAM, it doesn't really waste memory. If I were you I'd shrug and go on with my stuff. There should be no problem until you fill memory up to the brim.
|
|
Posted By
Basman
on 2019-04-23
03:38:50
| Re: PRINT statement fills the RAM
I'm porting this from the C64 where the Basic part just uses a couple hundred bytes for the variables. On the Plus4 I'm already getting out of memory errors but maybe I can rearrange some stuff to make room.
Thank you.
|
|
Posted By
SVS
on 2019-04-23
09:39:07
 | Re: PRINT statement fills the RAM
I've performed some tests for both PRINT text, and PRINT variable. Actually the strings to be printed are copied into the RAM on memory pages $FB and $FC.
Sometimes the string is aligned to end of the page $FC using last 2 bytes as signals, sometimes they are overwriting the area, but starting from a lower RAM address. I've not understood when/why.
|
|
Posted By
MMS
on 2019-04-23
16:28:52
 | Re: PRINT statement fills the RAM
Just a remark/idea, as I am not so much in the details:
some of the these BASIC routines may call/use Kernal routines too. Definitely it saves ROM space to call standard subroutines (while not so good for the speed).
Kernals should be very same on both machine, furthermore the C64 sees on 38K RAM in BASIC, the rest is not accessible
So maybe the same happens on C64 too, just the Kernal routine writes to such a hidden RAM area, not allowed in C64 to be used (due to parallel ROM area). Such RAM areas exists on C64 (as it has 64K RAM too, but just 38K visible in BASIC), but the full 6!K not so transparent towards customer/Basic programmer.
|
|
Posted By
Basman
on 2019-04-23
18:48:15
| Re: PRINT statement fills the RAM
I haven't checked yet, but it seems that the FRE function forces garbage collection on temporary strings. If the first string is not moved around in the process, it could be the solution.
The reason why I don't want the first string to be moved is that I use a ML routine for keyboard input, that directly accesses the first string through its descriptor (it assumes that the first variable is a string, so I initialize my string at the beginning of the Basic program). If you LIST the program after use, you'll see the last text that was typed, inside the quote marks.
Another difference between C64 and Plus4 string management is about string variables initialized through assignent to constant. On the C64, if you do a$="foobar", a descriptor will be created which directly points into the program's text; new strings in RAM are only created if they are the result of calculations or INPUT operations. The Plus4 always creates strings in RAM.
Thanks to all who replied.
|
|
Posted By
SVS
on 2019-04-24
02:17:52
| Re: PRINT statement fills the RAM
Yes I confirm you that FRE() function does execute a garbage collection. And BTW the string structure in the variable area has a different pattern than C64' one. It is designed to make faster the garbage collection itself.
Maybe the PRINT statements use the same variable area?
|
|
Posted By
JamesC
on 2019-04-24
21:17:56
| Re: PRINT statement fills the RAM
The Plus/4 copies strings to RAM because of the GRAPHIC command. GRAPHIC shifts the start of BASIC upward 12K; any previously-defined pointers "into the program's text" would be corrupted by this move.
Copying strings to the top of BASIC workspace solved this problem, at least in the eyes of Commodore's engineers.
For what it's worth, Commodore never put much effort into backward-compatibility until the C128 in 1985. Until then, each machine family (264 series, B series, etc) was its own beast with its own "rules" and "quirks" to deal with.
Just saying, grumbles that the Plus/4 doesn't work like the C64 isn't the Plus/4's fault. It wasn't intended to be 100% compatible; this is one of those things where they differ.
|
|
Posted By
Basman
on 2019-04-25
06:22:10
| Re: PRINT statement fills the RAM
Problem solved with the FRE function.
|
|
Posted By
Basman
on 2019-04-25
15:21:36
| Re: PRINT statement fills the RAM
Anyway, does anyone know why PRINT "SOMETHING" creates a "SOMETHING" string in RAM?
|
|
Posted By
gerliczer
on 2019-04-25
23:45:07
| Re: PRINT statement fills the RAM
I think JamesC explained it in his last post. Read his first two sentences carefully.
|
|
Posted By
Lavina
on 2019-04-26
03:10:19
 | Re: PRINT statement fills the RAM
Well it's ok to find that string at the $1000 area where the basic program is stored. But at the end of the ram, it's also a mystery for me, why putting it there if it's not a variable. Or the basic language works on 264 machines like the print command string is stored as a variable even if it's not an assigned variable. This is the only logical explanation I can think of. They programmed the print command to be followed by a variable by default. If it's not a defined variable the interpreter defines one of its own and stores the string just as if it would have been a variable?
|
|
Posted By
Basman
on 2019-04-26
14:39:07
| Re: PRINT statement fills the RAM
Sadly the FRE function din't help. Too many calls and memory corruption starts to occur. I got the program working by moving stuff around in such a way that more RAM is available for the strings. They need a ridicolously large amount of RAM. I'll probably have to leave some stuff out.
|
|
Posted By
SVS
on 2019-04-30
07:42:54
| Re: PRINT statement fills the RAM
@Lavina: I agree with yr opinion. They coded once the PRINT, and it is executed the same way both variable or constant string source.
@James: Yes, the garbage collection of Plus/4 is better and much faster than in C64, because in Plus/4 the strings use their last bytes to signal if they are obsolete or not.
@Basman: if the above opinions are correct, you cannot avoid the garbage collection by expanding the memory space. The interpreter, sooner or later, will do it automatically.
|
|
