Freeplaytech Forum

Full Version: Feature Requests
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2 3 4
All of this is very interesting to inspect further. When people buy Linkmasta/Flashmasta bundles, I had been including the PCB from the donor cart, because I didn't need to keep it. Maybe I should keep some of those for experimentation purposes.

Anyway, I still think there's a chance that 12V on the /RESET pin could possibly result in a programmable chip. I really should mess with this a bit more. I don't know if it would result in anything more than just an interesting experiment, but it would be cool.

The method described in the document you referenced is pretty foreign to me. I have not seen this in any of the Toshiba/Sharp/Samsung/etc. docs from the time.

Also, note that I only ever tried this on Crush Roller, and I didn't have many carts at the time. After frying the chip, I was not excited about trying it on other carts. I'd be more willing to try it again now, but I also have other plans for my time. Big Grin
I had a look at some of the docs for those manufacturers and can't find any other method to remove the protection either.

The reason I'd like to be able to flash the carts is mostly to avoid bit rot - the carts are getting older and are already past the half way point of the data retention period given by Sharp. Sad

Anyway, I would love to buy a flash cart with an microSD card slot, so if you are working on those, thats great Big Grin

If you find time to experiment with the old carts, the documents mention a minimum rise time for the voltage on the reset pin to reach the 12V. I imagine this is to avoid the voltage overshooting for a fraction of a second as the connection is made, or to avoid high frequency harmonics. Maybe in an experiment a pot could be used to slowly raise the voltage, or a small capacitor could be placed between the reset pin and ground, to act like a low-pass filter and slow the rise time.

The old carts could be modified by adding an un-protect switch that switches the reset pin between VCC and one of the unused cart pins, and in the linkmasta that pin could be set to 12V when writing.
Well, this is definitely something to look into, but I expect it to be unfruitful. That's why it won't be high on my priority list.

As for the MicroSD slot, yes, I'm looking into that. However, it is something that will come along very slowly (many months, maybe even year or more). I have researched some techniques for adding the slot to the cart and make it accessible, but that's only a small portion of what needs to be done before it's useful to an actual NGPC.
Another vote for MicroSD support. In fact, it's really the only upgrade that the Flashmasta needs. It'll also mean that you no longer need to make Linkmastas, making things a lot cheaper and easier all round Big Grin
Having implemented SD card reading on 65C816 and Z80-based systems, I'd say the crucial point would be to find a C compiler that can compile FF or PFF (FAT parsing library). You could certainly rewrite PFF in assembly, but it only takes a quick glance at the code to see why that would suck Tongue

The low level SD card I/O code that sends MMC commands and reads sector data could be done mostly in C except for the most performance-critical parts (though I've used assembly exclusively in my implementations).
(05-07-2012, 02:30 PM)-SD- Wrote: [ -> ]It'll also mean that you no longer need to make Linkmastas (...)

I'd stick with Linkmastas as an option. It's a great device for Bung cartridge owners and for those who want to backup their legit games and game saves. I for one am really glad I got it.
(05-07-2012, 04:26 PM)mic_ Wrote: [ -> ]Having implemented SD card reading on 65C816 and Z80-based systems, I'd say the crucial point would be to find a C compiler that can compile FF or PFF (FAT parsing library). You could certainly rewrite PFF in assembly, but it only takes a quick glance at the code to see why that would suck Tongue

The low level SD card I/O code that sends MMC commands and reads sector data could be done mostly in C except for the most performance-critical parts (though I've used assembly exclusively in my implementations).

So, I have actually worked on this a bit, but I am also working on several other things, so it's not progressed too much.

I have a SD card that I interface through the Linkmasta. In this way, the code acts as if it is on a NGPC cartridge, but the code runs on the PC (as opposed to the NGPC itself).

I can read and write the SD using PFF. It's pretty slow, though. I have yet to figure out where the slowdown is. I think it may just be how I interface with it through the Linkmasta. On the NGPC, it would be able to talk direct to the cartridge. The SD card would be just one level abstracted from that.

In my current setup, it has to go through USB, then through the Linkmasta, then to the cartridge, then the SD. USB or Linkmasta both could be slowing it down.

I haven't written any code to run PFF on the NGPC at all. If you've got something that could easily work, that'd be awesome.

Making the Linkmasta is definitely something that I think is important, as it does support the Bung owners. However, I agree that it's the part that takes the most effort, because it has the custom-cut pieces. I'm not sure I'd want to completely stop making them, but maybe they wouldn't be bundled if they weren't 100% necessary.
I'm assuming that you're going for a RAM-based solution for the SD cart, and not in-device flash programming?

You'd need to decide what kind of SD interface you plan to use. Something bare bones where the host CPU has to do all the work, or something that comes integrated with a uC or CPLD for hardware assisted communication with the SD card? This choise determines a few other things. For example, you don't want to access the SD card in SPI mode on a slow host CPU as that would kill the performance completely. OTOH, if you had some dedicated hardware to take care of that then SPI mode would be preferable over native mode as it would simplify the code a bit.

You'll also want to consider how you're going to map the SD interface and the cart RAM into the TLCS900 memory space. With a 32-bit address space this shouldn't be a big issue, but it's still something to think about.

Only after all that has been decided is it worth beginning to do any software design.

For PFF you really want a C compiler, which could become a problem since I don't know of any C compilers that target the TLCS900H. Is Toshiba's compiler still downloadable from somewhere?

The lower-level disk I/O code that initialises the card and reads sector data is not such a big deal and can be written without too much effort once the SD interface and memory mapping is known. Here's the Z80 implementation I made for the neoflash sega master system cart: http://code.google.com/p/neo-myth-menu/s...skio_asm.s
This is getting a bit too technical for this thread. I will contact you, mic_.
mic_, where can I found this PFF C library?
Pages: 1 2 3 4