Clean Assembly

[Hornpipe2]

Every 2600 reference I've seen is a little different about what exactly needs to be done to ensure maximum compatability and stability across systems, emulators and carts. I was really curious what 'safety' type things need to be included into my assembly source file to prevent e.g. improper loading by the various multicarts, etc.

 

My lack of understanding about this goes as far as not knowing when to disable VBLANK relative to WSYNC #3, etc. I know most TVs are a little forgiving about this stuff, but surely someone has some 'best practice' advice?

 

About all I can say for certain is:

* CLEAN_START macro is the safest way to start up.

 

I've also heard that:

* VERTICAL_SYNC macro is unsafe in its current (v1.06 macro.h) form

* Supercharger needs 0s at $FFF8-9 (?!)

* 7800 will freak unless $FFFA-B is 0

 

Hope my question makes sense. I basically want my game to be playable on any 2600 (and Flashback 2) out there, without fear of e.g. accidentally tripping the bankswitching emulation in TheSave50GamesOn1CartCart or whatever.

Edited September 20, 2007 by Hornpipe2

[DEBRO]

About all I can say for certain is:

* CLEAN_START macro is the safest way to start up.

It is but if you need the ROM space it's best to do it without the macro. Generally I don't do SEI and don't set y to 0. It saves me 2 bytes.

I've also heard that:

* VERTICAL_SYNC macro is unsafe in its current (v1.06 macro.h) form

That's not true. You should be fine as long as you make sure to disable the TIA before doing vertical sync.

[vdub_bobby]

* Supercharger needs 0s at $FFF8-9 (?!)

* 7800 will freak unless $FFFA-B is 0

I don't think the 7800 will freak out, but that (or something like it) is correct if you want your 4K game to play on a SC.

[+batari]

* Supercharger needs 0s at $FFF8-9 (?!)

* 7800 will freak unless $FFFA-B is 0

I don't think the 7800 will freak out, but that (or something like it) is correct if you want your 4K game to play on a SC.

Not exactly - you can put whatever value you want in FFF8-FFF9, as long as you don't try to access them Well, to be more exact, you can read the values as long as the addresses on the bus in the next 4-6 cycles are not in the $F000-$FFFF range Well, to be excruciatingly accurate, you can write there as well if you map the 2k bank in question to the first 2k of cart space

 

If you want your game to play on an FB2, avoid RESP multiple-player tricks and certain illegal opcodes (notably, SBX doesn't work even though it is very useful). There are other limitations but they are fairly obscure.

Edited September 21, 2007 by batari

[vdub_bobby]

So what's the list?

 

-disable the TIA before the vertical sync

-don't access $FFF8-9 for SC compatibility (see above for the complex version of this )

-avoid RESP multiple-player tricks and some illegal opcodes for FB2 compatibility

 

There are some 7800 compatibility issues but they've never been entirely clear to me. (Or anybody?)

And there are some HMOVE compatibility issues with late-model 2600 Jr.s, I think, though those have never been entirely clear to me either.

 

And shouldn't you avoid writing to the TIA at all during VSYNC?

 

Relatedly, when Al was building the first Elevators Amiss carts he discovered that the PF write timing is different for some 2600 models!

[+batari]

So what's the list?

 

-disable the TIA before the vertical sync

-don't access $FFF8-9 for SC compatibility (see above for the complex version of this )

-avoid RESP multiple-player tricks and some illegal opcodes for FB2 compatibility

 

There are some 7800 compatibility issues but they've never been entirely clear to me. (Or anybody?)

And there are some HMOVE compatibility issues with late-model 2600 Jr.s, I think, though those have never been entirely clear to me either.

 

And shouldn't you avoid writing to the TIA at all during VSYNC?

 

Relatedly, when Al was building the first Elevators Amiss carts he discovered that the PF write timing is different for some 2600 models!

Some 7800s don't line FE bankswitching, I've heard, and neither does the FB2, but who's gonna write a new FE game?

 

Also, by disable TIA before VSYNC, that means set VBLANK. The games that rolled with the 9-byte VSYNC only rolled when VBLANK wasn't set (but mysteriously, they did not roll with the older VSYNC routine...)

 

You can do stuff during VSYNC if you want. Some games do. And why not? It's 3 scanlines of wasted time otherwise. I've put a horizontal positioning routine there before.

 

The HMOVE incompatibility seems to be with "weird" HMOVEs. Cycle 73/74 work as expected (thankfully) and those at cycles 0 do of course, but those at weird times (e.g. cycle 20) won't work the same as on older consoles.

[DEBRO]

Also, by disable TIA before VSYNC, that means set VBLANK. The games that rolled with the 9-byte VSYNC only rolled when VBLANK wasn't set (but mysteriously, they did not roll with the older VSYNC routine...)

I thought this happened because the screen was still active and we were starting VSYNC 3 times. The other method only started VSYNC once and waited 3 lines. I'm not a hardware guy so I'm not sure this is correct but it was my understanding.

 

And I've noticed at least my 7800s have some timing issues with PF writes. I had the times written down somewhere but can't seem to find them now.

[+batari]

Also, by disable TIA before VSYNC, that means set VBLANK. The games that rolled with the 9-byte VSYNC only rolled when VBLANK wasn't set (but mysteriously, they did not roll with the older VSYNC routine...)

I thought this happened because the screen was still active and we were starting VSYNC 3 times. The other method only started VSYNC once and waited 3 lines. I'm not a hardware guy so I'm not sure this is correct but it was my understanding.

 

And I've noticed at least my 7800s have some timing issues with PF writes. I had the times written down somewhere but can't seem to find them now.

Yes, the screen is still active if you don't properly turn on VBLANK (or am I forgetting something?)

[SeaGtGruff]

Also, by disable TIA before VSYNC, that means set VBLANK. The games that rolled with the 9-byte VSYNC only rolled when VBLANK wasn't set (but mysteriously, they did not roll with the older VSYNC routine...)

I thought this happened because the screen was still active and we were starting VSYNC 3 times. The other method only started VSYNC once and waited 3 lines. I'm not a hardware guy so I'm not sure this is correct but it was my understanding.

 

And I've noticed at least my 7800s have some timing issues with PF writes. I had the times written down somewhere but can't seem to find them now.

I was doing some searches for "VSYNC" in the old Stella/Dig archives the other week, and saw some discussions about problems with VSYNC and screen rolling on some games (not homebrews, but actual Atari-released games). One idea that was suggested was that it had to do with performing other tasks during VSYNC, as all of the games in question were performing other tasks (positioning sprites, etc.). But that shouldn't matter, because as long as VBLANK is on, then the TIA shouldn't be sending any video information that would interfere with VSYNC. If I remember correctly, the real culprit turned out to be that VSYNC was being turned off too soon-- or maybe VSYNC was being turned on too late, I forget. In any case, as long as VBLANK is turned on before turning on VSYNC, and as long as VSYNC is turned on during the horizontal blanking interval-- but *before* the horizontal sync pulse has ended-- and as long as VSYNC is left on for three full scan lines (to get six *complete* long pulses), then there shouldn't be any problems (assuming, of course, that the scan line count is correct).

 

Michael

[Nukey Shay]

* Supercharger needs 0s at $FFF8-9 (?!)

* 7800 will freak unless $FFFA-B is 0

I don't think the 7800 will freak out, but that (or something like it) is correct if you want your 4K game to play on a SC.

Not exactly - you can put whatever value you want in FFF8-FFF9, as long as you don't try to access them Well, to be more exact, you can read the values as long as the addresses on the bus in the next 4-6 cycles are not in the $F000-$FFFF range Well, to be excruciatingly accurate, you can write there as well if you map the 2k bank in question to the first 2k of cart space

 

It was also mentioned that a single-byte instruction placed at $xFF7 could also inadvertantly trigger a bankswitch in an F8 game. Dunno if the same holds true for the Supercharger as well...but I just avoid placing any subroutine or interrupt up there where an RTS/RTI would exist at that address. I generally move all data to the upper reaches of ROM when hacking games...since there's a higher probability of saving space with the instructions and data segregated (more chance of being able to share program instructions or data tables...less chance of branches being out of range).

[SeaGtGruff]

* 7800 will freak unless $FFFA-B is 0

I would think that the 7800 might freak *if* $FFFA-B is 0. After all, it's the NMI vector, and wouldn't you want the NMI vector to point to valid code? Surely the registers at $0 can't be valid code? It would make more sense to set $FFFA-B to the same address as the reset vector.

 

Michael

[+batari]

* 7800 will freak unless $FFFA-B is 0

I would think that the 7800 might freak *if* $FFFA-B is 0. After all, it's the NMI vector, and wouldn't you want the NMI vector to point to valid code? Surely the registers at $0 can't be valid code? It would make more sense to set $FFFA-B to the same address as the reset vector.

 

Michael

Although the Maria has access to the CPU's NMI line, I'm 99% sure the Maria is disabled in 2600 mode with no possible way of re-enabling it. And since neither the cart port or the expansion port has access to NMI, I'd imagine that it really doesn't matter what the vector is.

[SeaGtGruff]

Although the Maria has access to the CPU's NMI line, I'm 99% sure the Maria is disabled in 2600 mode with no possible way of re-enabling it. And since neither the cart port or the expansion port has access to NMI, I'd imagine that it really doesn't matter what the vector is.

That's what I had suspected, but I wasn't sure if the NMI vector might cause some sort of weird glitch if an NMI somehow occurred as the 7800 was powering up (if that's even possible). In any case, setting the NMI vector to point to a location that doesn't contain any executable code, on the pretext that failure to do so might cause the 7800 to freak, sounds like a crazy urban legend.

 

Michael

[Hornpipe2]

Thanks for your input guys, this has been really helpful. So to put together a list of 'things to do to ensure compatability' we have:

-disable the TIA (by enabling VBLANK) before the vertical sync

-don't access $FFF8-9 for SC compatibility (see above for the complex version of this )

-avoid RESP multiple-player tricks and some illegal opcodes (e.g. SBX) for FB2 compatibility

-Set the NMI vector to point to the same location as the Reset vector (though this may be pure superstition)

-Be cautious in your use of the TIA during Vertical Sync period

-FE bankswitching may cause problems on an FB2 or 7800

 

Two questions:

1) Single-byte instruction at $xFF7 could trigger an F8 bankswitch

should that read $FFF7 instead of $xFF7?

 

2) avoid RESP multiple-player tricks and some illegal opcodes (e.g. SBX) for FB2 compatibility

can someone elaborate on this? What in particular doesn't work?

EDIT: http://www.atariage.com/forums/index.php?s...75267&st=25

Avoid SBX and ARR, at least.

Edited September 27, 2007 by Hornpipe2