Stupid game code that works by coincidence

[StingRay]

Since I just saw an incredibly buggy piece of code that worked by pure luck I decided to create this thread. I'm sure most coders here have seen some similar crappy code. So share your findings for some amusement.

I'll begin with this "nice" code found in the game "The Ultimate Pinball Quest".

; called after a key was pressed

		st $c8cc		; -> quitflag
quitflag	dc.b	0
someotherflag	dc.b	0
		tst.b	$c8cc		; -> tst.b quitflag
		beq.b	.noquit
		....

This crap only works because the coder seems to be an incredibly lucky guy... Have fun trying to figure out why it works.

[Leffmann]

I think it'll see an or.b (op-code $0000) right after the st because of the instruction prefetch, so the instruction stream is going to look something like this:

st    $c8cc
or.b  #something, d0
or.b  #$cc, d0
beq   noquit    ; this branch never taken
...

[Galahad/FLT]

Terminator 2 Arcade Game

Just had a quick look at it, and it appears to be a track buffer location error, with an undisclosed bug in the RNC Sector loader.

1). Game boot code is loaded, and then relocates sector loader and bootcode at $70000
2). program code at $7098a is executed.
3). Game reads disk root table at address $800
4). Game then loads T2 picture and other code at $71a00

Problem is caused by trackbuffer set too low at $78000. Sector start is $57D, Sectors to read is $38. $38*$200= $7000 length of data to read.

Take your base address of $71a00 and add $7000 and you get $78a00.

The game is attempting to read data OVER the start of the trackbuffer data.

Because of a bug in the RNC sector loader, sometimes it just happens to decode correctly, mostly it doesn't.

So, simply setting the trackbuffer base address to $7a000 instead means it will boot up correctly every time.

Not a protection error or Copylock related, simply programmer stupidity, and we've seen that lots of times!

Game doesn't crash, but, it could so easily have done as the programmer and game testers missed this bug.

[Codetapper]

In the Kiwi Crap demo by Reality, there is an exploding text routine near the start that completely locks up and crashes my Amiga 1200, but presumably this code works on some Amigas.

The coder Shayde must have decided that it's far more efficient to start a blit by loading an address register with $dff058 and then moving a data register into it. Since all address registers were used, he saved the stack, set the stack to $dff058 and then proceeded to start multiple blits (without any blitter waits). A complete unrecoverable crash was the result on almost every machine I tested it on.

But by luck it must work on some slow Amiga's or something! (Possibly due to interrupts?)

[Galahad/FLT]

Fire n Brimstone, has a colour routine that is nonsense.

lea $dff180,a0
moveq #32-1,d0
all_black:
clr.l (a0)+
dbra d0,all_black

lea $dff180,a0
lea pallete,a1
moveq #32-1,d0
do_colours:
move.l (a1)+,(a0)+
dbra d0,do_colours


See if you can spot the two obvious errors!

[Codetapper]

I assume it's the fact that the colour registers are word values not longwords, so you'd be trashing $dff180-$dff200 which would cause some bizarre effects!

[StingRay]

Originally Posted by Leffmann

I think it'll see an or.b (op-code $0000) right after the st because of the instruction prefetch, so the instruction stream is going to look something like this:

st    $c8cc
or.b  #something, d0
or.b  #$cc, d0
beq   noquit    ; this branch never taken
...

Almost. or.b #x,dx is a 4 byte instruction so the first word of the tst.b $c8cc instruction that follows after the dc.b 0,0 is used too. tst.b "mem" opcode is $4a39, since or.b uses bytes only the first byte of the $4a39 opcode isn't used thus the next instruction is:

or.b #$39,d0

The instruction that follows is or.b #$cc,d0 (first word of the mem location = 0 = or.b #x,dx, then the mem location follows ($c8cc), first byte is skipped as before = or.b #$cc,d0).

And the branch is indeed never taken but it doesn't matter because this code is only called after a key was pressed and is supposed to quit then. Which works. But not in the way the coder wanted it.

Originally Posted by Codetapper

The coder Shayde must have decided that it's far more efficient to start a blit by loading an address register with $dff058 and then moving a data register into it. Since all address registers were used, he saved the stack, set the stack to $dff058 and then proceeded to start multiple blits (without any blitter waits). A complete unrecoverable crash was the result on almost every machine I tested it on.

I had a quick look at the code and there's no problem doing things like this as long as interrupts are disabled or no interrupt can occur while the routine is running. He waits for the vblank before he starts the text routine and the routine is running in 1 frame => no problem!
Things like this were often done when speed was important, it's quite a usual trick actually.

This routine will only lock up when it needs more than 1 frame as then a level 3 interrupt will occur which is, of course, not exactly good as the stack is not correct.

And there are blitter waits in that very routine btw, at least in the version of the demo that I just checked.

[Leffmann]

Yeah that's what I meant with the "something", the lower byte of the tst.b abs.l op-code, I just haven't memorized the exact value. The code looks so odd I think he must've been rewriting it and quit for the day and just forgot about it the next day since it worked by a fluke.

BTW it has to be something else that causes the Kiwi Crap Demo to crash, because when any type of exception occurs the CPU always switches stacks first before writing the stack frame, so using A7 as a GPR while interrupts trigger is never a problem, the user stack and pointer will always be untouched.

[Keir]

Originally Posted by Leffmann

BTW it has to be something else that causes the Kiwi Crap Demo to crash, because when any type of exception occurs the CPU always switches stacks first before writing the stack frame, so using A7 as a GPR while interrupts trigger is never a problem, the user stack and pointer will always be untouched.

Most games and demos run permanently in supervisor mode?

[Leffmann]

I haven't looked inside a lot of games or demos, but I can't imagine there are many that do.

[StingRay]

I don't know about Kiwi Crap and can't be bothered to check now but many (mostly older) demos and games switch to supervisor mode. Most of them just use a simple trap instruction for that, e.g.

lea main(pc),a0
move.l a0,$80.w
trap #0

Main will run in supervisor mode then.

[DrCinicus]

I'm working on a slave for Wild Copper Megademo and I found this trick, used by the coder to enter in supervisor mode:

        move.l  #MyDemo,12
        move.l  #1,1
        or.w    #34,d0
MyDemo:
        Demo code here

        Wait Mouse Button
Exit:   and.w   #$dfff,SR
        rts

This code will work on 68000, but on 68020+ you have two problem:
1 - The long write to an odd address is legal, so there is no address error and the processor works in user mode, then the write to SR makes a privileged violation.
2 - The write to address 1 will write value 1 to the byte at address 4, so any move.l 4.w,a6 points to an invalid address.

Bye
Fabio

[TheDarkCoder]

Also, on 68010+, VBR can point to an address different form 0, so it may be that address 12 does not contain the vector for illegal instruction exception

[Photon]

Originally Posted by StingRay

Have fun trying to figure out why it works.

5 second guess... condition code before the st instruction is always false?

In all versions of Gravity-Force, when entering a name on the high-score list will guru on all kickstarts except 1.2 (and 1.3?). But if you're very quick to start another game, it aborts something to do with trackdisk.device and doesn't guru.

[IFW]

It's been a while... but I think Spaceport had a wrong protection check, that only ever worked because the check for the result was also incorrect

[Mrs Beanbag]

I think I just found one in Mr Beanbag!

I only discovered it because someone informed me it crashed in UAE whenever they pressed a key.

The keyboard handler code was polling VHPOSR to wait for a short while after reading the keyboard (as you're supposed to). Or so I thought. I just got round to looking at it. It wasn't polling VHPOSR ($DFF006) at all, but BLTDDAT ($DFF000)! Which, according to my hardware book, "returns a somewhat random number". So presumably on a real Amiga it waits for some random time (which usually works), but on UAE I guess reading $DFF000 always returns zero or something, so it would get stuck in an infinite loop.

Anyone know the actual behaviour of reading from BLTDDAT?

[spud]

Most of my code works by pure chance. Watching me code something in 68K asm is like sticking a type-writer in front of a group of monkeys and asking them to write Shakespeare.

[DDNI]

This is one of those threads that make feel stoooopid!

[CFou!]

in my memory for old 68000 games as Double Dragon 2, coder used for DMA registers by example:
- FFF180, EFF180 or DFF380 for DFF180 !!

it's no really stupid code because i suppose coder want hid real code to crackers

but on 68020 and higher, that crashed

;--------------------------
a little game now:

in futur Ghosts'n gobblins trainer i use following lines of code:

Clr.l (a0)
.enc
cmp.l #25,(a0)
blo .enc

is it a stupid code ?

[StingRay]

Originally Posted by CFOU!

in my memory for old 68000 games as Double Dragon 2, coder used for DMA registers by example:
- FFF180, EFF180 or DFF380 for DFF180 !!

it's no really stupid code because i suppose coder want hid real code to crackers

In the game Dugger any access to the custom registers was disguised like this too. Not much of a protection IMHO since any half-decent coder/cracker knows what's going on anyway.

Originally Posted by CFOU!

a little game now:

in futur Ghosts'n gobblins trainer i use following lines of code:

Clr.l (a0)
.enc
cmp.l #25,(a0)
blo .enc

is it a stupid code ?

Not necessarily since what a0 points to can be modified in the vertical blank for example. Let me guess, this is a delay loop?