using the cassette buffer to store data
Moderator: Moderators
using the cassette buffer to store data
I am just wondering if anyone else ever uses the cassette buffer, to store data, and thus save some memory.
I think you get from 828 to 1024 (inclusive?) to store stuff, as long as you never use the cassette.
It's not a ton of space, but could be a great place to store variables and the like.
I have only used it to store text (like an instruction screen or title page), for stuff i want to display, and then calling it up from various programs.
Chris
I think you get from 828 to 1024 (inclusive?) to store stuff, as long as you never use the cassette.
It's not a ton of space, but could be a great place to store variables and the like.
I have only used it to store text (like an instruction screen or title page), for stuff i want to display, and then calling it up from various programs.
Chris
I found a nice page of the vic 20 memory map, and it shows that the cassette buffer is only from 828 to 1019.
http://www.hut.fi/Misc/cbm/docs/vic20-memorymap.html
chris
http://www.hut.fi/Misc/cbm/docs/vic20-memorymap.html
chris
I have no idea if anyone will have use for these, but I like using them:
Here is a program I am using to store text in the cassette buffer, and then a routine that I can pop in any program, to read that text later.
If you are going to type this in and run it, just remember there is a 'new' comand on line 110
- I altered the listing a bit (like using chr$ everywhere) to make it easier to type into this forum.
- to stop typing before the end of using up the cassette buffer, just hit 'F1'
-----
10 print chr$(14);chr$(147);
20 for i = 829 to 1019
30 get a$: if a$ = "" then 30
40 if a$ = chr$(133) then 100
50 print a$;chr$(95);chr$(157);
60 n = asc(a$)
70 poke i,n
80 z = z + 1
90 next i
100 poke 828,z
110 clr: new
-----
the routine to get the text back
10 print chr$(147);
20 for i = 829 to 829+peek(828)
30 print chr$(peek(i));
40 next i
-----
Chris
Here is a program I am using to store text in the cassette buffer, and then a routine that I can pop in any program, to read that text later.
If you are going to type this in and run it, just remember there is a 'new' comand on line 110
- I altered the listing a bit (like using chr$ everywhere) to make it easier to type into this forum.
- to stop typing before the end of using up the cassette buffer, just hit 'F1'
-----
10 print chr$(14);chr$(147);
20 for i = 829 to 1019
30 get a$: if a$ = "" then 30
40 if a$ = chr$(133) then 100
50 print a$;chr$(95);chr$(157);
60 n = asc(a$)
70 poke i,n
80 z = z + 1
90 next i
100 poke 828,z
110 clr: new
-----
the routine to get the text back
10 print chr$(147);
20 for i = 829 to 829+peek(828)
30 print chr$(peek(i));
40 next i
-----
Chris
I like the empty slot on 673-767 ($02A1-$02FF). It is much smaller than the tape buffer, but more or less unused. This space is a few bytes less on the C64 if developing for maximum compatibility.
If you want an example of tight memory use, you should see the memory layout in the VICPIC part of VIMMII, the unexpanded version of the VIMM demo. I think both me and Albert optimized in both ways to fit both music and disk loader as well as the picture and viewer, and in the end had some 20-50 bytes free memory out of the 5K the unexpanded machine totally can offer. Of course, most or all of zero page, stack, Basic workspace etc was used up for own use.
If you want an example of tight memory use, you should see the memory layout in the VICPIC part of VIMMII, the unexpanded version of the VIMM demo. I think both me and Albert optimized in both ways to fit both music and disk loader as well as the picture and viewer, and in the end had some 20-50 bytes free memory out of the 5K the unexpanded machine totally can offer. Of course, most or all of zero page, stack, Basic workspace etc was used up for own use.
Anders Carlsson
Yep!
I used the 828 - 1029 space many times in my early programming days. I made a rather inefficient card game where I stored the deck in that area of memory. Later I used it to store data for a maze game.
But I totally agree with carlsson. After I got the programmers ref guide, I scanned the memory map (my FAVORITE section of any book ever!) and found the empty block at the 600 level!
I would use both if I need the space, but I like the idea of having the empty space with no conflicts. Even with a tape version of my game, I wouldn't need to worry about overlap. Back in the day, I used to make all of my programs in 2 parts: a graphic loader which would automatically load the second and main program.
I used the 828 - 1029 space many times in my early programming days. I made a rather inefficient card game where I stored the deck in that area of memory. Later I used it to store data for a maze game.
But I totally agree with carlsson. After I got the programmers ref guide, I scanned the memory map (my FAVORITE section of any book ever!) and found the empty block at the 600 level!
I would use both if I need the space, but I like the idea of having the empty space with no conflicts. Even with a tape version of my game, I wouldn't need to worry about overlap. Back in the day, I used to make all of my programs in 2 parts: a graphic loader which would automatically load the second and main program.
Actually a lot of tape-based VIC games consists of a short Basic program which installs a loader at address 673 which then is SYS:ed to and continuing to load the rest of the program. Sometimes the loader was put directly into the tape buffer as the first loader program was loaded, and I believe it can be made to autostart from there.
Anders Carlsson
Yep, but Imagine, Mastertronic, Bug-Byte and all the others didn't have access to something like PuCrunch. Their unexpanded games mainly are single filed, but so large that it occupies screen memory and there is no room for a Basic stub, so they had to make a loader. After crunching, they typically fit including a SYS statement into 3.5K.
Anders Carlsson
Please explain... give us an example. Wouldn't the note values need to start in data statements to be "loaded" into that section of memory?aneurysm wrote:I came up with an algorithm that generates the note values to that memory area. In the end I think it saved over 100 bytes instead of using Data statements.
Theoretically, frequencies of musical notes follow a mathematical structure involving the 12th root etc. After assuming the frequencies put out by the VIC chip follows the mathematical formula, one could calculate the tone values and store somewhere instead of using DATA statements.
However, reality isn't always as perfect as theory. To begin with, the mathematically "correct" scale sounds out of tune to a human ear, so it needs a little tweaking. Add the quite poor resolution of the VIC frequency and you need quite some hand work to get a music scale which works for polyphonic music. I know, since I have played around with this more than I wish I had to. Sometimes it helps to transpose a piece of music into another key to get rid of the worst dis-harmonies.
However, reality isn't always as perfect as theory. To begin with, the mathematically "correct" scale sounds out of tune to a human ear, so it needs a little tweaking. Add the quite poor resolution of the VIC frequency and you need quite some hand work to get a music scale which works for polyphonic music. I know, since I have played around with this more than I wish I had to. Sometimes it helps to transpose a piece of music into another key to get rid of the worst dis-harmonies.
Anders Carlsson
Be patient... I am an idiot.
if notes were equally spaced, I could just use simple multiplication (which is what I usually do with games because I don't care about perfect tones)...
FOR T = 1 TO 7: POKE 36876, 128 + T * 5 : NEXT
but I can't figure out the spacing of notes on the vic. Is there really a logical algorithm to lay out tones?
if notes were equally spaced, I could just use simple multiplication (which is what I usually do with games because I don't care about perfect tones)...
FOR T = 1 TO 7: POKE 36876, 128 + T * 5 : NEXT
but I can't figure out the spacing of notes on the vic. Is there really a logical algorithm to lay out tones?
Code: Select all
10 P=981:V=135:C=4
12 POKEP,V:P=P+1:V=V+8:FORO=1TO3
13 FORM=1TO2:FORN=1TO2:POKEP,V:P=P+1:V=V+C:NEXTN:POKEP,V:P=P+1:V=V+C*2:NEXTM
16 FORN=1TO6:POKEP,V:P=P+1:V=V+C:NEXTN:C=C*0.5:NEXTO:POKEP,V
500 FORI=981TO1019:PRINTPEEK(I)" ";:NEXTI
V is the current frequency value
C is the increment
line 500 prints out the values from the cassette buffer to the screen
it took me a while to find the tape with this on it but it does generate all tones listed in the Programmer's Reference Guide
I'm not usre exactly how the VIC chip translates these values into actual frequencies, however. In real science higher frequencies are further apart - not closer together...
but do you see hoe much memory this saves? if you used data statements you'd still hafta load into memory somewhere on top of that