Problem when using 673 memory address

[Lechuck]

Sorry if this is a silly question but I really cannot understand it....

I'm trying to use available memory after 673 and, for some reason, it works if I only use that memory, but it doesn't when I try to combine with other memory areas. For example, working with CBM, I can do:

* = 673
LDA #1
STA 7680
RTS

And works OK. However, if I try:
* = 673
LDA #1
STA 7680
RTS

* = 4100
LDA #2
STA 7681
RTS

I cannot even load the .PRG (it keeps with the 'LOADING' message). Is there a reason why I cannot use, at the same time, memory at 673 combined with other memory areas? If I try the same with, for example, 828 and 4100, it works OK. It also works, with 673, if I create the BASIC loader and run it.

Thanks

[chysn]

(Note: I rewrote this post in an attempt to make it more clear)

The VIC-20's KERNAL doesn't have any way to place a single file in non-contiguous regions of memory. In other words, there's no facility to load part of a file to 673 and then skip ahead and put something in 4100. So your cross-assembler is likely padding the area from 679 to 4100 with zeroes, in order to position the code at 4100.

However, the VIC-20 uses many locations in the $0300 page for BASIC. So when you load that file starting at 673, the file will eventually start filling important addresses with 0, the operation of BASIC will be corrupted, and that's why the computer is locking up during the load.

When you instead use 828, the only thing after that is RAM expansion area and BASIC RAM; nothing's there to be corrupted, so your load will be successful.

But, you're still loading a much larger file than you probably want. If you want to place two programs in non-contiguous areas of memory, you should use two separate files.

[Lechuck]

(Note: I rewrote this post in an attempt to make it more clear)

The VIC-20's KERNAL doesn't have any way to place a single file in non-contiguous regions of memory. In other words, there's no facility to load part of a file to 673 and then skip ahead and put something in 4100. So your cross-assembler is likely padding the area from 679 to 4100 with zeroes, in order to position the code at 4100.

However, the VIC-20 uses many locations in the $0300 page for BASIC. So when you load that file starting at 673, the file will eventually start filling important addresses with 0, the operation of BASIC will be corrupted, and that's why the computer is locking up during the load.

When you instead use 828, the only thing after that is RAM expansion area and BASIC RAM; nothing's there to be corrupted, so your load will be successful.

But, you're still loading a much larger file than you probably want. If you want to place two programs in non-contiguous areas of memory, you should use two separate files.

Thanks a lot for the explanation!.

When you say two different files I assume you refer to two different .prg files, right? (I already tried using two different .asm files but, after ‘compiling’ them, I got same result.

Thanks again

[chysn]

When you say two different files I assume you refer to two different .prg files, right?

That's right:

• One PRG file has the header a102 (which LOAD,device,1 will put at 673)
• The other PRG file has the header 0410 (which LOAD,device,1 will put at 4100)

What assembler are you using?

[Lechuck]

When you say two different files I assume you refer to two different .prg files, right?

That's right:

• One PRG file has the header a102 (which LOAD,device,1 will put at 673)
• The other PRG file has the header 0410 (which LOAD,device,1 will put at 4100)

What assembler are you using?

Thanks a lot! Will give it a try.

I’m using CBM PRG Studio.

Cheers

[Mike]

• One PRG file has the header a102 (which LOAD,device,1 will put at 673)
• The other PRG file has the header 0410 (which LOAD,device,1 will put at 4100)

For clarity, those are the header bytes $A1 $02 and $04 $10, respectively. The 65xx is a little-endian machine, but that only affects the byte order in memory, not the value itself. Please don't quote 16-bit values with the byte halfs swapped around.

Other than that, any decent assembler should provide a way to write out either a PRG file with included load address, or a "raw" BIN file without load address. The former is what you want for KERNAL load operations, the latter is more convenient when a file is supposed to be burned on EPROM on PC.

However, the VIC-20 uses many locations in the $0300 page for BASIC.

... and for the KERNAL vectors! When those are thrashed during the load operation, it locks up the VIC-20 already there.

[Lechuck]

For clarity, those are the header bytes $A1 $02 and $04 $10, respectively. The 65xx is a little-endian machine, but that only affects the byte order in memory, not the value itself. Please don't quote 16-bit values with the byte halfs swapped around.

Thanks Mike, understood.

Other than that, any decent assembler should provide a way to write out either a PRG file with included load address, or a "raw" BIN file without load address. The former is what you want for KERNAL load operations, the latter is more convenient when a file is supposed to be burned on EPROM on PC.

Yes, I understand CBM PRG Studio is correctly defining the loading address for the .PRG (it worked perfectly OK until I tried to use those memory addresses starting at 673).

My mistake was not to realize that, since the PRG is only including one load address, it has to do something to fill in the gaps when using different address locations for the code.

Cheers

[Lechuck]

Just tried with two .PRG files and works like a charm.

Thanks a lot for your explanations

Cheers