It's been a while since the last release, so I thought I should make a post about recent progress.
A large amount of my development time over the last year has actually been on CEmu, focusing mostly on improving the SPI and LCD emulation. This allows TI-Boy to be developed on it without resorting to an alternative build to get an image to show up at all, as well as actually being able to develop the LCD-related features. I'm still finishing up some of those CEmu improvements as I research LCD behavior, but it's more than usable enough at this point to continue on TI-Boy as well.
Specifically related to that, I've been working on a smoother fullscreen scaling mode which I showed in a previous post. I'm not fully satisfied with the performance, but it's still very playable and looks solid.
I also implemented proper port unlocking, which allows some code to now be unified across all calculator revisions (like executing code on the SHA256 hardware for speed) and lets me implement much more efficient callstack overflow detection by using the hardware stack protector.
On the Game Boy emulation accuracy side of things, I implemented joypad interrupts, which aren't used by many games but I was able to get at least one homebrew game to work that didn't work before.
As for bugfixes, I fixed an issue with the feature from the last release that attempts to correctly read data that was trimmed out of the ROM for space-saving purposes. Due to a rounding error, it wasn't being called for data that was very close after the trim point, so that data was still being incorrectly read as a buffer overflow from the AppVar as it was in previous versions. That fixes the only game issue that was reported since the last release.
My current development efforts are also related to the ROM trimming feature, improving it further so it allows trimming any byte value from the end of ROM banks and not a global 0x00 or 0xFF (which are the most common signifiers of empty space). This won't have any effect on many ROMs, but for some others the effect is rather dramatic; for example, Zelda: Oracle of Seasons can be packed into 16 data AppVars instead of 21.
The way I implemented this ROM trimming improvement is a jumping-off point for more potential avenues of custom behavior when accessing certain parts of a ROM, for example Game Genie support as discussed in a previous post. Other possible areas of research would be for dynamically loading ROM data when it's accessed, either from compressed AppVars or from external storage. Of course, that may not be feasible performance-wise if there's not enough RAM to cache data long enough to avoid frequent decompression or storage accesses, but like I said, it's just something to research for now. For the next release I would probably only work on cheat code support.
On the side, I played around with one of the USBDRVCE examples to see how feasible it would be to implement linking support. However, it was a bit finicky and I couldn't seem to get the latency I wanted out of it (I was getting 2ms latency for two-way communications and the original Game Boy has only 1ms latency, not to mention the Game Boy Color which could go much faster). That's something I may come back to in the future, but I suppose I'm not really targeting it for the next release.
A large amount of my development time over the last year has actually been on CEmu, focusing mostly on improving the SPI and LCD emulation. This allows TI-Boy to be developed on it without resorting to an alternative build to get an image to show up at all, as well as actually being able to develop the LCD-related features. I'm still finishing up some of those CEmu improvements as I research LCD behavior, but it's more than usable enough at this point to continue on TI-Boy as well.
Specifically related to that, I've been working on a smoother fullscreen scaling mode which I showed in a previous post. I'm not fully satisfied with the performance, but it's still very playable and looks solid.
I also implemented proper port unlocking, which allows some code to now be unified across all calculator revisions (like executing code on the SHA256 hardware for speed) and lets me implement much more efficient callstack overflow detection by using the hardware stack protector.
On the Game Boy emulation accuracy side of things, I implemented joypad interrupts, which aren't used by many games but I was able to get at least one homebrew game to work that didn't work before.
As for bugfixes, I fixed an issue with the feature from the last release that attempts to correctly read data that was trimmed out of the ROM for space-saving purposes. Due to a rounding error, it wasn't being called for data that was very close after the trim point, so that data was still being incorrectly read as a buffer overflow from the AppVar as it was in previous versions. That fixes the only game issue that was reported since the last release.
My current development efforts are also related to the ROM trimming feature, improving it further so it allows trimming any byte value from the end of ROM banks and not a global 0x00 or 0xFF (which are the most common signifiers of empty space). This won't have any effect on many ROMs, but for some others the effect is rather dramatic; for example, Zelda: Oracle of Seasons can be packed into 16 data AppVars instead of 21.
The way I implemented this ROM trimming improvement is a jumping-off point for more potential avenues of custom behavior when accessing certain parts of a ROM, for example Game Genie support as discussed in a previous post. Other possible areas of research would be for dynamically loading ROM data when it's accessed, either from compressed AppVars or from external storage. Of course, that may not be feasible performance-wise if there's not enough RAM to cache data long enough to avoid frequent decompression or storage accesses, but like I said, it's just something to research for now. For the next release I would probably only work on cheat code support.
On the side, I played around with one of the USBDRVCE examples to see how feasible it would be to implement linking support. However, it was a bit finicky and I couldn't seem to get the latency I wanted out of it (I was getting 2ms latency for two-way communications and the original Game Boy has only 1ms latency, not to mention the Game Boy Color which could go much faster). That's something I may come back to in the future, but I suppose I'm not really targeting it for the next release.