Tutankham - Copy protection or poor programming?

[kevgal]

Gday guys, I've started converting carts to single file prgs and was wondering what's up with Tutankham. It appears to use the screen memory stating at $1e00 regardless of memory expansion (so screen garbage with expansion although it is still working). Is this deliberate copy protection or just poor programming? Has anyone modified this to work regardless of expansion? How does a program know which screen memory location to use? Might be a straight forward fix?
Cheers
Kev

[groepaz]

I guess the game would simply come with instructions that tell what kind of expansion it needs (or not)

[Mike]

This is not a copy protection, and also not really poor programming.

In most cases, game cartridges are operated on their own, not alongside RAM expansions.

Some cartridge games copy a part of the KERNAL reset routine, that in this case errorneously shifts the screen if a larger RAM expansion is present. Normally this does cause no harm, as normally no extra RAM is there, see above.

[srowe]

I'm not sure you could call this poor programming, merely an assumption that seemed reasonable at the time. If the game was intended only for cartridge release then depending on the unexpanded layout was reasonable as the VIC only has a single cartridge slot and multi-slot expanders were not common.

Making the code handle either memory layout will take up precious space, either code to detect the layout or zero page to store addresses. If you want to fix it to run from RAM then it should be straightforward to modify it to use an expanded memory layout.

[Mike]

To be more specific: an autostarting cartridge needs to do some initialising of I/O and VIC as the KERNAL diverts control to the cartridge code rather early in the reset sequence.

Now if the cartridge code continues the reset sequence by calling RAMTAS ($FD8D) and there is RAM in BLK1, the screen base in $0288 will be set to $10(00). Later, a call to $E518 will set the VIC registers so the video chip reads from $1000. The game code however still assumes the screen at $1E00, and that with somewhat good reason - as I said in my preceding post, game cartridges are normally operated on their own! Of course you do not see anything if the game writes screen data at $1E00 but VIC reads from $1000 onwards.

In the thread "a BASIC game as cartridge", I actually 'hardened' the cartridge code against that situation. After RAMTAS, I force the memory allocation to unexpanded memory, see here: viewtopic.php?t=1360. The code in $A013..$A01D sets RAMBOT to $1000, RAMTOP to $1E00 and the screen base at $1E00. Then, the call JSR $E518 sets the VIC registers for a screen buffer at $1E00, even if there is a big RAM expander plugged in.

[kevgal]

Thanks guys, I guess they never planned for emulators when they originally wrote those games! Ive modified the cart so that it runs with or without expansion by loading $96 into Vic reg $9002. Seems to work (in Vice anyway).
Cheers
Kev

[Mike]

Just to put this straight:

I guess they never planned for emulators when they originally wrote those games [...]

this is not an emulation issue; you would experience the same problem if you'd operate the game and a +8K RAM expansion (or bigger) together in a cartridge extender on real hardware.

[nbla000]

We cannot consider it a copy protection simply because if you use 8k RAM expansion on BLK5 only, the game works without modifies.

In effect this "issue" is not unusual for BLK5 rom images, I've noticed it by working on the "cheated" version of a lot of cartridge games for the next Mega-Cart revision.

Normally to fix it, I've used the same method suggested by Mike.

Gday guys, I've started converting carts to single file prgs

Which kind of conversion are required?

You may find almost all cart image in PRG format on Zimmers, with 8K RAM on BLK5 just type:
LOAD"BLK5FILE",8,1
SYS64802

or use my CBM-FileBrowser.

PS: you may use also the CBM 8K Expansion by changing dipswitches inside

[chysn]

When I think of VIC-20 cartridge copy protection, it usually involves writes to Block 5 to intentionally corrupt the code, were it to be in RAM. Mostly, it underlined the fact that there's no such thing as "effective" VIC-20 copy protection.

This is simply running a game with the wrong expansion configuration and finding it to not work, which is an integral part of the VIC-20 experience.

My "copy" of Tutankham is a 2764 burned with the image from Zimmers, plugged into a Visible Solar System PCB. I just played it a couple times due to being reminded of it here. It's certainly among the best.

[Mike]

We cannot consider it a copy protection simply because if you use 8k RAM expansion on BLK5 only, the game works without modifies. [...]

kevgal copied the cartridge data from $A000..$BFFF down to $2000 and added a BASIC stub plus a small copy routine that moves the cartridge data back to $A000 and then calls the KERNAL reset routine to start the game.

In effect, kevgal tried to "onefile" the cartridge, so it can be loaded as normal BASIC program and RUN can be used to start it. Unfortunately, that method requires RAM in both BLK1 and BLK5, and without further preparations - i.e. patching the cartridge code before starting it - the RAM in BLK1 then leads to the observable mis-placed screen start, as written to the VIC register.

[srowe]

When I think of VIC-20 cartridge copy protection, it usually involves writes to Block 5 to intentionally corrupt the code, were it to be in RAM. Mostly, it underlined the fact that there's no such thing as "effective" VIC-20 copy protection.

I don't think this was really copy protection. As Andy Finkel explains somewhere it was often relied on that read-modify-write instructions could be used to save space in cartridge images.

[chysn]

When I think of VIC-20 cartridge copy protection, it usually involves writes to Block 5 to intentionally corrupt the code, were it to be in RAM. Mostly, it underlined the fact that there's no such thing as "effective" VIC-20 copy protection.

I don't think this was really copy protection. As Andy Finkel explains somewhere it was often relied on that read-modify-write instructions could be used to save space in cartridge images.

Perhaps. I always thought it was a lot of work to keep kids from playing games. But what's this read-modify-write technique that you're talking about? I'm not familiar with that.

[srowe]

Perhaps. I always thought it was a lot of work to keep kids from playing games. But what's this read-modify-write technique that you're talking about? I'm not familiar with that.

If you want to check if bit 0 of a byte you could do this

Code: Select all

LDA VALUE
LSR
BCS somewhere

but knowing VALUE is in ROM you could do

Code: Select all

LSR VALUE
BCS somewhere

and save yourself a byte. When VALUE is in RAM it works as expected the first time, but not on subsequent calls.

[groepaz]

But why would you test a value that is in ROM that way? you can just hardcode it, you already know what the MSB is

[srowe]

But why would you test a value that is in ROM that way? you can just hardcode it, you already know what the MSB is

I don't recall the actual explanation, probably it was a table and so LSR VALUE,X would have been a better example.