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.

No worries. I didn't realize you were modifying the DLL pointers to DLs, instead of the character object addresses. You can add the 4 objects to all of the DLs, but then point past them with the DLL pointers for all zones except the last.

It works with characters, but as you observed, the last zone needs 4 objects inserted before the character objects. It's true whether you use sprites or characters for the background. You just need to handle the bottom zone as a special case. The easiest way to do that is to just add 20 bytes of pre-padding to the last zone DL, but have your tables with DL locations skip over that 20 bytes of pre-padding. Then your special case for the last DL is just to point the DLL at the pre-padding, which can be done in your DLL build routine. Of course, that assumes you aren't otherwise running out of DMA on the line, even without the 4 objects.

I wrote a proof of concept a while back. I need to get back to it and turn it into a real game, rather than just a display test, but all of the enemies use 320c. phoenix.bas.a78

AV is the scourge of open source projects, for the last decade or two. The cost of false positives is externalised to the open source devs, who are asked to prove to several vendors that each and every new project release doesn't, in fact, contain a virus. Or you buy an expensive developer certificate, which lasts for a year, and still doesn't help with all AV engines. I'm not happy to see the AV scourge spread to our retro platforms that cannot have viruses.

I wouldn't sandpaper, personally. Erasers are good for cleaning edge contacts - gum art ones first, and if they need it, the rougher pink ones. Brasso is a good one too. Follow any of these up with alcohol.

What can be displayed is a function of the display kernel, though the 2600 has limits on how many players can arbitrarily be positioned on any one scanline. i.e. there are just 2 players, and their regularly spaced copies. There are some kernel tricks that can be employed, like in galaxian 2600, but it still doesn't allow "arbitrary" positioning of those player copies. Have a look at using the bB multisprite or dpc+ kernels . Using those you can have more players on the screen, but you will still get flicker when you try to put more than 2 players on the same horizontal strip, because that's a 2600 fundamental limit. If none of the alternate bB kernels are suitable, you'd need to learn assembly language and how to create your own display kernel. Even there you won't be able to get past the fundamental limits, but you can reuse objects as you see fit in different horizontal bands of the screen, which may or may not be helpful for your game design.

The standard kernel is full, in terms of cycles per scanline, but also in terms of display objects. To display other items, like your values, you'd need to flicker them, using one frame to display a game object, and another frame to display the math value.

If you want to lose 20% of the vertical resolution, I guess it's theoretically possible.

The shimmering when vertical scrolling is a known issue, and has been present since the original factory firmware. Like you mentioned, it's due to non-integer scaling. Not much to be done there.

You're welcome! Unfortunately there's no way to crop the screen or have black bars covering up those non-playfield area.