PitfallCreator

The 'downloadable version' and the 'digital copy' are the same thing. It is a special version of the game with the same serial number but uniquely encoded so that the High Score board can separate Cartridge from Emulator scores. (I assumed that purists would grant a higher value to scores earned on original hardware and want the scores separated.) You get this version with any Collector Edition game registered to your account from the MANAGE page of the Audacity Games Web Portal. Once the code is fully tested and approved, I will update the digital copy generator so that anybody who downloads (or re-downloads) their digital copy gets the update. Still looking for someone with the offending Jr. hardware willing to test the new code.

I thought about the idea of changing the downloadable version, but I'm not sure it would help anybody. Am I correct in the understanding that the problem only exists when playing a ROM on certain Jr. hardware? The downloadable version is only played on an emulator, and short of someone playing it on Stella in developer mode the problem would never happen. Agree? I have made those few changes to the code. And while the changes were minor, I am psychologically unable to switch to the new version without play testing the entire game. We are working on that, but it wouldn't hurt to also test a ROM version on the offending Jr. hardware. So, for those of you who have the offending version of the Jr. hardware, who wants a free loose cart with the new version in return for testing those bugs reported here? Email me (dc@audacitygames.com) if you are interested, including the email address you use to log into our site (if different).

Thomas, I have always had nothing but praise for Stella, but as an old-schooler I have trouble getting over the idea that no matter how good the emulator there is no substitute for testing on real hardware. That is changing. At the very least Stella will be a part of our testing strategy going forward. Thanks.

We first discovered the insidious missing '#' bug at Atari in 1978. A new programmer who was also new to the 6502 wasn't aware of the difference between loading a data value and load immediate. The code was full of missing '#' characters, but the game worked perfectly. Only when I was asked to help them find a (different) bug did I see it in the source. I immediately hooked up an HP 1611A logic analyzer on address and data busses. When the 6502 performs a read operation it tristates its data bus. That allows an external ROM, RAM, or register to drive the bus with the contents of the device at the requested address. We officially describe a tristated bus as undefined, but that is not completely accurate. Due to capacitance in the lines, a tristate output can hold data for a few microseconds. As a quick tutorial for anyone who doesn't know this: When the 6502 executes, for example, a zero-page read of address 6, it uses a two byte opcode $a5 $06 - both values read from ROM as a program fetch. The last value read from ROM in this case is $06. A read of address $06 on the 2600 returns a collision bit on bit 7, with all other bits not driven. So if there is no latched collision bit, bit 7 will be zero and bits 6-0 will likely be the same as the program instruction operand. An lda $06 instruction loads the accumulator register with exactly the same contents as an lda #$06. Of course we would never have done that on purpose. And I haven't seen it since. So while it is technically possible to anticipate the situation and test for it using Stella's trapread, for example, it never occurred to me to do so.

Thanks to all for calling attention to these bugs. Unfortunately this is the first I heard of them, and only when Matt Pilz mentioned it in passing on the AtariAge Facebook site over the weekend. I don't know why your bug reports never reached us, but that contact page still relies on email. And any of you who manage a site that generates emails can attest that 7,000 ISPs in the US use 7,000 different blocking algorithms. I will make it a point to improve on the contact system, maybe bypassing email. Kudos for you who realized it was a missing '#'. (I will tell a story about how that was discovered at Atari separately.) In my defense, the Circus Convoy source code contains 1,450,941 characters. Are you going to hold it against me that there were 2 missing characters? Plus the missing '#' is the most insidious bug. Such an oversight should cause awful, random operation, but it doesn't. It works on almost all hardware as an immediate as the programmer intended. We tested for hundreds of hours, and on all platforms (including the Jr.) and never once saw these bugs. It has been suggested that we should open up testing to the 2600 experts such as are on this forum, but we were operating in stealth mode. Right up until we went live, we were not going to release the game until we felt it was one of the best games out there, and worth "coming out of retirement" for. The question now is what do you think we should do about it? Do you want to send in your physical carts for replacement? Maybe those of you who play exclusively on the Jr. would like a loose cart with the new code and a second serial number? I want to hear from you what you think will make it right. And in the future remember that I am a member of this forum. If you post anything that you think should reach me, please link me into the discussion. That will raise the probability that I will hear of things as important to me as bugs in my code.

Thanks for that, Darrell. Stella, the labor of love and wonderful tool it has always been, never ceases to amaze! Part of the problem with Circus Convoy is that there is so much depth of game play it was very difficult to make sure every scanline count (that might have been affected by a page boundary shift from the smallest change) on every game screen remained consistent. I had checked it in every sideshow throughout development, but apparently Duck Shoot slipped by due to some late change. As many of you know, the 2600 was reduced to the cheapest system that would output some semblance of a TV signal. It was considered perfectly acceptable to use a non-interlace signal for NTSC, and then PAL was a double kludge - completely ignoring the alternating phase requirement. It worked on consumer TVs, and that was good enough. The point is that it is arguably surprising that more TVs and monitors view colors correctly than those that don't. Re the non-standard 2600 video signal, for those who like stories from the old days, keep reading. For the Laser Blast commercial, our child actor had to start out looking bored while earning millions of points without even looking at the game screen of some "other space game." To achieve this I had to write a self-playing, single-screen space game with a big on-screen score and provide it to the commercial production team. And, of course, I used a 2600 for this since I had the development system; a 2600 was portable; we had extras we could send to LA, etc. Digital effects added in post production were not common then, so they wanted the game to be on the kid's TV screen for the shoot. Enter Genlock - a studio-wide standard sync signal driven into every TV camera, monitor, etc. (You can tell when Genlock is not used when you look at a TV in the scene and a black sync bar drifts through the picture.) Of course, not only is a 2600 not equipped with Genlock, it doesn't even output an interlaced sync signal. Taking that as a challenge, I first gave the imaginary game an interlaced signal in software, changing the sync code to put out 262.5 scan lines so that alternating frames provided the required 1/2 line offset for interlacing. I then wired up an unused joystick input to read the Genlock signal and trigger each frame to keep the sync bar out of frame. All that for 4 seconds of the commercial. (It worked so well I then had to put the same mods into a Laser Blast cart so they could capture game play footage. And yes, I know, I should have saved that cart.)

Thank you to those who reported the issue, and the speculation is correct. Even with 2000 hours of Beta Testing, we missed a frame rate anomaly on the Duck Shoot game. (In our testers' defense, it has an insignificant effect on NTSC and only really shows up on PAL. And even then only on real hardware - the color effect does not show up on emulation.) Unfortunately, the ROM is what it is, and we can't fix it in your physical cartridge from halfway across the world. (If it helps, Collector Edition owners can now download a fresh copy from the MANAGE page of the Audacity Games™ Web Portal.) We had only one tester in a PAL territory playing on actual hardware. But we can fix that! Which of you wants to sign up as a Beta Tester later in the year for Casey's Gold™? David Crane