Welcome to the personal blog of Archerite

  • Archerite

    BatteryCheck DS - Finally made the external RAM work!!

    For days I have been trying to write a small tiny buffer into the SuperCard miniSD and the offical memory expansion pak from the opera browser. At the same time I have been searching for an emulator that supports the expanstion pack and desmume seems to support it but has hardcoded detection to enable only for the browser ROM. I might need to dive in and figure out a way to add a command line switch to enable it later, but since I can't even write a tiny 1024 byte buffer into it on real hardware what is the point right?

    Well, only a couple of minutes ago it hit me!!! OMG!!! I forgot to change the SLOT-2 owner to the ARM9 that is required on the DS to get access to the GBA address space!! I remembered it from my GBA rom validator app that I needed to do that! I feel so dumb now! :shy:

    That tiny 1024 byte buffer can't be anything special you might think, well it's only the palette for the image I posted yesterday but it's proof that it's finally working!! And it's not just the memory expansion pak that;s working but also both of my SuperCard mini SD cards that work now! This means my crazy idea to "stream" the ZIP file might not be required after all and I can just load it up entirely into the RAM on the SuperCard. When the expansion pack is used I might need to figure out another method to lower the memory requirements a bit. maybe just loading the 5MB block of setup.exe that I really need to read from has to be in RAM actually and I just translate the file offsets and stuff......sorry getting excited again and going into technical details!:D

    I'll keep it short this time, but just wanted to say the DLDI driver for the SuperCard still does not work if I first enable the SLOT-2 ownership unfortunately. But if RAM mode IS working on the GBA then I might be able to load a ROM from the SC menu and have it switch to RAM mode allowing it to use the extra RAM to unpack and convert the graphics into tiles and tilemaps ON the GBA itself! :D

    Going to test a few things now before this posts get's too long again. :lol:
  • Archerite

    BatteryCheck DS - A little progress on this one and explaining why I moved to this one from the GBA.

    I wanted to make this a "short update" on my DS progress but failed hard on that one, hahaha:rofl2:. To reduce the damage I put a lot of it in spoiler blocks so read them if you like...or not;). This is really just a way to share my thoughts and clear my mind and show what I am doing for those who follow the BatteryCheck remake adventure.

    My homebrew adventure spans many platforms already and I have a few threads open about the Wii/GameCube version here which is kind of the main thread about the development and progress. I also have a 3DS version here and worked on it for the PSP too but that one is not released. Or playable even because of issues with the devkit and generating the textures in the correct PSP format. And the list of platforms does not even end here....but that is a discussion I have already talked about a lot on my blogs :lol:

    My recent rediscovery of the GBA and expanding my library of physical games sparked my interest in porting BatteryCheck to the GBA. While I really think it will be possible in theory it requires a flashcard with writable RAM inside that I can use. My first target for memory will be the SuperCard MiniSD because it's dirt cheap and I have two or three of them ( and even bought a few more to play with :D) I know they are crappy flashcarts and the EZ Flash omega is considered the best cheap alternative to an Everdrive this is what I have for now. I did receive the Omega a few days ago though so I might change my mind on which cart to use first;)

    To explain why I moved to the DS and not continue on the GBA is because of missing and outdated libraries and examples. And no doubt my inexperience on the platform:P. I have bashed on libgba and libfat a few weeks ago but I have to admit things are not as bad as I thought actually. It's just not as complete as I am used to and libnds has soooo much more convenient helper functions and abstractions that makes everything a lot easier. The good thing though is that the DS has evolved from the GBA and therefore the GPU in both of them is very similar except for the 3D support ofcourse that the DS has. This similarity will help me later porting stuff back to the GBA when the DS version is running well enough.

    What helps the most though is that everything just seems to work on the DS. My rant about libfat and DLDI on the GBA is litteraly "plug-and-play" on the DS. The 4MB onboard memory makes converting the graphics on the DS much easier and with DLDI I can read them from any card a user throws at it (as long as there is a driver for it ofcourse). And after a few hours the installer actually worked perfectly and extracted all files from the Setup.exe like it should. Only thing that is not yet working is extracting setup.exe from the downloaded zipfile which would be more user friendly, it needs 12MB of RAM to load it in though....and the DS only has 4MB so that's not gonna fit in there is it.:rofl2: I have tried multiple things to work around it but it means rewriting (or cleaning up) my installer code a bit so it reads the setup in a smarter way I like to call multi-layer-streaming, hahahaha.:D
    So how does one use multi-layer-streaming to extract the gamefiles??? Well I would need to explain a bit how my installer is working right now or it will not make sense at all I think. So what happens is the installer searched for the ZIP or EXE in the root of the storage device. If it finds the ZIP it assumes it's the original 12MB file downloaded from the instruction...without much checking if it is. With this original file I know EXACTLY where setup.exe is stored and how big the compressed size is. I am not using a ZIP file library at all to extract it but just blindly load it into memory which requires about 12MB to store the entire file. This has not been a problem on my PC, Wii, GameCube, 3DS or PSP which have enough RAM to store that file and unpack the gamefiles after that. (not sure though I have even tested this on the PSP....but it has 32MB RAM so it should fit ;)).

    To lower the required memory there are actually two options:
    - Extract setup.exe from the zip file and write it to the SD card (wasting 12MB of space and more junk on the card)
    - Load the setup.exe with a "streaming wrapper" that uses a sliding window into the file

    The first option is easy but would be my last resort for multiple reasons. Not only is writing to the SD slow there is also a risk of corruption and it means more wear of the card that I think can be avoided with my second option. By implementing a sliding window that moves over the 12MB file containing decompressed data just before it's requested by the installer for a game file I hope to reduce the requirement to 64-128kb of RAM to extract the files!! That is a considerable reduction from 12MB that would be required for reading the entire file into memory all at once right! :D

    I have no idea if this method is going to be slow or if it's useful on the other platforms that have the 12MB to spare for just reading it all into RAM. This means this trick will only be usefull on the DS, GBA and anything else that has lower specs and not enough RAM.

    While the above is a bit of a summary of how and why I am now working on the DS version of my homebrew instead of the GBA, I do have some progress to show in the form of a picture...which I really want to share but have doubts about since it's a bit complicated with the rights of using these graphics. Since it's an unaltered version of the original menu graphics that is just reduced in size to fit on the DS screen....and this is about the BatteryCheck game and I am not using it for commercial purposes.....hopefully this is considered "fair use" :shy:. Here it is:
    20200703_103948_small.jpg
    This simple screen shows on real hardware that I can load the graphics and convert it directly on the DS and then use hardware scaling to make it fit on the small screen. It looks a little better in person because the screens are a bit bright for my camera (note 9) but for this purpose I think it's good enough.:) It may look so simple to "convert graphics and include in homebrew" from PNG, JPG and such right? Well, sure to get started that's quite simple with the provided tools....but I am not using any of those! This image is loaded directly from the original game files (Data.j2d in this case) and decompressed using zlib. The palette had to be converted from RGBA (8bit per channel) into BGR(5bit per channel) and the pixel data had to be copied to the correct VRAM addresses and background setup. To make it clear: I am not complaining or bragging (much:ha:)....just proud that it actually works now! :D

    Getting this working on the GBA later is going to be a HUGE challenge as it requires nearly 1MB of RAM to do all the conversions. I need to load this actual image which is already 300kb on it's own. Then I need another image that shares the palette with it for some reason so another 300kb. Then I need to cutout a section of the 640x480 image to fit into the 512x512 background buffer requiring another 256kb. Converting the palette takes less than 1kb, but adding it all together requires a LOT of RAM just for this one image! Scaling it down is done by the GPU so that does not require extra RAM fortunately.

    The idea is to optimize this in more ways that I can think of right now. But I want to resize them during loading and keep the resized versions in RAM whenever possible. Or maybe resize it in smaller groups of pixels using tiles...but the image is stored as a large bitmap right now. Anyway, the DS has the memory to do this so it's not yet a big problem. I was thinking of showing this screen when the installer has unpacked data.j2d and then continue or something....just to add some more fun into it. :D
    The DLDI system that works great on the DS and a lot of drivers are available for many devices...they are very much outdated and not updated anymore. While the SuperCard SD has a DLDI driver I can't seem to make it work. Not on the DS and not on the GBA! Since this is my biggest requirement for getting BatteryCheck running on the GBA I really need to get it working. I hope with some testing to at least make sure the driver is OK or that maybe the SuperCard Mini SD actually needs another driver or some tweaks. Or maybe it's just the SD card interface that does not work but I might be able to hijack the RAM inside after my homebrew has loaded. It's just a matter of writing some bytes to some address to unlock it.

    If I really want to test things out I can always try out GBFS and see how that works. Then I can at least open the files on the GBA and see what's possible with the unlocked RAM. While I can not release a GBA version with the GBFS files included I could wrap it up into a generator that runs on the DS. (crazy idea ofcourse, but possible) Then it would unpack just like it does for the DS version and generate an optimized GBA version that gets attached to a GBA rom file. For a user that would just mean: Drop batterycheck.zip on the SD card and run "bc_setup-for-gba.nds" and wait a while for it to finish.Then you will have a ready to run ROM that works on the GBA:D

    Thank you for your time. :)
    plasturion likes this.
  • Archerite

    BatteryCheck GBA - A struggle with libraries....pushing me to the DS instead!

    My previous blogs have been full of complaints about libgba already but we can add libfat to the party aswell! In the days with many different flashcards on both GBA and DS there were issues with compatibility for homebrew and a solution was created called DLDI. In simple terms it allows for a driver to be patched into the homebrew that enables it to access the specific flashcard hardware. And this DLDI layer then gives libfat something to talk to and access the files on the flashcard. This works great on the DS with it's many variations of storage options that used SLOT-2 and later SLOT-1 cards that auto-patch the specific DLDI driver at runtime. This way homebrew was compatible with any card that had a DLDI driver for it and you would think that DLDI was the solution then right?

    That's where I get to my point and the struggle mentioned in the title....for many hours I have tried to solve outdated compiler issues on a modern toolchain. But no matter what I tried DLDI seems to only work for DS and unlike this site makes you beleive it does NOT WORK on the GBA!! At least not without patching libfat to make use of it that is!!! You see, the DLDI layer is present in libgba for libfat to talk too but it does not. So I dived into it and figure out how to make DLDI work on the GBA and load a driver for my SuperCard miniSD. Just to not scare anyone I put the code example into a spoiler block, but it shows and explaines what's missing to make DLDI work on the GBA.

    Code:
    /* ====================== NDS ====================== */
    #elif defined (NDS)
    #include <nds/system.h>
    #include <nds/memory.h>
    #include <nds/arm9/dldi.h>
    
    const INTERFACE_ID _FAT_disc_interfaces[] = {
        {"sd",  get_io_dsisd},
        {"fat", dldiGetInternal},
        {NULL, NULL}
    };   
    
    /* ====================== GBA ====================== */
    #elif defined (GBA)
    #include <disc.h>
    
    const INTERFACE_ID _FAT_disc_interfaces[] = {
         {"fat", discGetInterface},
        {NULL, NULL}
    };   
    
    I am sure without programming experience you might not see what's happening here. In the fist section labeled NDS it includes header files telling the compiler about the memory address and value types used by libnds. Then it tries to detect the DSi SD cardfirst and then a DLDI driver. Below that is a section labeled GBA and it calls a different function named discGetInterface() that is part of libgba. This function in theory loops through a series of popular GBA flashcarts and tries to initialize one of them. This explains why it takes a little while for fatInitDefault() to fail on the GBA as it needs to try every single one of those drivers first. Even while the SuperCard SD is included mine are not detected. Possibly they are clones that work differently or the SCSD is truly different form the miniSD version that I have.

    Funny thing is that libgba actually has a dldiGetInternal() function but it either not used (anymore) or it never was! Or for those that wanted to make use of it had to do just what I have done....and replace the function "discGetInterface" with "dldiGetInterface" and compile it myself. So while I can't complain it's not available at all this time ;)...it is hidden deep inside the libraries and absolutly NO clue on how to use it! At least I did not find anything!

    So what I did was add the DLDI header and changed the function name to have libfat compatible with the dlditool:
    CODE]/* ====================== GBA ====================== */
    #elif defined (GBA)
    #include <disc.h>
    #include <dldi.h>

    const INTERFACE_ID _FAT_disc_interfaces[] = {
    // {"fat", discGetInterface},
    {"fat", dldiGetInternal},
    {NULL, NULL}
    };[/CODE]
    And by recompiling libfat with these changes and having my Makefile use this one instead of the one included in Devkitpro I could finally patch in the DLDI drivers I had found for the SuperCard SD. Unfortunatly the card is not detected and I still get errors from fatInitDefault()! Using the GBAMP CF driver was a little more successful as it passes the initialize function and can read files from the card. It also created the directories required during the BatteryCheck install and all filenames are created....as empty files with 0 bytes!! I am not sure if this was because of the DLDI driver or an issue of running out of memory which is sparse on the GBA ofcourse. Even with DLDI patching working now it's useless if the drivers are apparently not working!
    Because I wanted to make sure the DLDI drivers are actually working I wanted to try them on the DS. So I have ported over my "GBA abstraction layer" to the DS and that was quite easy since they are very similar. I first tried writing to the SD card of the SuperCard DS One which does auto-patching for it's DLDI driver and just magically works! I also have an M3 Simply and that did not work at first until I read it needed manual patching with the "R4 drivers" as it was noted somewhere that might work. And it did! On both SLOT-1 cards the files are extracted and I checked the SHA1 hashes of the extracted files which were a perfect match! Funny how my attempt of porting to the GBA ends up working earlier and better on the DS instead! Even when it's really only the installer unpacking the gamefiles that's currently running:D

    What is not working in the DS installer (yet) is unpacking setup.exe directly from batterycheck.zip as that file is 12MB and that does not fit into the DS or GBA onboard RAM. The reason for that is that on the other platforms I can simply unpack it entirely into a 12MB buffer because the RAM is available, and it's MUCH faster this way too. Maybe I should rewrite it a little to switch to unpacking the file to the SD card on the DS for now and either delete it when done or leave it there. That should at least make it possible to just drag and drop the ZIP file onto the card I guess :D
  • Archerite

    BatteryCheck - GBA: Planning ahead of what needs to be done first.

    When working on a game you need a lot of files like Graphics, Sounds, Levels, etc...and for my homebrew remake BatteryCheck those files are not my property. To prevent any issues with the Creative Commons license the instructions required you to download a zip file and run the setup.exe inside on you're windows PC (or in Linux with wine). After that you had to manually copy certain files to the SD card of you're console so my preview game could use them. The files are converted on the platform they run on at runtime and thus I do not need to store or redistribute the graphics :).

    While this worked the need to first install it on a PC seemed not very user friendly too me so I researched how I could just extract the game files I need from the Setup.exe. It took me a few months last year and some serious reverse engineering to figure that out!! But I think it was worth it in the end. You still need to download the Zip file yourself and that will stay this way forever I think, but with the details I discovered about the setup extraction process I was able to write an installer that does this...directly on your console! :D At first you still had to extract the Setup.exe from the zip file but even that is no longer necessary since my installer takes care of it. It does require the authentic ZIP file from the instructions though...since I made a very simple unpacker ;)

    I thought this little history about the installation process was required to understand the issues I will talk about now. The consoles I have the installer working on right now all have plenty of memory to unpack the files directly in RAM and that makes it both simple and relatively fast. But it needs almost 12-16MB of working space to unpack those files and an SD card to store them! And the poor little GBA only has a tiny 256kb of RAM (and a few special ones for a total of 288kb;)) and without a flashcard no place to store the unpacked files. I already talked about using the ROM/RAM inside a flashcard as extra memory on my blog a few times and there is really no way around that. So that will be my first step: Make use of the RAM inside a flashcart with a homebrew program. I have found sourcecode to access the SuperCard's RAM and the EZ flash Omega has plenty of details about it, and I assume the Everdrive has something available too. So using a flashcart's RAM solves the problem of working RAM as all three I mentioned have 32MB and as a bonus they also have an SD card reader to load and store the files on! How convenient right! :D

    Then what is the first thing to do? Well, porting my installer to the GBA and have it load the setup.exe into RAM and extract the required files to the SD card ofcourse! :lol: The advantage of doing this first is that I can experiment with a few things on the GBA and the output is still just text about the current file and the unpacking progress. I really want to improve the interface but it's no priority since you only see it once:wink:

    I have been quite active with blogs lately....not sure if i'll keep doing it but it does clear my head and that helps:).


    EDIT: After adding the driver layer for the GBA to my installer compilation was successful! And I get a very pretty red error screen about fatInit() failed :cry:....no matter what I tried it seems libfat is not detecting my SuperCard MiniSD. The frustrating part is that the driver for the SCSD is included in libgba but I have NO CLUE how to make libfat use that thing! No examples! No explanation! How the :shit: should anyone know how to make use of that stuff!!!!! :angry: Then I remembered I have a GBAMP CompactFlash that did work to dump the bios with the provided example! And guess what....the thing actually works!!! I mean, libfat initializes the CF card and after changing the details of using it on the GBA even the batterycheck.zip is detected and it starts extracting setup.exe....to somewhere I guess. When it reaches 100% nothing happens anymore because it probably realizes there is no memory left :lol:
  • Archerite

    What am I getting myself into....libgba looks like a wasteland!!

    I really like DevKitPro and the libraries and tools it comes with for most consoles, but it really seems the GBA is barely getting attention with libgba. It looks more like a collection of header files than a library to help homebrew development. Maybe it's because the system is old and less popular but the NDS has many helper functions to handle sprites and effects. The GBA with libgba has exactly ZERO functions to help you setting this up!! Maybe they removed it or because of the low memory they did not want to include too much or something, I don't know. :wtf:

    I thought...let's be helpful and contribute to the GBA examples by porting the simple ones from the NDS that just use the 2D engine and not require touch. Even the one called "simple" is very hard to get working because you have to setup the sprites yourself. To be fair there is also libtonc that seems to provide these functions, but the entire API is different and incompatible with libgba. I got TONS of errors and warnings because stuff gets declared twice by them. All I wanted is a way to initialize the OAM and reserve some VRAM for my sprite which in this example was just a single colour!

    Is there really so little homebrew going on for the GBA these days that nobody cares or noticed this earlier? Or is it because of this that there is not much homebrew for the GBA????

    Only these options are left I guess:
    - make a fork of libgba to add the missing functions
    - switch over to libtonc
    - write my own helper functions
    - "borrow" libtonc functions and modify to work in libgba :evil:

    I am not really liking option 2 and 3 for a couple of reasons, and option 1 is going to take a bunch of time!! :cry::angry: Option 4 is kind of evil but will get me further a lot sooner that doing it all on my own I think. The best way is to make it as compatibly as I can to the NDS so the examples are easily ported over. The reason for porting by the way is also to get experience with the GBA and the libraries. Helping others by providing the examples later is just a nice additional bonus. ;)

    Originally I had many ugly words planned towards libgba but I think I managed to keep myself under control. Right? :rofl:




    EDIT1: After considering a few options and testing stuff out....the first example called "simple" from the NDS examples has been ported to the GBA now :D
    EDIT2: It took a while longer but the "Sprites" part of the "fire_and_sprites" example is ported too.
    libgba-examples-simple.png libgba-examples-sprites.png
    NB: This is not WinXP (just to be clear) but a theme on XFCE ;)

    Attached Files:

    Wolfvak and alexander1970 like this.
  • Archerite

    Getting ready for GBA Homebrew Development

    In my recent post I have been talking a lot about the GBA and some of my plans of writing homebrew for it. I have already tested a few small things but now I want to set up a development workflow for it. This means testing examples, tweaking and running on real hardware. The obvious way to do this is running a ROM in an emulator and ofcourse this is part of that workflow. But at some point it needs to be tested on real actual hardware. And that is what I am going to talk about today :D

    Over the last few days I have been reading a lot of documentation and I think I have a very basic idea of how to use the system. What I would really like to have something similar to wiiload and 3dslink that allows me to "upload" a new ROM to test stuff out on the hardware. Since the GBA already has a build-in feature that allows it to download programs over a link cable that was originally meant for multiplayer that is a good place to start. For this purpose I have cut a multi-player cable and wired it to a Raspberry Pi to test a few programs I had found. While the upload speed is quite low it does work for small programs. I am currently using a python script that's based on a C++ uploader and the cable is connected to a breadboard and jumper wires....resulting in a less than stable connection. But at low speeds it seems to work good enough though.;)

    The other obvious way to test bigger ROM's is using a flashcard's but the hassle of swapping SD cards get's old really quickly! What I am planning is to create a "gbalink" uploader that runs on the raspberry (or eventually on a remote PC) allowing to upload "multi-boot" homebrew to the GBA. As an extension to that I also want a way to have the uploaded program act as a "bridge" so I can access the RAM and VRAM from my PC with various commands. This will allow me to easily test graphics and sprites without compiling a new ROM every time!

    To give an idea of how I see that upload work:
    - execute command: "gbalink remote_mb.gba"
    - "gbalink" will wait for a GBA and upload that ROM to it
    - the "remote_mb.gba" ROM is a small loader that will wait for commands like:
    - READ: read a RAM location in 8,16 or 32 bit mode
    - WRITE: read a RAM location in 8, 16 or 32bit mode
    - UPLOAD: upload data of size x (I guess small packets of 1-1024kb) or something would be nice)
    - DOWNLOAD: same as upload but in reverse
    - DMA: Use DMA to copy data from one place to another. (useful to upload graphics data or OAM data and than quickly transfer it to the GPU)

    Maybe more useful commands could be added but this should be enough to get the idea. While I have an EZ Flash Omega on it's way to play with later, at the moment I only have the SuperCard MiniSD. While it's considered a bad and cheap flashcard it's what I have and hopefully it's good enough. It should have 32MB of RAM and it has an SD card slot to load data from. No matter how slow it might be loading data from it should be WAY FASTER than over the link cable :D Ofcourse the 2GB card limitation and no SDHC is an issue but I think it's only a problem of the default firmware being outdated! Electrically the SD cards are compatible but the protocol to access the card and the default filesystem are different, and that is why it does not work. Since I need to add SD card support manually in homebrew anyway why not test this theory right :wink:


    In case anyone knows of helpful documentation or already existing apps (opensource preferred) please let me know. At least all my projects are keeping me too busy to get bored :rofl2:
    alexander1970 and Stealphie like this.
  • Archerite

    BatteryCheck - GBA: Why do I 'like' to make things so hard for myself?

    I have not written or updated anything about my homebrew project BatteryCheck in a while now. I really want to update it with new and improved features but the fundamentals are just not working right. With that I mean the actual game engine I have created. It works alright all things considered but that's only because the current systems (GC, Wii and 3DS) have a bunch of memory and horsepower to make up for my bad and inefficient engine. ;)

    My ultimate dream for BatteryCheck is to have it run on the Sega Genesis and NIntendo SNES! Mostly because the game feels like it belongs on them and it's from about that time period, sort of. Ofcourse it's a grey area with all the legal stuff about the graphics and stuff which I do not own. Converting them "on the fly" and not distributing them with my homebrew was a nice loophole to get around it I think :D And like I said above the systems I currently have it working on all have enough memory and CPU power to handle that. Scaling down to the DSi would still be possible since it has 16MB of build in memory to use for converting the graphics. The DS is a huge challenge with only 4MB and slower speed. The GBA with a tiny 256k (among other smaller special caches) is going to be tough! Going to SNES en Genesis which have even less memory and very slow CPU.....it seems impossible! Right? :P

    Well, I have been thinking about how to get this to work just like on the current systems. It might take longer to load and some libraries have to be ported....but when using a FlashCard on each of the lower speced systems you have a LOT more potential memory available! The slower loading would actually be more accurate and faithful to the original game, because it has very cool graphics to make your wait a little more interesting. I really wish I could share them....but I can't :sad:...yet. Maybe I can find a link to some screenshots later and show them that way.

    Anyway, this idea I have had for a long time since I have Genesis Everdrives and a SD2SNES (never even used it I think :shy:) and while documentation for using the extra memory in homebrew is not very detailed, there are examples with code to show how things work. While on these low-memory systems even the Everdrive will not provide enough memory to keep every thing in it's memory I would like to prevent having to write the converted images to the SD card or whatever storage would be available. Just to avoid legal issues later :) For the time being I have just kept it as a "nice to have" project for the future when most of the game would probably be finished already, hahaha:lol:

    Recently I have been drawn back into the GBA and slowly discovering what that little handheld is capable of. Reading lot's of documentation about it's graphics made me realize my game engine is using a lot if the same concepts already, since I based it on how the NDS works. And that is in turn based on the GBA so that was a nice re-discovery that got many new ideas firing through my mind! Aside from the original/bootleg stuff I talked about earlier in my blogs here I also tried to figure out what might be possible with FlashCarts. Most contain 32MB of SRAM (or similar) that is only used to load a ROM into and patch it to allow saving to SD or savestates and whatever. But if I could somehow use this memory for my own purposes that would mean on the NDS I might have 36MB of memory!!!! On the GBA it would still be 32MB and for conversion I need between 10-16MB on the current platforms. Since the graphics also need to be scaled down a bit they might end up using even less memory than that. Or more depending how I might optimize things of course.:D

    From what I have read until now the cheap crapy Supercard which I have is listed with commands to unlock the SRAM for writing but I have not tested it myself yet. I do still need to find a DLDI patch so that I can read/write to the SD card on it since that I have not been able to figure out yet. I also have an EZ Omega on the way just in case I hit a brick wall with the SuperCard :wink: But the idea in general is the same. Load my homebrew and the orginal game files onto the SD card as on the other platforms, load it and it will unpack the files for first time use. Then when loading the game the second time it will use those files and convert them using the "spare ROM/SRAM" of the flashcard. Just hoping that the SuperCard firmware does not mess up or block control of the hardware too much to prevent it from working.

    The above kind of exxplains what I would like to do already, but I also want to test things NOW!!! I am very impatient when it comes to things like that! :lol: Guess I could try just loading some levels in and show just the collision map and a rectangle for the player on screen. This way I can test and improve the collision detection/correction which will help all the other platforms in the end. And it's a great way to restructure my code tree (again) and clean the helper libraries from BatteryCheck specific code and contants. Eventually the same engine could support Jazz Jackrabbit 2 too since the gamefiles are nearly identical. And bring that game to ALL platforms my gameengine can run on! :D

    My signature gives a hint of supported platforms but here it is again: And I see that the GBA had completely slipped my mind when putting down this list more than a year ago
    • Linux
    • Raspberry Pi
    • GameCube
    • Wii
    • 3DS
    • GBA
    And I have tried to port it to:
    • PSP
    • PlayStation 2
    And originally planned for:
    • DS-i
    • NDS
    • Nintendo Mini's
    • Playstation Classic
    • Sega 32X (requires Everdrive for RAM)
    • Sega MegaDrive (also needs everdrive)
    • SNES (SD2SNES required for RAM)
    • N64

    I have been told before this might be a little to ambitious to have so many platforms it runs on. :wink: The fun in this for me is figuring things out and making them work. Learning how game consoles work at a really low level is my number one priority during this adventure. That's why progress is sometimes a little slow, sorry. :shy:Another advantage of working with multiple platforms that use different architectures and memory contains is that you end up with better solutions. Sometimes because code runs slow or is inefficient, or it runs fine on one platform and crashes on the other for no apparent reason. That's how I learned about CPU Little Endian and Big Endian which is a nice confusing story for another time :wink:. It also helps optimizing overall memory requirements when you need to preserve it which will be the case on the NDS and GBA. If it could run on the GBA stepping down further to the SNES and Genesis should be alot easier since it's already optimized to use less memory at that point.

    I think I would better stop writing now. :D
  • Archerite

    Clearing my conscience and going for the real GBA cartridges! ;)

    In my previous blog post here I talked about how my younger self was ignorant when buying GBA games on ebay 15 years ago. So I ended up with four of my favorite games being bootleg copies without even knowing it all these years.:angry: For multiple reasons my collection of GBA games never expanded that much. One obvious reason was I did not make that much money back then but having a flashcard might also be a part of it :blush:. Saving for my drivers license and a car of my own also limited my gaming budget I guess....but it all sounds like lame excuses right? :teach:

    Whatever the reasons are/were it's time to expand my GBA collection!!! So I looked around on my favorite retro Nintendo webshop and seeing what it would cost to replace the bootleg's for the real thing. It was not going to be cheap I can tell you that...but I also wend a little overboard and got a few extra games :lol:. So here is my current collection (including the bootleg's and...ehm...homebrew carts ;) ):
    gba_games.jpeg
    They might not all be the best jewels but some were cheap enough or interesting as a research object. Since the GBA has a really low resolution I can learn a few things to port my homebrew game Batterycheck to it....eventually. Mostly I want it to look better on the 3DS first but my interest in the GBA has been sparked enormously which also led to this...:
    gba_consoles.jpeg

    Only the NES special edition was my own original store bought version from 15 years ago. Got the grey regular GBA when ordering among other things the zelda minish cap. I had wanted the original version for a long time but the non backlit screen kind of kept me away from it. It has lot's of scratches unfortunately on the screen that makes it really hard to play actually, but that got me looking for replacement parts and screens and other modding options. The grey SP and purple one only got in yesterday together with the new games:D Why do I need this many GBA's? Well I don't to be honest. But zelda fourswords could be an option one day now. Testing multiplayer with the link cable, using the GBA as a controller on the gameboy player on TV, or in the extreme case....replace the screen in one of the GBA's with the one from the grey SP to have a backlight. Neither of the SP's is an AGB-101 though so it won't be as good but it was one of the considerations. That grey SP is even more beat up and was really played and abused over the years it seems, luckily the screen is fine and barely scratched. Purple GBA has a couple of scratches but not as much as the grey GBA but it does have an issue with the power switch.

    My orignal NES edition looks almost good as new since I did not use it that much and I always take care of my consoles. It has always been in it's protective cover...and that one looks like it needs replacing though ;) For my new additions to the GBA family I am considering getting replacement shells and at least one of them will get an IPS v2 replacement! Even though the NES SP is in good condition it's backlight is still crap compared to even the original DS on which I have played through most of the minish cap actually. :wink: And while 50 euro for a screen replacement kit is not exactly cheap, it looks awesome in video's and is a lot cheaper than getting an AGS-101 at the aforementioned store: 160 euro's!!!

    Now I have multiple GBA's it's less of a risk to try multiboot and other stuff that might blow one up. I have been testing an example I found on github with a rapsberry pi (is there anything these things can't do???) since both work on 3.3v and that makes interfacing very easy. Tweaking that example I got a maximum speed of 28KB/s while uploading a 250KB example from devkitpro. Though at these high speeds the link is not very stable so it needs more tweaks and a better more reliable cable and connections. I just cut a link cable and hooked it up through a breadboard right now ;)

    So in the next few weeks/months I might be posting more crazy projects related to the GBA. So many ideas...too little time as always :D
  • Archerite

    Getting the old DS, DS Lite, DSi (in DS mode) connected to wifi......it's like mission impossible!!!

    Ofcourse I am aware the DS is an old legacy system and the WFC network has been offline for a while now. But why can't it even connect to a simple highly unsafe open wifi network anymore???? What kind of black magic is the "connection test" doing to see if there is an internet connection? I am not even seeing a connection attempt in the logs of my Ubiquity Unifi controller! Also using the Nintendo USB Wifi connector on Linux with a software based access point shows nothing that looks like an attempted connection! I mean, it's great modern wifi equipment by default does not allow WEP encryption anymore but an open network is still possible if you want it. But for some reason the DS refuses to connect to it!

    Doing homebrew development on the 3DS and wii got me spoiled with quick uploads using wiiload and 3dslink. Seeing the DS has it's own variant dslink I obviously want to make use of it for my "crazy GBA validator" homebrew app. Swapping SD cards all the time for new uploads is sooooo....not fun :angry:!!!!!

    Anyone else have this issue or is it just me?:lol:

    Whatever the solution is to get the DS connected to....something....ti's going to be less secure than a regular wifi with WPA2 ofcourse. So it's going to be separated on it's own VLAN and only specific traffic is going to be allowed into and out of that VLAN! I have to admit I have not jet tested a homebrew program that uses wifi yet to see if it would work anyway, even with the connection test saying it is not working. Most likely it wants to connected to the servers from nintendo which are now offline. But somehow wiimmfi seems to have discovered a way around it but none of the DNS instructions I could find made it work.

    My only solution seems to be getting an old router which supported WEP and see if that works. What I am hoping for is to at least have a raspberry pi 3/4 stand in for that so it's smaller and uses less power and gives more firewall controls for the unsafe wifi hotspot.

    Just had to write down my frustrations....once again. :)
    alexander1970 likes this.
  • Archerite

    I have been scammed on eBay with my GBA cartridges!!....about 15 years ago ;)

    The short version:
    Bought some GBA games on eBay about 15 years ago and just found out TODAY they are actually not original legit Nintendo carts! Found out that most original carts use FLASH or EEPROM to store saves but the bootleg's use SRAM and have patched the ROM's to make it work. The downside of SRAM battery backed savegames is when the battery runs out...it's bye bye savegame! And you can not save with that cart anymore unless you replace that battery.

    As usual I started having crazy ideas again and plan on writing a simple NDS homebrew tool to detect these fakes!! Because they are patched versions of the original ROM their hash should not match those known for that game. As a bonus this utility will allow you to backup and restore GBA savegames and possibly make a backup of the ROM too! Just need a name for it better than "nds-gba-checker" as my work-in-progress version is called now, hahaha.

    Enjoy the long version if you want, but the above pretty much summarizes what it's about.:D


    The long and hopefully entertaining version: :D
    I think it was around 2005 that I bought my Gameboy Advance SP in the classic NES edition with of course: NES classics Mario bros to go with it. Since most other games were kind of expensive for me back then (don't remember the prices though) I was looking on eBay to what was there. Only buying from local sellers I was assuming people finished those games or just did not like them or something so I bought at least: Supermario Advance, Supermario Advance 2, Zelda: A Link To The Past and Tony hawk's underground after testing them on my flashcard if I liked them or not :shy:...for me that was the reason flash carts were made. Right?:D:lol:

    Anyway....buying them on ebay from local sellers I was assuming the games were original and not copies / fakes / counterfeit / bootleg or whatever which they so obviously are! But in my ignorance of my 15 years younger self I had no idea those existed or just did not see the signs. The games played just fine for years so I had no reason to suspect anything was wrong....until a few days ago when I popped in my Zelda and find my 100% completed savegame to be GONE!!! I have never loaned them to anyone who might have erased them as far as I know, so just to see if it might have been the save battery I played a little and created a save. Turned of the system. Back on...and GONE was my save I had just created! Tested it on my SP, NDS, and NDS Lite same results! Taking the cart apart...this is what I found inside:

    gba_zelda_fake.jpg

    I have opened it a couple of times now and the first time I did not even notice the bad soldering and the epoxy blob. Just to confirm my suspicion of the empty battery which I saw was enough to just accept it won't be saving anymore, until I get replacement batteries. Then I noticed the exact same on Supermario Advance that it would not hold the save anymore. Since I only had about 6 games anyway I just opened them ALL up to check which of them had the ticking timebomb battery inside of them:

    gba_carts_inside.jpg

    Looking at them like this it's just so obvious to spot the fakes, isn't it :blush:...I feel so stupid. And upset!!! So what is the actual problem with these carts aside from being illegal ofcourse?? They have the game inside that's on the label and at least for a few years saving worked fine. But since original legit Nintendo carts with a very small list of exceptions ALL use either EEPROM or FLASH storage for the savegames, these copies are patched/hacked to save to the SRAM (with battery backup) instead! And from what I have read about these fakes those saving patches are not very stable or reliable. Or if they are the battery they put in might be empty before being send out!! And as you can see on the pictures...the soldering is TERRIBLE on almost all of them! I am surprised they worked at all! Or this long actually. If I had knowingly bought these as "copies" for a cheap price it would have been a different story. I am actually looking into getting some from aliexpress since I have read that you can reprogram some of these with your own GBA homebrew!!! Thinking Batterycheck GBA here :D:lol:...although it would be a private cart only. No selling allowed and multiple copyright issues in the way of that ;)

    Well, at least my newest addition to my GBA collection: Zelda Minish Cap is a legit original Nintendo game cartridge:D

    I was already looking into making backups of my carts and their saves to use on the 3DS with mGBA. Multiple options are possible these days from unbearingly slow (using GBA Gamecube cable) to lighting fast with the Retrode 2 and an adapter. I have a retrode 2 and GB/GBA adapter but I read it does not support the savestate dumping/restore so that sucks. Plus I need to find the retrode in my storage box first ^_^. So looking at the GBA cable and the sourcecode of that dumper utility, which I know FIX94 only wrote as a proof-of-concept for those that kept asking if it was possible. And it actually is but it's about a 45min wait to get the data over the stupid cable from the GBA over to the gamecube or wii!! The protocol and electronics in the cable are very inefficient and from what I have seen in the code...FIX94 did a fine job considering the point of his utility:). Only with specialized hardware directly on the GBA expansion port...like the wireless adapter. A higher speed "might" be possible according to the docs I found, which defeat the purpose of the "simple and cheap" method of using the cable.

    Then I started thinking...and thinking...and thinking.....about the NDS! It has a GBA port with direct access and a way to transfer the data over wifi or store it on the SD card of a slot-1 flashcard. Looking around I noticed there is already a tool for this NDS GBA backup tool...but that was the only one and it does not look like it's open source. Then I found this amusing story about how someone transferred a savegame from a bootleg cart (which he got by accident like me) and transfer it back into an original. Let's sumize his story by saying it's not just copy-paste and he had to go through a few hoops, but he succeeded and sharing his efforts on github. Looking through it he really only made an SRAM savegame dumper for his game, but it shows how to access the cart and read the SRAM holding the savegame. Combining this with the headers of devkitpro NDS I figured out most of the stuff he did...and it's AWESOME. Knowing a tool that worked to dump a cart already existed is one thing...but having an example that mostly does what I need already is even better!

    After some more thinking ( I do that to much sometimes :rofl:) instead of a pure GBA dumper it might be usefull to have a utility that could detect these fakes by placing them into an NDS and have it verify the GBA ROM in the cart! I have downloaded a list from the no-intro site that lists all known releases and their ROM hashes in CRC32, MD5 and SHA1 to verify the cart with. To do this my utility will read the GBA header to identify the game with it's 4 letter serial code to lookup these hashes and know the size of the ROM to read. Then read in all the bytes from the GBA cart and push the data through the hashing functions and at the end verify them to indicate if it's real or not! I have no idea how reliable this method will be, but if the fakes with SRAM savegames are patched their hash will NOT match the original release. As a side effect of the ROM validation I might as well include a dump feature right? Unless someone has strong arguments to not do this of course. But at least savegame backup/restore is what I want to include in it. :D

    The best advice when buying used GBA carts is, check the average value of the game and if it's way to low...assume it's not an original cart. To help out others I might do another post later to point out what I know about the fakes and how to spot them with detailed pictures of my own. The pictures above I took quickly just to show the insides in this post ;)

    Wow, this one got long but hopefully it was interesting to read and have a laugh at me. Either for buying fakes or my crazy ideas and project 10.001 :rofl2:

    That's all for now.


    EDIT: After a quick copy-paste and edit I have a little demo that already looks good in an emulator:
    gba_cart_validator__quick-test-in-emulator.png
    This is from DeSmuME with a Zelda ROM loaded in slot-2 :D


    EDIT-2: For those interested in following the NDS app part of this story I have just created a thread for it: https://gbatemp.net/threads/yet-another-way-to-make-gba-backups-with-an-nds.566771/
    tfocosta, tirges, Ryccardo and 4 others like this.
  • Archerite

    A small update and rectification about wii-linux-ngx

    In my last blog post I was complaining a lot about wii-linux-ngx and bashing it a little for not working better. After a long night yesterday of compiling the Linux kernel and a lot of failed boots and looking closer at the wii-linux-ngx kernel. I have to give more credits to the creators because they have done a TON of patches to get the Wii hardware supported and show output on the screen and make it work as well as it does. Even though a lot can be done to make it better.....much respect to you guys: Neagix and DeltaResero...for making it even possible to get Linux running in a usable fashion on the old Wii! The repository has not been updated in the last two years and the keys I mentioned only expired like a month ago.

    I am not sure if my new Linux 5.7 kernel is actually running and not showing output or if it's really crashing. I do know that the wii-linux-ngx kernel patches contain special drivers for the Wii hardware so I just decided to try and compile that one, so I would be able to tweak that version and get a working starting point. It took me a while to figure out why this older kernel would not compile on my Ubuntu 18.04 with GCC 7 and had to make use of my recent Docker skills to setup an ubuntu 14.04 environment that has an older GCC 4 that compiles without issues. The good news is that I can now compile this patched kernel and actually modify it myself and it even boots!!! It performs slightly better than the precompiled kernel actually and I was able to update the package list and install a few extra applications I wanted. :D

    There are still many issues to figure out like why it does not like to make use of the swap I have provided but I have something to work with. I also want to try to use Adelie Linux instead of debian as it's a lot smaller and still updated for the PPC architecture. For those that do not know Adelie Linux is based on Alpine Linux which is designed for running inside small docker containers.

    Another option I am considering to get a filesystem image ready is to run Adelie in a PPC Qemu virtual machine and just setup the system that way. So it will be fully updated and ready for first boot on the Wii or something.....when I have more time to actually work on it. Spend too much on it already. :lol: What I will try soon is accessing the gamecube ports with a native Linux app running on the Wii itself! Just reading the buttons and making the gamepad rumble or something. :D

    It's a good thing I have a long Linux history and know my way around a few of the hoops I had to jump through to get it working at all. And I have an intterest in how Linux actually boots so this is a good learning experiment....again....to get close knowledge of how it works. Some stats for those that like to know: My custom 3.14 wii-linux.ngx kernel is 6.2MB uncompressed and only 2.5 with compression! When I continue optimizing the kernel my priority will be stability but I do hope to also make it really small so it uses less memory by default. I could also try building it for IOS instead of MINI to see what that does for stability and memory usage. I did read somewhere performance would be slower with IOS but if it would than at least work I call that a win ^_^

    I'll stop know :D
    KleinesSinchen and alexander1970 like this.
  • Archerite

    Getting Linux running on the Wii!!!

    It has been tried a lot over the years and I knew it had to be possible but never actually got it running. Until a few days ago when I decided to take a risk with wii-linux-ngx and just write the diskimage to an SD card. It was not plug-and-play AT ALL!!! It would not boot with priiloader complaining about missing bootmii so after putting that on the card I got into the bootloader screen....yay!!

    Then selecting the option to load the Linux kernel I saw actual Linux running on my Wii and I thought it was the coolest thing ever!!!:D It generated an SSH hostkey at first boot which is nice since that would make it unique and being able to login with SSH is even more awesome!!!! After the first boot completed I logged in as root and looked around a bit to see if it was a legit Linux running here, and it sure looks like it is!! Memory and CPU info looks good although memory usage is a bit high to my liking for running on the Wii. And this was a hint to the rest of the issues I ran into......

    The release of wii-linux-ngx was from 2017 and is based on Debian 8 (jessie) which is one of the last that support the PowerPC 32bit CPU of the Wii. Being a little "out-of-date" is not really an issue but when the encryption keys for the package repository expired only a month ago.....that is an issue!!! A huge one to be more exact. Normally "apt-get update" should correct the problem from every guide and forum post I could find about the expired key's but nothing helped. Without apt-get update the package list is out of date, and no new software can be installed.

    Beyond this issue the ext3 partition was only 512MB with a few MB's free space left so I first had to expand it on my desktop to the full 16GB of my SD card. And while I was add it also added a 1GB swap partition to at least add some virtual memory. This process took FOREVER since the card I choose was kind of slow....but after maybe 30min's or something the partitions were expanded and created. After booting the Wii again I saw the swap was not used automatically and I had to manually enable it. So i did. But even then it never got used at all! And the biggest reason I need swap is because everything I tried....including updating the package list....seemed to require more than 20MB of RAM that was free after booting. It resulted in "hanging" processes that did not seem to move anymore but I could still kill the process with CTRL-C so it was not a total lockup. The frustrating part is that Linux runs fine on embeded systems which only have 4-16MB of RAM!!! And since the Wii has 84MB of RAM in total it should at least be more capable of running linux and updating the packelist to install new packages!!!!!

    The the SSH ability I talked about I was able to connect but not login as root. I expected that as it's a safety thing in Linux to not allow this so I created a new user named Wii...and now I could login with SSH remotely into my Wii!!! Awesome right!!!! :yay:......but if you can't do anything useful it's pointless to get into it. I could even use SFTP to browse the filesystem and look at at the configuration files...but not edit them as that needs root permissions. I tried uploading a large 80MB file to it with SFTP and it got stuck around 20MB every single time I tried. The frustrating thing was that a full reboot of the Wii is required to try again....otherwise it get's stuck directly! Even downloading the same file with wget on the Wii directly got stuck around 17-20MB and my frustration level kept rising and rising.....

    Then I thought lets try something funky with a "chroot" environment and try install "adelie linux" into a subdir. Which was the 80MB file I was trying to get on there actually but ended up putting the card in my PC to get it there. Then unpacking it was slow but it worked and after a few other Linux tricks I had network access in the chrooted Adelie linux environment. Having no experience with adelie gave it's own set of problems but let's say "pkg update" is equivalent to "apt-get update" and it should be getting the keys and package list and stuff. While it worked after a little fight with the network settings it hang at 12% updating for the same reason as before.....out of memory!!!!!!!!!!:gun:

    For now I have kind of given up on getting useful things done with wii-linux-ngx since I have a lot of things to do already with the Wii Mini and BatteryCheck of course. But even with my complaining and ranting above.....a lot of respect and credits to everyone involved in getting a modern Linux running on the Wii! (https://neagix.github.io/wii-linux-ngx/)

    I have a lot of ideas of my own to get a clean adelie linux image with a fresh fully custom Wii Linux Kernel up and running but it needs a ton of research. The frustrating part is that Linux should run fine on embeded systems which only have 4-16MB of RAM and they run perfectly fast!!Never compiled a Linux kernel and make it work is one of the obstacles I need to take. But the advantage of a custom build is leaving out everything not required on the Wii, like maybe USB3 and firewire drivers for example. The good thing is that even the latest official Linux kernel source code still contains special Wii hardware support so it's not impossible. ^_^

    My useful goal of Linux on the Wii with low memory usage is the ability to quickly test hardware related testing of stuff I want to know. Like how fast can the memorycard, gamecube controller ports, USB, NAND, SD, etc interfaces transfer data. I can do that with homebrew of course....but doing quick tests with something like python over the network through SSH will greatly speedup the debugging process. And because the Linux kernel will protect against a full system crash reboots should also be much less there. It would just give a segmentation fault when thing go bad. But the kernel and everything else keeps running. I think I will try out a small Linux distro in a virtual machine with only 32MB of RAM... just to see if it could work. If it fails I could increase to 48-64MB and if it still does not work as I want.....just give up on running an actual common distro at all.

    I am sorry if this got to technical or complicated for those who do not know Linux, but I just had to get this out of my head and complain a little. I think it already helped a bit. :D
  • Archerite

    BatteryCheck - Planning for new features and improvements in preview 0.4!

    WIth all the crazy stuff going on and very limited time to do any hobby work....I still want to sneak in some dev time for BatteryCheck again!! My first priority though is getting a list of features that would even be considered deserving a new version. So here are a few things I have in mind but I am definitely open for more suggestions or ideas
    • Parallax moving backgrounds with the elevators and the chain moving very near the camera at certain points. While the movement for that is working for the most part, it only works on tile 0,0! The very upper left part of the level that you can not reach during normal gameplay. The way the backgrounds work to create the illusion of depth is by moving at a different speed than the player. Since the backgrounds are a lot smaller than the entire level itself the tiles used are repeated over and over. But to get this right a LOT of calculations need to be done to figure out where tiles are moving to at the current position.
    • What really needs to be in there before release is working battery holders!!! The animations related to that are kind of easy but for each machine a holder activates I need to write a bit of code to make it work. I might do the elevators first as their logic is quite simple for the movement. Each end of the elevator track has an end-stop indicating it should stop and go the other way. Some elevators only go up and down a number of times which is not that difficult to calculate either I think. It will bring even more life to the game and give the player more to do and not get bored after a while. :lol:
    • The "doors" and "stampers" that should block your way need to start acting like that. And their respective battery holder should activate them for all the parameters that are configured for it. Some go REALLY fast for example that even I can not get through 8-10 times, hahaha. Not that I am an pro player of the original game though :rofl:
    • Water should be damaging and give the player a bit of floating to escape it. If you can't escape your battery drains and you die...sinking to the bottom of the pool like a fish.
    • Some real effort to make the background music work on Wii and Gamecube! I am using libmikmod on the PC and 3DS that can play the native files used by BatteryCheck. Also for later when the game engine is used for Jazz Jackrabbit it can play ALL of the different formats! So it makes a lot of sense to port the libmikmod library myself since it's not included in Devkitpro.
    • Working intro and menu system. Not that it will be useful just yet to load a saved game but it will make it look more like the actual game, just like the stuff above.
    • Pause option!
    • Leaking green drops go to the floor and splash out. And damage when it hits you.
    • Moving enemies with very minimal AI: They will jump into your direction but I am not sure how difficult it will be to write the attack AI. Because it will need to freeze the player, take damage, and run an animation with A LOT off frames. It will be cool though when they work
    • Near the supper batteries are monitors with the end boss on them. In the original game his eyes will move into your direction... to freak you out! Should be really simple to do this.
    And the following bug fixes:
    • Alignment issues with battery pickups need to be fixed!
    • Sticky walls, glitchy 1px shaking, not jumping into -10px platforms.
    • Better movement of the player in general. He walks to fast and not aligned with the distance he travels. Same for jumping and nearly all other things he does.
    One other thing I have been looking into is making a Raspberry Pi release! I have tested it to run flawless on a Raspberry Pi 3B+ but at the time extracting the game files was imposible and something I really wanted to include. The plan is to make it a real .deb package that will auto install any dependencies required to run on the latest Raspbian. Maybe even separate versions for Rpi 2/3 and Rpi 4. The instructions to install it will of course be detailed like I have done for the Wii and 3DS already.

    Special thanks too @niuus for the awesome comment in this thread Best Homebrew Games? and redirecting my thoughts into BatteryCheck again. Thanks man! :yay:
    KleinesSinchen and KiiWii like this.
  • Archerite

    Wow! My batterycheck Wii thread just passed 10.000 views!

    What I consider my main thread about Batterycheck for the Wii has just passed it's second milestone: 10.000 views! :D

    This much interest in my little homebrew adventure project with no real update in a few month's is what keeps me motivated to actually continue. I have a bad habit of jumping into many projects and not really finishing anything....lack of time, complications, or just the new wearing of or something. :( :rofl:

    Thank you all for the support on my longest running project. :D
  • Archerite

    Yet another crazy idea....Raspberryi 4 as an I/O interface for the Wii Mini!

    I just had one of my many crazy ideas again...for a few days actually but who is counting :lol:. Almost a year ago I already thought of a way that a Raspberry Pi could maybe be a modern modchip for the GameCube and make all it's awesome wifi,bluetooth, ethernet, etc..available for homebrew. I came to the conclusion that a microcontroller was needed to translate between the fastest ports on both devices: EXI or MemoryCard slot on the cube and then USB 2.0 OTG on the Raspberry Pi. Then I got to busy to actually design the hardware and software and it kind of got on the bottom of my "todo list"....like sooo many other projects! :blush:

    Last week I discovered that the Wii Mini had the BlueBomb exploit that I had totally missed. And a few days later I read that the Raspberry Pi 4 could actually be a USB OTG gadget on it's "power port" USB-C connector. Yeah I know, the Rpi 4 is probably just powerfull enough to emulate the GameCube/Wii with dolphin but that is not the point here :lol:...just imagine this:
    By connecting a single magical USB device to the Wii Mini it would get:
    - Four USB ports of which 2 are USB 3!!!
    - Gigabit Ethernet!
    - Wifi at 2.4Ghz and 5Ghz (I think at least it has both?)
    - An extra bluetooth interface
    - 2-4GB RAM to do fun stuff with!
    - Micro-HDMI would be kind of useless since the GPU access will be to slow.

    Besides this hardware I/O that would become available the USB gadget drivers on the raspberry Pi could emulate a small Mass storage device from which the initial homebrew could be launched. Then with a custom IOS and drives that could be loaded it might be possible to give transparent access to this new hardware! Just like how cIOS can redirect the diskdrive reads to a USB drive. Ot how Nintendont can simulate GameCUbe controllers and load games from the SD card. All of this is done with a specialized IOS. This also has some similarities with my idea for a "NAS Loader GX" that would use a big NAS harddrive over the network instead of a local drive plugged in directly. Ofcourse I did not actually had a Rpi 4 yet to even give this a try....so I bought a few last week as well. :D

    I am not saying it's going to be easy but the last week or two I have been reading a lot of documentation again about the Wii hardware. I am even thinking of a way to replace the NAND chip in hardware to give zero change of bricking while testing all my crazy ideas...and not having to worry about the NAND getting corrupted or wear out. I have seen an EmuNAND is an option and I might look into this but I also like the idea to just load a real NAND backup from an SD card into a microcontroller or FPGA and have it act like a NAND chip.

    I did find out the NAND can reach a raw speed of 55.000.000 bytes per second on it's interface. That is way to fast for anything I could build that would be able to simulate the NAND....but since writes have to be done in pages you will not ever reach this speed! If I remember correctly you need to divide this number by at least four to account for page write/loading overhead. This leaves a possible speed of a little under 14MB/s which I am not that sure it could reach anyway on the Wii since the Starlet CPU is not fast enough to read/write while also encrypting and decrypting. It may reach about 1/4 of this speed which leaves about maybe 3.5MB/s! Now that might just be enough to let an STM32F4 at high clock speeds to handle and simulate a NAND flash interface that would be compatible. The "Emulated NAND" needs will still need to be encrypted with the console's unique encryption keys so it will be required to have these keys first or work with an original NAND backup.
    This also comes down to my craziest ideas which I have kind of got from the bitbuilt forums....building a portable Wii into a really small enclosure with an LCD and game controls. This has been done sooooo many times already and I do plan on someday taking the jump and cut a motherboard into pieces according to those guides. Although I am still not sure how small I actually want to go but I am thinking in the range of the PS Vita size with GameCube like control's.

    I am not sure if the above is making any sense...just needed the idea's out of my head so I can sleep a little better tonight! :lol: Some other time when I am less tired I might actually talk some more about one of these ideas in more detail. Or report that I have succeeded...or failed...at trying it out, hahaha! :D
    MicmasH_W likes this.