Why do 8K+ programs relocate their code?

[D-Type]

First time poster!

I've been disassembling some old game code from a prg file for the VIC with 8K+ RAM expansion and the first thing the code does is relocate the main program to $2000 from it's initial position straight after the BASIC loader.

I asked this question why on another forum and the answer given was that you can then put custom character sets in it's place.

But it's not clear to me why would you want to do that, why wouldn't you leave the code where it is and put the character set data somewhere else in RAM?

Can anyone explain the reasoning behind it?

Warning: I'm a VIC-20 newbie, last time I had a VIC-20 was the early 80s, instead I've been hacking 6809 Forth on Vectrex for a few years.

[beamrider]

The character set has to be located in Vic internal RAM otherwise the Vic chip can't see it.

[Mike]

You often see that relocation procedure with (BASIC) programs that need +8K RAM or more and do user defined graphics, but it is not strictly necessary. For machine code programs, it is quite easy to incorporate the character data at a place where the video chip can "see" it (as beamrider writes, it needs to be placed in the address ranges of internal RAM), and arrange the remainder of code and data around that.

The text of BASIC programs though needs to be in one piece, and you can't simply drop a character set 'inside' it. With a bigger RAM expansion, the only sensible procedure is to put the character set (and screen) at a lower address than the BASIC program text, and this is done by raising the BASIC start address. It is not necessary though to use a boot loader for this, this procedure can be one-filed. See here: Load Charset Direct to Correct Memory Location.

Greetings,

Michael

P.S. Oh, and welcome to Denial!

[D-Type]

Thanks for the welcome and replies, guys. So the VIC can only see UDGs characters somewhere between $1000 and $1fff?

The program I'm disassembling copies roughly 8k from just after $1200 to $2000. It has UDG characters at the top of that block. I presume it will then have to copy the UDGs back to between $1000 and $1fff so the VIC can see them. That sounds a bit wasteful of RAM.

I'm left wondering why they didn't assemble it in the first place with the UDGs already in the $1000 block and start the code either straight afterwards or at $2000. Maybe it's faster to load a single block with no gaps in it and then relocate when loaded?

[srowe]

Thanks for the welcome and replies, guys. So the VIC can only see UDGs characters somewhere between $1000 and $1fff?

Strictly speaking it can also see $0000-$03ff, but that's not a configuration you could use from BASIC.

[Mike]

[...] I presume [the program] will then have to copy the UDGs back to between $1000 and $1fff so the VIC can see them. That sounds a bit wasteful of RAM. [...]

Edit: I see it's JetPac you're having a look at.

The original likely loads directly to $2000. Someone else put a BASIC stub in front of it, so the "cracked" copy need not be loaded with ",8,1" and started with a difficult to remember SYS xxxx - rather a load with ",8" and RUN suffice.

[D-Type]

The original likely loads directly to $2000. Someone else put a BASIC stub in front of it, so the "cracked" copy need not be loaded with ",8,1" and started with a difficult to remember SYS xxxx - rather a load with ",8" and RUN suffice.

(Yes, I'm disassembling JETPAC.)

OK, I guess that could certainly be true. Having learned the (very simple) structure of a PRG file, I assumed that loading from a cassette tape would put data into memory in the same way as it's laid out in the PRG file and would then auto-run.

I don't remember any SYS requried when I loaded it from tape, but given it's best part of 40 years since I last did so, I might not remember all the detail!

I'll have to take a look at the circuit diagram to understand why the VIC can see what it can see, but for now, I'll just accept it as-is

Thanks again for your thoughts.

[Mike]

Having learned the (very simple) structure of a PRG file, I assumed that loading from a cassette tape would put data into memory in the same way as it's laid out in the PRG file and would then auto-run.

A simple *.prg file does not at all preserve the full details on what happens on a tape load!

Not only is the payload written to (BASIC) RAM, but there's also the tape buffer which is affected. As a side effect, the tape buffer holds some information (type of tape data, start address, end(!) address, file name) relevant for the KERNAL tape routines, but it can also be crafted to contain extra data. This is easily missed when copying the payload to disk, and can even serve as somewhat effective copy protection.

I don't remember any SYS [required] when I loaded it from tape, [...]

Tape originals often featured a forced autostart, the tape buffer playing an important role in this.

Starting with SYS would only be required with a bad crack, i.e. just the memory dump of the payload as *.prg file (and by lucky chance the tape buffer was not referenced later for the aforementioned copy protection).

You find an example of a successful tape-to-disk transfer - where it was necessary to retain the tape buffer contents - somewhere else here in Denial: Tips for Reverse Engineering a Cassette Program.

I'll have to take a look at the circuit diagram to understand why the VIC can see what it can see [...]

The 6502 in the VIC-20 cannot tri-state its address bus, therefore the address (and data) bus are split into a "VIC side" and a "CPU side" while the VIC is supposed to access memory. Internal RAM and character ROM are on the VIC side; KERNAL and BASIC ROM and everything on the cartridge port are on the CPU side. The two VIAs and the colour RAM take an extra role in that context, but that need not concern us here.

Even though there exist register values for $9005 that suggest it ought be possible to set either text screen or character definitions into the range $0400..$0FFF, this just doesn't work. An external +3K RAM expansion is on the wrong side of the '245 bus buffers that split the address and data bus.

[D-Type]

Thanks for the informative explanation. For the disssembly I'm doing, I guess it's not critical to know, but certainly interesting! I'll no doubt learn more as I delve into the code.