|
Post by spenoza on Apr 3, 2019 1:25:59 GMT
I 101% support doing something fun because you want to, especially when curiosity and SCIENCE! are involved.
|
|
TailChao
Gun-headed
I Must Eat Muffin Gear.
Posts: 68
Fave PCE Game Overall: Bonk's Adventure
|
Post by TailChao on Apr 3, 2019 16:17:20 GMT
This seems like the only Cypress 5V dev board that I can find that might fit the bill ... and it has a built-in SD card interface for non-volatile storage. But it only has 128KB of RAM total. Unfortunately, that seems to be it. The higher end chips like the S6E2CC, while also capable of 5V native operation - only have 3.3V evaluation boards available (likely from all the fancy bling included on them). Since you're only required to level shift a few pins, I don't think this is too big a deal. You could always prototype with 3.3V and then go all 5V native whenever you feature set is finalized and it's time to design a PCB. Honestly, apart from the joy of the challenge of making it all work (which would be immensely satisfying), by the time that you've added on all of the extra electronics, and designed a small circuit board to handle the extra TTL chips, then you might as well have just bought a real MB128 for $30 from Japan. Sure, but it would be so much more than an MB128... well, mostly more satisfying. YES!
|
|
|
Post by elmer on Apr 4, 2019 3:02:53 GMT
I 101% support doing something fun because you want to, especially when curiosity and SCIENCE! are involved. Definitely! Well ... whoops! I checked the circuit diagram and the Atmel datasheet, and the whole 128KB of the external SRAM chip isn't available to programs. The bottom 8KB of the 64KB data space is permanently mapped to internal SRAM and hardware, so there's a maximum of approx 112KB+ of memory on that board that could be used for storage. I guess that's why they use the weasel-wording that they do in the board's description. I wonder if it might be possible to just use that nice-n-cheap FM4-U120-9B560 board at 5V (for simplicity), and just not provide the whole 128KB of backup space that the MB128 provides ... say by faking the existence of a permanent dummy "file" that takes up the extra space that you don't actually have free RAM for on the board.
|
|
|
Post by dshadoff on Apr 4, 2019 5:24:27 GMT
It's just too bad that these modern boards are so rare to have 5V-compatible pins (although some are "5V-tolerant" which isn't exactly the same thing). Actually, a healthy number of people playing with these boards are doing it in order to interface to something old, like retrogames, old computers, etc. All they would need to do is make *some* pins 5V (say, 8 or so) in order to please virtually everybody. They are probably acting this way because level-shifters are merely an inconvenience, not a serious issue... although again, most people buying these boards are doing it beacause they don't want to deal with discrete parts. On the other hand, here's a nice 5V-compatible serial EEPROM which would probably substititue nicely for the MB128 memory, yet be nonvolatile: www.mouser.com/ProductDetail/Microchip-Technology-Atmel/AT24CM01-SSHD-B?qs=sGAEpiMZZMuVhdAcoizlRXokt0l6n8h7F9nEDxBlgFM%3D
|
|
TailChao
Gun-headed
I Must Eat Muffin Gear.
Posts: 68
Fave PCE Game Overall: Bonk's Adventure
|
Post by TailChao on Apr 4, 2019 14:42:37 GMT
I wonder if it might be possible to just use that nice-n-cheap FM4-U120-9B560 board at 5V (for simplicity), and just not provide the whole 128KB of backup space that the MB128 provides ... say by faking the existence of a permanent dummy "file" that takes up the extra space that you don't actually have free RAM for on the board. I'm still convinced you can do this with a really fast PIC and External SRAM. Looking at Mooz's notes on GitHub, the console doesn't read very fast. So there's more than enough time to try and grab what the game is slowly requesting, do write caching, whatever. Of course, using the FM4 and attaching that same SRAM would be much more friendly . It's just too bad that these modern boards are so rare to have 5V-compatible pins (although some are "5V-tolerant" which isn't exactly the same thing). Actually, a healthy number of people playing with these boards are doing it in order to interface to something old, like retrogames, old computers, etc. All they would need to do is make *some* pins 5V (say, 8 or so) in order to please virtually everybody. It's a healthy number, but not the only number. Keep in mind many of the devices usually interfaced with these microcontrollers are also now 3.3v or below - especially external memory.
|
|
|
Post by dshadoff on Apr 4, 2019 17:06:18 GMT
I'm still convinced you can do this with a really fast PIC and External SRAM. Looking at Mooz's notes on GitHub, the console doesn't read very fast. So there's more than enough time to try and grab what the game is slowly requesting, do write caching, whatever. Yes and no. Depends on the speed of the PIC and whethr it can do edge detection. The challenge is that you aren’t in control of the bus, and can’t be late returning data. You have about 2 microseconds to notice an edge transition and send your bit. The job here, is to be a specialized USART like device, which is really easy for glue logic but really hard for slow microcontrollers. But in the end, if suitable logic is too expensive (beyond cheap CPLD, but FPGA is too expensive), and if a PIC is similar in price to a FM4 or ESP32 module, I’ m not going to worry about wasted cycles, if development time is more favorable. It's a healthy number, but not the only number. Keep in mind many of the devices usually interfaced with these microcontrollers are also now 3.3v or below - especially external memory. I’m not saying that all boards should have it. Just that more feature-rich boards should include it along with theit 56 GPIOs. ...but we could argue about possibilities all day without making progress... I’ll just see if I can make some progress on my easy hardware first, and then we can have an optimization competition.
|
|
TailChao
Gun-headed
I Must Eat Muffin Gear.
Posts: 68
Fave PCE Game Overall: Bonk's Adventure
|
Post by TailChao on Apr 10, 2019 18:06:00 GMT
Yes and no. Depends on the speed of the PIC and whethr it can do edge detection. The challenge is that you aren’t in control of the bus, and can’t be late returning data. You have about 2 microseconds to notice an edge transition and send your bit. The job here, is to be a specialized USART like device, which is really easy for glue logic but really hard for slow microcontrollers. Oh, of course. This is why I recommended the external shift register and hooking the MB128 data clock input to both the MCU's SPI clock and a timer input - PIC or not. It won't completely eliminate the timing constraints but you decoding logic can be much less complex. But in the end, if suitable logic is too expensive (beyond cheap CPLD, but FPGA is too expensive), and if a PIC is similar in price to a FM4 or ESP32 module, I’ m not going to worry about wasted cycles, if development time is more favorable. An FPGA is definitely out of scope for this, you wouldn't need that many gates. I think the FM4 is still the best route in terms of convenience and price. The only reasons to go PIC are to make the device extremely low power and extremely cheap in quantity. ...but we could argue about possibilities all day without making progress... I’ll just see if I can make some progress on my easy hardware first, and then we can have an optimization competition. Agreed.
|
|
|
Post by dshadoff on Apr 20, 2019 14:29:24 GMT
Quick status update: During this time, I've learned how to use EAGLE PCB layout software well enough to create a simple board, and designed/ordered a breakout board which will manage the level-shifting and include connectors for the inputs and outputs (mostly because those connections are a pain in the neck). The boards are on their way, but didn't arrive in time for my long weekend, so I started to take advantage of my previous "Step 1" work - where I got an Arduino board to access the MB128 directly. I have taken that same code and ported to a 3.3V board (in this case, an Adafruit Feather M0 Adalogger), and decided to use that as the test driver for my other 3.3V board which will emulate the MB128 (an Adafruit ItsyBitsy M4 Express). As I was able to reuse existing code and temporarily eliminate the need for level shifting, this is actually the perfect test setup to make progress on the MB128 state machine, even though I hadn't originally envisioned using it this way. Reviewing both sets of log output on the same computer monitor is quite nice. Notes: 1) Arduino studio will work with two boards at the same time (even different ones), but you need to invoke two separate instances of it - not just two separate windows. If it's just two windows, the board selection between them will be linked, but if you open another instance, the instances behave completely separately, including text font size. 2) I have slowed down the delays about 100,000-fold, so that I can see the actual bits pass by and review whether the state machine is recognizing them properly. Once this works, I'll ramp up the speed again to see if it can handle full speed, or if there are critical sections which need to be examined/optimized/etc. So, where delays had been a few microseconds before, they are now hundreds of milliseconds. At the moment, I have got the state machine implemented to the point where it: - recognizes the initial '0xA8' sequence (i.e. whether the MB128 should assert its own outputs or leave the joypad as pass-through) - responds correctly identifying its existence to the host - identifies the 'boot' sequence - identifies well-formed sector read/write headers I should be able to implement the remainder this weekend - identify bad requests and reset to idle state - retrieve/store sector data within one of those block read/write requests - ramp up the speed at least 10,000-fold in order to be back in the ballpark for testing on a real system As my breakout board is due to arrive on Monday, I may be able to start testing on a real system later in the week or next weekend (assuming no major mistakes on the board). Here's a pic of the test setup: Separately, I had previously made mention of FPGAs as a possible implementation; I have found that the Lattice ICE40UP-3K and 5K FPGAs have 128KB of internal RAM and would seem to be easily able to handle being a MB128 replacement, even reducing parts count since they should be able to handle communication to the joypad at 3.3V and ultimately absorb the functionality of the 75HC157 (needing only level-shifters and power supply management). This might be an interesting approach, as they are actually cheap parts (see the UpDuino breakout boards), though it could be a lot of effort to get them to be 'more than a MB128' - to communicate to a computer, store to a non-volatile storage place, or implement any other additional functionality I had envisioned. Still, could be pretty cool. Dave
|
|
|
Post by dshadoff on Apr 21, 2019 19:39:02 GMT
So, it *seems* like I have the currently-known functionality implemented into the microcontroller, and it can keep up with the M0 Feather board at a speed similar to the PC Engine. It's hard to say if it will be fast enough for a real PC Engine because the delayMicroseconds() function (used on the host side) doesn't seem so precise, and could give more leeway than expected. Still, it's looking good at the moment.
Tomorrow/Tuesday, I will get the boards and try a perfunctory test, checking that it can keep up with my test program and Emerald Dragon. If that goes well, it will be time to go through other software to determine whether they use any commands that we don't currently understand.
|
|
|
Post by elmer on Apr 22, 2019 20:39:14 GMT
Cool stuff! I see that the MB128 is built with only a 74HC324 clock generator, an MSM6389 1Mbit serial memory, and an ASIC for the glue logic. I doubt that there is any CPU in there at all, just simple hardwired logic. pcedev.blockos.org/viewtopic.php?f=5&t=98The data sheet for the MSM6389 may give good clues about the timing restrictions, and why the packet formats are the way that they are. I'm also seeing old threads that imply that Linda3 and Emerald Dragon's MB128 code is buggy, and that Private EyeDol's MB128 code is much more reliable.
|
|
|
Post by dshadoff on Apr 23, 2019 2:24:16 GMT
There isn't a CPU in there. It's a 1990's-style ASIC, with the clock driven by the RESET line on the joypad - it's probably about 100-200 flip-flops plus a bunch of gates. This level of logic would be a trivial load for an FPGA these days.
I'm driving my solution with a CPU because I know how to program one, and the tools are readily available (plus it could be extended). It is *not* the best tool for the job. An FPGA would be a more analagous fit, and would be much lower-power as well (the ICE40UP-5K I previously mentioned would be about 100uA... a 2000mAH battery would be able to keep it alive for over 2 years).
In other news, I got the boards today, and they had a couple of minor issues that I can work around (a mis-labeled jumper, and the DIN jack is mirrored so it needs to be mounted on the underside), but there also seems to be an issue with the level-shifted signals from PCE to microcontroller, which I need to figure out. So, no full-speed tests yet. But on the other hand, I can speed up the M0 controller by using fast I/O instead of the regular digitalWrite().
|
|
|
Post by soop on Apr 23, 2019 13:23:43 GMT
In other news, I got the boards today, and they had a couple of minor issues that I can work around (a mis-labeled jumper, and the DIN jack is mirrored so it needs to be mounted on the underside), but there also seems to be an issue with the level-shifted signals from PCE to microcontroller, which I need to figure out. So, no full-speed tests yet. But on the other hand, I can speed up the M0 controller by using fast I/O instead of the regular digitalWrite(). I'm about to try to design my first PCB soon. I'm quite excited! Was the turnaround quite quick? And did they make the mistakes, or was it in the design?
|
|
|
Post by dshadoff on Apr 23, 2019 16:56:28 GMT
I'm about to try to design my first PCB soon. I'm quite excited! Was the turnaround quite quick? And did they make the mistakes, or was it in the design? All mistakes are my own. One was that I used a footprint from an external library for the mini-DIN jack; it confused me because the connections did not match the labels. After what I thought was deep study, I decided all it needed was to mirror the footprint and all would be well; as it turns out, it didn’t need to be mirrored (this is equivalent to mounting it on the underside). The jumper was also my fault. It really depends on how large your board is; if you’re using free EAGLE, you’re limited to 80x100mm, which is fine if you send it to seeed studios, who will make simple double-sided boards of this size for 10 units for $5US with a turnaround of 3-4 days, but if you want them back quickly you’ll need to splurge about$25 for DHL. Oshpark’s expedited service is also fast, but much more expensive - though if you have a very small board, you may find it acceptable. Normal turnaround for them is closer to 2-3 weeks. I used SMD parts, and sortof regret doing that because I don’t have a reflow oven or tools. It’s not as easy as it looks with a hand soldering iron. Dave
|
|
|
Post by soop on Apr 24, 2019 12:55:37 GMT
I'm about to try to design my first PCB soon. I'm quite excited! Was the turnaround quite quick? And did they make the mistakes, or was it in the design? All mistakes are my own. One was that I used a footprint from an external library for the mini-DIN jack; it confused me because the connections did not match the labels. After what I thought was deep study, I decided all it needed was to mirror the footprint and all would be well; as it turns out, it didn’t need to be mirrored (this is equivalent to mounting it on the underside). The jumper was also my fault. It really depends on how large your board is; if you’re using free EAGLE, you’re limited to 80x100mm, which is fine if you send it to seeed studios, who will make simple double-sided boards of this size for 10 units for $5US with a turnaround of 3-4 days, but if you want them back quickly you’ll need to splurge about$25 for DHL. Oshpark’s expedited service is also fast, but much more expensive - though if you have a very small board, you may find it acceptable. Normal turnaround for them is closer to 2-3 weeks. I used SMD parts, and sortof regret doing that because I don’t have a reflow oven or tools. It’s not as easy as it looks with a hand soldering iron. Dave wow, that's fast! With regard to the SMD soldering, I might be able to help. I'm not sure of your skill level, so I hope it's not condescending, but when I have to solder very small SMD components like resistors, I make sure all the pads are cleaned, and then get the component in place, held down with tweezers. Then I apply flux liberally, whet the soldering tip with an appropriate amount of solder, and then weld the first joint. This just basically lets you do things two handed without having to apply fresh solder from the spool. Additionally, if you're ever soldering a chip in, it's fine to use a big tip, plenty of flux, and then drag solder. If you apply too much solder and bridge some pins, you can use a wick, but often if it's just a little bridge, just add flux and drag the tip away from the chip down the legs. you might be doing that already, but just in case, hope that helps.
|
|
|
Post by dshadoff on Apr 25, 2019 2:43:53 GMT
Don't worry, it's not condescending... I'm reasonably certain that I can develop the technique, but watching a few Youtube videos can give you the wrong impression about how easy it is. Especially since I'm getting older and my hands aren't as steady as they used to be.
I may need to go the reflow route since I'm too impatient to develop the skills - though I might get a reflow hot air blower instead of an oven - seems like a half-way measure which could be useful for small-scale work like I am doing.
In other news, even though I don't have the circuit operational yet, I am pretty confident about the M4's ability to process data at full speed. I had written a test program on the PC Engine which would read all 256 sectors at full speed (and display a portion on the screen); it processed the full contents in 10.5 seconds.
Up until today, my Arduino driver was taking closer to 40 seconds to do the same, but the problem was on the driver side because: 1) digitalWrite() is very slow 2) the delayMicrosecond() call lacks precision below 4 microseconds 3) I had a bunch of logging turned on
I increased the speed on the test setup by changing the digitalWrite()/digitalRead() functions to direct port access, and removing the bulk of the log output (and reducing the delayMicrosecond() to 1). In so doing, I have reduced the time to write 256 sectors down to 6.1 seconds, with no apparent errors. While I still need to run a more comprehensive data-corruption test suite, this is very promising. Hopefully the PC Engine will not bring any surprises, and this can be used as it is today (but of course, I'll add functionality).
Dave
|
|