easmith Posted February 23, 2018 Share Posted February 23, 2018 I was in the process of having a few carts made for my game. When tested on real hardware , the player shot always initiates from the left edge of the screen, despite the shot initiating from the player X position -as designed - in Stella. Also , the enemy bombs seem to move slower at times. See video. https://www.youtube.com/watch?v=rSyTy7z50cA Are these types of bugs common when moving from emulation to real hardware? Any insight into what could be causing this would be appreciated . I can share source code, but perhaps there is a simple explanation? Thanks, ES Quote Link to comment Share on other sites More sharing options...
Omegamatrix Posted February 23, 2018 Share Posted February 23, 2018 Without digging too deep into your code, I believe the issue is in RESMP0 and RESMP1 is not properly emulated in any emulator. I too went through a headache of writing to RESMP0 and getting unexpected results. I have raised this issue to the Stella team, but no fix is in place yet. Quote Link to comment Share on other sites More sharing options...
+SpiceWare Posted February 23, 2018 Share Posted February 23, 2018 Are these types of bugs common when moving from emulation to real hardware? Any insight into what could be causing this would be appreciated .most likely you left out a # on an immediate mode instruction, it's a very common bug that causes problems like you're seeing. Check the following topics for examples of this, as well as how to make those problems show up in Stella. from reply 10 onward http://atariage.com/forums/topic/258401-trex-aka-first-attempt-at-6507 from 34 onward http://atariage.com/forums/topic/269701-nyan-cat-game-work-in-progress/ Quote Link to comment Share on other sites More sharing options...
easmith Posted February 23, 2018 Author Share Posted February 23, 2018 most likely you left out a # on an immediate mode instruction, it's a very common bug that causes problems like you're seeing. Check the following topics for examples of this, as well as how to make those problems show up in Stella. from reply 10 onward http://atariage.com/forums/topic/258401-trex-aka-first-attempt-at-6507 from 34 onward http://atariage.com/forums/topic/269701-nyan-cat-game-work-in-progress/ Without digging too deep into your code, I believe the issue is in RESMP0 and RESMP1 is not properly emulated in any emulator. I too went through a headache of writing to RESMP0 and getting unexpected results. I have raised this issue to the Stella team, but no fix is in place yet. I cannot find a missing #, at least not when writing to RESMP0. Doesn't DASM compile the code correctly for real hardware binary file independent of emulator? I'm confused as to why it would work beautifully in Stella but not on real machine. Could it be specific to the test console? Quote Link to comment Share on other sites More sharing options...
+stephena Posted February 23, 2018 Share Posted February 23, 2018 I cannot find a missing #, at least not when writing to RESMP0. Doesn't DASM compile the code correctly for real hardware binary file independent of emulator? I'm confused as to why it would work beautifully in Stella but not on real machine. Could it be specific to the test console? Because no emulation is ever quite perfect (or at least Stella is not yet, but it is very close). While it could be something specific to the console, it's likely that the issue is what Omega suggested. He has found similar issues over the years, and we've fixed pretty much all of them, but as he said, we're still working on that specific item. Testing should always be done a real hardware at some point in the development cycle. I would guess that Stella is 98% of the way there, but there are still some corner cases that we have to fix. Quote Link to comment Share on other sites More sharing options...
easmith Posted February 23, 2018 Author Share Posted February 23, 2018 Because no emulation is ever quite perfect (or at least Stella is not yet, but it is very close). While it could be something specific to the console, it's likely that the issue is what Omega suggested. He has found similar issues over the years, and we've fixed pretty much all of them, but as he said, we're still working on that specific item. Testing should always be done a real hardware at some point in the development cycle. I would guess that Stella is 98% of the way there, but there are still some corner cases that we have to fix. Thanks . I still don't understand why , if I am using correct 6502 instructions, the DASM compiled bin file would not work correctly on hardware, regardless of emulation. Does that mean that there is an actual problem is in the code but it is somehow working in Stella by chance due to a bug? Quote Link to comment Share on other sites More sharing options...
+stephena Posted February 23, 2018 Share Posted February 23, 2018 It could be a problem in your code, or it could be an emulation issue. You won't know for sure unless/until you also test on real hardware. You could have perfectly working code, in that you're telling Stella to do something, and it does it. Problem is, what Stella does isn't the same as what real hardware would do, so you get discrepancies. So you told the 'real machine' to do the wrong thing. You could have an error in your code, that happens by chance to 'work' in Stella, but not on a real machine. You could have a console that is somewhat different than normal. Whether the binary was compiled by DASM with a certain set of instructions is irrelevant. The problem here is that the emulation and real console do not match. I guess what you really fail to realize is that Stella is also a program that can (and does) also have bugs, and can sometimes behave differently than a real console. In such a case, it is by definition a bug in Stella (since its sole responsibility is to act like a real console). Determining whether the bug is in your code or the emulator is an exercise left to the reader 1 Quote Link to comment Share on other sites More sharing options...
DirtyHairy Posted February 23, 2018 Share Posted February 23, 2018 No emulator is a 100% faithful recreation of the hardware. If the behavior of your code differs between Stella and real hardware, there are two possibilites: * You are sensitive to the initial conditions of the machine, in particular RAM (this is essentially what Spiceware suggested) * You have encountered a corner case where the emulation does not match real hardware. While Stella's (and 6502.ts') TIA emulation is very close to real hardware at this point, there are still some corners where hardware behaves differently. The issue Omegamatrix refers to is such a case. "Fixing" it is tricky as we need to find out how real hardware works in the first place I promise to investigate (I must admit I forgot about the issue), but I am currently swamped, so we're talking weeks - months. So, to sum things up: you wrote your code to work in Stella, and real hardware is apparently different. Quote Link to comment Share on other sites More sharing options...
easmith Posted February 23, 2018 Author Share Posted February 23, 2018 (edited) No emulator is a 100% faithful recreation of the hardware. If the behavior of your code differs between Stella and real hardware, there are two possibilites: * You are sensitive to the initial conditions of the machine, in particular RAM (this is essentially what Spiceware suggested) * You have encountered a corner case where the emulation does not match real hardware. While Stella's (and 6502.ts') TIA emulation is very close to real hardware at this point, there are still some corners where hardware behaves differently. The issue Omegamatrix refers to is such a case. "Fixing" it is tricky as we need to find out how real hardware works in the first place I promise to investigate (I must admit I forgot about the issue), but I am currently swamped, so we're talking weeks - months. So, to sum things up: you wrote your code to work in Stella, and real hardware is apparently different. Ok, bummer. I do not have a console anymore . The tester was Albert at Atari Age. If anyone else has time to test it with Harmony cart I would appreciate it . I am clearing RAM in my code. But perhaps that does not actually clear the RAM on a real console? I am a beginner so sorry for being so dumb, but It still seems that if an instruction is written using valid 6502 code consistent w/ Stella guide , then the hardware should execute the instructions correctly. In other words, that it has to be a code error.. One thing I did not ask just in case : for fire detection, I have this in the code: checkfire lda Missileheight ; if missile below Y=200 don't fire cmp #200 bcc fireenemy ; skip fire lda #%10000000 ; else check for fire bit INPT4 bne fireenemy lda #1 ; if fire then reset missile to bottom and play sound 14 frames sta Missileheight lda #2 sta RESMP0 lda #0 sta RESMP0 lda #0 sta soundcount ; initialize sound counter lda #14 sta AUDC0 lda #10 sta AUDV0 lda #29 sta AUDF0 lda XPosP clc adc #8 ; set missile X location at center P0(doublewide) sta MissileX Edited February 23, 2018 by easmith Quote Link to comment Share on other sites More sharing options...
DirtyHairy Posted February 23, 2018 Share Posted February 23, 2018 (edited) I have looked at the schematics, and I think I have spottet the issue --- the actual circuit works quite differently from what is implemented in Stella and 6502.ts. I'll do an attempt to change 6502.ts / Stellerator accordingly this weekend, but I cannot promise anything. In a nutshell, you need at least one full redraw of the player between enabling and disabling RESMP0; otherwise, you won't see any effect. The easiest way to ensure this doing two WSYNCs (if you can spare the cycles) in between. I am 99% sure this will fix your issue If I can reproduce your issue in Stellerator, you can check there even without real hardware. Edited February 23, 2018 by DirtyHairy 1 Quote Link to comment Share on other sites More sharing options...
easmith Posted February 23, 2018 Author Share Posted February 23, 2018 I have looked at the schematics, and I think I have spottet the issue --- the actual circuit works quite differently from what is implemented in Stella and 6502.ts. I'll do an attempt to change 6502.ts / Stellerator accordingly this weekend, but I cannot promise anything. In a nutshell, you need at least one full redraw of the player between enabling and disabling RESMP0; otherwise, you won't see any effect. The easiest way to ensure this doing two WSYNCs (if you can spare the cycles) in between. I am 99% sure this will fix your issue If I can reproduce your issue in Stellerator, you can check there even without real hardware. Wow! I am super impressed . I am checking for fire and doing all the RESMPOs during overscan, and positioning player during VBLANK. So will I have two wait 2 whole frames to release missile or will just adding 2 WSYNC between reset and release do it ? Quote Link to comment Share on other sites More sharing options...
DirtyHairy Posted February 23, 2018 Share Posted February 23, 2018 (edited) Wow! I am super impressed . I am checking for fire and doing all the RESMPOs during overscan, and positioning player during VBLANK. So will I have two wait 2 whole frames to release missile or will just adding 2 WSYNC between reset and release do it ? Don't be impressed before I am proven correct If I am correct, two WSYNCs between writing 2 to RESMP0 and writing 0 to RESMP0 should do the trick. Edited February 23, 2018 by DirtyHairy Quote Link to comment Share on other sites More sharing options...
easmith Posted February 23, 2018 Author Share Posted February 23, 2018 Don't be impressed before I am proven correct If I am correct, two WSYNCs between writing 2 to RESMP0 and writing 0 to RESMP0 should do the trick. Albert at Atari Age just confirmed that this fixed the problem ! 1 Quote Link to comment Share on other sites More sharing options...
DirtyHairy Posted February 23, 2018 Share Posted February 23, 2018 (edited) Albert at Atari Age just confirmed that this fixed the problem ! Awesome! I will make the necessary adjustments to Stella and Stellerator; however, after looking at the schematics a bit longer, I realize that I need some solid testing on real hardware before I have enough confidence in what is going on, so I have to backpedal a bit: probably not this weekend Edited February 23, 2018 by DirtyHairy 2 Quote Link to comment Share on other sites More sharing options...
scitari Posted February 23, 2018 Share Posted February 23, 2018 The problem I encountered when moving to original hardware was that I was only clearing the RAM during initialization as I had seen done in many other code examples. I had to clear the registers as well to get it to work properly. I am sure this is common knowledge but sharing just in case it is helpful to someone just getting started. 2 Quote Link to comment Share on other sites More sharing options...
Omegamatrix Posted February 24, 2018 Share Posted February 24, 2018 The problem I encountered when moving to original hardware was that I was only clearing the RAM during initialization as I had seen done in many other code examples. I had to clear the registers as well to get it to work properly. I am sure this is common knowledge but sharing just in case it is helpful to someone just getting started. Other common errors not mentioned already that will usually burn you later: - not clearing decimal mode upon initialization - not handling a multibank game starting in any bank at power-on - not handling VSYNC properly, as this is even worse to detect as some TV's are much more tolerant than others - not having a stable scanline count 4 Quote Link to comment Share on other sites More sharing options...
easmith Posted February 24, 2018 Author Share Posted February 24, 2018 (edited) Now that that bug is solved , If anyone would like to test on harmony cart to see if there are anymore bugs I would be much obliged . Sadly my parents gave my console away years ago AlienAttack2.1.bin AlienAttackPAL.bin Edited February 24, 2018 by easmith Quote Link to comment Share on other sites More sharing options...
Mr SQL Posted February 24, 2018 Share Posted February 24, 2018 The problem I encountered when moving to original hardware was that I was only clearing the RAM during initialization as I had seen done in many other code examples. I had to clear the registers as well to get it to work properly. I am sure this is common knowledge but sharing just in case it is helpful to someone just getting started. This is interesting, the bug I encountered where the SuperCharger behaves differently had to do with Stella and Stellerator not handling a register correctly, not clearing it I believe. Javatari handled it correctly though, did you try this there? The Harmony was patched to handle the register correctly to emulate the consoles behavior with a real SuperCharger, I think this bug may be related. Unless Al burned a 4K cart you didn't get a fully accurate test because the Harmony BIOS and Stella could still be at odds making it difficult to tell which one is correct. Quote Link to comment Share on other sites More sharing options...
+stephena Posted February 24, 2018 Share Posted February 24, 2018 This is not what happened there, and I wish you would stop spamming threads about this issue and saying the issue is with Stella, and now with Stellerator too. 2 Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted February 24, 2018 Share Posted February 24, 2018 Another tip would be to use Stella's default "Developer settings" during development. They should help catching a lot of coding errors. Quote Link to comment Share on other sites More sharing options...
tokumaru Posted February 24, 2018 Share Posted February 24, 2018 Amazing that this late in the game there are still TIA registers that aren't fully understood! Do we have schematics of the internals of the TIA? It would be really cool if we could simulate it at the hardware level like Visual 2C02 can do with the NES PPU. Anyway, it does make sense that the TIA needs to "scan" the player in order to be able to reset the missile to a position relative to it. This is a pretty cool find. 3 Quote Link to comment Share on other sites More sharing options...
alex_79 Posted February 24, 2018 Share Posted February 24, 2018 Do we have schematics of the internals of the TIA? Yes. I cleaned up a bit those scans some time ago. Here they are if anyone is interested: TIA_1A_logic_diagram.pdf 3 Quote Link to comment Share on other sites More sharing options...
DirtyHairy Posted February 24, 2018 Share Posted February 24, 2018 (edited) Yes. I cleaned up a bit those scans some time ago. Here they are if anyone is interested: TIA_1A_logic_diagram.pdf Cool, those are much better than the original scans I know what I will use from now on... Amazing that this late in the game there are still TIA registers that aren't fully understood! Do we have schematics of the internals of the TIA? It would be really cool if we could simulate it at the hardware level like Visual 2C02 can do with the NES PPU. Anyway, it does make sense that the TIA needs to "scan" the player in order to be able to reset the missile to a position relative to it. This is a pretty cool find. The schematics have been around for a pretty long time, and there is Andrew Tower's excellent analysis of them (it is floating around on the web). Just following ATs notes is enough to get emulation about 80% there (that's the route I went), but the remaining 20% depend on the details of the interaction between the various clocks and phases inside the circuit (the TIA is driven by a mess of four-phase clocks). Looking at the schematics is very helpful to get an idea of how the various aspects are implemented and interact, but at least I am incapable of reading the behavior in the various edge cases from them (I am no electrical engineer though, that might be part of the issue ). A full gate level simulation of the TIA would be great for studying those edge cases, but I have a feeling that just modeling the gates without including "analog" effects wouldn't be enough to get the full picture. For example, the details of the starfield effect almost certainly depend on the exact shape and interference of two different clock signals. Fwiw, the visual6502 project claims to have decapped a TIA and created a gate-level simulation in 2010, and they say they can generate frames from games by combining it with their 6502 simulation, but I haven't seen a public simulation yet. In the case at hand, I was under the assumption that RESMPx would synchronize the missile and player counters into lockstep (this is the reason why enabling it has an immediate effect in Stella and Stellerator, and I guess other emulators implement it similarly). Instead, a look at the schematics shows that enabling RESMPx causes a reset of the missile counter every time the first player copy is drawn. This is the reason why the player needs to be drawn at least once for RESMPx to take effect. This is also described by AT, I just overlooked it The implementation is a NOR gate with 7 different inputs, the output of which is ORed with RESMx (missile position reset). However, the issue (at least for me) is the precise structure of the input: 3 of the 7 inputs come from the player position counter, one is the player render clock, one is the RESMPx itself, but the remaining two are more obscure (at least to me). Looking at the missile positions relative to the first player pixel for the different player sizes (5, 9, and 14) and combining this with the four pixel shift between RESMx and the actual missile position suggests that there are different conditions encoded here that trigger the reset (a particular counter value won't do), depending on player size, and I guess those again depend on relative phase between different signals. So, in the end, I will end up with a combination of my less-then-competent interpretation of the schematics, experiments and educated guesses Edited February 24, 2018 by DirtyHairy 3 Quote Link to comment Share on other sites More sharing options...
easmith Posted February 27, 2018 Author Share Posted February 27, 2018 (edited) One thing I forgot to mention is that I also have the enemy firing a missile , and have the same logic lda #2 sta RESMP1 lda #0 sta RESMP1 back to back in the code. No one has mentioned a problem with the enemy missile not initiating from the correct spot ( I cannot test on real hardware myself). Perhaps someone could test the above .bin file from earlier post . Why would this not be a problem also since it was for P0? I went ahead and made the same fix just in case Edited February 27, 2018 by easmith Quote Link to comment Share on other sites More sharing options...
Mr SQL Posted February 27, 2018 Share Posted February 27, 2018 This is not what happened there, and I wish you would stop spamming threads about this issue and saying the issue is with Stella, and now with Stellerator too. Here's the link with the binary for DirtyHairy and Alex79: http://atariage.com/forums/topic/221197-sprites-stuck-on-supercharger/ Ekhard (that's his code you're working on) wasn't clearing the CPU registers in instances where the target locations contents were unknown, so this code: lda #55 lda Hotspot Results in #55 being left in the accumulator. Looks like a fairly simple bug to correct; if you don't know what's in the target location at least clear the register being loaded, then you'll have much closer performance to the real hardware. Quote Link to comment Share on other sites More sharing options...
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.