Could a Duo be modded so as to have more internal save capacity?

[Bardoly]

As many other gamers have discovered, the save capacity of Duos is rather lacking, what with many of the later release RPGs saves taking up most (if not all) of the save capacity.

Is there any easy way that a Duo could be modified so as to increase the internal save capacity and allow more save games to be stored using the same internal memory manager?  If so, then I think that this would be a useful mod.

[whisper2053]

Interested to see where this goes.

[NecroPhile]

Technical feasibility aside (it's surely doable), I'd not bother with such a mod while Tennokoe Banks are so plentiful and cheap.

[burn_654]

I would think that the big obstacle wouldn't be placing in a bigger ram chip, as much as altering the bios/system card to know that there's more ram.

What could be interesting (if that was the case)...being able to flip between a few memory "pages" with a physical button/switch that mapped to a larger chip. Or even an sd card. That'd be awesome.

[bust3dstr8]

You could increase the save size by 16 times pretty easily by swapping the 16Kbit Ram for a 256Kbit Ram...ifc Duo uses a 16Kbit.

6116 and 62256 Rams both use standard JEDEC pinouts, so solder the matching pins onto the pcb and use a 4 position
SpDt dip switch on the 4 high address to select one of the 16 banks at a time.

A Hex rotary switch with pull-ups/pull-downs would probably work also and be easier to use.

[whisper2053]

Hold up...would it seriously be that easy?? I would have thought that burn had the right of it in the bios not necessarily recognizing the extra memory space. If it *is* this easy...oh my...

[OldMan]

Hold up...would it seriously be that easy??

Probably. With external control of the high address bits, bios would only see a 2K page. -Which- page would be selected by whatever method you used to control the address bits.

Might I suggest a 4 bit counter, with the increment input connected to a switch? You'd need some kind of readout to know the page number, but 4 leds would do it....

[SignOfZeta]

He's talking about switching banks (manually, with the system off) so the BIOS doesn't even know anything has changed. It might be a good idea to uprate the cap that powers the chip as well. All banks would need to be powered at all times, which might run out the stored voltage sooner.

It would be cool to see.

[whisper2053]

I do not have the necessary resources where I am at to be able to perform any sort of hardware mods, and have been rather reluctant to send my duo off to have anything done to it (not so much worried about doing so, more like I just do not want to do without lol), but I would drop postage in a heartbeat to get something like this done...

[Bardoly]

This sounds great!  Although I'd like to hear from someone who says that this is possible, and that they can do it.       Of course, a mod which could install an SD card for memory with no need for capacitors would also be awesome!

Also, if this would be doable, then how about modding a standard TurboGrafx-16 console to be able to save games?  Basically a Turbo Booster Plus mod?

[bust3dstr8]

It's possible....I haven't done it with back up RAM, but I have built multi-carts that use  DIP switches and 4Bit counters to
manually select 8 pages on a ROM chip. RAM wouldn't be any different.

If you wanted to pay an extra $10 or so you could this mod with a Ramtron/NVSRAM and eliminate the need for the save cap.

TheOldMan's idea using a counter,4 LEDs and a momentary switch for a clock pulse would work and look pretty cool too. 


I would probably use a Hex switch. It has a 4Bit output and you can easily read what page your on.

http://www.farnell.com/datasheets/9526.pdf

[OldMan]

using a counter,4 LEDs and a momentary switch for a clock pulse would work and look pretty cool too.

I think in binary. Reading the page would be no problem The NVSRAM is a great idea, though.

Next question: Could we invert a tsop socket (and clean out the notched corner) and make it press-on?
Everything on a little board that just presses into place on top of the curent chip?

(Yeah, I know about the power issue. Just wondering if it could be done.)

[whisper2053]

Bust3d, that switch is pretty cool. Also, I am looking at the number of positions on there being each linked to a separate bank and... 

That's a helluva lot of space! The project MUST happen!

[bust3dstr8]

using a counter,4 LEDs and a momentary switch for a clock pulse would work and look pretty cool too.

I think in binary. Reading the page would be no problem The NVSRAM is a great idea, though.

Next question: Could we invert a tsop socket (and clean out the notched corner) and make it press-on?
Everything on a little board that just presses into place on top of the curent chip?

(Yeah, I know about the power issue. Just wondering if it could be done.)

Doesn't look like a snap on module would be easily done. Address 11 and 13 on the 62256 would need to be lifted for wire jumpers
to Vcc and /WE.

[OldMan]

I will need to think on this some more.....

But, if the socket goes on the 2016, most of the lines could be wired to the 62256 fairly easily. You are going to have to lift A11-A14 anyway for the bank number, however it is done. It seems like 2 or 3 jumpers might make it work....

What I'm thinking is to use the socket on top of the 2016, to bring the pins up to a board where they could be re-routed to where they need to be on the 62256. My worry is more what to do with CE and OE to keep the 2016 from interfering. You would definately have to cut them to remove the 2016 from the busses, and use jumpers to re-route them to the snap on board.


In any case, I think the question is settled. Yes, it -could- be done. ;)

[Bardoly]

In any case, I think the question is settled. Yes, it -could- be done. ;)

So..., who has the skill to do this, and is ready to give it a try?

[whisper2053]

$64k question right there.

*waiting with bated breath*

[spenoza]

Dude, eating bait is pretty gross. Perhaps you meant "bated breath".

[whisper2053]

Fair enough, I stand corrected! Also, I am just standing as well, but that is neither here nor there. Where is the electronics maestro who will bring us MAWR SAVE POWAH?

[bust3dstr8]

Nothing wrong with baited breath...calamari tastes gooood

[Bardoly]

In any case, I think the question is settled. Yes, it -could- be done. ;)

So..., who has the skill to do this, and is ready to give it a try?

Anyone...?

[Marll]

This would be an interesting project to see tackled.

[NecroPhile]

Steve is likely your best best for such a project.  Have you asked him about commissioning it as a project?

[TheClash603]

This sounds awesome.  Extra memory on a chip that didn't need to stay charged would be amazing.

Almost enough for me to consider letting my duo be used for the test...

[dshadoff]

As many other gamers have discovered, the save capacity of Duos is rather lacking, what with many of the later release RPGs saves taking up most (if not all) of the save capacity.

Is there any easy way that a Duo could be modified so as to increase the internal save capacity and allow more save games to be stored using the same internal memory manager?  If so, then I think that this would be a useful mod.

Well, without actually connecting up any hardware, the answer is at least "partially yes".

The internal save RAM is a capacitor-backed 2KB SRAM.

When David Michel first came out with MagicEngine, he "accidentally" allocated the savegame memory bank as 8KB, and realized that the CDROM memory manager was dealing with addresses beyond 2KB without any problems (or rather I should say, "without any fixed-size limitations").

So, one could expand the 2KB to 8KB.

However, I don't know if everything would treat the 8KB savegame naturally.
- Some games implement their own BRAM managers, so they migh not deal well with larger-than-2KB.
- Tennokoe banks would not deal with the size beyond 2KB well
- Not sure about the Memory Base 128/Save-kun unit either - or rather, I should say, not sure about the various MB-compatible games, and their associated BRAM managers.

Beyond that, one could take a larger-than-8KB (or larger-than-2KB) SRAM, and connect a certain number of the high-order address lines to a selector circuit, so you could "dial-in" a BRAM bank.  I've seen some PCB-mounted rotary switches which have 8 positions and BCD output, so one of those might work well.

For anything like SDCards or other flash memory, that's not really feasible, unless a related patch is made to the BRAM save functions inside of the CDROM card, if you use flash memory.  On the other hand, FRAM or MRAM may not have this constraint, and may actually be available in sizes relevant to this application.  Of course, you would almost certainly need some sort of 5V-to-3.3V (or lower) conversion circuitry.

[bishopcruz]

As many other gamers have discovered, the save capacity of Duos is rather lacking, what with many of the later release RPGs saves taking up most (if not all) of the save capacity.

Is there any easy way that a Duo could be modified so as to increase the internal save capacity and allow more save games to be stored using the same internal memory manager?  If so, then I think that this would be a useful mod.

Well, without actually connecting up any hardware, the answer is at least "partially yes".

The internal save RAM is a capacitor-backed 2KB SRAM.

When David Michel first came out with MagicEngine, he "accidentally" allocated the savegame memory bank as 8KB, and realized that the CDROM memory manager was dealing with addresses beyond 2KB without any problems (or rather I should say, "without any fixed-size limitations").

So, one could expand the 2KB to 8KB.

However, I don't know if everything would treat the 8KB savegame naturally.
- Some games implement their own BRAM managers, so they migh not deal well with larger-than-2KB.
- Tennokoe banks would not deal with the size beyond 2KB well
- Not sure about the Memory Base 128/Save-kun unit either - or rather, I should say, not sure about the various MB-compatible games, and their associated BRAM managers.

Beyond that, one could take a larger-than-8KB (or larger-than-2KB) SRAM, and connect a certain number of the high-order address lines to a selector circuit, so you could "dial-in" a BRAM bank.  I've seen some PCB-mounted rotary switches which have 8 positions and BCD output, so one of those might work well.

For anything like SDCards or other flash memory, that's not really feasible, unless a related patch is made to the BRAM save functions inside of the CDROM card, if you use flash memory.  On the other hand, FRAM or MRAM may not have this constraint, and may actually be available in sizes relevant to this application.  Of course, you would almost certainly need some sort of 5V-to-3.3V (or lower) conversion circuitry.

Cool info. Also, didn't the Duo-RX have 128k SRAM? I could have sworn I read that somewhere. If that's the case, how did the Tennokoe and MB work with that system? Of course I might be completely confused, but I could have sword I read the 128k thing somwhere.

[thesteve]

simple answer to the original question
the system could have additional bram added with a selector switch to chose 2K at a time
the dma controller does have more address lines then used in the ifu, as it addresses 2 ram banks in the duo which are managed by the sys card in the non integrated setups
however the system would only recognize the allocated 2K at any given time as its only identification is its address range as set in software

[megatron-uk]

Hopefully my everdrive-fat library will (at least partially) make the issue of save retention and storage space go away. Once I've finished it (read support is mostly done) I intend to create a bram tool that can save individual save records to SD card and load them back again.

[Duo_R]

Do you have a thread on this?

Hopefully my everdrive-fat library will (at least partially) make the issue of save retention and storage space go away. Once I've finished it (read support is mostly done) I intend to create a bram tool that can save individual save records to SD card and load them back again.

[Bernie]

Hopefully my everdrive-fat library will (at least partially) make the issue of save retention and storage space go away. Once I've finished it (read support is mostly done) I intend to create a bram tool that can save individual save records to SD card and load them back again.

Wait...this is a tool that is used through the Turbo EverDrive?  That would be sweet.  More info please.