31 July 2012, 20:07 | #1 |
move.l #$c0ff33,throat
Join Date: Dec 2005
Location: Berlin/Joymoney
Posts: 6,865
|
Stupid game code that works by coincidence
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". Code:
; 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 .... Last edited by StingRay; 31 July 2012 at 20:13. Reason: typo |
31 July 2012, 21:49 | #2 |
Join Date: Jul 2008
Location: Sweden
Posts: 2,269
|
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:
Code:
st $c8cc or.b #something, d0 or.b #$cc, d0 beq noquit ; this branch never taken ... |
01 August 2012, 01:18 | #3 |
Going nowhere
Join Date: Oct 2001
Location: United Kingdom
Age: 50
Posts: 9,018
|
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. |
01 August 2012, 04:22 | #4 |
2 contact me: email only!
Join Date: May 2001
Location: Auckland / New Zealand
Posts: 3,187
|
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?) |
01 August 2012, 10:35 | #5 |
Going nowhere
Join Date: Oct 2001
Location: United Kingdom
Age: 50
Posts: 9,018
|
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! |
01 August 2012, 11:11 | #6 |
2 contact me: email only!
Join Date: May 2001
Location: Auckland / New Zealand
Posts: 3,187
|
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!
|
02 August 2012, 09:26 | #7 | ||
move.l #$c0ff33,throat
Join Date: Dec 2005
Location: Berlin/Joymoney
Posts: 6,865
|
Quote:
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. Quote:
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. Last edited by StingRay; 02 August 2012 at 09:33. Reason: typo |
||
03 August 2012, 14:28 | #8 |
Join Date: Jul 2008
Location: Sweden
Posts: 2,269
|
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. |
05 August 2012, 09:22 | #9 | |
Registered User
Join Date: May 2011
Location: Cambridge
Posts: 682
|
Quote:
|
|
05 August 2012, 18:17 | #10 |
Join Date: Jul 2008
Location: Sweden
Posts: 2,269
|
I haven't looked inside a lot of games or demos, but I can't imagine there are many that do.
|
05 August 2012, 18:45 | #11 |
move.l #$c0ff33,throat
Join Date: Dec 2005
Location: Berlin/Joymoney
Posts: 6,865
|
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. |
09 October 2012, 09:49 | #12 |
Registered User
Join Date: Oct 2008
Location: Assemini/Italy
Age: 51
Posts: 23
|
I'm working on a slave for Wild Copper Megademo and I found this trick, used by the coder to enter in supervisor mode:
Code:
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 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 |
09 October 2012, 10:12 | #13 |
Registered User
Join Date: Dec 2007
Location: Dark Kingdom
Posts: 213
|
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
|
16 October 2012, 11:15 | #14 |
Moderator
Join Date: Nov 2004
Location: Eksjö / Sweden
Posts: 5,660
|
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. |
10 November 2012, 23:04 | #15 |
Moderator
Join Date: Jan 2003
Location: ...
Age: 52
Posts: 1,838
|
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
|
07 March 2013, 21:51 | #16 |
Glastonbridge Software
Join Date: Jan 2012
Location: Edinburgh/Scotland
Posts: 2,243
|
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? |
14 March 2013, 11:45 | #17 |
Registered User
Join Date: May 2010
Location: London, UK
Posts: 268
|
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.
|
14 March 2013, 13:24 | #18 |
Targ Explorer
|
This is one of those threads that make feel stoooopid!
|
14 March 2013, 14:16 | #19 |
Moderator
Join Date: Sep 2004
Location: France
Age: 51
Posts: 4,277
|
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 ? Last edited by CFou!; 14 March 2013 at 15:13. |
14 March 2013, 16:53 | #20 | |
move.l #$c0ff33,throat
Join Date: Dec 2005
Location: Berlin/Joymoney
Posts: 6,865
|
Quote:
Not necessarily since what a0 points to can be modified in the vertical blank for example. Let me guess, this is a delay loop? |
|
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Can anyone work with the code from this game...? | Peter | Coders. General | 3 | 09 November 2009 16:19 |
New Syndicate game in the works? | Dastardly | Nostalgia & memories | 20 | 21 October 2008 15:11 |
XPadder, now your game pad works with everything | Shoonay | Retrogaming General Discussion | 12 | 24 June 2008 19:58 |
Killing Game Show (ADF version that works in WinUAE) | Bolch | request.Old Rare Games | 6 | 14 October 2007 15:20 |
WIN UAE no game works | hannable80 | support.WinUAE | 8 | 05 May 2006 17:30 |
|
|