memory locations used by disk loading

[jdxpolygon]

Hey guys, something I was wondering about today. Which memory locations on the unexpanded VIC-20 are needed/affected when using the kernel to load a prg from disk? And does their state going into the load function matter?

Thanks

[Mike]

Which memory locations on the unexpanded VIC-20 are needed/affected when using the kernel to load a prg from disk?

Several zeropage locations are affected, see here: http://unusedino.de/ec64/technical/aay/c64/zpmain.htm

And does their state going into the load function matter?

As long as you don't mess around with them, and use the KERNAL jump table, no. The routines SETNAM, SETLFS and LOAD take care to set everything up correctly, so for the most part it isn't necessary to poke zeropage locations directly.

[jdxpolygon]

Thanks Mike So nothing is needed in the $0200-$03FF area, I could continue to store some data there?

[Mike]

Of course KERNAL and BASIC also occupy workspace in the $0200 to $0300, which you can easily infer from the link! Some of the bytes there are taken, for example, to keep the tables of open files, etc. And you surely don't want to trash the vectors (including but not restricted to those beginning at $0300) without good reason.

Without you giving out details about what you're really after, it's really difficult to assess what memory you can use in the $0000 to $03FF area without problems.

If you are really asking about 'free' zeropage addresses:

- $FB .. $FE are completely uncommitted by BASIC and KERNAL,
- $03 .. $06 contain pointers which are not used by the OS, and are essentially also free.

There are lots of ZP addresses which are used and/or shared between RS232 and tape operations. As long as neither of these two are active, you can store values and pointers there. These are $96, $9B, $9C, $9E, $9F, $A3..$A5, $A7..$AB, $B4..$B6, $BD, $BE, $F7..$FA - for my own programs I usually allocate these beginning from the end of the list. As an RS232 or tape operation is started, the locations are reset to sensible values by the OS, and your own values are overwritten ($F7..$FA contain pointers to the RS232 buffers and should be reset to their old values by your own program when a RS232 channel is opened).

If you are really asking about 'free' addresses for larger buffers, in the system area:

- 673 .. 767 are unused by the OS (some cartridges, notably Super Expander, use that area though),
- 828 .. 1023 is the tape buffer and can be used as long as there are no tape operations active.

When you use any memory location in an interrupt routine and don't temporarily store its contents away on the stack, don't forget that this location then is effectively 'spoilt' for the main program in the foreground, as its contents can change without the main program having any clue about this. So you should be wary about this, unless that location is explicitly intended for communication between the interrupt routine and the main program.

Finally, all these considerations only simply apply in that way when starting from a 'fresh' machine. When there is already another program active, be it another interrupt service routine, or a BASIC extension, or a drive speeder (... you get the idea) that program will probably require its own share of those otherwise free memory areas, too.

[jdxpolygon]

Thanks for the extended info Mike. I appreciate I didn't say much about what I was wanting to do or why. I have a machine code game that already uses most of the zero page, and pretty much all of $0200-$02FF as data, and the cassette buffer wherever it is in the $03 page as a variable area. I know BASIC and Kernel routines use those memory areas, the game wasn't utilizing either of those. I was looking at the possibility of changing the game so that it could load new sets of data from disk using the Kernel routine, which is why I was wondering which of these areas I could no longer use for contiguous data. It's occurred to me since then that I could actually avoid the need for most of that data if it can be loaded directly from disk. Having said that, it would be good to have more memory available for code.

[Mike]

Having said that, it would be good to have more memory available for code.

There's a simple remedy for this: just spend your VIC-20 a RAM expansion.

I'm serious.

Really... I suppose there are a lot of unfinished games for the VIC-20 just because the programmer made a knot in his brain how to cram everything into unexpanded memory.

...and: it's really an artificial limit. There had been RAM expansions available at that time.

[jdxpolygon]

Having said that, it would be good to have more memory available for code.

There's a simple remedy for this: just spend your VIC-20 a RAM expansion.

I'm serious.

I think that's down to the individual really. I never owned a VIC-20 in its time (it's older than I am) and the one I do own now is pretty much unusable at this point, so I only use emulators. Which does make memory expansion free, but like I said, making a game on VIC-20 appeals to different people for different reasons, I'm sure I've seen it debated on here before. For me it's the challenge of what can be produced from the original spec.

Really... I suppose there are a lot of unfinished games for the VIC-20 just because the programmer made a knot in his brain how to cram everything into unexpanded memory.

My game isn't actually unfinished:
http://www.psytronik.net/main/index.php ... &Itemid=59

But it's coming out on the C64 soon and I was investigating the possibility of an updated VIC-20 version to go alongside it on the disk.

[Mike]

I think that's down to the individual really. [...], making a game on VIC-20 appeals to different people for different reasons, I'm sure I've seen it debated on here before.

I can tell you: in that time, the people I knew who also owned a VIC-20 first got the datasette, and then a +3K and then maybe a bigger RAM expander - before spending any thought about a disk drive. Which means, the combination of VIC-20 + disk-drive *without* RAM expansion was *extremely* uncommon. If anything, the disk drive was bought alongside or shortly after obtaining a C64.

For me it's the challenge of what can be produced from the original spec.

Nothing wrong with that. But for me, that restriction makes a certain class of programs, if not downright impossible, but at least unfeasible to implement on the VIC-20: namely those which use most of the internal RAM to hold 'live' graphics data. You can still pull off some tricks, see the intro picture of my games collection for the unexpanded VIC-20, where a MINIGRAFIK picture is being shown - something, which would 'normally' require a RAM expansion -, but I did it just to show it can be done. It's not even possible to keep the picture on display while the menu is being loaded.