|
Post by dshadoff on Oct 29, 2019 3:35:19 GMT
I've been doing some electronics projects this year, mostly related to interfacing with the PC Engine. One of the things I've been working on has been understanding the Memory Base 128 protocol, and trying to create a better version of one. Along the way of getting there, I realized that I needed to make a tester, to ensure that the new device functions properly - but also to backup and restore the data as a failsafe. Today, I'm publishing the PC board and the code that drives this device. Please take a look here: github.com/dshadoff/MB128-TesterThe device itself is pretty simple, based on an Adafruit Feather M0 Adalogger (but with level-shifting hardware), with some added switches and lights. The magic is all in the programming, and the existing functionality of that microcontroller board (especially the SDCard slot). I doubt that anybody will go to the trouble of making one of these for themselves - especially as elmer is embedding MB128 backup functionality into the upcoming version of TEOS - but I thought that some people might find it interesting. Here is a picture of the board:
|
|
mooz
Deep Blooper
Posts: 29
|
Post by mooz on Oct 30, 2019 8:44:01 GMT
Nice!
|
|
|
Post by dshadoff on Nov 2, 2019 23:09:08 GMT
Oh, a special note: since this needs both 5V and 3.3V, it needs to be powered by USB, not the battery-socket that the Feather board has.
|
|
|
Post by elmer on Nov 5, 2019 3:40:37 GMT
The device itself is pretty simple, based on an Adafruit Feather M0 Adalogger (but with level-shifting hardware), with some added switches and lights. The magic is all in the programming, and the existing functionality of that microcontroller board (especially the SDCard slot). That's a really beautiful project board! Don't sell yourself short, I wouldn't use the word "simple" to describe any of what you've created there.
|
|
TailChao
Gun-headed
I Must Eat Muffin Gear.
Posts: 68
Fave PCE Game Overall: Bonk's Adventure
|
Post by TailChao on Nov 7, 2019 16:02:37 GMT
Nice work, thanks for sharing (and documenting the protocol).
|
|
|
Post by dshadoff on Nov 18, 2019 4:28:06 GMT
As I just mentioned in the Homebrew section where we worked out the protocol, the Save-kun and MB128 can be differentially detected, based on one of the status bits after a write command/
I found that my MB128 backup device didn't work with KOEI Save-kun devices, because I had assumed (prior to actually purchasing a Save-kun) that the status bits would be identical, and was checking the value of both status bits in order to determine success. (One of thee had nothing to do with success of the write command).
The meanings of the 2 status bits are:
The first bit determines the device type: 0 = Save-kun 1 = Memory Base 128
The second bit states whether the write was successful: 0 = OK 1 = FAIL
So, I have made an update to the GitHub source to address this.
|
|
|
Post by dshadoff on Dec 2, 2019 1:17:32 GMT
Another update to the MB128 tester. After a write, the second "status" bit apparently also isn't a success flag, so I am now ignoring it in favour of a read/verify step. GitHub has been updated to reflect this: github.com/dshadoff/MB128-TesterThanks goes to Mooz for finding this.
|
|
|
Post by dshadoff on Jan 15, 2021 22:12:22 GMT
New update. While Making a PCB is fun, the user interface is so much more lush with a screen. So I updated this to use a new Arduino-compatible device, a Seeeduino Wio Terminal (inexpensive, and also available at Mouser). I still ended up with a daughterboard design, but I think the end result is quite nice. I will probably make a small adjustment to the daughterboard - but just to improve the fit and feel. Link to the GitHub: github.com/dshadoff/MB128-Tester
|
|
|
Post by SignOfZeta on Jan 15, 2021 22:50:46 GMT
That’s hard core.
|
|
|
Post by dshadoff on Apr 18, 2021 5:22:17 GMT
I've gone back and updated my Verilog Memory Base 128 project, bringing it from about 70% complete to 98-99% complete. I had designed some HuCard-sized boards some time ago, but lost motivation somewhere along the way (it must be all the other projects I start...). I had already got the Verilog code working about a year ago, which became part of MiSTer - but even before that, I had wanted a physical device, using FRAM instead of batteries. So, this past week I got motivated and learned more about the Lattice Diamond tools. Every FPGA manufacturer has their own proprietary tools, which you need to get used to. In my case, I hadn't really done much with simulation or in-circuit analysis - even on MiSTer - so I had some catching up to do. In any case, I got it all working today (and while doing so, I learned that real signals and devices have specific watch-outs). I also realized that I want to shrink the PCB board a bit more, and find/make some sort of housing for it (I don't have a 3D printer though). I plan to clean up the code a bit and publish a GitHub of the device (current version) sometime soon - perhaps in the next week or so. Here's a picture of the board being tested:
|
|
|
Post by dshadoff on Apr 18, 2021 19:16:48 GMT
|
|
|
Post by dshadoff on Apr 18, 2021 20:55:34 GMT
And one more piece of follow-up information - I did some power-consumption testing... although it's not exactly disciplined and scientific, some information came out of it. I tested Memory Base 128, versus Save-kun, versus my FPGA Save 128, for power consumption. Approach:1) I used a USB power/current measuring device (which updates approximately once per second), while the MB128-type devices were connected to one of my USB-powered, microcontroller-based MB128 backup devices. 2) I observed current usage in quiescent startup mode, while backing up to SDcard, and while restoring from SDCard. (*) Note that this doesn't have the benefit of separating the power used by the microcontroller from the power used by the save device. I found some odd things. Here are the results:
| MB128 | Save-kun | FPGA device | Quiescent | 0 mA | 15 mA | 50 mA | Read from MB128 | 2 - 5 mA | 18 - 22 mA | 28 - 36 mA | Write to MB128 | 13 - 17 mA | 32 - 33 mA | 47 - 48 mA |
A couple of things may jump out at you from that table, but first let me say that each of them ended up at roughly 50mA at the end of the test, when nothing else was going on. I suspect that this has something to do with the microcontroller's loop scanning for inputs, more than the save devices... although it is different from the "quiescent" at the start of the test, so perhaps there is also something different going on in the state of the save device. First thing that jumped out at me, was the 0mA for the MB128; this implies that the microcontroller itself wasn't consuming any power, which doesn't make sense. On second thought, I realized that the battery from the MB128 was actually driving the microcontroller, not the USB ! This means, if you have a MB128 (or a Save-kun), DO NOT LEAVE IT PLUGGED INTO YOUR PC ENGINE, IT WILL DRAIN THE BATTERIES ! So I removed the batteries and ran a second test for something closer to actual power consumption, although remnants of super capacitor power may still have been hanging around.
| MB128 | Save-kun | FPGA device | Quiescent | 32 mA | 44 mA | 50 mA | Read from MB128 | 38 - 40 mA | 25 - 29 mA | 28 - 36 mA | Write to MB128 | 49 - 51 mA | 39 - 40 mA | 47 - 48 mA |
This second set of tests makes the FPGA device look a lot better in terms of actual usage, although the original set of numbers is probably closer to realistic for the actual drain on the PC Engine's power supply (when batteries are full). The second set is a closer approximation when the batteries are nearing empty. As mentioned at the beginning of the article, this isn't showing the actual consumption of the devices - because it also includes the consumption of the microcontroller - but shows relative power usage.
|
|