Silly, buggy code in ST games

All 680x0 related coding posts in this section please.

Moderators: simonsunnyboy, Mug UK, Zorro 2, Moderator Team

AtariZoll
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2978
Joined: Mon Feb 20, 2012 4:42 pm
Contact:

Silly, buggy code in ST games

Postby AtariZoll » Sat Dec 27, 2014 8:08 am

I start this here, because will be most interesting for coders. After peeking and poking in several hundreds of ST games, I saw really lot of bad coding. Some were obviously because low experience with 68000 CPU - using for example instruction tst after some data operation, or even worse, cmp #0, ... :D That just lowers code efficiency. Bigger problem are bugs, which passed tests because they had no machine with 4MB RAM for example, or an STE. Or just did not test enough.

Very fresh (in my head) examples - what actually made me to start this:

NorthStar: it gives IKBD reset 3x (complete unnecessary even once) , actually want to give it, because there is stupid bug - overwritten reg a0, so it gives seq. $80,0 instead $80,1 . If exit from game mouse is dead. What is not usual case with floppy games, of course. Note: IKBD bugs are probably most present in ST games. It seems that there was no proper literature about it in 80-es.

Livingstone, I Presume: It works on 512K machines, but there is setting screen to address $100000 called many times. What results in ugly mess on screen for moment on 512K machines. I really can not explain what they wanted .. Someone was wasted, for sure. Another bug is copying title screen pic. to low RAM - TOS workspace, and copying it back to screen after game over - instead loading it from disk. Bad idea, what causes crash on some TOS versions, for sure.

Outcast: Crashes with 4MB RAM - overshot in screen delete code - goes over $400000 . Such bug is also very common. Additionally, it uses not wise Line-A text print code - because of which can not run from AUTO.

Examples for not STE compatible game:
Grand Monster Slam and Hyperforce : same bug - overshot in palette writing code, what screws HW scroll reg. on STE.

There is much more, unfortunately. Worst bugs are likely those which prevent normal gameplay - for instance finishing it (normally). Please add own experiences .
Famous Schrodinger's cat hypothetical experiment says that cat is dead or alive until we open box and see condition of poor animal, which deserved better logic. Cat is always in some certain state - regardless from is observer able or not to see what the state is.

User avatar
Stefan jL
Atari God
Atari God
Posts: 1260
Joined: Thu May 09, 2002 3:21 pm
Location: Sweden
Contact:

Re: Silly, buggy code in ST games

Postby Stefan jL » Sat Dec 27, 2014 1:11 pm

Some of this info could be added to Atarimania game entrys... i have already made a test for "Livingstone i presume" entry:
http://www.atarimania.com/game-atari-st-livingstone-i-presume_21436.html

I skipped the words "silly", "buggy" and "wasted coders" though :wink:
The game showed the garbage with 1mb also? is that correct as you mention it only happen for 512kb machines? or did i misunderstand you? I was testing with Steem sse.
Also i tested TOS 1.00, 1.02 and 1.04 and they all seemd to work even if you mention some TOS versions crashed the game?
I never bothered to test any newer TOS versions since they are STE/Mega or Falcon specific and the game does not claim to support them anyway.
Image

AtariZoll
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2978
Joined: Mon Feb 20, 2012 4:42 pm
Contact:

Re: Silly, buggy code in ST games

Postby AtariZoll » Sat Dec 27, 2014 2:40 pm

Some garbage may appear on 1MB machines too, if regular screen space is not clean when game starts. Main problem with Livingstone is that setting screen to $100000 has no sense at all - it never writes there.
Writing data to TOS workspace , so to area $8-$6000, or higher by higher TOS versions ($8900 by T 1.02) is very stupid, because you simply can not know will it make some TOS calls not working - like file access. Since different buffer locations change in different TOS versions it depends from concrete space where game writes and TOS version. I did fixed game version instead testing in diverse TOS versions - which just reloads title from floppy after game over.

Skychase is another example for writing to TOS workspace ( area at $3000) - it works not in TOS 2.06 because of that. In 1.04 is OK.

Funny thing is that there is unused space when game starts from AUTO folder (or autoboot, and uses TOS calls). For instance in TOS 1.04 it is : $611C-$A84E, so 18KB . It is actually AES workspace, not used when SW starts from AUTO folder. Only smart enough SW to using it is Dungeon Master.

Surely we don't need to write words like "silly" at Atarimania. I'm just little tired after 3 games in row, with dumb bugs :D But "wasted coders" are welcome here to discuss about :D Who works, makes mistakes. Pointing on them may help in doing work better, and to understand appearing problems with SW.
Maybe we need new movement: SW fixation :mrgreen:
Famous Schrodinger's cat hypothetical experiment says that cat is dead or alive until we open box and see condition of poor animal, which deserved better logic. Cat is always in some certain state - regardless from is observer able or not to see what the state is.

AtariZoll
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2978
Joined: Mon Feb 20, 2012 4:42 pm
Contact:

Re: Silly, buggy code in ST games

Postby AtariZoll » Mon Dec 29, 2014 1:56 pm

Negative surprise: Leavin' Teramis from Thalion has same IKBD reset bug as Northstar, and when exit game, mouse is dead. And it is done by some of most respected coders.

Tracker: it has probably worst mouse code from all games: overcomplicated, with direct jumps in TOS ROM - what means of course that works only on specific TOS version: 1.00 UK and US .
Famous Schrodinger's cat hypothetical experiment says that cat is dead or alive until we open box and see condition of poor animal, which deserved better logic. Cat is always in some certain state - regardless from is observer able or not to see what the state is.

AtariZoll
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2978
Joined: Mon Feb 20, 2012 4:42 pm
Contact:

Re: Silly, buggy code in ST games

Postby AtariZoll » Sun Feb 22, 2015 9:50 am

Continuing with bad IKBD coding examples:
Sensible Software made some really good games, starting at 1990, if I see it correct. But I had lot of troubles with their International 3D Tennis. It just wont read joystick properly, or at all when game menu appears. On some STE, Falcon certainly not. Someone asked me at YouTube to say more about bad coding in it, so I will do it here.
But need to say few words before: you can not read keyboard, or joystick, mouse state directly in ST, because it is done by IKBD chip, which normally generates an interrupt whenever something changes -some key pressed or released, mouse moved. There are codes for every action. It seems that some coders had troubles with that - I guess mostly those programming on 8-bit machines like Sinclair Spectrum, where is direct access to keyboard matrix.
Serial communication is used, with relative slow speed, and small sized buffer. If CPU not reads all sent data whole system freezes, and further action are not readable. Then you need to flush ACIA first. Such data overflow happens mostly when some longer code with disabled interrupts is executed. Usual and efficient cure against is to disable IKBD chip's code sending, and reenabling after SW is again ready to receive IKBD input. Normal way of reading IKBD chip is via MFP interrupts - at every IKBD code sending an interrupt is generated, and then CPU can read it in service routine, after what IKBD chip can send next one - there are multi-byte sequences, which start with specific header byte.
And this is where main problem in International 3D Tennis lies. During intro they use wrong method: ACIA interrupt is disabled, and ACIA is readen by SW periodically. But that may confuse IKBD chip, and putting it in some bad state. Interesting thing, what I did not notice before is that giving command $14 - enable joysticks instead $12 - disable mouse is not good in such bad IKBD reading way. Mouse will be still readen, and that code for joystick read goes confused. In normal work, giving $14 or $12 has same effect - mouse goes disabled, and can read 2 joysticks. There are some other bad codings in International 3D Tennis, like enabling Timer-D, while it is not used at all - what made Steem working bad.
Their later game Cannon Fodder has better IKBD code, but still made me troubles in version with STE DMA music loaded from mass storage during intro. It again used method with disabled ACIA interrupt during intro, what worked with PSG music, but not with STE audio DMA and constant loading from disk with rate of 50 KB/sec . There is code what should detect absolute mouse position package from IKBD chip - but it fails under mentioned music playback way (I guess that there were traces of it on bus, instead ACIA data when code tried to read it) - user needs to press mouse button multiple times and longer to abort intro. Stupid thing is that they used same, absolute mouse pos. reading way in intro, where even no mouse cursor :D
I fixed both cases, but it took too much time - it is not easy to fix badly concepted code.
Famous Schrodinger's cat hypothetical experiment says that cat is dead or alive until we open box and see condition of poor animal, which deserved better logic. Cat is always in some certain state - regardless from is observer able or not to see what the state is.

EvilFranky
Atari Super Hero
Atari Super Hero
Posts: 854
Joined: Thu Sep 11, 2003 10:49 pm
Location: UK
Contact:

Re: Silly, buggy code in ST games

Postby EvilFranky » Sat Mar 07, 2015 8:34 pm

Talking about Cannon Fodder and bad/lazy development...

I appreciate at the time Cannon Fodder was released the ST user base was in free fall and obviously not the target platform but I played your recent musically patched version (which is great) earlier and compared it to the Amiga version.

Sensible Software don't seem to have been able to master software based horizontal scrolling, Cannon Fodder seems quite good scrolling vertically but it jumps in chunks horizontally. It actually makes the game far more difficult as it only moves once the characters are moved to a certain part of the screen so you can't see on coming enemies.

It lacks any polish like the Amiga version, no recruitment screen, no intermission screens. Obviously the fancy parallax chopper animation would have been too much but a nice static graphic explaining the next area would have been good. The intro sequence appears to be made from about 4 shades of grey and look really rough compared to the Amiga...I know the ST has half the shades but still.

Just all seems a bit half arsed.

A Zamuel STE update of this would be excellent :wink: Instantly enhanced by implementing just hardware scroll! Could easily have in game digital sounds as there is no music, and could play the same MOD music during level loading.

Sorry I'm just thinking out loud haha, wish I had the mental capacity to learn ASM to that sort of level and make the changes myself! :lol:

User avatar
Stefan jL
Atari God
Atari God
Posts: 1260
Joined: Thu May 09, 2002 3:21 pm
Location: Sweden
Contact:

Re: Silly, buggy code in ST games

Postby Stefan jL » Sat Mar 07, 2015 9:26 pm

About Northstar and Leavin Teramis.. afaik so it is not buggy code, it was just not necessary to add that code since you can not exit the games to TOS anyway :)

Although i have seen several games telling you not to touch the mouse/joystick when the game is loading... right now i remember Torvak the Warrior being one of them.
Last edited by Stefan jL on Sat Mar 07, 2015 9:58 pm, edited 1 time in total.
Image

AtariZoll
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2978
Joined: Mon Feb 20, 2012 4:42 pm
Contact:

Re: Silly, buggy code in ST games

Postby AtariZoll » Sat Mar 07, 2015 9:54 pm

Stefan jL wrote:About Northstar and Leavin Teramis.. afaik so it is not buggy code, it was just not necessary to add that code since you can not exit the games to TOS anyway :)
Although i have seen several games telling you nt to touch the mouse/joystick when the game is loading... right now i remember Torvak the Warrior being one of them.


It is bug to give invalid reset command. Only that it makes not problems while playing game. Especially is bug because reset command is completely unnecessary at game start. All you need is to set wanted mode - joystick, mouse, absolute mouse mode ... Not touching controls while load problem is not related with invalid reset. But may see both errors in same games.
Lame coding expects that user think instead programmer :mrgreen:
Famous Schrodinger's cat hypothetical experiment says that cat is dead or alive until we open box and see condition of poor animal, which deserved better logic. Cat is always in some certain state - regardless from is observer able or not to see what the state is.

User avatar
TheNameOfTheGame
Atari God
Atari God
Posts: 1085
Joined: Mon Jul 23, 2012 8:57 pm
Location: Almost Heaven, West Virginia

Re: Silly, buggy code in ST games

Postby TheNameOfTheGame » Wed Mar 11, 2015 5:18 am

Back in the day I figured out how to read packets directly off the ACIA with MFP interrupts turned off and IKBD in #$15 mode.

I would get the packets like this:

Code: Select all

chk_acia
     btst.b  #1,KB_CNTRL
     beq.s   chk_acia
     move.b  #$16,KB_DATA   ;request packet
IKBD_receive
     btst.b  #0,KB_CNTRL
     beq.s   IKBD_receive   ;wait until request is confirmed
get_header
     move.b  KB_DATA,d0     ;header byte = #$fd
wait_joytick0
     btst.b  #7,KB_CNTRL
     beq.s   wait_joystick0 ;wait for signal that data is ready
     move.b  KB_DATA,d1     ;joystick0 data byte
wait_joystick1
     btst.b   #7,KB_CNTRL
     beq.s   wait_joystick1 ;wait for signal that data is ready
     move.b  KB_DATA,d2     ;joystick1 data byte


It always seemed to work for me...was I writing buggy code?

AtariZoll
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2978
Joined: Mon Feb 20, 2012 4:42 pm
Contact:

Re: Silly, buggy code in ST games

Postby AtariZoll » Wed Mar 11, 2015 7:24 am

That code is OK - if you warn user to not touch keyboard :D , and I saw similar in some games. But interrupt based way is much better - because direct packet way takes many times more CPU time - there is too much waiting for next byte from ACIA. Remember that speed is only some 7 Kb/s, so you must wait first that IKB chip process joystick request, then about 1mS for header byte, then next 1mS for data, 1mS for next data byte . If you activate this in every Vblank, may spend about 3-4 mS only for joystick read, what would be about 15-20% CPU time !
Famous Schrodinger's cat hypothetical experiment says that cat is dead or alive until we open box and see condition of poor animal, which deserved better logic. Cat is always in some certain state - regardless from is observer able or not to see what the state is.

User avatar
TheNameOfTheGame
Atari God
Atari God
Posts: 1085
Joined: Mon Jul 23, 2012 8:57 pm
Location: Almost Heaven, West Virginia

Re: Silly, buggy code in ST games

Postby TheNameOfTheGame » Wed Mar 11, 2015 11:48 am

Yes, now I realize it is much more efficient to use the interrupt method, but in 1995 I didn't know that :mrgreen:


Social Media

     

Return to “680x0”

Who is online

Users browsing this forum: No registered users and 4 guests