Basic "crunching" question.
Moderator: Moderators
- JohnnyRockets
- Vic 20 Enthusiast
- Posts: 178
- Joined: Wed Jun 13, 2012 5:42 pm
- Location: Michigan, USA
- Occupation: IT Manager
Basic "crunching" question.
Page 79 of the PRG says that crunching a program is a good way to save memory.
It says by abbreviating keywords, memory can be saved.
But it also implies that if the program is "listed" before saving it the abbreviated commands will be "inflated" to their normal length and all memory savings would be gone.
The method is to use abbreviations and then save the program before doing any kind of listing.
Does that sound right?
Also by adding multiple command to one line, where are the savings derived? From the fact that you do not need to have a new line number, spaces, etc?
It says by abbreviating keywords, memory can be saved.
But it also implies that if the program is "listed" before saving it the abbreviated commands will be "inflated" to their normal length and all memory savings would be gone.
The method is to use abbreviations and then save the program before doing any kind of listing.
Does that sound right?
Also by adding multiple command to one line, where are the savings derived? From the fact that you do not need to have a new line number, spaces, etc?
Thanks!
JR
><>
JR
><>
You can fit more commands per line by using abbreviations and removing unnecessary spaces (exceeding the 88 character limit for a program line). The fewer lines you have, the smaller the program. Remember that each line takes a chunk of memory just to index it.
I try to make my programs as compact as possible while editing and "crunch" when I am finally done. So that I can maximize savings. Another trick is to make the best use of variables so that you're not repeating commonly used numbers, etc.
I try to make my programs as compact as possible while editing and "crunch" when I am finally done. So that I can maximize savings. Another trick is to make the best use of variables so that you're not repeating commonly used numbers, etc.
- JohnnyRockets
- Vic 20 Enthusiast
- Posts: 178
- Joined: Wed Jun 13, 2012 5:42 pm
- Location: Michigan, USA
- Occupation: IT Manager
Thanks Jeff!Jeff-20 wrote:You can fit more commands per line by using abbreviations and removing unnecessary spaces (exceeding the 88 character limit for a program line). The fewer lines you have, the smaller the program. Remember that each line takes a chunk of memory just to index it.
I try to make my programs as compact as possible while editing and "crunch" when I am finally done. So that I can maximize savings. Another trick is to make the best use of variables so that you're not repeating commonly used numbers, etc.
When you "crunch" at the end, do you do like a "find and replace" type of search like in Notepad?
Thanks!
JR
><>
JR
><>
BASIC is tokenized when you type in the line, so each BASIC command and function only uses 1 byte of RAM.
If you type in a line such as:
The "INPUT" keyword will be tokenized, and if you were to type "I shift-N" for the shortcut of INPUT you'll still get the same token. Typing LIST will not un-crunch the line, it still only takes 1 byte in RAM. The LIST command interprets the (1 byte) token that it finds in RAM and displays it as the full keyword, but it still only uses 1 byte.
If you type in a line such as:
Code: Select all
10 INPUT"ENTER YOUR NAME";N$
Ray..
- JohnnyRockets
- Vic 20 Enthusiast
- Posts: 178
- Joined: Wed Jun 13, 2012 5:42 pm
- Location: Michigan, USA
- Occupation: IT Manager
Buzbard,buzbard wrote:BASIC is tokenized when you type in the line, so each BASIC command and function only uses 1 byte of RAM.
If you type in a line such as:The "INPUT" keyword will be tokenized, and if you were to type "I shift-N" for the shortcut of INPUT you'll still get the same token. Typing LIST will not un-crunch the line, it still only takes 1 byte in RAM. The LIST command interprets the (1 byte) token that it finds in RAM and displays it as the full keyword, but it still only uses 1 byte.Code: Select all
10 INPUT"ENTER YOUR NAME";N$
Thanks for your explanation! But it sure seems like they are insinuating something different on page 79 of the Programmer's Reference Guide, under "Abbreviating Keywords". Almost like a "crunching" of some kind can take place with abbreviations and save memory...?
Thanks!
JR
><>
JR
><>
- JohnnyRockets
- Vic 20 Enthusiast
- Posts: 178
- Joined: Wed Jun 13, 2012 5:42 pm
- Location: Michigan, USA
- Occupation: IT Manager
Excellent! I will do this and report back my results! Cool!buzbard wrote:Well, you could type in the line above then type PRINT FRE(0), note how much RAM is free.
Then power cycle the VIC to clear all the RAM then type it in again using the shortcut then type PRINT FRE(0) again to see if you get a smaller number.
I'll bet you get the same number though.
Thanks!
JR
><>
JR
><>
- JohnnyRockets
- Vic 20 Enthusiast
- Posts: 178
- Joined: Wed Jun 13, 2012 5:42 pm
- Location: Michigan, USA
- Occupation: IT Manager
Yes, four bytes are saved by not having another line number and line link.Also by adding multiple command to one line, where are the savings derived? From the fact that you do not need to have a new line number, spaces, etc?
Only where it allows you to enter a line that will be longer than one logical screen line when listed.It says by abbreviating keywords, memory can be saved.
No, the problem with lines that are longer than one logical screen line is that they can't be edited with the screen editor. When the line is listed it gets broken into screen line length chunks and each chunk is treated as an individual part by the screen editor.But it also implies that if the program is "listed" before saving it the abbreviated commands will be "inflated" to their normal length and all memory savings would be gone.
For example the line ..
Code: Select all
10?:?:?:?:?:?:?:?:?:?:
?:?:?:?:?:?:?:?:?:?:?:
?:?:?:?:?:?:?:?:?:?:?
Code: Select all
10 PRINT:PRINT:PRINT:P
RINT:PRINT:PRINT:PRINT
:PRINT:PRINT:PRINT:PRI
NT:PRINT:PRINT:PRINT:P
RINT:PRINT:PRINT:PRINT
:PRINT:PRINT:PRINT:PRI
NT:PRINT:PRINT:PRINT:P
RINT:PRINT:PRINT:PRINT
:PRINT:PRINT:PRINT
However, if you try to use the screen editor on the code, even if no changes are made, you either get a truncated line, a syntax error or three blank lines printed depending on where the cursor is when you hit return.
Sort of. Once the program is listed it is all too easy to invoke the screen editor and end up with a truncated long line. If this happens the only way to fix the truncated line is to retype it in its abbreviated keyword entirety.The method is to use abbreviations and then save the program before doing any kind of listing.
Does that sound right?
Lee.
- JohnnyRockets
- Vic 20 Enthusiast
- Posts: 178
- Joined: Wed Jun 13, 2012 5:42 pm
- Location: Michigan, USA
- Occupation: IT Manager
- JohnnyRockets
- Vic 20 Enthusiast
- Posts: 178
- Joined: Wed Jun 13, 2012 5:42 pm
- Location: Michigan, USA
- Occupation: IT Manager
Ahem... Yes, of course you can! I knew that!buzbard wrote:If you list a progam then use the cursor key to move to a line and change what is there, that's the screen editor. You don't have to retype a line from scratch.JohnnyRockets wrote:...what is the screen editor you are talking about?

Actually, I didn't know that! And it is awesome!
Be kind everyone, please keep all laughter and jokes to yourselves...

Thanks!
JR
><>
JR
><>
Above I tried to write everything Lee wrote, but it got lost in translation. He did it much better.
I use abbreviations all the time to get more info into a basic line.
My favorites are the undocumented abbreviations one can put between quotes. If you look at Commodore game tape listings, they put some kind of line break trick to squeeze full title screens of text into single lines. I still haven't figured that out. I think Blue Meanies was a good example.

My favorites are the undocumented abbreviations one can put between quotes. If you look at Commodore game tape listings, they put some kind of line break trick to squeeze full title screens of text into single lines. I still haven't figured that out. I think Blue Meanies was a good example.