Tutankham - Copy protection or poor programming?
Moderator: Moderators
Tutankham - Copy protection or poor programming?
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
Cheers
Kev
Re: Tutankham - Copy protection or poor programming?
I guess the game would simply come with instructions that tell what kind of expansion it needs (or not)
I'm just a Software Guy who has no Idea how the Hardware works. Don't listen to me.
- Mike
- Herr VC
- Posts: 4849
- Joined: Wed Dec 01, 2004 1:57 pm
- Location: Munich, Germany
- Occupation: electrical engineer
Re: Tutankham - Copy protection or poor programming?
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.
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.
Re: Tutankham - Copy protection or poor programming?
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.
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
- Herr VC
- Posts: 4849
- Joined: Wed Dec 01, 2004 1:57 pm
- Location: Munich, Germany
- Occupation: electrical engineer
Re: Tutankham - Copy protection or poor programming?
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.
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.
Re: Tutankham - Copy protection or poor programming?
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
Cheers
Kev
- Attachments
-
- tutankham(mem-mod).zip
- (13.69 KiB) Downloaded 78 times
- Mike
- Herr VC
- Posts: 4849
- Joined: Wed Dec 01, 2004 1:57 pm
- Location: Munich, Germany
- Occupation: electrical engineer
Re: Tutankham - Copy protection or poor programming?
Just to put this straight:
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.kevgal wrote:I guess they never planned for emulators when they originally wrote those games [...]
Re: Tutankham - Copy protection or poor programming?
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.
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
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.
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
Mega-Cart: the cartridge you plug in once and for all.
- chysn
- Vic 20 Scientist
- Posts: 1205
- Joined: Tue Oct 22, 2019 12:36 pm
- Website: http://www.beigemaze.com
- Location: Michigan, USA
- Occupation: Software Dev Manager
Re: Tutankham - Copy protection or poor programming?
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.
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.
VIC-20 Projects: wAx Assembler, TRBo: Turtle RescueBot, Helix Colony, Sub Med, Trolley Problem, Dungeon of Dance, ZEPTOPOLIS, MIDI KERNAL, The Archivist, Ed for Prophet-5
WIP: MIDIcast BASIC extension
he/him/his
WIP: MIDIcast BASIC extension
he/him/his
- Mike
- Herr VC
- Posts: 4849
- Joined: Wed Dec 01, 2004 1:57 pm
- Location: Munich, Germany
- Occupation: electrical engineer
Re: Tutankham - Copy protection or poor programming?
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.nbla000 wrote: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, 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.
Re: Tutankham - Copy protection or poor programming?
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
- Vic 20 Scientist
- Posts: 1205
- Joined: Tue Oct 22, 2019 12:36 pm
- Website: http://www.beigemaze.com
- Location: Michigan, USA
- Occupation: Software Dev Manager
Re: Tutankham - Copy protection or poor programming?
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.
Re: Tutankham - Copy protection or poor programming?
If you want to check if bit 0 of a byte you could do this
Code: Select all
LDA VALUE
LSR
BCS somewhere
Code: Select all
LSR VALUE
BCS somewhere
Re: Tutankham - Copy protection or poor programming?
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'm just a Software Guy who has no Idea how the Hardware works. Don't listen to me.