Hacking EZ-FLASH Junior TestFlight

  • Thread starter Thread starter EZ-Flash2
  • Start date Start date
  • Views Views 364,727
  • Replies Replies 1,300
  • Likes Likes 11
Hurry up, it can't be that complicated! :whip:
I need it for Pokemon and my girlfriend for her GBC without CPU suffix.
I would even go with the latest version that you took down, if I had a link. Most peoples SD-card are fast enough anyway. Just make it idiot proof with a big disclaimer for people with slow cards.
 
  • Like
Reactions: WiLLiW
Hurry up, it can't be that complicated! :whip:
I need it for Pokemon and my girlfriend for her GBC without CPU suffix.
I would even go with the latest version that you took down, if I had a link. Most peoples SD-card are fast enough anyway. Just make it idiot proof with a big disclaimer for people with slow cards.
It can't be THAT complicated right? interpreting ARM instructions in HDL and properly managing everything in-between of loading from an (MMC)SD card opposed to a simple ROM + mapper that's expected by the GBC whilst running at two different clk speeds, so having to perfect math the shit out of it to get it as close to OEM as imaginable.

It's not rocket science though guys, just finish it already!! :p1ng:
 
  • Like
Reactions: Xalusc
they have been working on this update pretty much since the time you registered on this this site. Its never going to happen lol
Exactly! It's like to watch a dragon ball z fight! It's like to wait to Half-Life 3! Or Sega Dreamcast 2! Or a good Star Wars sequel! More the waiting, more the final results!
 
  • Like
Reactions: GASH and limpbiz411
Exactly! It's like to watch a dragon ball z fight! It's like to wait to Half-Life 3! Or Sega Dreamcast 2! Or a good Star Wars sequel! More the waiting, more the final results!
i believe we have a better chance to see half life 3 drop before the update happens.
 
  • Like
Reactions: GASH
It can't be THAT complicated right? interpreting ARM instructions in HDL and properly managing everything in-between of loading from an (MMC)SD card opposed to a simple ROM + mapper that's expected by the GBC whilst running at two different clk speeds, so having to perfect math the shit out of it to get it as close to OEM as imaginable.

It's not rocket science though guys, just finish it already!! :p1ng:
This.
If it's "not that complicated", go on and learn Intel 8080 and Zilog Z80 Assembly and GBC architecture and make a better FW yourselves. It's easy, right?
 
  • Like
Reactions: Shadow#1
It can't be THAT complicated right? interpreting ARM instructions in HDL and properly managing everything in-between of loading from an (MMC)SD card opposed to a simple ROM + mapper that's expected by the GBC whilst running at two different clk speeds, so having to perfect math the shit out of it to get it as close to OEM as imaginable.

It's not rocket science though guys, just finish it already!! :p1ng:

This.
If it's "not that complicated", go on and learn Intel 8080 and Zilog Z80 Assembly and GBC architecture and make a better FW yourselves. It's easy, right?

You guys are making one vital mistake, hardware rarely works how it should and is full with bugs. You don't notice that in reallife that much because drivers are written to handle these mistakes.

For example how annoying it is to find hardware bugs is the GBA hardware bug that makes an infinite loop finite.
More about this bug can be read here: https://mgba.io/2020/01/25/infinite-loop-holy-grail/
 
You guys are making one vital mistake, hardware rarely works how it should and is full with bugs. You don't notice that in reallife that much because drivers are written to handle these mistakes.

For example how annoying it is to find hardware bugs is the GBA hardware bug that makes an infinite loop finite.
More about this bug can be read here: https://mgba.io/2020/01/25/infinite-loop-holy-grail/
We were both being incredibly sarcastic. But thanks :D!
 
Hurry up, it can't be that complicated! :whip:
I need it for Pokemon and my girlfriend for her GBC without CPU suffix.
I would even go with the latest version that you took down, if I had a link. Most peoples SD-card are fast enough anyway. Just make it idiot proof with a big disclaimer for people with slow cards.
Tottaly agree! And also, Pokemon is the way :tpi:
 
  • Like
Reactions: GASH
Yay! It's about time! :grog:
When is the next update coming? So, there is an unnoficial EZ-Flash Jr. scene going on?
The next update will come... whenever I have time. Although there isn't much to add to this particular thing other than detecting the system type and reducing load times for non-SGB systems.

But this is really just a quick and simple hack. Looking forward, Daid has been reverse engineering the communication protocol and I've been looking at the hardware side of things. So a custom kernel is on the horizon. What's lacking for the both of us is time to work on it. But a custom kernel would potentially have a much better user interface.

What I would also like to do is replace the first stage bootloader (which is in the firmware). I've been researching how to do this without access to the source code, to achieve SGB compatibility. It's possible but really difficult. But this is a less important aspect because EZ Flash Team released FW5 SGB version and I also came up with this method of SGB support later. And if I ask EZ Flash directly they can maybe make a special firmware version if I send them a ROM.

These are the relevant Github repos:

https://github.com/daid/OpenGBLoader (Simple proof of concept ROM loader.)

https://github.com/daid/ezflashjr (Collection of software and hardware info about the EZF Jr.)
 
The next update will come... whenever I have time. Although there isn't much to add to this particular thing other than detecting the system type and reducing load times for non-SGB systems.

But this is really just a quick and simple hack. Looking forward, Daid has been reverse engineering the communication protocol and I've been looking at the hardware side of things. So a custom kernel is on the horizon. What's lacking for the both of us is time to work on it. But a custom kernel would potentially have a much better user interface.

What I would also like to do is replace the first stage bootloader (which is in the firmware). I've been researching how to do this without access to the source code, to achieve SGB compatibility. It's possible but really difficult. But this is a less important aspect because EZ Flash Team released FW5 SGB version and I also came up with this method of SGB support later. And if I ask EZ Flash directly they can maybe make a special firmware version if I send them a ROM.

These are the relevant Github repos:

https://github.com/daid/OpenGBLoader (Simple proof of concept ROM loader.)

https://github.com/daid/ezflashjr (Collection of software and hardware info about the EZF Jr.)
Wow! You're my new gb programmer God! Do you think in release a flashcart too?
 
progress report
 

Attachments

  • B3A6A9DE-9464-446C-8C06-7FAE7D2F2AB0.jpeg
    B3A6A9DE-9464-446C-8C06-7FAE7D2F2AB0.jpeg
    462.5 KB · Views: 216

Site & Scene News

Popular threads in this forum