PokeMe64/include/transferpak/TransferPakManager.h
Philippe Symons d106863b50
V0.3 (#16)
* Feature/add support for other game languages (#13)

* Add support for other game localizations/languages

* Increase PokeMe64 version to v0.3

* Update README.md

* Slightly improve the text in docs/Why_I_Had_To_Give_Up_On_Batteryless_Repros.md

* Update libpokemegb submodule to commit 3d86aa8

* Add Japanese characters to the fonts

* Make validating Japanese save files work correctly

Turns out these Japanese cartridges are using an MBC1 controller. There's a notable difference between it and
MBC3: by default it is doing banking mode 0. But in this mode, you can't switch SRAM banks!

So in order to make japanese cartridges work, we must switch to mode 1.

* Update Arial font: add Japanese glyphs from Osaka Regular-Mono.ttf

In order to render japanese characters, we need to have a font which has japanese characters and make sure they
are added to the .font64 file with mkfont during compilation.

I wrote a small program before to figure out which Japanese characters are actually used in the Japanese gameboy
cartridges.

I only added those unicode ranges to the fonts to keep them small.

There was no easy way to have a font that has both latin and Japanese characters, especially not free. So I
used FontForge to merge the japanese glyphs from Osaka Regular-Mono into Arial.ttf

* Update libpokemegb to commit 0ef7a3a

* Update libpokemegb submodule

* Update libpokemegb submodule to commit d6f3423

* Various changes

- Upgrade libpokemegb to commit c47f8b3

- [Korean gen II games]: Make the UI show Trainer and Pokémon instead of the actual trainer name and pokémon name.
  This is needed because our font does not include the necessary characters for the Korean games. And while I could attempt to add them, I don't sufficiently care to do so.

- Attempt to randomize random values. This is needed for random IVs and shininess chances.
  It's not entirely clear to me whether the rand() function would actually return random values in previous versions of PokeMe64.
  While libdragon does gather entropy at bootup and implements a getentropy() function, I don't see this function referenced anywhere.
  That being said, it DOES look like libstdc++ would call a getentropy() function, so perhaps this is a way in which getentropy() from libdragon would get called.
  But I'm not using libstdc++'s functionality to obtain random values, I'm using libc's rand() function. And I don't see any reference from libc (for rand()) to getentropy(), so...
  At the very least we might need to use values from getentropy() to seed with srand(). But because I have trust issues with randomizing pseudo-random values in a system
  that doesn't have a system clock, I also added trainerID, trainerName and the number of elapsed cpu cycles until we are going to the main menu to the seed. I might consider
  adding the RTC values for gen II games to the seed as well later.

* Update README.md

* More README.md

* Update libpokemegb to commit 17232c4

* Feature/automatically reset rtc in backed up save file for gen2 (#14)

* Add support for other game localizations/languages

* Increase PokeMe64 version to v0.3

* Update README.md

* Slightly improve the text in docs/Why_I_Had_To_Give_Up_On_Batteryless_Repros.md

* Update libpokemegb submodule to commit 3d86aa8

* Set the flag to reconfigure RTC in the backed up save file when backing up the save of a cartridge.

* Update libpokemegb submodule to commit 5037690

* Update libpokemegb submodule to commit 8ff128c

* Add support for Pokémon Green (JPN)

* Update libpokemegb submodule to commit 1897845

* Update README.md -> japanese pokemon fallback OT name change -> PokeMe64 -> PM64

* Add gen I move delete feature. (Idea by /u/ImranFZakhaev on Reddit)

* Add check to make sure the player is in a pokémon center before allowing him/her to delete a pokémon move.

The reason behind this check is to avoid getting the player stuck on a map after deleting an HM.

* Forgot to add the actual check in the last commit

* Feature/implement gen1 move deleter (#15)

* Add gen I move delete feature. (Idea by /u/ImranFZakhaev on Reddit)

* Add check to make sure the player is in a pokémon center before allowing him/her to delete a pokémon move.

The reason behind this check is to avoid getting the player stuck on a map after deleting an HM.

* Update screenshots

* Update CREDITS and add some people as Testing/Validation credits in the AboutScene

These people have been a great help in getting PokeMe64 to work correctly.

Thank you, everyone!

* Fix whitespace issues

* Update libpokemegb to commit aedb588
2025-02-17 20:34:12 +01:00

120 lines
4.0 KiB
C++
Executable File

#ifndef _TRANSFERPAKMANAGER_H
#define _TRANSFERPAKMANAGER_H
#include <libdragon.h>
#ifdef __GNUC__
#define likely(x) __builtin_expect(!!(x), 1)
#define unlikely(x) __builtin_expect(!!(x), 0)
#else
#define likely(x) (x)
#define unlikely(x) (x)
#endif
enum class TransferPakMode
{
ROM,
RAM
};
/** @brief Transfer Pak command block size (32 bytes) */
#define TPAK_BLOCK_SIZE 0x20
/**
* @brief This class manages the N64 transfer pak
* Both SRAM and ROM access are implemented in the same class here
* because the transfer pak itself has some shenanigans:
* - it has its own banking mechanism independent of the cartridge banks -> It can only access 16 KB of the gameboy address space at a time. However, libdragon
* takes care of most of the heavy lifting.
* - It can't do single byte read/writes. Everything must be done in multiples of 32 bytes.
* - switching transfer pak banks influences whether you are reading/writing the right addresses for ROM or SRAM.
*
* So you can't implement ROM and SRAM reading in separate classes.
* TransferPakManager manages and keeps track of all this and abstracts this complexity.
*/
class TransferPakManager
{
public:
TransferPakManager();
~TransferPakManager();
joypad_port_t getPort() const;
void setPort(joypad_port_t port);
bool hasTransferPak();
bool isPoweredOn() const;
bool setPower(bool on);
uint8_t getStatus();
bool readCartridgeHeader(gameboy_cartridge_header& cartridgeHeader);
/**
* @brief This function switches the Gameboy ROM bank index
* WARNING: it switches to transfer pak bank 0
*/
void switchGBROMBank(uint8_t bankIndex);
/**
* @brief This function enables/disables gameboy RAM/RTC access.
* WARNING: it switches to transfer pak bank 0
*/
void setRAMEnabled(bool enabled);
/**
* @brief This function switches the Gameboy RAM bank index
* WARNING: it switches to transfer pak bank 1
*/
void switchGBSRAMBank(uint8_t bankIndex);
/**
* For MBC1 controllers, this will effect the ROM or RAM modes, depending on what is written in $6000-$7FFF.
* If the mode is 0 (default), the RAM bank will be locked to 0, but the extended banks (bankindex > 0x1F)
* can be accessed in the 0x0000 - 0x3FFF range (thereby replacing bank 0) by modifying the 0x4000-0x5FFF registers.
* However, in this mode, the RAM bank is locked to bank 0
*
* If the mode is 1, the RAM bank can be switched, but the extended rom banks (bankindex > 0x1F) can't be switched to.
* In this mode 0x0000 - 0x3FFF is locked to rom bank 0.
* Sources:
* - https://retrocomputing.stackexchange.com/questions/11732/how-does-the-gameboys-memory-bank-switching-work
* - https://gbdev.io/pandocs/MBC1.html
*
* For our use case though, we don't need mode 0.
*/
void switchMBC1BankingMode(uint8_t mode);
/**
* @brief This function reads data from the specified gameboy address
*/
void read(uint16_t gbAddress, uint8_t* data, uint16_t size);
/**
* @brief This function reads data from the specified SRAM bank offset
*/
void readSRAM(uint16_t SRAMBankOffset, uint8_t *data, uint16_t size);
/**
* @brief This function writes the given data to the given SRAMBankOffset
* The write is cached and won't be written until a new write outside the current 32 byte block
* is triggered or finishWrites() is called by the user.
*
* WARNING: Don't forget to call finishWrites() when you're done writing! Otherwise corruption will occur
* due to the cached writes
*/
void writeSRAM(uint16_t SRAMBankOffset, const uint8_t *data, uint16_t size);
/**
* @brief This function writes the current writeBuffer immediately
*/
void finishWrites();
protected:
private:
joypad_port_t port_;
bool isPoweredOn_;
uint8_t currentSRAMBank_;
uint16_t readBufferBankOffset_;
uint16_t writeBufferSRAMBankOffset_;
uint8_t readBuffer_[TPAK_BLOCK_SIZE];
uint8_t writeBuffer_[TPAK_BLOCK_SIZE];
};
#endif