DarkerBit Posted November 12, 2019 Share Posted November 12, 2019 I am not very well versed with the Atari 2600 yet (but I made a dvd screensaver and got a stable image so that's a start), only knowing 6502 from other projects. I was RTFM when I came across this quote: "The microprocessor stack is normally located from FF on down, and variables from 80 up, hoping the two never meet." I certainly ran into bugs during my first kernel, one of which was a misplaced org causing vars to be on the stack... Then I did a JSR. I was using a SetPos routine to set the horizontal sprite position, and thought the routine was broken when the sprite went somewhere completely unrelated but constant every time. I have solved the issue now, but I ask: What's the weirdest bug you have ever had? 2 Quote Link to comment Share on other sites More sharing options...
Rogerpoco Posted November 12, 2019 Share Posted November 12, 2019 I can't believe "regular people" can understand this stuff, at all... The weirdest bug I've ever had was a Tailless Whip Scorpion, lol!!! Seriously, making a joke, but very impressed at you, or anyone taking on 2600 programming, WOW! Quote Link to comment Share on other sites More sharing options...
+Karl G Posted November 12, 2019 Share Posted November 12, 2019 Game programming can result in some funny bugs sometimes. When I was making Space Game, I marked the beginning of a new wave with "WAVE 1", "WAVE 2", etc. When I first did this, some of the letters went flying around the screen and shooting. 1 Quote Link to comment Share on other sites More sharing options...
+SvOlli Posted November 12, 2019 Share Posted November 12, 2019 Weirdest bug so far: on a cartridge with a hotspot at $FFF8, I had an RTS at address $FFF7, not realizing that there will be a "ghost-read" at the hot spot address, triggering the bank switch, which it shouldn't have. It took me hours to figure out why a) the program was crashing the the first place (going into wrong bank config) and b) (after learning I was at the wrong bank) why the bank was switched. (Most probably, I've lost >90% of the readers here... ? Sorry, but there's no easy way to explain it without going to very deep details.) 3 Quote Link to comment Share on other sites More sharing options...
DarkerBit Posted November 13, 2019 Author Share Posted November 13, 2019 16 hours ago, SvOlli said: Weirdest bug so far: on a cartridge with a hotspot at $FFF8, I had an RTS at address $FFF7, not realizing that there will be a "ghost-read" at the hot spot address, triggering the bank switch, which it shouldn't have. It took me hours to figure out why a) the program was crashing the the first place (going into wrong bank config) and b) (after learning I was at the wrong bank) why the bank was switched. (Most probably, I've lost >90% of the readers here... ? Sorry, but there's no easy way to explain it without going to very deep details.) That's quite a big section to be at an address that high! Quote Link to comment Share on other sites More sharing options...
+Andrew Davie Posted November 13, 2019 Share Posted November 13, 2019 18 hours ago, SvOlli said: Weirdest bug so far: on a cartridge with a hotspot at $FFF8, I had an RTS at address $FFF7, not realizing that there will be a "ghost-read" at the hot spot address, triggering the bank switch, which it shouldn't have. It took me hours to figure out why a) the program was crashing the the first place (going into wrong bank config) and b) (after learning I was at the wrong bank) why the bank was switched. (Most probably, I've lost >90% of the readers here... ? Sorry, but there's no easy way to explain it without going to very deep details.) Had the same sort of thing with Sokoboo. Code ended at the end of a RAM bank in 3E bankswitch scheme. In that scheme, you read from RAM with a normal address, and you write to RAM with adding $400 to the address. So, I just happened to have a subroutine/RTS at the very end of the RAM bank (say, $F3FF). That caused a phantom access to $f400, which then became a WRITE to the first part of RAM (+semi-random offset) Which subsequently did some funky stuff next frame. The weird thing was it only happened when that RTS happened to be pushed to the end of the bank. I tried removing random code and the bug went away. But eventually... it came back. When, of course, the bank filled up and the RTS was at the end. Drove me bonkers for a couple of days! Eventually I reported it as a Stella bug because stella was the only emulator I tried that crashed. All the others worked "perfectly". It turned out that Stella was emulating correctly and all the other emulators I tried... were incorrect. So, that was a recent weird one! 1 1 Quote Link to comment Share on other sites More sharing options...
+SpiceWare Posted November 13, 2019 Share Posted November 13, 2019 Reversed shields in Medieval Mayhem. Due to how the Atari's designed the bug worked as expected on the vast majority of the 2600s out there, including mine. It was discovered about a year after Medieval Mayhem was released when David Mrozek encountered it when he went to review the game for his site. The bug was caused by how only bits 7, and sometimes bit 6, are connected for the read-registers: When you read from those registers the values for bits 0-5 (and 6 for those not connected) are undefined, though they usually come back filled in with the address used to access the register. If you read from INPT0 the address is $08 (%00001000). Only bit 7 is connected, so you usually get back either $08 or $88 (%00001000 or %10001000) depending upon the state of paddle 0. As a 2600 programmer it's highly recommended that you turn on Stella's Developer Settings as it will reveal bugs like this. You can see another example of that in this topic. 2 Quote Link to comment Share on other sites More sharing options...
Shawn Posted November 13, 2019 Share Posted November 13, 2019 I had pneumonia really bad many years ago. That was an awful bug to get over. Damn near fatal. 1 Quote Link to comment Share on other sites More sharing options...
Ed Fries Posted November 13, 2019 Share Posted November 13, 2019 The weirdest bug in Halo2600 lets the player enter what I called "Magic Land" and is documented elsewhere online (for example here: http://infinitelives.net/2010/09/16/hello-homebrew-halo-2600/#sthash.1CZlvLrs.dpbs). It's caused by a problem in the hit test code. If the master chief is hitting a wall he gets moved back to the "safe position" where he was in the previous frame. Seems like a good solution except in the case where the player has also crossed onto a different screen on the map between those two frames. In that case the player can be teleported outside the normal 64 rooms and the game code starts constructing rooms and monsters based on random data. 2 Quote Link to comment Share on other sites More sharing options...
mbd30 Posted November 13, 2019 Share Posted November 13, 2019 (edited) On 11/12/2019 at 10:03 AM, Karl G said: Game programming can result in some funny bugs sometimes. When I was making Space Game, I marked the beginning of a new wave with "WAVE 1", "WAVE 2", etc. When I first did this, some of the letters went flying around the screen and shooting. That's great. I'd almost want to leave that in the game. Edited November 13, 2019 by mbd30 3 Quote Link to comment Share on other sites More sharing options...
+Karl G Posted November 13, 2019 Share Posted November 13, 2019 6 minutes ago, mbd30 said: That's great. I'd almost want to leave that in the game. That would be a good topic, too: bugs you liked so much that you left them in the game. There is one of those in Space Game, too! 2 Quote Link to comment Share on other sites More sharing options...
Mr SQL Posted November 14, 2019 Share Posted November 14, 2019 This programmers bug for the SuperCharger routines in the emulator is interesting, games with the bug will only run in the emulator: @John Saeger may be able to fix this one, the bug originated in Z26. 1 Quote Link to comment Share on other sites More sharing options...
KevKelley Posted November 16, 2019 Share Posted November 16, 2019 I had found in some early versions of my game as I would try to create boundaries, I didn't fully understand the coordinates and the math on the system to where every once and a while something weird would happen like the player Sprite jumping onto the other side of the screen or getting stuck outside of the preferred boundary. Fun to try and troubleshoot and definitely a cool learning experience. 1 Quote Link to comment Share on other sites More sharing options...
bluswimmer Posted November 17, 2019 Share Posted November 17, 2019 Weirdest one by far would be this bug in Tumble Temple. When a block falls onto the one of the towers spanning the height of the screen, the whole screen freaks out and you lose instantly. Upon looking at the code after the livestream, apparently I had forgotten to check the bounds of the playfield array in RAM, so it overwrote other parts of RAM. While not entirely related to the subject at hand, both Tumble Temple and Cannonhead Clash have a couple of bug-turned-features. In Tumble Temple, the ability to run across one-wide gaps was not originally intended, it was just a quirk of how gravity was handled. Cannonhead Clash has the implementation of the fireworks, specifically its sound. Originally I was going to use the shoot sound effect for the sound, but what I got was a mix of the shoot and charge sounds. I liked it, so I kept the sound; that didn't stop me from accidentally patching it, and then having to reimplement the bug... 1 Quote Link to comment Share on other sites More sharing options...
+TwentySixHundred Posted November 17, 2019 Share Posted November 17, 2019 (edited) Weirdest bug recently that i can remember was when finishing up Bass Fishing Tournament. There was nothing funny about it just incredibly frustrating and with no syntax errors, bblint found nothing or compile errors it was driving me nuts. Basically i use bit operations for both level select and other conditions, so it was ideal rather then just jumping to a label. Problem was everytime the program would execute that piece of code, it would reset the level and clear the score ? There was a bankswitch routine that followed after to fetch some data so i was wondering why it wasn't bankswitching and what the living .... was making the score reset to zero (nowhere near any zeroing out code - it's not even in that bank). After a good hour or so of racking my brain and sifting through code while running Stella's debugger, it finally popped it's head out when i was generally gazing at the code. Turns out there was some whitespace in one of the bit operations and wow how dumb did i feel. For example "blah {0} = 1" when it should have been "blah{0} = 1". What baffles me is none of the tools picked it up and the score was zeroing out. However i did notice it wasn't running an drawscreen causing the screen to roll so that's what pointed me towards the code not executing properly in that bank. It would get to the whitespcae freak out then rerun code from the start of the bank. Somehow this obliterated all memory other then what was stored in the TIA. Fun times Edited November 17, 2019 by TwentySixHundred 2 Quote Link to comment Share on other sites More sharing options...
RevEng Posted November 17, 2019 Share Posted November 17, 2019 I think an interesting one is when you accidentally write something like "lda 0" when you mean "lda #0". Usually this typo isn't particularly obvious when you actually run the code... undriven/floating bits at the read address will typically take on the last value on the bus, which happens to be the last opcode byte ("0" in the "lda 0" example) so you regularly wind up with the value you wanted anyway... until the code runs on one of those rare consoles where undriven bits change quicker than usual. I ran into this one during the development of 21 Blue, after someone reported a very odd score display in certain conditions. Then I experienced the bug from another angle in my 7800basic pokey-chip detect code, when carts with pokey-support but without pokey chips caused false positives. The code had to be minimally rewritten so the values I was looking for weren't put on the bus prior to comparison. The player positioning routine in Haunted House has this same bug, and it makes the game unplayable on these problem consoles. pro-tip: run Stella with "-dev.settings 1" and "-dev.tiadriven 1" (or turn it on in the gui) to make this bug very obvious. 2 Quote Link to comment Share on other sites More sharing options...
+stephena Posted November 17, 2019 Share Posted November 17, 2019 If you think 'tiadriven' is neat, wait until you see what's been added to 6.1: 3 Quote Link to comment Share on other sites More sharing options...
+SpiceWare Posted November 17, 2019 Share Posted November 17, 2019 1 hour ago, stephena said: If you think 'tiadriven' is neat, wait until you see what's been added to 6.1: Nice! Do the ghosted checkboxes show what's active for the selected chip type? Back in 2012 I ran into an early playfield color change while working on Space Rocks, photo in reply 35. Quote Link to comment Share on other sites More sharing options...
Tickled_Pink Posted November 17, 2019 Share Posted November 17, 2019 It depends entirely upon your definition of funny. "Funny haha" or "funny peculiar." The latter is usually the biggest source of frustration. I haven't tinkered with 2600 coding for years but had a "funny peculiar" bug in Unity a couple of days ago that cost me 2 days work to pin it down. Still not sure what exactly the issue was but was fixed by creating a new C# class file and just copying the code from the class that was causing problems. Some kind of corruption issue, I guess. Quote Link to comment Share on other sites More sharing options...
+stephena Posted November 17, 2019 Share Posted November 17, 2019 2 hours ago, SpiceWare said: Nice! Do the ghosted checkboxes show what's active for the selected chip type? Back in 2012 I ran into an early playfield color change while working on Space Rocks, photo in reply 35. The checkboxes are activated depending on which 'glitch' you select from the dropdown box. Selecting 'Custom' will allow all options to be toggled individually. 1 Quote Link to comment Share on other sites More sharing options...
+stephena Posted November 18, 2019 Share Posted November 18, 2019 8 hours ago, SpiceWare said: Nice! Do the ghosted checkboxes show what's active for the selected chip type? Back in 2012 I ran into an early playfield color change while working on Space Rocks, photo in reply 35. Hmm, can you send me the ROM from that thread, so I can see if the current code models that TIA version? Or you could always download from Git and compile the latest version yourself. Quote Link to comment Share on other sites More sharing options...
+SpiceWare Posted November 18, 2019 Share Posted November 18, 2019 16 hours ago, stephena said: Hmm, can you send me the ROM from that thread, so I can see if the current code models that TIA version? Or you could always download from Git and compile the latest version yourself. Not sure I have that specific build anymore, but here's a quick test ROM and source that recreates it. VerticalBlank: preps the playfield and sets color for player 0, KernelLoop: modifies the color for player 1. <see next reply for ROM and source> In Stella 6.0.2: On my light sixer: Quote Link to comment Share on other sites More sharing options...
+SpiceWare Posted November 18, 2019 Share Posted November 18, 2019 Got to thinking we might want to test if some TIAs have a late color change for Score Mode as well. pf_score_test.zip Use left difficulty switch to select between the 2. Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.