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

I don't know if this has been suggested, but if the GBA is impossible, why not try NES or maybe even SNES? I'm not sure how many pixels the SNES has, but both should be possible other than that spec-wise. Very good job with the Gameboy and GBC by the way!

There's no way that the SNES could be emulated at full speed. Not only is the PPU far more capable and the CPU clocked higher, but it's a 16 bit CPU being emulated by an 8 bit (sort of) CPU.

That said, I think that the 84+CE is perfectly capable of emulating the NES at full speed. In fact, I've already started work on an emulator, and will be posting status reports as that progresses. I don't expect it to be in a great state until mid-late summer, especially as it'll probably need a JIT. Calc84Maniac and I were just discussing this on Monday :-)

Actually, I have a base setup for it, I can send you this, but two things: 1. PPU is in need of the most work as a pretty laggy thing, and is not timed with the CPU correctly; 2. Palette is messed up

So...
You know how there's a turbo mode? It would be nice if there was a reverse turbo mode of sorts. It would prove useful in situations where more finesse is required.
Additionally, it would be nice if there was a built in translator for foreign language games. I have no idea how that would work, but it would be nice if it were to exist. I recently added Pokemon Ao(Japanese Blue) to my TI-84 Plus CE(RIP CelSheet), but I have no idea what is being said. If you're going to ask me to get rid of it and try again with a non-Japanese ROM, I know, BUT I want to see the special features of this version for myself.

It would indeed be a nice feature to make the speed limit configurable, instead of just normal speed and unlimited. It's a bit tricky with the current setup because it's synchronized to the screen refresh rate (which in turn is synchronized as close as possible to the Game Boy's), but it might be possible to do something different using timers.

As for auto-translation, that would be a landmark feature in any emulator and certainly won't be a feature in this one. In this case you might be able to find a ROM hack like this one that gives the experience you're wanting.