Does anybody happen to have documentation on how the MB128 is identified/accessed ? I am wondering whether it might be a good idea to make a little Arduino data logger to "sniff" the data going back and forth on the joypad...
Mooz, if you are around, could you let me know how much of your GitHub code has been tested ?
I'm thinking of a few projects... the first of which is a Tennokoe addition to the "alternate OS" for Turbo Everdrive. This should be trivial, if your code for reading/writing is ready to read/write sectors at a time for the full MB128.
The other project would be to get a mini microcontroller to act like a MB128 as a replacement. SDCard is more permanent than battery-backed SRAM. For this, I need to compare the MB128 signalling versus regular joypad, and understand how they decide whether to send joypad data or MB128 data. I'm assuming that the CLK and RESET signals are passed through to the joypad chain, but something in the pulse determines whether the 4 bits are passed back from joypad or MB128.
Also, is the 1us up-pulse timing critical, or is it just "long enough to be sure of propagation, but short enough for fast data" ?
OK, it looks like most of the important pieces have been tested... THANKS MOOZ !!!
I spent some time playing with these routines today, bodging them into a rudimentary HuC-based hexdump utility.
Notes: Each sector is 512 bytes, and there are 256 sectors. Use the up and down arrows to scroll the hexdump within a sector, and use the left and right arrows to move to next/previous sectors.
For the moment, there isn't an easy way to get data off of the PC Engine without using the same port that the MB128 uses... but this will help people to understand the overall format.
Here's what I adjusted: - Built a shell/print framework in HuC - copied basically all of Mooz's assembler into a #asm block (Here's a pointer to his GitHub: github.com/BlockoS/mb128 ) - used global C variables for anything that needed to be passed back and forth - created wrapper functions around the primary functions (mb128_boot() and mb128_read_sectors() ); for these, I turned off interrupts for any I/O periods, and used asm to pass the variables in/out
I noticed that just using the mb128_detect() function, it was never detected, so I had to switch to mb128_boot(), which retries up to three times (which did the trick).
A note about MB128 organization (at least how the Emerald Dragon utility uses it): - The first 2 sectors are used as an index, with entries for each "slot" - I used the Emerald Dragon utility (hold "up" as you hit "run" when booting from the System Card), I placed 3 different backup RAM snapshots into the MB128. They were not stored uniformly. - MB128 strips the "HUBM" header and a few extra bytes off of the BRAM; it detects how many entries are ACTIVE, and stores them. It rounds up to the next sector, and that's all it takes. One of my BRAMs only took up one sector, while I was expecting them to take up a uniform 4 sectors each. So, it can probably hold more than 64 useful BRAMs
You may also find it interesting, so I'm attaching the code here.
Once the new TED OS is ready, I'll somehow put something together for MB128 backup/load, so it can be backed up onto SDCard (and restored).
A note about MB128 organization (at least how the Emerald Dragon utility uses it):
I do seem to remember seeing a note somewhere that Private Eyedol or Vasteel 2 can do a complete backup of BRAM to the MB128, but that it is in a totally different format to the one that Emerald Dragon uses.
Yes. As far as I remember a number of players bought Emerald Dragon for the utility(even though the game was good on its own) but my experience was that it wasn't really friendly and I even had my data corrupted a few times with it. IMO the utility provided by Private Eyedol was much more polished and stable (though with an incompatible format) so I used it instead.
I'm not sure about all the other games which use the MB128 though - I got the impression from somewhere that the KOEI war strategy-type games use the whole memory themselves (though I've never tried, so I could be wrong).
A-Train III Aoki Ookami To Shiroki Mejika The Atlas: Renaissance Voyager Bishoujo Senshi Sailor Moon Collection Brandish Eikan Wa Kimini Emerald Dragon Fire Pro Female Wrestling Linda Cube Magicoal Nobunaga's Ambition: Zenkokuban (Nobunaga no Yabou) Nobunaga's Ambition: Bushou Fuuunroku (Nobunaga no Yabou) Popful Mail Princess Maker 2 Private EyeDol Sankokushi III Shin Megami Tensei Super Real Mahjong P II + III Custom Super Real Mahjong PV Custom Tadaima Yusha Boshuuchuu Vasteel 2
It's been a long time so I could be wrong, but as far as I remember Emerald Dragon doesn't use the MB128 itself. It instead contains an utility to manage it, so it's hard to decide whether it should be on the list.
Anyway, there are two more games from this list: 001 Super Mahjong Taikai (it's a Koei game so...) 022 Mahjong Sword Princess Quest Gaiden
From that new book (PC Engine Perfect Catalog), in chronological order:
Super Mahjong Taikai - no specific information (note that this was released over 2 months before the MB128 hardware was released) Nobunaga's Ambition: Bushou Fuuunroku (Nobunaga no Yabou) - needs MB128 in order to save (I assume it occupies most/all memory) A-Train III - needs MB128 in order to save (I assume it occupies most/all memory) Aoki Ōkami to Shiroki Mejika - needs MB128 in order to save (I assume it occupies most/all memory) Sankokushi III - needs MB128 in order to save (I assume it occupies most/all memory) Magicoal - no specific information Tadaima Yusha Boshuuchuu - no specific information Nobunaga's Ambition: Zenkokuban (Nobunaga no Yabou) - needs MB128 in order to save (I assume it occupies most/all memory) Shin Megami Tensei - no specific information Emerald Dragon - includes data transfer utility The Atlas - needs MB128 in order to save (I assume it occupies most/all memory) Brandish - no specific information Vasteel 2 - includes data transfer utility Eikan ha Kimi ni - needs MB128 in order to save (I assume it occupies most/all memory) Super Real Mahjong P II + III Custom - no specific information Popful Mail - no specific information Bishoujo Senshi Sailor Moon Collection - no specific information Fire Pro Female Wrestling - includes data transfer utility Super Real Mahjong PV Custom - includes data transfer utility Princess Maker 2 - no specific information Mahjong Sword - includes data transfer utility Private Eye Dol - includes data transfer utility Linda3 - includes data transfer utility
I've figured out a bit more about the MB128 protocol, but now it's heading in an electronic direction, so I'll start a thread in Personal Projects discussing what I'm trying to do in order to create a replacement device.
Super Mahjong Taikai - no specific information (note that this was released over 2 months before the MB128 hardware was released)
I have this game. As far as I remember the MB128 was not necessary to save, just that it was supported(which matched the list I posted earlier, as it's with black text).
Magicoal - no specific information
I have this too. Actually it's one of the few late releases that supported nearly every single add-on(even the mouse), BUT there was a bug if you use the MB128 together with a multitap(I think it's this combination that caused problem, as I was never successful to load a save from the MB128 BiTD and the multitap was connected by default). Under this configuration, you could save your game to the MB128 but could not load it(the game would freeze) which beat its purpose as a 2-player collaborative game. You could move its save slots between main BRAM and MB128 though.
Princess Maker 2 - no specific information
Another game that supported nearly every single add-on. A bit off-topic, though. Initially some emulators(including Magic Engine and Hugo I think) incorrectly assumed the system had a full 8kb bank of main BRAM. Running this game (and Princess Maker I too) under such emulators would provide A LOT MORE save slots than on real hardware, prompting that they might had plans for a upgrade with more than 2KB of BRAM(like how the System 3 CD card actually did support more than 2Mb of BRAM) by switching to a newer version of the Tennokoe II/AV booster/CD Interface Unit but that idea was totally dropped since the Super CD and Duo came out as the BRAM were no longer changeable.
I don't have any of the Koei simulation games (plus AIII and others) but I doubt any of them would really take most of the 128KB in a single save(it's just that 2KB was obviously not enough). These games were available for the other consoles and I think they didn't use as much there either.
OK, after finding that the "write_sector" function wasn't working yesterday, I learned two more bits of information:
1) Mooz had documented (but not implemented) an important part of the protocol: when setting up which sector to read/write, the initiate sequence starts with a 1-0-0 bit sequence for read, or a 0-0-0 for write. Once I added this extra differentiation, it worked for writing as well.
2) The pulse width doesn't appear to make a difference - at least for reads. Maybe there would be problems with writes if it were to be "too short", but a longer pulse doesn't seem to be a problem, or cross a threshold.