TODO

• (Very High priority) Make comment box larger, or at least resizable; feels too small to read anything of value.
• (Very High priority) Add option to use Basic note file.
  • 
  • Rationale? My MPKNote header only adds comments and a timestamp. Some apps may use the more pure original format. However this should only affect saving notes that have no comments, and should not be enabled by default. So yeah, mostly this will be useful for legacy software that does not support the new header; I think raphnet is the only software potentially affected, but having this option enables flexibility.
  • Why not default behavior? Because internal timestamps are more reliable than "date modified" in many respects; I and perhaps others might appreciate the piece of mind of having an internal timestamp, if somehow the "date modified" field is lost somehow (during file transfer/upload etc). The additional header is also quite compact, and relatively straight-forward.
• (Very High priority) When saving .SRM, use confirm box to ask the user to confirm if they want .SRM or .MPK. Or find a more elegant solution.
  • To clarify, MPKEdit detects loaded .SRM format from Mupen64Plus. Saving will keep the structure. The option to get plain .MPK for other emulators/purposes would be useful.
• (Very High priority) Add timestamp support to the MPKMeta format.
• (Medium priority) Fix bug in pixicon - top right pixel is missing.
  • Rename references to "icons" to "pixicons".
• (Medium priority) More robust NoteName editing (deal with extension issue.)
• (Medium priority) Do a direct libultra port for comparing parsing results. Could be very insightful.
  • Design test cases that libultra can repair but not MPKEdit. Improve checkIndexes.
• (High priority) Add way to change region of a save file.
• (Low priority) IndexTable Defrag (Rebuild) and Randomize (for debugging purposes/fun).
• (Low priority) Improve the IndexTable diagrams a bit, with opacity and mouseover stuff.
• (Low priority) Attempt 'emulator detection' of MPK files. i.e. display a message if the file originates from emulator. DexDrive too maybe.
  • Just for fun. I abandoned the idea of using flags to store that info in note files, and its not reliable anyway.

Honestly everything below here is pretty unimportant or not good enough to do.

---

TODO (Old)

• (Medium priority) Develop heuristic detection ASCII GameCode/Company Code. Typically check if bit 7 is set. If check fails, display the hex as monospace text instead, e.g. DEADBEEF. This is simply to allow undocumented homebrew stuff to not look ugly.
• (High priority) Add Note export to the detail modal. Not hugely important but seems like quality of life improvement.
• (High priority) Incorporate deviceid bit check, and '01' bank check. This is possibly unnecessary if I do the libultra port first.

---

TODO (Low priority)

• (Low priority) GameTests battery: Go through games and see how they react to changes to ID header bits. Possibly unnecessary now.
• (High priority) GameTests battery: Game note tests (Data Constraints, Duplicate data use between notes, etc.)
• (Low priority) Heuristics for mismatched DexDrive comments. Some files may have mismatched comments, such as wwf_no_mercy_caw_b.N64. It may be possible to find unused comments and apply them to existing save data. I'll need to first find all the affected files.

Idea box (Super low priority)

• (Low priority but interesting) Note name beautify database, e.g. ASB '99 ROSTER > All-Star Baseball 99: Roster or DKRACING-TIMES > Diddy Kong Racing: Track records. This would be tedious.
• (Low priority) Drag (or copy/paste) notes between MPKEdit instances. Could be useful, but is it even possible?
• (Low priority) Hex view: Display save data as raw hex/ascii. Currently done for note table data
  • Per-game data parsing engine for displaying save variable contents.
• (Medium priority) Allow user to specify/modify output filename. Not really an issue if the user already supplies a MPK file. Perhaps, specify the name for "New.mpk" on launch?
• (Silly idea) Investigate the effectiveness of a bit-flip recovery scheme in the header. If a checksum becomes corrupt by a single bit flip, can we safely repair it? Is it a good idea? Is it redundant?

Main Tasks

Consider grouping Delete / Export into a "..." menu

For added flexibility, I could convert the two buttons, Delete and Export, into its own dropdown menu.

• Export
• Export (Raw)
• Add to Archive
• Delete

This could facilitate certain new options like 'Add to Archive' more cleanly.

Copy a note from one C-Pak to another

It's possible to save notes as .note files, and these files can be loaded into any .mpk manually. And it's actually kind of flexible to keep your notes outside of a .MPK file, to be free of the 16-note limitation.

But there's no reason we can't provide added convenience. At first I considered adding a tabbed interface, but this would be a lot of extra code.

But there may be another way.

We could use the Clipboard itself. Of course this would overwrite people's clipboard... but it'd be the easiest method.

Another option would be to use Local Storage or IndexedDB to sort of store a 'temp' file that can be easily moved to and from .MPK files. In theory this could be integrated into the "Archive / Database" idea. It being permanent, but with a temporary section for copying between two tabs.

One problem with this is that any custom visual indicator would not be instantly updated between tabs. There might be a way to do it using timers or events though.

Archive / Database pane

Alright. I've had this idea for a while but it felt almost out of scope, too ambitious, but thinking about it more, I think some people could find it useful. So I want to do an outline.

The idea is a browser-based database of your save files, not bound to the 16-note limit of normal MPK paks.

The main idea is to roughly simulate the workflow of saving notes externally, but do it internally, and provide a more dedicated interface, while also allowing backup and restoring of the whole database as a ZIP file.

Other finer points:

• IndexedDB for storage (more resilient, handles binary data better)
• Store 'date archived' metadata - should be handled similarly to how date-modified is handled when saving note files.
• • Basically, the interface switches to let you sort by date, perhaps with a 'timeago' scheme, grouping stuff
• In addition to sorting by date, filtering by game should be possible, so prior revisions of the same game are shown.
• Comments should be highly visible and perhaps allow inline-editing.
• Import/Export is extremely important - use ZIP format with zero compression(?)
• • Ensure that all metadata is losslessly retained. A root JSON file might be required to store some stuff.
• A nice to have would be browser sync, but if this cannot be done in Brave/Opera/Chromium I will possibly scrap it.

Mupen64Plus-Next .SRM Support

Status: 99% Done.

• Other save types are removed during saving. To remedy this, either an elegant solution, or significant restructuring is required.
• Only Port 1 is used currently. Further enhancement could involve a "port detector"; which uses simple logic to determine which offsets contain actual notes. If only one of them contains notes, use that. If more than one does, throw error. This is an extreme edge case (BattleTanx), and likely isn't a simple change, so is not important.

Further information: RetroArch's Mupen64Plus-Next emulator saves a single 290 KiB .srm file for each game. This file allocates memory for all possible save data, even if the game does not support one or the other. Here's the structure:

Type	Offset	Size
EEPROM	0	2048
MPK P1	2048	32768
MPK P2	34816	32768
MPK P3	67584	32768
MPK P4	100352	32768
SRAM	133120	32768
FLASH	165888	131072

A note about Raphnet MPK4 format: Raphnet's N64 USB adapter defines a format called MPK4, which is just four 32,768 byte MPK files concatenated together. I believe the intention is that these represent controller ports 1 to 4. This system is similar to the above RetroArch scheme, but without the additional save types. Currently MPKEdit supports this by simply loading only P1 data. I have no clue if it's possible to have data in ports 2-4, considering the design of the adapter only has one or two controller ports.

Luckily, detection is not an impossible task.

• If a file's size is exactly 131072 bytes, we assume it is MPK4.
• If a file's size is exactly 165888 bytes, we assume it is .SRM.