Let SCHPC/GCHPC support 64K memory

[tobiasvl]

Not sure if this is out of scope, but it would be cool if SCHPC/GCHPC supported the full 64K of address space.

The 3584 byte limit (and original SCHIP/GCHIP limit of 3583) seems kind of arbitrary – of course I realize it's based on the fact that I and PC can't be set to a value larger than 0xFFF, but in theory there wouldn't be anything stopping them from incrementing beyond that naturally if it weren't for the hard file size limit, so for full compatibility one could argue that the limit shouldn't be there.

In addition, this would let the HP 48 support games that run in both SCHIP and XO-CHIP interpreters. Since games can run code conditionally based on whether the interpreter understands the long instruction, creators can already make backward compatible games that support HP 48 but are enhanced if they run in Octo or another XO-CHIP environment, but these games can't utilize the 64K address space to add those enhancements, so it's not very useful right now.

Of course, this is made slightly harder by the fact that not all HP 48 calculators have 64 K of RAM, so it would probably either have to query the OS for available memory (if this is possible) to be feasible, or be a standalone executable separate from SCHPC/GCHPC... And if it has to be standalone, then it would be tempting to add more XO-CHIP instructions as well, so in that case it definitely is out of scope.

[Chromatophore]

OK, yeah it is probably out of scope but, shall we just, do it anyway? Because I had been thinking of doing it any way. But.. should we just... write a new chip8 interpreter for the hp48, rather than try to reverse engineer it into schip 1.1?

In Superchip 1.0, the program requests a memory allocation of 2000 nibbles for the max rom + an additional 450 or so for the display buffer and all the registers.

Presumably then we can just... increase this number?

Obviously though there's a bit of a shopping list of other things to do if we're going to implement a handler for the double length instruction 0xF0 0x00 0x## 0x## aka i := long address. First of all, can the schip implementation of I support the 5 nibbles needed for 64kb? 5 nibbles long was super common for a word size in the instructions I can remember so it should be alright? There's also questions like, can a double length instruction work well without the interpreter as written exploding?

Then there are questions of: How can we even determine how much memory we can lay claim to? I'm sure there are ways to do this. I mean, we could also request a data area as large as the rom that's provided but obviously that requires people to, y'know, initialise all their data in the rom.

Also, the audio system that is used in XO chip is remarkably/disturbingly similar to how the audio system works on the hp48, too, with on/off square waves. The down side is we don't have a separate thread to run the audio system with so I'm not sure what the realities would be but I mean, there's options to explore.

[tobiasvl]

should we just... write a new chip8 interpreter for the hp48, rather than try to reverse engineer it into schip 1.1?

Yeah, that would obviously be super cool too. I have been toying around with the idea of making an XO-CHIP interpreter for the HP 48 – it's apparently possible to have several shades of gray by alternating how many frames you draw each plane. https://www.hpcalc.org/hp49/graphics/grayscale/

However, what I was thinking with this issue was not supporting long, but simply making SCHPC/GCHPC not crash when loading a ROM that's more than 4K bytes big.

That way, a ROM can use @johnearnest's trick of detecting XO-CHIP support and use only SCHIP instructions in SCHPC/GCHPC, but the same game can make use of XO-CHIP instructions in Octo, and in the latter case also utilize the memory above 4K for that.

Example: A game can be completely SCHIP compatible, except that if it detects that it's running in XO-CHIP with John's snippet, it can play some nice music, and the data for that music could be stored beyond 0xFFF. But on an HP 48 it just wouldn't play the music.

But yeah, like I said, "full" XO-CHIP support would obviously be amazing too!