How I went about defeating the tape version of Rubicon

Removing anti-disk-transfer protections

In order to make a version of Rubicon that runs off two disks, I had to remove built-in protections designed to make things go horribly wrong unless the game is specifically loaded from tape and by its original loader.

Rubicon load picture

Rubicon title screen

Protection #1

$dc0c is set to 0xd0 within the “Cyberload F3” loader (after a sync byte is read in from tape):

*=$fa64
	lda #$d0
	sta $dc0c

When any level starts, if $dc0c is not 0xd0 then the play area is littered with spurious chars.

Disable protection: set $dc0d to 0xd0 as early as possible and certainly before Level 1 starts.

Protection #2

At Level 1 $2f95 is set to the value at $01 as per below:

*=$1765
	iny		; Y=1 now
	lda ($07),y	; $07/$08 = 0x0000
	sta $29f4,y

If the game is loaded from tape, when Level 1 starts the datasette play button is still pressed, hence bit 4 at $01 will be clear, so that $01 will hold 0x25. If the game is not loaded from tape, then $01 will hold 0x35, which enables unlimited energy for the green dragon, making it impossible to complete this level.

Disable protection: replace instruction at $1766 with “lda #$25”.

Protection #3

Before loading upper levels, $1507 is set to the value at $01 as per below:

*=$0b41
	lda $fffa,x	; X=7 now
	sta $1500,x
	dex
	bpl $0b41

Again, when a value other than 0x25 is found there, the protection kicks in after the level is loaded, during the gameplay.
As example, at Level 2 the game crashes when the trap is about to be detected.

Disable protection: At $0b30 there’s some code to wait for the play button to be pressed on the C2N. This code can be removed for a disk version and the subsequent code can be shifted up to $0b30. The shifting leaves enough room to add the following code just after the above block:

*=$0b44
	lda #$25
	sta $1507
	nop

SW sprite fixing

When the game is over, the “Software” sprite bitmap is not reset to show that no parts were collected.
However, upon game over, the tape version of the game shows a message that requests rewinding to the beginning of Side B as per below:

	ldx #$1b
b0f54	lda $0f6f,x
	sta $cd19,x
	lda #$0f
	sta $d919,x
	dex
	bpl b0f54

	lda $dc00
	and #$10
	bne *-5

After the game is transferred to disk, such message is not relevant any longer, and can be replaced with:

	ldx #$3f
	lda #$00
	sta $bfff,x
	dex
	bne *-4

The above code correctly re-initializes the sprite, ready for playing again from Level 1.

Also, at the beginning of Level 4 there’s some code that is supposed to set the overall “Software” sprite bitmap (so that it shows three parts were collected) as it happens at Level 2 and Level 3 (where the sprite is set for 1 and 2 parts respectively). However, the code is just not quite right:

	ldx #$0b
b2446	lda $1b30,x
	sta $c00f,x
	dex
	bne b2446

The side-effect of the above code is not visible as the sprite bitmap is already in a suitable state, unless a level skipper trainer was used to skip part of Level 3 before the third software upgrade was taken.
When a level skipper trainer is installed, the above code has to be changed to:

	ldx #$1b
b2446	lda $aaf5,x
	sta $bfff,x
	dex
	bne b2446

Finally, if a level skipper is used to skip from Level 4 to Level 5 before the last part of the software upgrade is taken, in Level 5 there’s no code that adds the missing part to the sprite bitmap. So the level skipper has to do the work when skipping part of Level 4:

	ldx #$0b	; Complete the sw sprite bitmap at Level 4 before skipping to level 5
_sprcp	lda $1b3b,x
	sta $c00f,x
	dex
	bne _sprcp

That’s all for now. Enjoy this release and don’t forget that it loads at ultra-fast speed if you disable true drive emulation in VICE 🙂