Emulateur Game Boy déjà pour Casio Prizm fx-CG/Graph 90+E !

[tswilliamson]

The 84+ CE should be able to run the emulator, I plan on doing this in the next few months, though I'm not sure of calc84maniac's plans.

Despite being 48 MHz and in the z80 family (just like the gameboy) It will need a bit of z80 assembly for the CPU core code and probably the draw routines. The reason for this is that the calculator has a pretty horrendous memory clock rate which makes effective emulation 4x slower. I have some ideas how this can be mitigated with caching to on chip memory areas in IO, etc, but it probably won't be as fast as Prizoop regardless.

I actually prefer the overclock in Prizoop over using Ptune 2. It uses the same code as the Ptune2 (provided by sentaro). The reason for this is I've tuned the overclock usage based on your other settings. For instance, less overclocking is needed when you do not scale the screen.

Thanks for the kind words everyone!

[Adriweb]

The 84+ CE should be able to run the emulator, I plan on doing this in the next few months, though I'm not sure of calc84maniac's plans.

Well, what I know is that he's had a hard time getting it to the current state, and that is through insanely optimized assembly.
IMHO, there's absolutely no way at all a C version could work on the CE. Not only with ZDS (which is C89 only btw), but even with LLVM - there is simply not enough RAM and power for something not meticulously hand-crafted specifically for the CE, contrary to the Prizm that is "big/powerful enough".

Note: unless split in appvars (which makes it more complex), the maximum size of a program is 65k.

Another note, here's a reminder of the memory structure for C programs on the CE:


(that said the stack may be a bit different now, I'll have to check with MateoC)

[critor]

The 84+ CE should be able to run the emulator, I plan on doing this in the next few months, though I'm not sure of calc84maniac's plans.

Despite being 48 MHz and in the z80 family (just like the gameboy) It will need a bit of z80 assembly for the CPU core code and probably the draw routines. The reason for this is that the calculator has a pretty horrendous memory clock rate which makes effective emulation 4x slower. I have some ideas how this can be mitigated with caching to on chip memory areas in IO, etc, but it probably won't be as fast as Prizoop regardless.

I actually prefer the overclock in Prizoop over using Ptune 2. It uses the same code as the Ptune2 (provided by sentaro). The reason for this is I've tuned the overclock usage based on your other settings. For instance, less overclocking is needed when you do not scale the screen.

Thanks for the kind words everyone!

By reading the Cemetech topic, I thought your built-in overclock was based on the inferior Pover tool, and not on Ptune2.
Also, there is an hypothesis on Cemetech and Codewalrus, about many fx-CG bricking being related to the use of Pover.

But no problem then - my fault - I'm going to edit the post.

Thank you very much for your valuable post.

[Ti64CLi++]

Arrêtez de vous chamailler comme des gamins critor et Adriweb
Sinon, très bonne nouvelle pour la FX-CG20, j'ai bien fait de ne pas la vendre
Pensez vous qu'un émulateur gba serait fonctionnel sur une telle calculatrice?

[Ti64CLi++]

Et juste petite question pratique, est-ce qu'il fait tourner les jeux gbc?

[critor]

Comme expliqué en 1er post, non.

[tswilliamson]

IMHO, there's absolutely no way at all a C version could work on the CE. Not only with ZDS (which is C89 only btw), but even with LLVM - there is simply not enough RAM and power for something not meticulously hand-crafted, contrary to the Prizm..

Prizm is a bit more handcrafted than it appears. Despite starting from a "working" C emulator which only supported 1 game, I had to invent a number of techniques no one has done before to get it working at a good speed, such as the DMA from on-chip memory to the LCD controller.

Note: unless split in appvars (which makes it more complex), the maximum size of a program is 65k.

I've done some research on this. Paletted VRAM is much more preferable for an emulator anyway which frees up another 75 kb or so. Prizoop has MUCH slower reads from Flash ROM so I have to do a lot more caching, and it only uses about 100 kb more memory than what I'd be able to piece together on CE.

In terms of executable size, Prizoop is pretty large just due to a bunch of inlined C code that won't be used the same way in a z80 based emulator core.

[Ti64CLi++]

Ok, merci, et désolé, je n'avais pas bien lu, je suis désolé du dérangement

[Adriweb]

Prizm is a bit more handcrafted than it appears. Despite starting from a "working" C emulator which only supported 1 game, I had to invent a number of techniques no one has done before to get it working at a good speed, such as the DMA from on-chip memory to the LCD controller.

Oh, I saw that, which is a nice work But I'm only talking about the standard core, or even just parts of it, sadly!
(Note: DMA isn't really fully understood on the CE yet, which is part of why it's not implemented in CEmu (another reason being that it's a PITA to implement)

Note: unless split in appvars (which makes it more complex), the maximum size of a program is 65k.

I've done some research on this. Paletted VRAM is much more preferable for an emulator anyway which frees up another 75 kb or so. Prizoop has MUCH slower reads from Flash ROM so I have to do a lot more caching, and it only uses about 100 kb more memory than what I'd be able to piece together on CE.

There are several things about that (and more tricks in general). For instance:
- Using parts of the VRAM as scratch memory (especially since the low gameboy BPP gives "a lot" of RAM there). Possibly for double buffering etc.
- Using the LCD palette area to have a low-wait-state executable memory (I think calc84 managed to fit 1023 bytes (out of the 1024 available) of critical code in there)

In terms of executable size, Prizoop is pretty large just due to a bunch of inlined C code that won't be used the same way in a z80 based emulator core.

About inline stuff, this keyword isn't even known by ZDS Remember, it's some weird C89 with a whole lot of bugs (both at compiling and linking)
The eZ80 LLVM backend is solving all this but isn't quire ready yet. It could possibly compile the emu, but have fun trying to actually launch the final binary! (if by some luck it links and fits in an .8xp)

[tswilliamson]

I appreciate the details. It's not immediately pertinent as I want to finish Prizoop up with GBC, save state support, etc, as well as make sure it takes advantage of the FX50.

Once I get to it though, in the best case the C code works well, otherwise I'll write it in ASM. It's not something I am unfamiliar with.