|
Post by dshadoff on May 20, 2019 21:48:36 GMT
Well, after going around in circles for a while, it looks like I have it working with Emerald Dragon now too.
Without taking a backup of what was working, I added all the new information, and then it no longer got past the format step... So I undid everything, and it still didn't work (!) As it turns out, my PCE Backup RAM had somehow become empty, and Emerald Dragon prints an error message about that... I mistook it for a formatting error.
It seems all I had to add was to take the IDENT line low immediately after all the data had been written (which is a few bits earlier than I was doing). Oddly, the READ function doesn't seem to have such a restriction.
I may not get a chance to invest more effort for maybe a week and a half, so I'm happy it now seems to work (at least superficially) with both Emerald Dragon and Private Eye Dol.
I'll see if I can get this documented and up on my GitHub, and then more thorough testing can take place. Probably a few more adjustments will be needed. After that, I'll see if I get it put into FPGA and get the power level down: right now it's riding at 30mA constantly, with peaks around 40mA during Flash update - I'd ideally like it closer to 10mA with peaks below 25mA.
Dave
|
|
|
Post by elmer on May 21, 2019 0:19:41 GMT
Cool stuff, congratulations on getting it working!
|
|
|
Post by soop on May 24, 2019 12:06:48 GMT
I know you haven't even finished this project, but I was just wondering if anyone had made a decent PS2 SD card memory adaptor, and thought of you. Apparently the official cards only go up to 8mb, and the unofficial ones (which go up to a chunky 128mb) are prone to wiping data. It's strange that no-one seems to have made an SD Card adaptor. Presumably because an SD card is non-volatile it should eliminate that issue. I think a lot of people would appreciate a large ps2 memory card, is that something you'd ever look into? *edit* looks like someone has made strides in that actually, I'm looking through this now psx-scene.com/forums/f19/sd-card-sio2-driver-157485/And this psx-scene.com/forums/f19/sd-card-ps2-memorycard-adapter-implementation-157491/I understand some of it, but I don't know a lot of the acronyms. And it doesn't seem to have translated into an actual product. It's not as simple as soldering an SD Card onto a memory card is it? (sorry for the hijack of the thread btw)
|
|
|
Post by dshadoff on May 24, 2019 23:52:37 GMT
To be honest, I'm not so interested in systems other than the PC Engine, so I haven't looked into it, and I doubt I will.
But I can tell you that it's not a case of "memory is memory". On anything with a small number of contacts (i.e. less than a HuCard), there is some sort of serial communication going on - and in that case, both the sender and receiver need to agree on the voltage, the protocol, and the timing. Even SDCards have a lot of variation among them - there are several different access protocols (mostly speeds) which they may or may not be able to work with for example... but the host needs to query the capabilities of the card in order to know it.
|
|
|
Post by soop on May 26, 2019 17:31:50 GMT
Got ya, thanks for the advice
|
|
|
Post by dshadoff on Jun 3, 2019 1:30:46 GMT
I have published the Arduino code for this on GitHub (with copious comments) here: github.com/dshadoff/SYMB128It works hand-in-hand with the breakout board PCB published here: github.com/dshadoff/PCE_Joypad_Breakout-v3Today I tested with the BRAM backup sections in Vasteel 2, Private Eyedol, and Emerald Dragon, and all appear to work OK. (I didn't give them too much of a workout though... and there are other games I haven't tested with yet...) Dave
|
|
|
Post by dshadoff on Jul 2, 2019 0:09:58 GMT
I did a bit of light testing today. The following are the results:
In order of release date:
Super Mahjong Taikai -> Seems to get stuck in the middle of a command, and the game stalls as a result.
Nobunaga no Yabou - Bushou Fuuun Roku -> Seems to be a bit slow, but able to navigate -> There is, however, a point where the SYMB128 appears to get jammed and unable to push into flash
A. III -> Seems OK
Aoki Ookami to Shikroki Mejika -> seems OK
Sankokushi III -> Seems OK
Magicoal -> Didn't play long enough to get to the part where it saves MB128 -> But, seems to be OK trying to load from MB128 when there are no files
Tadaima Yuusha Boshuuchuu -> Seems OK
Nobunaga no Yabou - Zenkoku Ban -> Seems to be a bit slow, but able to navigate -> There is, however, a point where the SYMB128 appears to get jammed and unable to push into flash
Shin Megami Tensei -> Seems OK
Emerald Dragon -> Previously tested, seems OK
The Atlas -> Did not get to a save point
Brandish -> Seems OK
Vasteel 2 -> Seems OK
Eikan wa Kimi ni -> Seems OK
Super Real Mahjong PII-PIII -> Seems OK
Popful Mail -> Appears to work, but I didn't put any save data onto the unit. Utility can read fine.
Bishoujou Senshi Sailor Moon Collection -> Seems OK
Fire Pro Women's Wrestling -> Seems OK
Super Real Mahjong PV -> Did not get to see any accesses
Princess Maker 2 -> Didn't play far enough to get to a save point
Mahjong Sword -> Couldn't get to the part where it accesses MB128; instruction manual makes no mention of MB128.
Private Eye Dol -> Previously tested, seems OK
Linda3 -> Seems OK; same utility access as Emerald Dragon (press up when loading)
|
|
|
Post by spenoza on Jul 2, 2019 1:09:50 GMT
That is impressive progress. Any ideas where to look for the solutions to the buggy games?
|
|
|
Post by dshadoff on Jul 2, 2019 1:36:27 GMT
I'd have to look at the bit streams. I can get a traceback log from the microcontroller, but it's not clear how helpful that would be. It could also be a timing problem especially on the KOEI games, which would probably need to be seen on a logic state analyzer or something like that. I haven't tried using the debugging features of the microcontroller either... might find something there.
But actually I was thinking of putting the logic into a FPGA for lower power, and smaller board size (and potentially lower cost). The PC Engine wouldn't be able to outrun a FPGA either. And if I do it right, I might get it to automatically be non-volatile (without needing a pushbutton).
Right now I'm starting to think that the microcontroller would maybe be best as a Develo Box replacement...
|
|
|
Post by dshadoff on Jul 12, 2019 23:34:45 GMT
I tested again on my testbed microcontroller, which pretends to be a PC Engine making requests (based on the Emerald Dragon code).
One goal is to drive a regular MB128 and get a complete logic trace type of dump of every input and output at each state transition, to determine what might be different, and to ensure that the eventual FPGA implementation is a matching implementation. All of this data could be written to SDCard as a log.
As part of this goal, I am able to modify timings in order to slow things down in case timing is an issue, and so that I can visibly see state transitions on the earliest of FPGA tests (i.e. '0xA8' recognition).
While running a few tests on my existing implementation, I discovered that there seems to be a bug somewhere during long write sequences. At regular speeds, the '0xA8' recognition often doesn't get recognized the first time (but does get recognized the second time), but if I add extra timing (20 microseconds instead of 2-3) it seems to be OK.
However, at the end of the write of the 62nd sector (512 bytes each), it fails to recognize the 0xA8... and fails in a way similar to the Nobunaga game issues above. Need to investigate...
EDIT: I found that it had overrun the trace buffer. My test ran 256 sectors of reads, and then tried to do another 256 sectors of writes. Each read/write operation transitions through about 9 states, and I had only allocated the buffer to 2048 states (microcontrollers have limited memory). This may also be the reason for the Nobunaga failures; I will try to make a conditional-compile version of the program so this limit won't be exceeded, and retest the failed games.
|
|
|
Post by dshadoff on Aug 4, 2019 15:28:29 GMT
The other day, I noticed on my MB128 that the LED was dimly lit. This is actually the low-battery indicator (paradoxically because LEDs draw quite a bit of power, actually...) It had been just over 4 months since I put brand-new alkaline batteries in - beyond what I had expected for life expectancy - so I was not surprised, but rather impressed.
But when I plugged it in to try it out, I noticed that the contents had been corrupted: I ran it through my read/display program, and it was all utter nonsense - not just a few dropped bits here and there.
So, that raises more than one concern with the original device: 1) I didn't notice the LED until it was too late 2) Once it was too late, the light stayed on
...All the more reason to save to something non-volatile.
|
|
|
Post by dshadoff on Aug 11, 2019 16:13:47 GMT
Just in case anybody wasn't following the other (software) thread, I documented the bitstreams: pcengine.proboards.com/thread/707/mb128-protocol-documented?page=4I haven't updated the microcontroller code yet (and I don't know when I will get a chance); I am working to implement on a FPGA now, which reduces the flexibility but also reduces the bill of materials cost. Dave
|
|
|
Post by dshadoff on Oct 14, 2019 19:57:41 GMT
As a follow-up to the battery-drain issue, I have had to replace the batteries twice more since August - having left the unit on all this time. I used basic/cheap Amazon-brand Alkaline batteries, and they seem to last about a month (which seems quite short to me).
|
|