RevEng

Yep, it all looks right to me!

If you have too much dma going on, display interrupts and wsync hits can get deferred to later lines.

It's not, but I see what you mean. I'll open a ticket. Thanks for the heads up.

I just uploaded a copy of the NTSC bios (updated with additional comments) to my github. (it's not open source, which is why I didn't add it to the 7800 devtools github) The source could use more commenting, for sure, but I'm not seeing a jump to F000. The bios NMI lives at F000, so maybe that's what you're seeing? In any case, search for "26C2" and you'll find the start of the 2600 Init code.

[edit - trebor beat me to it] According to Kevin Horton's 2600 Bankswitch guide, there was only one commercial game that used F4, Fatal Run. The best practice for 2600 bankswitched games is not to assume a particular start-up bank. I tried starting up Fatal Run in different banks using Stella's "-startbank" argument, and the game appears to follow best practice. So it wasn't a problem during the commercial life of the 7800, and shouldn't be a problem for homebrew games that follow best practice.

I have to be a bit careful here, as I'm not able to disclose closed technical details. I will just point out that it's been publicly reported that the 2600+ YM/Pokey emulation works with games that have code to drive these chips but don't physically have them on the PCB.

Great work! Minor suggestion: it would look good if you changed the background color to the sky color below the visible screen. That way the upper overscan area would be sky colored.

When a game doesn't load right, the FPS isn't a matter of emulator performance, but rather the 2600 rom not giving out proper sync signals. The target FPS and actual FPS values being displayed in the debug info match each other, so the emulator is actually keeping up just fine with the (broken) code. Zippy is a 64k rom, and only 16k was dumped, so this is a problem with the current public dumper.

I'm not really sure why you'd want to do that... the embedded size needs to be correct, and v3+v4 headers should be synced for maximum compatibility with emulators and flash devices. Older emulators will ignore any v4 headers present, if they don't support them. That said, if you want to go back to what you had before, 7800header always creates a ".backup" version of your rom. (though if you made changes in two or more sessions, the backup will be overwritten)

Yep, that works. The wrinkle there is you need to run the visible DLL all the way to the bottom of the PAL overscan area (or have a specific PAL version that does that) so you wind up with a different amount of play area between regions. Even with the NTSC version, you need to go a lot deeper than usual, to look right with TVs that have more visible area.

My tinfoil hat is showing, but that suits the corporate push for walled gardens and software licensing just fine.

I think that's a correct prediction. There is no incentive for the AV vendors to correct heuristics that result in false-positives, because any cost to the false-positives is external to the AV vendor.

Virus scanning was added to Chrome a year ago, but it seems a recent update has some very aggressive virus signatures and heuristics.. Apparently the 2600 Halo rom also has malware! There are instructions in that thread on how to disable the check globally, if you so wish. I really don't think stella has a virus, and there's not much to be done here. Unlike other AV vendors, Google doesn't have a process to appeal and white-list a falsely flagged executable. The executables from my open source projects, which are cross compiled on Linux and never touch a windows box, are regularly flagged as containing viruses, though the vendors always disagree on what. They use heuristics like "small download" and "not signed by a developer certificate" ($$$), in addition to overly-small overly-generic signatures that get triggered by a Hello World test.

Phoenix first

Entirely right. The approach of what gets updated just depends on the game design.