RevEng

One ground rule that I use... If the jitter duration is longer than a single frame, then you don't have much hope of removing the jitter without crushing the paddle response time. Even with your simple menu application, adding more than a frame of visual lag between moving the paddle and updating the object on screen to that position will make the control feel "floaty" to the player. IMO If the jitter is longer than a frame, then it's the responsibility for the player to clean or replace paddles. A median filter of size 3 on the rolling paddle data can remove single frame jitter (which is analogous to salt and pepper noise that median filters are used on all the time) with only one frame of lag if the removed "jitter" was actually a rapid move. You need 3 bytes of storage, and the compute is relatively cheap. I have more thoughts on paddle filters and the 7800, but they don't fit your application, so I'll leave the filter talk there. In your application, you only need three events required to measure "left, dead, right" zones. (1) resetting the paddle cap, (2) checking if the cap is charged yet at the lef+dead boundary, (and if not) (3) checking if the cap is charged yet at the dead+right boundary. Bear in mind that the time between the three events is proportional to how much the user will have to twist the paddle to move between the zones. Lastly, hitting WSYNC doesn't disturb the 7800's display, generally speaking - it's just stopping the 6502 until the end of the scanline. But you do need to be careful not to hit WSYNC near any NMI, or the NMI will be skipped, which definitely could cause issues if your game uses the NMI for display.

Cookie batter is delicious, even if it doesn't turn into cookies @raz0red implemented souper support in js7800 not that long ago. I know both of your projects have drifted from the original prosystem source, but having access to a similar reference implementation might help you work things out.

This is a 7800basic thing. The hi-score code in 7800basic doesn't call the official hsc routines, because it provides a unified interface and driver supporting both hsc and savekey devices. At first I didn't have hsc init, because I didn't want to accidentally introduce a bug into the init and be the reason some 7800basic game cart got a reputation as an hsc eraser. (the reasoning being, a player would almost certainly have played official release titles before homebrews) hsc init has been added since then, when it became apparent emulated hsc was going to be a pain point, but initially it relied on the mame nvram init values. (0xFF) I added a check for 0x00 fill later, but I just discovered a bug in it that would likely cause the 0x00 init to be skipped. As to what the historically accurate default fill is, it's probably 0x00.

How old is the AtariVox? There was a problem with AtariVox and the 7800 (in 7800 mode) in units sold before December 2019. Technically the problem was also triggered by a 2600 game on some units (the Champ games Wizard of Wor) but it was definitely more pronounced on the 7800.

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.