Jump to content
IGNORED

problem when testing on real hardware


easmith

Recommended Posts

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.

 

 

 

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

Link to comment
Share on other sites

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/

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

 

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?

Link to comment
Share on other sites

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.

  1. 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.
  2. You could have an error in your code, that happens by chance to 'work' in Stella, but not on a real machine.
  3. 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 :)

  • Like 1
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 by easmith
Link to comment
Share on other sites

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 by DirtyHairy
  • Like 1
Link to comment
Share on other sites

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 ?

Link to comment
Share on other sites

 

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 by DirtyHairy
Link to comment
Share on other sites

 

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 by DirtyHairy
  • Like 2
Link to comment
Share on other sites

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.

  • Like 2
Link to comment
Share on other sites

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

  • Like 4
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

  • Like 3
Link to comment
Share on other sites

Yes.

 

 

I cleaned up a bit those scans some time ago. Here they are if anyone is interested:

attachicon.gifTIA_1A_logic_diagram.pdf

 

Cool, those are much better than the original scans :thumbsup: 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 :P ).

 

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 :P

Edited by DirtyHairy
  • Like 3
Link to comment
Share on other sites

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 by easmith
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...