For *.prg files, the load address is part of the file (a two-byte header).
This is an adopted convention from the KERNAL LOAD and SAVE calls.
The load address does not appear in memory - at least not at a position 'near' the memory dump. A KERNAL SAVE call puts the load address in front of the memory dump, so there's an easy way to find out where to put back that memory dump, for KERNAL LOAD. You can instruct KERNAL LOAD to re-instate the file data (sans load address) at either the original address (that's called an 'absolute' load) or force it to load the data to another address (again, sans load address) - that's then called 'relative' or 'relocating' load. The latter, relative load, is used by BASIC to load a BASIC programm to the current BASIC start, rather than to the original address it was saved from.
Please refer to my post in the pinned thread '
ROM call & other tricks' here in the Programming section.
...
Now what you have is - some data from an essentially unspecified source, that you've managed to be mapped into the range $A000..$BFFF. If this was from a *.bin file (without load address), the information where the file really should be located is lost.
If your hardware actually maps in the complete *.prg file, including load address, then of course the addresses $A000 and $A001 contain this load address. The information still missing is the length of file, and that's not as unimportant as you might think: if you save an over-length BASIC program away, a memory range behind the BASIC program will not be available for the storage of variables. This can easily lead to an ?OUT OF MEMORY error, even if the program as such fits into memory, because it hasn't anymore enough memory for its variables! Also, you won't ever be able to store away a complete 8K block as *.prg file.
Neither is 'just' moving away the program to another range, and then doing a SAVE"...",8,1 going to help you. The SAVE command has no information, that there has been new data re-instated by some POKE loop somewhere in memory. It will just save away an empty BASIC program or the current program in memory, provided it wasn't overwritten by that copy action.
Suppose you want to use BLK5 as scratch board, filled by PC and stored away by VIC-20: to write *.prg files to disk, you'll need to add an extra step to the protocol, providing the file length and load address independently and then construct a correct *.prg on the CBM disk drive roughly as follows:
Code: Select all
10 <instruct your hardware to map in the file length in $A000/$A001 *excluding* this 2-byte-header>
11 L=PEEK(40960)+256*PEEK(40961)
12 <instruct your hardware to map in the first two bytes of the file in $A000/$A001>
13 A=PEEK(40960):B=PEEK(40961)
14 OPEN2,8,2,"FILE.PRG,P,W":PRINT#2,CHR$(A)CHR$(B);
15 FOR T=0 TO L-1 STEP 8192:S=0
16 <instruct your hardware to map in the next 8K block of the file>
17 IF S+T<L AND S<8192 THEN PRINT#2,CHR$(PEEK(40960+S));:S=S+1:GOTO17
18 NEXT
19 CLOSE2
... or something like this.
![Smile :)](./images/smilies/icon_smile.gif)