Propane13

I'm curious... Are the problems reproducible on that last build? I did some code checks and there is a small possibility that one of the breakages that I fixed in that last build could have caused a situation of unpredictable behavior. It is a small possibility, but I thought I would check to see if I got a magic fix. Doubtful, but you never know.... -John

As far as my testing can tell, the fix is in place for the "floating issue" that I introduced in the last release. This also solves a couple of other boundary-checking cases in code near to what GroovyBee found an issue with (thanks GroovyBee!). Here they are; the black screen and the "brown bar freeze" issues are still at large, but at least people can continue gameplay without their character doing weird things. getlost.bin getlost.a78 Enjoy! -John

I'm at about that same point for now; but, yeah it may make sense to wait just in case I have to redesign a section. It's a low probability, but it could happen. I'll leave it up to Mord though; I wouldn't want him to waste his time. But, the levels are pretty much what I would call beta-stage. Unless there's a major problem, they're staying this way for now. -John

Wow; I admire your dedication and perseverance. That is quite the death count. This made my morning. You asked, so I'll answer. 1) You probably wouldn't believe me, but before releasing, some areas were much harder; I tried to remove all pixel-perfect jumps related to spikes. There were a few that were even too annoying for me. So, it's hard, but it was worse for a time. 2) I can speak to the ladders you have to perfectly jump to-- when I was 5, I remember playing Pitfall 2, and getting to the final ladder area underneath Quickclaw. I had to go through a nightmare tower to get there; there were buzzards everywhere, and bats you could barely sneak under. I got to a point where I saw a red cross to save my progress, and then... the power went out. It wasn't fair. I played that game again days later, and it took me forever to get to that spot. The farther I got, the harder things seemed to get. And at the end, you have to pass 3 scorpions (which I hated timing jumps for), and then get past a frog going up. I still die on that stupid last frog on occasion; that tower was a great piece of gameplay that just got harder as you went. But, the only way to get back to the rest of the game world was to take that path. So, you had no choice. Flash forward to Super Pitfall. Yes, I know most people hate it, but there's a similar section in the caveman area where you have to go all the way down and left, up a huge tower, and then make some terrible jumps from vine to vine in order to leave that world. That section was HARD. Oddly, I have beaten Supert Pitfall 3 twice in a row (the third quest is the exact same as the second quest, so I decided to stop there). I guess that concept of the "hard way to get back" somehow stuck with me. I will say that it can be done; when all of this gets released, I'm considering making a youtube video walkthrough. Some day, I hope to see a Speed Run of this game out there. No comment on the Submarine, though. For 3), well... let's just say the game is BIG. Level design took somewhere between 4-6 months (I come up with an idea at night, rough-sketch it on paper during the morning, and implement it in code after work), and I was constantly trying to come up with map concepts that would be cool, fun, and different. Hopefully, it's not too boring or frustrating and has just enough "new stuff" to make it interesting. Glad you are having fun with it. -John

Though this would be difficult to change, it might be possible. I can't remember how the collision routines work (they were written in 2009), so I'd have to investigate. No promises on this one at the moment, but.I'll at least put it into consideration for feature-requests. This can be done-- does anyone else see the same problem on real hardware? I'd like to get a consensus for the best color, and then we can try it out. I am pretty willing to tweak colors here or there to make them more visible / help prevent color bleeding. Glad to hear that you're enjoying it. I tried to cram as much stuff in as I could, so hopefully, people keep finding little surprises. And, yes, the submarine can be beaten, but I will agree that it's a tough nut to crack. Thanks for helping out on this one! -John

So, at the moment, there are 3 bugs I'm counting: 1) the jump bug that was recently found 2) The "red bars freeze screen" 3) The black screen For 1, that should be easy enough; that was actually a fix-on-fix issue; the fix I made for GroovyBee somehow causes a jumping issue. I'll look into how to correct this, since I can reproduce it. For 2, I notice 5 similarities for those who have reproduced it. Let me share the 2 reproduced screenshots (one from KevinMos3, one from AtariBrian) side-by-side: So, here are the 5 things I notice: a) it's the same screen, so it may be easily reproducible here, specifically. b) It's an irrecoverable freeze, meaning that basically, my code is stuck in an infinite loop, or has left the program and gone on its own, yet hasn't corrupted the screen c) The 2 "curtain bars" that are typically black have changed to the same color in both screenshots d) The player character is in almost the same place. e) I don't see a bat in either picture This is making me suspect my bat movement code has a problem somewhere. If I were to guess, the exact spot where the Hero character stands is right where more data would be fetched into RAM for screen drawing (both players represent the left-most and right-most one needs to be to reproduce that). So, maybe the player moves left or right, causing the screen to fetch new data EXACTLY at the second that the bat is offscreen. Something like that. So, maybe testers should go to this screen, and just run back and forth (you can do so on the little ledge just above the player) and see if we can reproduce that freeze when the bat goes off the edge. Might be tricky to trigger, but this MAY be it. In short, go to the little ledge above where the player is in these 2 pictures, and run toward the right into the wall just as the bat's off-screen. Oh, I hope that makes it recur. On my side, I want to dive into my bat code a little bit and see if I can find some sort of race-condition problem. If I don't come up with anything, I could fix my jumping bug I introduced and just disable the bat code temporarily. to see if the problem goes away. But... I'm hesitant to do that, as it could give explorers a real advantage in beating the game and getting to places they haven't been yet. Oh, and for 3), I wonder if it's related to 2). So, we'll table that for now. Thanks for the inspiration and assistance. I think we may be on to something here. -John

Yep. That's a starting gameplan. As I learn more, I may ask to peek at other areas. But, now I am thinking there are 2 scenarios here. The one you describe happened to someone else before. So, when that happened, the game froze but the graphics were still on-screen plus the 2 vertical bars? Basically, the game stopped, with the controls unresponsive? That is slightly different from the black screen. But since I think someone had seen it before, I have some hope to fix it. If the screen doesn't go black, I would love a screen shot. -John

Ok, let's try something a little more crazy. DanBoris and KevinMos3 inspired me to try something a little out-of-the-box. Here is a new demo: getlost.a78 getlost.bin Ok, so 2 things: 1) I think I fixed GroovyBee's issue. I want to thank him for finding this; yes, your assumption was correct about what was wrong. I have since added a little logic that should prevent that case from happening. I would be very happy if you could verify my fix. 2) I made a debug mode, and am asking for a little bit of patience to help find this problem. Here's how it works: - when you feel like unlocking debug mode, insert controller 2 and press it's left button. - it will bring up a screen with a 4-digit number, and a 2-digit number (both hexadecimal, so numbers go 0,1,2,3,4,5,6,7,8,9,A,B,C,D,E,F in both digits). - Left/right on the second controller will decrement/increment the number on the left. - For faster movement, Up/down on the second controller will decrement/increment the leftmost 2 digits - Reset will restart the game and git you out of this mode. But, you'll lose all progress-- sorry about that (it's a full reset). I would like to try to see if some of my memory has been corrupted, and if so, what pieces of memory. My guess is that my display segments of code are somehow getting changed or wiped out. Maybe I can find a pattern and figure it out. I realize this is a lot to ask, but here's what I'm hoping for (I may be looking at gambler172, who seems able to reproduce it most easily). - stay on screen 1 - when the issue happens, push button 2 - select and go through some memory, and see if these numbers line up. - If they don't, let me know what values you see there. ========= $2400: 00 $2401: 1E $2402: 80 $2403: 07 $2404: 1E $2405: 80 $2406: 07 $2407: 1E $2408: 80 $2409: 07 $240A: 1E $240B: 80 $240C: 00 $240D: 1E $240E: 80 $240F: 07 $2410: 1E $2411: 80 $2412: 07 $2413: 1E $2414: 80 $2415: 07 $2416: 1E $2417: 80 $2418: 4F $2419: 18 $241A: 00 $241B: 4F $241C: 18 $241D: 80 $241E: 4F $241F: 19 $2420: 00 $2421: 4F $2422: 19 $2423: 80 $2424: 4F $2425: 1A $2426: 00 $2427: 4F $2428: 1A $2429: 80 $242A: 4F $242B: 1B $242C: 00 $242D: 4F $242E: 1B $242F: 80 $2430: 4F $2431: 1C $2432: 00 $2433: 4F $2434: 1C $2435: 80 $2436: 4F $2437: 1D $2438: 00 $2439: 4F $243A: 1D $243B: 80 $243C: 07 $243D: 1E $243E: 80 ========= $1800: 36 $1801: DE $1802: 80 $1803: 20 $1804: 36 $1805: DE $1806: 80 $1807: 28 $1808: 4E $1809: DE $180A: 80 $180B: 30 $180C: 00 $180D: 1E $180E: 80 $180F: 38 $1810: 00 $1811: 1E $1812: 80 $1813: 40 $1814: 00 $1815: 1E $1816: 80 $1817: 48 $1818: 00 $1819: 1E $181A: 80 $181B: 50 $181C: 00 $181D: 1E $181E: 80 $181F: 58 $1820: 00 $1821: 1E $1822: 80 $1823: 60 $1824: 00 $1825: 1E $1826: 80 $1827: 68 $1828: 00 $1829: 1E $182A: 80 $182B: 70 $182C: 00 $182D: 1E $182E: 80 $182F: 78 ========= If you leave "screen 1", all of the info in the $1800-$182F section will be slightly different, but not necessarily wrong. Before diving in full-force, you can try this out on screen 1 without waiting for the bug, and you should see these line up. It took me about 5 minutes to verify these numbers in emulation. This will also let me know if debugger mode is actually working on real hardware, which I can't verify at the moment. I want to thank those that have stayed with me on this; sometimes, motivation slips away, and getting it back is difficult. I am hoping that maybe a little bit of this information may help me to find what's going wrong. If any programmers want the source code for this feature, I am willing to share it. Best regards, -John

How about a screenshot? -John

Hello! I'm trying to learn more about hardware; in the 7800 world, I'm trying to make something that can "sniff" the address/data lines on a cartridge and store them so that I can trace a nasty bug. With that being said, I don't have a great background in electrical hardware, so I need a little help to get over the learning curve. I had some questions; I figure if I ask some 2600 folks, I can try to translate that info to the 7800 world as well. So, my first question is... are the cartridge signals analog or digital? Sorry if this seems like a dumb question. If I can piece it together right, I believe that they are digital, since they typically have 2 values (ignoring noise) of 0V and +5V (Vcc). An analog signal I think would be like from a paddle controller, where resistance makes the line vary between 0 and 5V depending on where it is set. Is that assumption accurate? My next questions come from looking at the 2600 cartridge pinouts. Since there are 24 pinouts, I see that: - 13 are used for address lines (2^13 = 8K addressable space) - 8 are data lines - 2 are Ground (GND and SGND) - 1 is VCC (+5V) So, my second question is: If there are 8K of addressable space, why are games limited to 4K before bankswitching? Or, perhaps my math is wrong? This seems weird to me My third question is: why is there no CLK line? If I think about how this works in my mind, it's like this: - the Atari system wants to get new information, so it changes the address lines - the cartridge takes these lines and reads from the cartridge at that address, and sets the data lines appropriately - I am guessing the Atari system delays for a little bit of time (milliseconds) before taking the input from the data lines. - the dance begins again So, shouldn't there be a CLK line to signal the cartridge that there is new data to be fetched? Sometimes I would expect there to be some noise on the lines, or a delay between pins where say, A7 is set just ever so slightly behind the others. When this happens, you'd have funky data get fetched, and then I guess instantly later get the real data. If there was a clock line, I wonder if that would help as a signal that data was ready to be fetched from those address lines. Maybe I'm overthinking, but I'm hoping that someone can explain why this isn't a problem. Thanks! -John

Yeah, sadly I have seen it on my NTSC 7800 on a burned cartridge three times. It is a little rare, but it's definitely I there. If I can trace back to where it's happening, I may be able to fix it. -John

So, my last eprom programmer required: - a parallel port - MS-DOS - a 3.5" floppy drive for software The computer that has all of that support is very old, and in storage. What do folks currently use for this? Is there some sort of cool/new cheap burner that works on modern hardware? Thanks! -John

Wow... that artwork is really amazing! I really like the color hues, and the addition of in-game details. It made my day. I think you have a great plan for this; I'd love to see what you come up with. I'm going to try to start thinking about what hardware I need to debug this stuff. I'm not very good in that area, so I may need some help. Not guaranteeing it goes too far, but at least I might as well start thinking about what parts I need to procure. -John

Hello! Some of you may know from another thread in the 7800 forums that I was working on an Atari 7800 game called "Get Lost". It worked wonderfully in emulation, but once people started trying it on physical hardware, a difficult problem occurred. On occasion, the screen would go completely black. This is not reproducible in emulation, which makes me suspect that something is triggered only by real hardware. I have done some thinking, and I have an idea for how to debug this-- I basically need to make something that can "sniff" and record information in real-time. Then, when the issue reproduces itself, I can go back through the trace that I have, and try to deduce what went wrong. I could do this with a logic analyzer, but even to get there, I need some sort of hardware to be able to interface with the cartridges. That's when a few ideas hit me, and I'd like to query some hardware folks for some information. My first thought was to basically make an extendo-cartridge between the 7800 and the cartridge that I would solder some wires to, in order to hook those into some sort of logic analyzer or equivalent place that stores data. There are 32 pinouts on a cartridge: http://www.atarimax.com/jindroush.atari.org/7800cart.html They include: - 16 address lines - 8 data lines - 2 ground lines - 1 Vcc (+5V) - HALT - R/W - CLK2 - EAUDIO - IRQ If I was to make my own "sniffer", I think the pieces of importance are the address and data lines, and the clock. So, my first question is... if I made such a cart to get information from these pieces, how do I account for crystal drift in the clock? Here's what I mean-- if I monitor oscillations in the clock line, I need to deduce when to read the address and data lines. And, there could be very, very small differences in when the clock refreshes vs. these lines. Do I need some sort of mechanism to sample the clock only when it's exactly halfway-between oscillations? Maybe this sounds crazy, but if I sampled all lines the exact millisecond when the clock changed, I wonder if everything will be ok, or if a circuit needs a millisecond to change a data line, etc. I'm wondering how that's all handled in hardware, as I'm new to this. My second question is that I was debating whether or not I could just hook in alligator clips inside the atari 7800, and if there was a place where I could read the PC. Is that exposed? Or, is the PC hidden inside of the 6502 hardware itself? I think sampling that might actually get me the data I need a little bit easier than translating data and address lines and mapping them to locations in code. Is that something that's doable? My third thought is that I was wondering about space utilization. If I sampled a 3 bytes each clock iteration (2 address bytes, one data), and logged it to a file, how fast would it grow? This site: https://sites.google.com/site/atari7800wiki/vblank seems to indicate there are 2166 cycles per frame in a base case. So, 2166 * 3 * 60 frames/second = 389,880 bytes per second. That's 23,392,800 bytes per hour (so, 23M an hour). So, this implies that if it generally takes 1-2 hours for my bug to show up, hardware-wise, I'd need the ability to store at least 100M of data in the miniumum case, but probably I should have a couple hundred megabytes available just to be safe. So, are my calculations correct here? Thanks for the insight; I have a very limited hardware background, so I'm grateful for any help. -John

Thanks for the support. I really mean it. Yes, I'm burned out by this project, at least for now. I had hoped I could rekindle my desire to work on this, but it's difficult; I can't seem to refocus at this time. This project has been started and stopped many times as you can see from the first post (sometimes a few years in-between). My last time I coded for this, I had a good many-month stretch where I was coding almost every day. I thought I could get to the home stretch. Honestly, I'm amazed at how much stuff I put into this. All I had left were a few things; music, a title and end screen, and maybe a small feature or two. But, that all was dashed to pieces when this bug came up. It's a critical failure that I have no ability on how to solve it. I never thanked GroovyBee for his finding; it's something I need to fix, but I do have a suspicion that there's a deeper fundamental problem in the code. This is because I believe that someone once reported a few color-change situations or other weird behavior. It means my main kernel, while perfect in emulation, has some sort of timing problem on real hardware. That's the hardest kind of problem I'm aware of. And, the only way I can possibly debug it is with a logic analyzer. I just don't have the stamina or knowledge base to hook one up and use it at this time. And, there are few who do. So, now I'm just... kind of waiting. For now, this is a fully-playable game (and it does end, but not with a spectacular ending), but it'll just have wait on being finished. I really wish there were more hardware folks on the 7800 scene. If anyone is a hardware guy and is interested in a small project, this is one I could use help with. I have a feeling that this may have been how Bob felt about Frenzy. -John

It's a terrible topic title, but at least it's to the point. When playing ET, how do I get things to "reset"? Sometimes all of my phone pieces get snatched, and the question-marks seem to lose their ability to work. I can only find pieces by randomly falling in pits. Or, on a related note, I feel that something similar happens sometimes with the Reese's pieces-- they disappear, and I need to find more. Is there something I'm supposed to do to "reset things"? -John

Hello all, I need to pick 10 unique colors that are different for a little project I'm working on. I was just going to randomly pick from here: http://www.qotile.net/minidig/docs/tia_color.html But then, I realized that I have no concept of how to deal with people with a degree of color-blindness. Would anyone be able to suggest what colors are "too close" so that I make good picks? Thanks! -John

Hello all, I have switched a few of my computers to mac, and now am realizing that I don't have the capability to run makewav. Apparently, the version that's out there doesn't compile for me, and the binary throws this error: Launch of "makewav" failed: the PowerPC architecture is no longer supported. Is there a web-based verison of makewav/wplaybin, or a new version of makewav that works with modern Mac OSX systems? -John

Wait-- do you guys see my Scrapyard Dog avatar, or just the Yar? -John

I used to have an avatar; maybe the format of it is no longer supported? -John

Aww... Bob is a stand-up guy. I think I could even say he's the nicest guy I've dealt with on atariage. I am sad to see him go, but then again, there are times in life when things change and I understand that you have to move on. @mmervine-- your blog post indicates that he dumped his source code to the world-- where is the source code posted? I've always wondered how he did some of his magic, although part of me feels like it'd be sacrilege to look at it. Also, @mmervine, since it's quite possible that Bob may not be returning to atariage for awhile, I'd like to humbly that you at least make sure he's aware of this thread. I'm not suggesting that he reply-- but, I'd at least like to make sure that he knows how much he was appreciated by a lot of is. He will be missed. Without him, my Atari 7800 coding level would never have gotten to where it is. Bob was a great motivator, and always helpful with a piece of code, advice, or playtesting when needed. I looked up to him, and wish him well. -John

It works! I didn't know what to google for, so I came up with some empty nets. Thanks man. -John

Ok, I've converted "How to Draw a Playfield" -- yes, that old thing, over. I like this assembler, although I have a few gripes. 1) We need a retooled vcs.h. I can use .byte declarations, but I can't seem to find the equivalent to .ds. 2) The atari2600.cfg file that I found online has some problems. It raises 3 warnings: ld65: Warning: Duplicate external identifier: `__TIA_SIZE__' ld65: Warning: Duplicate external identifier: `__RIOT_SIZE__' (the third warning was that during the linking stage, the -o should be before any other flags, so I moved it) I think we need a better one. 3) I grabbed some code from an old thread: http://www.atariage....variable-0-150/ Unfortunately, this compiler has no idea how to handle "sta.wx HMP0". Does anyone know the equivalent? -John

I just installed this, and want to try it. I've done some simple examples, but before I commit, I want to verify that I can re-assemble something that was dis-assembled byte-for-byte. So, with that note, does anyone have a 2K or 4K game that's disassembled into a format where I can try to assemble it back again? Is it easy enough to convert from a dasm disassembly? Such a thing might help get the ball rolling a little further. -John

Here's the new bin: - reset does a "full hard reset" - dying doesn't do a "full hard reset" getlost.bin For the freeze-up, that could be a slightly different problem to delve into. Sounds like I may have some major annoyances to find in rare situations-- we'll see what I can do. With the help of a few people that are ok testing stuff, I hope to at least get somewhere. -John