Testing on Hardware

[gauauu]

Hey all,

 

I'm slowly working on my first homebrew game, but I haven't yet tested on actual hardware. I have some questions about that:

 

First, how accurate is Stella? If my game runs in Stella, can I assume that it will work on hardware, or is Stella lot more forgiving than the actual machine? (I spent a while doing homebrew on the Nintendo Gameboy Advance and DS, and I often ran into issues on hardware that never showed up in the emulators.) I'm nervous that my timings (number of scanlines, vblank times, etc) will be slightly off and not really work on a real Atari.

 

Assuming I DO really need to test on hardware, is the Harmony Cartridge the only decent way to do so nowadays? I'm not in a hurry to spend that much, but if it's the only proper way to test, I guess I can bite the bullet and do so.

 

Eventually, I'd like to do the "Custom Atari 2600 Cartridge" that you can buy on the store here. Are there any specific cartridge-specific things that I'd need to keep in mind to make sure that my game would run on that? (other than bankswitching I guess? -- I'm using the standard "Atari style 8K" scheme, which looks like it shouldn't cause any issues). Are there any sort of special headers/magic bits/etc that need to be there for the cartridge to work correctly?

 

Thanks!

 

[+SpiceWare]

As awesome as Stella is, it's best to test on real hardware. The Harmony is your best bet for doing so.

[yllawwally]

Testing on real hardware is a necessity. However Stella is topnotch. It's probably the most accurate emulator I've ever used. You're not likely to see much difference. The harmony is really a bargain. It's cheaper that doing the game on chips, and significantly faster. Unless you already own an eprom burner and uv eraser. If you're willing to post your bins, there are many of us here that would be happy to test it on the real hardware. Unless you're using custom hardware, like a new bank switching scheme, the AA store could put practically any game on hardware for you. If it can be run on a harmony, it could be put onto a melody board by AA.

[gauauu]

Thanks. I may end up getting one at some point. Until then, I appreciate the offer of having someone test. I'll let you know.

[gauauu]

Ok, here's an early build of what I'm working on....Ylawwally, would you or someone else here be kind enough to try it on the real deal? (I managed to retrieve my 2600 from my parents' house at christmas, but haven't yet gotten it running on our newfangled TVs!)

 

anguna_20150108.bin

 

 

Eventually I'll start a dedicated thread about the game if I get significantly further along. (For now, suffice to say that it's an attempt at adapting my GBA homebrew game Anguna, a zelda-like game, to the 2600). This build is really early and and full of bugs and unfinished features (Your sprite is invisible at first until you've moved around a bit, the top header bar is messed up, there's some graphical glitches, and it falls apart after the 3rd room) but I'd love to ensure that it actually runs on hardware before I get further along. Basically, you should be able to move around, kill enemies with your sword, and move between rooms. The screenshot above is what it looks like in Stella, so hopefully that's what it looks like on hardware.

 

Thanks to anyone that is willing to try it for me!

anguna_20150108.bin

Edited January 8, 2015 by gauauu

[classiccollector]

So I tried this on my Harmony cart and when going into a new room the screen will flash or roll. When you just go down to about the fourth room your character disappears and it kick you back to the first room. Also the colors are off from what I see in stella to what I see on my TV screen, hopefully my tv screen isn't going bad. No special mods on my atari it is just hooked up normally. Also if your run your character into the enemy where neither one of you can move the game will restart. Doing the same thing in Stella made Stella crash. Seems to be an interesting concept of a game I hope you will complete this, I hope my suggestions have helped. If you need anything else checked on let me know I will be happy to help where ever I can.

[gauauu]

Cool, thanks for your help!

 

when going into a new room the screen will flash or roll.

 

Is that just a real quick flash/roll and then it returns to normal? (Pretty sure I'm taking too much time in the room transition, and running into the next frame. I guess I need to force a blank frame before trying to draw the room for the first time)

 

 

When you just go down to about the fourth room your character disappears and it kick you back to the first room.

 

Yup, I don't have the 4th room implemented, so the door dumps you back into a broken state

 

 

Also the colors are off from what I see in stella to what I see on my TV screen, hopefully my tv screen isn't going bad.

 

Are they significantly different (ie completely different colors?) or is it possibly just the difference of screens?

 

 

Also if your run your character into the enemy where neither one of you can move the game will restart. Doing the same thing in Stella made Stella crash.

 

Can you give a little more detail about how you managed this? (Were you and an enemy were both stuck in a wall during a room transition? Or something else?) I'm having trouble reproducing it.

 

Thanks for your help, I really appreciate it!

[classiccollector]

Sorry about the delay in in responding back to you, My computer died a few days ago and I just got one running yesterday. I will try to get you the info in the next few days. I have to get all my files and reinstall stella and such. I will try to capture video of the incident that I described but usually i got to the bottom of scree by the door way and I head left staight into the enemy and neither one of will move then after about 10-15 secs , maybe less, it just crashes.

[tokumaru]

Just wanted to point out that while flash carts are great for testing homebrew on real hardware, they too aren't perfect. It's not a big deal, but flash carts that run software prior to running the games (as is the case with the Harmony's menu) temper with the power-up state of the console, meaning that when your program runs, the console isn't in it's original power-up state anymore. This is often not a problem if you're careful with your initialization code, but it does happen sometimes that a program doesn't work when run directly because it relied on something that was initialized by the flash cart it was tested with. Just be sure to always initialize memory mapped registers and variables and you should be safe.

 

As for emulators, no matter how accurate they are, there's always the odd edge case that will cause unpredictable results. This is particularly true for the 2600, that has more control over the video signal than any other console, so there are a lot of analog stuff that could go wrong, and that's hard to replicate in the digital domain.

[gauauu]

Hey all, if anyone is willing to test on hardware for me again, I'd be forever grateful! (It's embarrassing that I haven't gotten my Atari in working condition yet!) I've fixed a number of the previous issues, and added a bit of content, although I'm still a long way from done.

 

I've fixed a bunch of the timing issues in the kernel, a number of collision-based bugs, and I'm just HOPING (fingers crossed!) that the screen doesn't roll anymore when you load a new room.

 

Thanks all!

 

 

 

anguna.bin

[Papa]

In Stella you can check your scan count with Alt+L. This will pop up a little counter at the top left of the screen that informs you of how jumpy-rolly-jittery your game may be. I've tested Atari games from the past that are roms of the original games that freak that counter out like crazy, so it's not absolutely perfect in detecting what your screen may do (obviously real hardware is a must and a Harmony cart is just the right tool)! Another thing to consider is what TV you test with. I have a CRT that will usually not jump or roll no matter what the scan count in my game is (I don't break the count too bad, though), and other CRT televisions that will jitter or jump when the others won't. I would recommend testing on at least one CRT and an HDTV. You may also want to consider testing on a few systems as there are often color differences between the older systems and the newer ones.

[CPUWIZ]

the console isn't in it's original power-up state anymore

 

If you rely on that, you have already failed.

[+SpiceWare]

In Stella you can check your scan count with Alt+L. This will pop up a little counter at the top left of the screen that informs you of how jumpy-rolly-jittery your game may be.

 

 

I made a change for Stella to emulate screen jitter and roll. It was added to version 4.6.5.

 

It's not perfect, but it does show problems with both ROMs in this topic.

[gauauu]

 

 

I made a change for Stella to emulate screen jitter and roll. It was added to version 4.6.5.

 

It's not perfect, but it does show problems with both ROMs in this topic.

 

Awesome, didn't realize that was there. Thanks SpiceWare!

[+SpiceWare]

 

Awesome, didn't realize that was there. Thanks SpiceWare!

 

 

No problem. I need to figure out how to implement the "bounce" that happens after a big divergences in scanline counts. Right now it recovers from any difference in a single frame. It should take multiple frames to recover from a large variance, making it more obvious.

[gauauu]

 

 

Right now it recovers from any difference in a single frame. It should take multiple frames to recover from a large variance, making it more obvious.

 

Yeah, that would be even better -- I'm pretty sure my main kernel is fine, but I tend to mess up on transitions between screens/rooms/scenes, which causes one single frame that's wrong. But between this and the Alt+L scanline counts (And being able to put breakpoints on the scanline counter), I think I'm slowly getting most of the issues straightened out.

 

But dang, this Atari programming thing is hardcore

[+SpiceWare]

But dang, this Atari programming thing is hardcore

 

 

Yep - that's why I like it

[gauauu]

Oh man, a friend with a Harmony tested for me, and he said that it doesn't work at all: a few seconds of rolling lines, and then a blank screen. Now I'm back to the drawing board.

 

Are there obvious first places I should start in trying to debug the difference of why it works in Stella but not on the Harmony? (I guess I can always do a git bisect and try going back to an older version that worked, and slowly testing my way through, but first wondered if anybody knew of any common issues that might be biting me)

 

(I'm attaching a version of the rom that's been slightly simplified in order to remove some of my scanline jitter, in case anyone sees anything obvious that I'm doing)

 

 

anguna.bin

[Crispy]

I tried the build of Anguna that you posted on 1/19/16, and found no problems with it on my FPGA 2600 or my Atari 2600 Jr. / Sony Bravia flat panel setup. So, out of curiosity I pulled some signals out of the TIA, and put them on the test header on my FPGA 2600. I found that your vertical sync is stable, but your vertical back porch jitters wildly during gameplay (it's stable while the splash screen is displayed though.) Take a look at this video that captures the scope waveforms. The yellow trace is the vertical sync pulse, and the blue trace is the inverted BLANK signal pulled out to the test header from inside the TIA.

 

 

During the first five seconds of the video, the game is on the splash screen, and you can see that the back porch is stable. Then when I started playing the game at the 5 second mark, you can see that the back porch becomes very unstable. At 11 seconds into the video, I changed the scope setting to zoom in a bit. Counting the horizontal timing at the end of the back porch, you can see that the back porch is changing by as much as 8 horizontal line times. My FPGA 2600 tolerates this, because it uses a counter to wait a fixed amount of time after the vertical sync pulse before it starts using the data from the TIA as active video. I suspect that my 40 inch Sony Bravia flat panel tolerates your timing for similar reasons. But, there are a lot of TVs out there that rely exclusively on the composite signal, and will choke on what you're feeding them.

 

To arrive at a conclusion, I believe that your problem will go away if you write your code so that it maintains a constant number of horizontal line times after the vertical sync pulse before turning off the blanking bit in the VBLANK register.

Edited January 25, 2016 by Crispy

[gauauu]

Wow, thanks for taking the time to help with this, and giving me the detailed analysis of it!

 

On my friend's harmony, he couldn't even get the title screen to display, so I think something else odd was going on (particularly because the title is based on very standard 6-character sample code!). But if it works on your setup, that gives me a lot of hope at least.

 

 

To arrive at a conclusion, I believe that your problem will go away if you write your code so that it maintains a constant number of horizontal line times after the vertical sync pulse before turning off the blanking bit in the VBLANK register.

 

Just to make sure I understand correctly: you're talking about the 37 scanlines that occur between VSYNC and the start of the actual picture, the stuff at the top labeled VERTICAL BLANK in Andrew Davies' tutorial diagram here?

 

Assuming that is what you mean ....I realized a day or two ago that my main update logic is taking too long -- I even have a few cases where, depending on what's happening in the frame, it goes WAY too long and the kernel doesn't start in time, messing everything up. I imagine in many of the frames, I'm taking too long and the INTIM timer has already ended by the time I get to the point where I'm checking it. Looks like I need to optimize things and tighten them up.

 

Again, thanks for taking the time to look at this and help me out!

[gauauu]

Well, I finally got my Atari Jr running, and bought a harmony. Like my friend, I couldn't get the game to run at all on hardware.

 

It turns out that my mistake was that I was trying to jump to my main bank (with a bank-jump routine that used the stack to rts) BEFORE clearing memory, then clearing in my main bank. It worked fine in Stella (even with the "randomize" checkboxes checked), but barfed on the real thing.

 

Once I set it to properly clear memory before doing the rts, it worked fine.

 

Thanks all!

[+stephena]

I know your main interest is in developing your game, but I'd like to look into this issue at some point, possibly thinking how to improve Stella in this area. Specifically, I'd like to figure out what combination of randomization and clearing RAM/registers/etc is triggering the incorrect behaviour. Are you willing to share the source to this, or at least provide test ROMs to figure this out in Stella?

[gauauu]

Yeah, I'd love to help.

 

For my actual game code:

The previous attachment a few posts up demonstrates the problem. I guess it worked fine when Crispy tested it, but it failed on my and my friend's harmony. The source is a bit of a mess (I'm learning as I go, and probably not doing things remotely normally), but is available at https://bitbucket.org/gauauu/stanguna/ If you look at the commit graph, (https://bitbucket.org/gauauu/stanguna/commits/all), the broken version above was built from the commit 978ad4b (labeled "cleanup" on 1-19). The fix labeled "always zero memory before bank jump" (9d364b8) fixed it for me.

 

A simplified demonstration

A simpler example that has a bit less baggage and mess, but still demonstrated the problem on my hardware, is attached. (It still has a little bit of baggage from me adding and removing bits of my real code to try to simplify and find the conditions that broke things). It has 4 banks, the allBanks.asm is common to all 4, which includes the startup routine and bank jump trampoline code. It then immediately jumps to main.asm, where it clears memory, then does another jump to the bank that should show the title screen. (My banks are numbered stupidly, a leftover from the fact that I started with 8k then changed to 16k).

 

Once I added the memory-clearing code to allBanks.asm at the Start label, it worked correctly for me.

 

(one caveat: I'm on a different computer, and I fiddled for awhile late last night with this code, I hope I haven't gotten confused and remembered incorrectly)

 

If you have any questions, or want further explanation or code, let me know!

titleScreenBroken.zip