using the cassette buffer to store data

Basic and Machine Language

Moderator: Moderators

vic user
VicGyver
Posts: 1401
Joined: Thu Mar 25, 2004 9:40 am

using the cassette buffer to store data

Post by vic user »

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
vic user
VicGyver
Posts: 1401
Joined: Thu Mar 25, 2004 9:40 am

Post by vic user »

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
vic user
VicGyver
Posts: 1401
Joined: Thu Mar 25, 2004 9:40 am

Post by vic user »

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
carlsson
Class of '6502
Posts: 5516
Joined: Wed Mar 10, 2004 1:41 am

Post by carlsson »

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.
Anders Carlsson

Image Image Image Image Image
User avatar
Jeff-20
Denial Founder
Posts: 5759
Joined: Wed Dec 31, 1969 6:00 pm

Post by Jeff-20 »

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.
High Scores, Links, and Jeff's Basic Games page.
carlsson
Class of '6502
Posts: 5516
Joined: Wed Mar 10, 2004 1:41 am

Post by carlsson »

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

Image Image Image Image Image
User avatar
Jeff-20
Denial Founder
Posts: 5759
Joined: Wed Dec 31, 1969 6:00 pm

Post by Jeff-20 »

See, I have come to dislike mutli-load programs. I used to like the Compute games presented in 2 programs, but I am more impressed by anything that can be done in one program.
High Scores, Links, and Jeff's Basic Games page.
carlsson
Class of '6502
Posts: 5516
Joined: Wed Mar 10, 2004 1:41 am

Post by carlsson »

Yep, but Imagine, Mastertronic, Bug-Byte and all the others didn't have access to something like PuCrunch. :lol: 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

Image Image Image Image Image
vic user
VicGyver
Posts: 1401
Joined: Thu Mar 25, 2004 9:40 am

Post by vic user »

Thanks.

I had no idea of the empty slot on 673-767 ($02A1-$02FF).

Chris[/quote]
aneurysm
not your PAL
Posts: 178
Joined: Sat Mar 06, 2004 11:06 pm

Post by aneurysm »

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.
User avatar
Jeff-20
Denial Founder
Posts: 5759
Joined: Wed Dec 31, 1969 6:00 pm

Post by Jeff-20 »

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.
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?
High Scores, Links, and Jeff's Basic Games page.
carlsson
Class of '6502
Posts: 5516
Joined: Wed Mar 10, 2004 1:41 am

Post by carlsson »

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.
Anders Carlsson

Image Image Image Image Image
User avatar
Jeff-20
Denial Founder
Posts: 5759
Joined: Wed Dec 31, 1969 6:00 pm

Post by Jeff-20 »

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?
High Scores, Links, and Jeff's Basic Games page.
aneurysm
not your PAL
Posts: 178
Joined: Sat Mar 06, 2004 11:06 pm

Post by aneurysm »

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
P is pointer in the cassette buffer
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 :lol: :shock:
vic user
VicGyver
Posts: 1401
Joined: Thu Mar 25, 2004 9:40 am

Post by vic user »

That will be a quickie to type in.

I am just starting to clue in to how much memory you can save by poking and peeking values instead of using variables all the time.

Chris
Post Reply