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.

So, it's recently been brought to my attention that I have yet to add support for cheat codes. With my new memory mapping design, I have a couple of implementations I could choose, but I'd like some opinions on what would be best from a user perspective.

GameShark codes are very straightforward and don't rely on any particular implementation; they just write specific values to RAM on every frame.

Game Genie codes are where it gets complicated, because they effectively patch the ROM directly. I have a few options here:

Option 1: Bake cheat code information into the ROM metadata at ROM conversion time, and patch or unpatch the ROM directly when enabling and disabling codes.

Pros:

• Cheat codes can be verified to work with the game at conversion time, and be stored in the most optimal way to parse them.
  
• No runtime performance or memory cost during emulation.

Cons:

• Cheat codes can't be changed without reconverting the ROM.
  
• Patching the ROM involves unarchiving and rearchiving files, which can cause garbage collects. However, since the patchable areas are known in advance, they can be split into smaller (<=16KB) files to reduce archive load.
  
• ROMs could end up in an inconsistent state if the patching process is interrupted (e.g. the user refuses a Garbage Collect).

Option 2: Convert cheat files separately, and load patched segments of the ROM into RAM.

Pros:

• Can easily change cheat codes. If it's in a textual format, they could even be edited on-calc with a text editor.
  
• No archive usage or garbage collection when enabling or disabling codes.

Cons:

• Incurs a performance cost when switching memory banks containing patched data, as well as extra splits in JIT code blocks.
  
• Number of active codes is limited by available RAM (approximately 256 bytes per code).
  
• Cheat code parsing on the calculator is more complex, as well as detecting when the file was edited so codes can be disabled.

Option 3: Same as option 2, but load entire 16KB banks into RAM when they're patched. This significantly reduces the number of possible active codes, but has no performance cost.

I'd also like opinions on cheat code persistence between loads of the ROM. I'm leaning towards saving which codes are active (especially if Option 1 is taken), not as part of save states but as either part of the ROM (in Option 1) or the per-game config file (in Option 2/3).

I think Option 2 is potentially the best - Isn't there a performance hit already in gameshark since it has to modify the ram areas?

Gameshark is pretty negligible, because it only does it 60 times per second (and just one byte written per code).

I like option 2 more, as well as the idea of being able to edit codes on-calc.

I like option 2 as well.

I wonder if there's like an online Gameshark repository that you could append to ROM's at conversion time and then have a Gameshark enable option in the menu to reflect a similar thing to using a real Gameshark ......... sounds like too much work to me lol.

I also guess Option 1-ish is just naturally possible if someone patches ROM's themselves beforehand (romhax).

I just wanted to add that your emulator is really impressive! I am having a great time using it.
Thanks