So this is 100% impossible on the CE? Or just something super difficult that no one will ever try?

The GameBoy Advance has a 2²⁴ Hz (~16.8 MHz) 32-bit ARM CPU, while the TI-84 Plus CE has a 48 MHz 8-bit eZ80 CPU.

That alone might be at least somewhat close (but still too slow) with heavily optimized static binary translation were it not for the wait states the CE has, which makes its effective clock rate more like 12 MHz, which is way too slow. Dynamic translation like TI-Boy does would help in some ways due to being able to take advantage of information only known at runtime, but it would also add overhead for the translation itself, making it probably worse overall. On top of all that, additional processing power would have to be spent emulating other things that the GBA does with dedicated hardware (like graphics).

The GBA also has 384 KiB RAM in total vs. the 406 KiB on the CE, which does not really leave enough room to do emulation of other hardware the GBA has even if the CPU were fast enough (& definitely not enough to handle dynamic translation). GBA games also take up too much space to fit into the CE's flash, & they would be even larger once processed by static binary translation.

So, no, there is no plausible way to make generic GBA games work on the CE. It would be more reasonable to clone individual games (which would involve completely rewriting the code, not some sort of automated translation) if they do not require the full power of the GBA.

Hey, I really appreciate this project and it's been cool to see it evolve over time, and it's a great time killer in study hall. I was just wondering if you were ever planning on adding 4:3 fullscreen so you can set it to fullscreen and not stretch the image too much horizontally? That would be pretty cool tbh

That's not currently planned, because of technical limitations of the design (for performance and memory usage) it's only possible to scale up by 2x horizontally. It may be possible to add a mode to also 2x scale vertically for the correct aspect ratio, though that would require manually panning up and down to see everything. Or it may be possible to have some kind of mixed vertical scaling that would look decent in certain situations, as suggested here.

Thank you for the response, I don't really use the forums much if you couldn't tell by my late response lol.



That's a bit of a shame, but I guess you cant help hardware limitations like screen size lol. Just out of curiosity, did you write this in C or in z80 asm? I can't take a look at the github on this computer because my school blocked it, but if it's in C I may consider dropping by the source to check it out because I tinkered with a few NES emulators for the GBA and DSi and their screens are, although way newer, way lower res, so I got a good look at all the tile scaling scripts. I may be able to implement some, but I'm fairly new to C so I'm not entirely sure.

It's made in optimized eZ80 ASM, no C there.

The GBA and DSi have hardware-based scaling so unfortunately I don't think their techniques would help much. However, I am currently working on a method to make the fullscreen scaling smoother, even if it's still not the correct aspect ratio. This actually is a technique I've heard was used in some NES emulators for GBA to avoid losing parts of the image, i.e. flickering lines between consecutive frames.

Here's an approximate comparison of the old and new methods (nearest neighbor on the left and flicker-based linear on the right):


It's not quite perfect, since I can only blend at a 50% ratio with flickering, but it seems to reduce the unevenness of the lines by a lot. I'll be leaving both scaling methods as an option though, especially since the linear scaling does cost a small bit of performance.

I see a TI-Boy update, I click.

The effect is very nice and I imagine even better in motion. What's the performance hit for such scaling (if any)?

So, the normal penalty for nearest-neighbor scaling (compared to unscaled) is directly copying to the 96 unrendered lines from a subset of the 144 rendered lines. The same penalty applies here, but it must be done on every screen refresh even if frameskip is in effect, to avoid visible flicker.

Fortunately, I'm also able to double-buffer in the LCD's memory and swap between the two as much as I want, so I can cap the overall penalty to at most twice per rendered frame, even at higher frameskips.