|
Post by dshadoff on Nov 20, 2019 4:45:02 GMT
OK, I can basically agree with this assessment - I actually hadn't noticed the '0001' pattern during write on the MB128 - but there are still two points which are important to consider:
1) For status reads, KOEI reads the port roughly 1uS after the downward transition, yet still obtains the same data values which would be there after 'stabilization' following the upward transition. It is not clear exactly how much later my Arduino read takes place (possibly less than 2 uS ?), but it retrieves different 'settled' values from the MB128. -> So while KOEI's code works, it's basically bad form, relying on slow transitions. -> And with modern logic, it would be very difficult for me to delay any data transitions by a whole microsecond, so I'm safer copying the Save-kun's output which almost never transitions at that point (only on the Length MSB for writes, which probably isn't ever validated by game code).
2) Since the first 'status' bit after the write ends up being device-specific (whether by design or by accident), it can be used to identify which device is actually being used. I don't think any software is actually using it this way though.
|
|
|
Post by elmer on Nov 20, 2019 5:50:25 GMT
So while KOEI's code works, it's basically bad form, relying on slow transitions. Yes, that is absolutely abominable code ... I can only hope that it was a cut-n-paste bug that somehow just-about-worked-in-practice and was never found. But, it's not the first place that I've seen that idiocy. Apart from whatever other Koei games, or others publishers' games, contain similar MB128 code ... I've seen similar read-just-after-releasing-reset code in a bunch of mouse handling code. Yuk! I doubt that there's much that you can do about it with the hardware that you're using, but won't that affect your compatibility with some games? 2) Since the first 'status' bit after the write ends up being device-specific (whether by design or by accident), it can be used to identify which device is actually being used. I don't think any software is actually using it this way though. Yes, it definitely makes it possible to detect the different devices ... assuming that there weren't any hardware revisions during the manufacturing cycle. Just like you, I've not seen any code, yet, that bothers to treat them differently.
|
|
|
Post by dshadoff on Nov 20, 2019 5:56:58 GMT
I doubt that there's much that you can do about it with the hardware that you're using, but won't that affect your compatibility with some games? I actually don’t think it’ll be a problem; I’ll just hold the same value for both CLK high and low (except in the one case where it changes, but I doubt any programs actually read those values). Dave
|
|
|
Post by dshadoff on Nov 21, 2019 12:38:35 GMT
But, it's not the first place that I've seen that idiocy. Apart from whatever other Koei games, or others publishers' games, contain similar MB128 code ... I've seen similar read-just-after-releasing-reset code in a bunch of mouse handling code. If you're able to locate that bad mouse code again, please let me know... an upcoming project idea of mine is to make a modern mouse adapter - to allow the use of modern Bluetooth LE mice with the PC Engine. The PC-E side signalling could be the most challenging part.
|
|
|
Post by elmer on Nov 21, 2019 19:32:36 GMT
If you're able to locate that bad mouse code again, please let me know... an upcoming project idea of mine is to make a modern mouse adapter - to allow the use of modern Bluetooth LE mice with the PC Engine. The PC-E side signalling could be the most challenging part. Good luck with that! The variety of different delay times and methods of reading and detecting a mouse are pretty interesting. Here is the code from some games ... mouse-example-code.zip (23.93 KB) Note that Lemmings and Princess Maker 2 both do that nasty thing of reading the joypad with no settling-delay immediately after releasing the CLR bit (there may be others). The mouse detection code in both Lemmings and Vasteel 2 mistake a 6-button joypad for a mouse ... actually a lot of mouse games get freaked-out by a 6-button joypad. IIRC, Princess Maker 2 is the only one that I've seen that correctly handles both a mouse and a 6-button joypad ... but it only detects a mouse in port 1, so a multi-tap isn't supported. I believe that I've figured out a better detection method, based loosely on the method used in Princess Maker 2 ... but that's another thing on the "not enough time to do yet" list.
|
|
|
Post by dshadoff on Nov 22, 2019 5:06:54 GMT
Thanks, this is great information ! I'm digesting it now, but I'll start a new thread to discuss once I have a few conclusions.
|
|
|
Post by dshadoff on Dec 4, 2019 18:20:10 GMT
I was having a conversation with a friend the other day about the FPGA 128 I’m still planning to build, and he asked me whether the device could be expanded with new functionality or additional storage, and I mentioned to him that the access protocol is pretty much rigid in terms of memory size and access amounts...
EXCEPT
The “sync up” bit sequence is 0xA8, but I suppose that a new/expanded protocol could be made which syncs up on, say, 0xA9, and does more. Is anybody interested in a Memory Base 1024 (or something along those lines) ?
|
|
|
Post by dshadoff on May 27, 2020 15:57:09 GMT
I've just put my Verilog into the MiSTer project, and it seems like all games are working OK except: "Nobunaga no Yabo Zenkokuban", "Sangokushi III" and "Aoki Okima to Shiroki Mejika Genchohisshi" by KOEI
However, "Nobunaga no Yabo Bushofuunroku" from KOEI seems to be OK.
Checking the command status at the time of failure, it says that it is doing a read, with bytes = 0 and bits = 0 (a not-really-defined condition). My code treats this as a full read of the complete 1 megabit, but I'm not sure how the real hardware device considers this.
I can check a logic trace soon, but does it make sense that the game would actually make this request ?
Elmer, I believe that the "Ghengis Khan" code you examined was actually from "Aoki Okima to Shiroki Mejika Genchohisshi", correct ?
|
|
|
Post by dshadoff on May 28, 2020 22:25:29 GMT
So, the fix for this appears to be that a zero-byte & zero-bit request should be interpreted as a null request rather than a request for 1 megabit of data. I haven't had a chance the verify this on real hardware, but I am told that the fix is working fine...
|
|
|
Post by elmer on May 31, 2020 18:42:08 GMT
Elmer, I believe that the "Ghengis Khan" code you examined was actually from "Aoki Okima to Shiroki Mejika Genchohisshi", correct ? Sorry, this kinda got lost ... the answer is "yes", that was the game that I looked at. So, the fix for this appears to be that a zero-byte & zero-bit request should be interpreted as a null request rather than a request for 1 megabit of data. I haven't had a chance the verify this on real hardware, but I am told that the fix is working fine... Nice find!
|
|
|
Post by dshadoff on Apr 18, 2021 19:19:01 GMT
To close the link on this, the KOEI games do send a 0-byte/0-bit request which needs to be treated as null. If you're so inclined, please feel free to check out the code in the repository I built for the project; I have just made it public. github.com/dshadoff/PCE_Save128
|
|
|
Post by dshadoff on Jun 7, 2021 3:10:38 GMT
With FPGAs in short supply and FRAM also out of stock, the FPGA version isn't really going to be possible to make until the end of the year. So I've updated this again, this time (barely) using one of the interesting PIO processors on the RP2040 microcontroller, which is relatively plentiful, inexpensive, and small. Because of the way that the PIO communication takes place, it was easy to make the code easier to understand, and the protocol itself much more obvious. The RPi pico-sdk is very different from Arduino, but that's not necessarily a bad thing - it makes several features easier to access, such as raw read/write to flash. I've also put the PC board files and JLCPCB assembly information in the repository. All it needs is a case (but I have something in mind...). github.com/dshadoff/PC_Engine_RP2040_Projects
|
|
|
Post by dshadoff on Jun 7, 2021 11:53:23 GMT
Picture of the whole family of MB128s: On the left, NEC MB128 and Koei Save-kun. Middle, a HuCard for size comparison and my FPGA version. On the right, latest version based on Adafruit QtPy RP2040.
|
|
|
Post by dshadoff on Jul 6, 2021 4:26:34 GMT
|
|