Switching resolution erases screen data

[tobiasvl]

When switching from high to low resolution or vice versa in XO-CHIP, the display is cleared. Correct me if I'm wrong, but this is different from how it worked in SCHIP. I believe that in SCHIP, the display is always 128 x 64, but in low-res mode each displayed "pixel" is in fact 2 x 2 pixels large and the DXYN instruction takes this into account. (This is why SCHIP is able to scroll a "half-pixel" up, for example.) Switching modes would just change how DXYN addresses pixels on the screen, and would not erase the screen in the process.

This might have been intentional, but if so the incompatibility should probably be documented.

[tobiasvl]

Hmm, OK, I see that this is intentional based on #90.

[JohnEarnest]

As I understand it, there is no consensus on behavior for transitioning framebuffers from low- to high-resolution modes. Clearing the screen seems, to me, to be a sane option.

Any program which issues a clear immediately before or after a change in resolution will behave the same on any reasonable interpreter, and so I strongly recommend that for any programs which mix resolutions.

[tobiasvl]

I see @Chromatophore has done extensive research on this, as I should have expected. https://github.com/Chromatophore/HP48-Superchip/blob/master/investigations/quirk_display.md

[JohnEarnest]

Indeed. As you can see, the actual behavior of SCHIP is surprisingly complex, yet at the same time quite inconvenient for programmers.

Much like the bizarre behavior of SCHIP's implementation of jump0 and its strange results for sprite collision, I don't think it was thought out in any intentional way and is not worth reproducing in modern emulators.

[tobiasvl]

I don't really disagree. Although it would be nice to be able to run all existing CHIP-8 programs by having control over a million different quirk settings, I guess that's not really Octo's goal.

[JohnEarnest]

Crucially, I am not aware of any extant programs which rely upon the display not being cleared when resolution is altered. The vast majority of software executes hires once shortly after startup. My own Eaty The Alien uses low-res for the title screen and clears after switching to hires.

[tobiasvl]

Crucially, I am not aware of any extant programs which rely upon the display not being cleared when resolution is altered.

I know of only one: Hap's Emutest which tests specifically for this behavior. 😝

[JohnEarnest]

While that is of some historical interest, it doesn't change my decision: lots of "test" roms do weird stuff with no sane basis in reality. There's at least one test ROM out there which only makes sense if it was written with the flawed assumption that vx := random NN produced output from [0,NN] rather than [0,255]&NN.

Octo's opt-in linter does, however, warn users if a program attempts to depend on the state of the screen after changing res: https://github.com/JohnEarnest/Octo/blob/gh-pages/js/debugger.js#L220-L234

[tobiasvl]

Yeah, I totally agree, it was mostly a joke – it was just funny to me that the only program I could find that relies on that behavior is a test program that specifically tests for it.

Wasn't aware that the linter checked that, that's super nifty!