Savegame drive idea

For hardware talk only (please avoid ROM dumper stuff)
Sik
Very interested
Posts: 939
Joined: Thu Apr 10, 2008 3:03 pm
Contact:

Savegame drive idea

Post by Sik » Tue Mar 08, 2016 4:13 pm

I came up with the idea of a removable drive for savegames for the Mega Drive. The idea here would be to just take a 24C64 (serial EEPROM) and wire it to a joystick port, then let the 68000 talk to it directly. Exact implementation is still not defined, thinking about mapping SDA and SCL to bits 2 and 3, then hardwiring the remaining bits (using VCC and GND) to be used for detection.

Pros:
  • Should work with just about anything out there
  • Cheap to make (there's only a single component, everything else is wiring)
Cons:
  • Doesn't play nice with multiplayer, unless you're OK with hotswapping or multitaps
  • Moving it to port 3 won't work since way too many systems lack this port
  • Also wouldn't be trivial to retreive the data from or into a PC
That last one could be probably solved by just having a cartridge that talks to a SD card (both Everdrive and Mega Everdrive should be capable of this). We're going to want a program to manage the drive anyway just for doing housekeeping like copying files and checking what's inside and such, so we could just slap a SD card on it too if we need =P

More things to consider:
  • I'm saying 24C64 here but anything similar would work (e.g. 24LC64 can take 5V too)
  • It seems there are larger sized serial EEPROMs too, may want to look into those?
The biggest problem in my opinion is the multiplayer thing. Any ideas on what could be done here?

As for the filesystem, I need to write up the exact specs yet. Would probably use 32 byte blocks since that's the size of a page. Filenames would be encoded using a 40 value charset (this way I can cram three characters into two bytes), as follows:

Code: Select all

  0 1 2 3 4 5 6 7 8
9 A B C D E F G H I
J K L M N O P Q R S
T U V W X Y Z . - '
For the sake of safety, library code would be provided so every game can just use that instead of everybody coming up with their own implementation each with their own set of bugs (if we're going to have bugs, they better be consistent). Also would make everybody's lives easier and then more games can make use of it =P

Any comments?
Sik is pronounced as "seek", not as "sick".

HardWareMan
Very interested
Posts: 745
Joined: Sat Dec 15, 2007 7:49 am
Location: Kazakhstan, Pavlodar

Re: Savegame drive idea

Post by HardWareMan » Tue Mar 08, 2016 5:45 pm

You can use SPI FLASH too. Hmm, SD/MMC card has SPI mode. Wait, oh shi~...

Mask of Destiny
Very interested
Posts: 615
Joined: Thu Nov 30, 2006 6:30 am

Re: Savegame drive idea

Post by Mask of Destiny » Tue Mar 08, 2016 6:19 pm

SD/MMC is 3.3V though. SPI level shifters are cheap, but if you're trying to keep the parts count to a minimum it's not ideal.

What's the price you're aiming for here? Is the goal to have a small production run of these or to have people assemble them by hand?

Sik
Very interested
Posts: 939
Joined: Thu Apr 10, 2008 3:03 pm
Contact:

Re: Savegame drive idea

Post by Sik » Tue Mar 08, 2016 6:33 pm

Last time I discussed with people about SPI I was told that getting it to work was complex enough to actually make a FPGA a necessity. Honestly I have no idea what's actually involved. I'm suggesting the 24C64 because not only it can be wired directly, this is what some games did back in the day even.
Mask of Destiny wrote:What's the price you're aiming for here? Is the goal to have a small production run of these or to have people assemble them by hand?
Eh, just trying to set up some "defacto standard" for homebrew to follow, so when somebody comes in manufacture such stuff we don't need to make homebrew exclusively designed for that (i.e. if homebrew implements this, then somebody wants to manufacture drives, they can use the existing protocol and older homebrew will still work with it). Also the idea that this could work with homebrew that's just a ROM (for those cases where games actually make it to actual cartridges) and also having the data not tied to a single cartridge as used to be the case.

In short: just setting up a common protocol we all can agree on and that is as cheap as possible to make.
Sik is pronounced as "seek", not as "sick".

Mask of Destiny
Very interested
Posts: 615
Joined: Thu Nov 30, 2006 6:30 am

Re: Savegame drive idea

Post by Mask of Destiny » Tue Mar 08, 2016 7:11 pm

Sik wrote:Last time I discussed with people about SPI I was told that getting it to work was complex enough to actually make a FPGA a necessity. Honestly I have no idea what's actually involved.
SPI is pretty simple. The main disadvantage over I2C is that it requires more pins (4 for a simple system with a single slave device, and one extra pin for each additional slave vs. 2 for I2C). You can definitely bit-bang SPI, though obviously a hardware implementation will be faster.
Sik wrote:
Mask of Destiny wrote:What's the price you're aiming for here? Is the goal to have a small production run of these or to have people assemble them by hand?
Eh, just trying to set up some "defacto standard" for homebrew to follow, so when somebody comes in manufacture such stuff we don't need to make homebrew exclusively designed for that (i.e. if homebrew implements this, then somebody wants to manufacture drives, they can use the existing protocol and older homebrew will still work with it). Also the idea that this could work with homebrew that's just a ROM (for those cases where games actually make it to actual cartridges) and also having the data not tied to a single cartridge as used to be the case.

In short: just setting up a common protocol we all can agree on and that is as cheap as possible to make.
I guess the reason I'm asking about costs is that I see a number of alternate designs aiming at the same basic goal, but would almost certainly be at least a little more expensive than just wiring an EEPROM to a DE-9 connector. Using an SD card for instance, would require both the SD/MMC connector and the SPI level shifter as a minimum, but obviously brings some flexibility as well as allowing saves to be copied to a computer. The multiplayer concern could be addressed a number of ways. The simplest would be to just have both male and female DE-9 connectors so that it could be used in the EXT port when available. This would add the cost of the second connector and would probably mean that supporting the controller ID protocol would be mandatory (though that's probably a good idea anyway). Another option would be to add a port for a controller to be attached and have some kind of multiplexing protocol. This would probably be most easily achieved with a low-end low pin count microcontroller. A third might be to just use the expansion port. You'd lose Sega CD access and there would be some small price increases from the edge connector and larger PCB, but it could still be relatively cheap with the right design.

Sik
Very interested
Posts: 939
Joined: Thu Apr 10, 2008 3:03 pm
Contact:

Re: Savegame drive idea

Post by Sik » Tue Mar 08, 2016 10:18 pm

The problem with the EXT port is that it's missing from most consoles (including every model 2 and 3 out there), and as you say the expansion port prevents the Sega CD from being used which I bet is a no-no for quite a good bunch of people (especially with all the "make it a CD 32X game!" demands)

The multiplexing one is probably more reliable, but I can't think of an easy way to do this either, not to mention that a controller wants to make use of all 7 lines, which makes it kind of problematic. Maybe it could be something more like the EA multitap? It plugs into both controller ports with the 2P port used for multiplexing. It could be used as some sort of deck for other stuff (e.g. the EEPROM would be provided separately), heck include the multitap capabilities into it as well. But honestly at this point it starts becoming kind of excessive compared to the original idea, the only advantage against an add-on in the cartslot instead is that it's guaranteed to work even with clones.

Of course the real question here is how relevant is multiplayer to homebrew.
Sik is pronounced as "seek", not as "sick".

Mask of Destiny
Very interested
Posts: 615
Joined: Thu Nov 30, 2006 6:30 am

Re: Savegame drive idea

Post by Mask of Destiny » Wed Mar 09, 2016 12:07 am

Sik wrote:The problem with the EXT port is that it's missing from most consoles (including every model 2 and 3 out there),
I guess what I was thinking with the dual gender suggestion is that players with an EXT port could get multiplayer + savedrive and players without would choose whether they wanted save support or multiplayer support. Definitely not ideal, but better for those that have an EXT port without being really worse for those without. Whether it's worth the increased cost is another matter.
Sik wrote:and as you say the expansion port prevents the Sega CD from being used which I bet is a no-no for quite a good bunch of people (especially with all the "make it a CD 32X game!" demands)
I suppose if you wanted to get really fancy, you could support saving to the Sega CD's internal BRAM in the library. Then users with a Sega CD wouldn't need the hardware for normal usage.
Sik wrote:The multiplexing one is probably more reliable, but I can't think of an easy way to do this either, not to mention that a controller wants to make use of all 7 lines, which makes it kind of problematic
The simplest single port setup would use an additional two pins as outputs. One would select between the SD slot and the controller and the other would select between the high and low nibbles of the controller output. Another option is something similar to the Sega multitap using a microcontroller.

You could do something like the EA multitap, but it does start to get kind of excessive part-count wise as you say.
Sik wrote:But honestly at this point it starts becoming kind of excessive compared to the original idea, the only advantage against an add-on in the cartslot instead is that it's guaranteed to work even with clones.
Except for the emulator-based clones, but nothing is likely to work with those anyway. Is there a summary anywhere of what cart signals are typically missing on clones?
Sik wrote:Of course the real question here is how relevant is multiplayer to homebrew.
No idea on that one.

cero
Very interested
Posts: 338
Joined: Mon Nov 30, 2015 1:55 pm

Re: Savegame drive idea

Post by cero » Wed Mar 09, 2016 8:55 am

Forgive me for asking, but who is the target audience?

As I see, most homebrew uses flashcarts -> saves can already be backed up. This isn't compatible with existing games. So the only use for this would be removable saves for future homebrew production runs?

Sik
Very interested
Posts: 939
Joined: Thu Apr 10, 2008 3:03 pm
Contact:

Re: Savegame drive idea

Post by Sik » Wed Mar 09, 2016 11:11 am

Mask of Destiny wrote:I suppose if you wanted to get really fancy, you could support saving to the Sega CD's internal BRAM in the library. Then users with a Sega CD wouldn't need the hardware for normal usage.
I was going to mention this, but then I was wondering how would you transfer saves between both devices (inevitably somebody will want this).
Mask of Destiny wrote:Another option is something similar to the Sega multitap using a microcontroller.
Fuck no (that thing is a pain in the ass to program for) Maybe if it was more like Ten Key Pad, but even then. Besides, the Sega multitap only supports the 3-pad and 6-pad, things will go haywire the moment somebody wants to use the mouse.
Mask of Destiny wrote:Except for the emulator-based clones, but nothing is likely to work with those anyway.
Yeah, those can't even run normal games properly =P I was thinking more about those unlicensed clones from Russia and China that tend to be about as good as real hardware for the most part, but also tend to lack the stuff needed for expansion. (except that 8MB ROMs tend to be a tad more reliable, there must be a reason why bootleg DRM is always on the >4MB address range)
Mask of Destiny wrote:Is there a summary anywhere of what cart signals are typically missing on clones?
Pretty much look at a model 3 and you'll get an idea, those clones aren't too far away from that.
cero wrote:As I see, most homebrew uses flashcarts -> saves can already be backed up. This isn't compatible with existing games. So the only use for this would be removable saves for future homebrew production runs?
Yep. And there have been quite a bunch of those lately, so it's not as unwarranted as it sounds.
Sik is pronounced as "seek", not as "sick".

Mask of Destiny
Very interested
Posts: 615
Joined: Thu Nov 30, 2006 6:30 am

Re: Savegame drive idea

Post by Mask of Destiny » Wed Mar 09, 2016 9:32 pm

Sik wrote:
Mask of Destiny wrote:I suppose if you wanted to get really fancy, you could support saving to the Sega CD's internal BRAM in the library. Then users with a Sega CD wouldn't need the hardware for normal usage.
I was going to mention this, but then I was wondering how would you transfer saves between both devices (inevitably somebody will want this).
Seems like a pretty niche scenario to worry about, but if the expansion port device has a small boot ROM on it you could potentially transfer saves using a BRAM cart.
Sik wrote:
Mask of Destiny wrote:Another option is something similar to the Sega multitap using a microcontroller.
Fuck no (that thing is a pain in the ass to program for) Maybe if it was more like Ten Key Pad, but even then.
Eh, it's not so bad. Controller ID + data for four controllers is a fair bit of data to have to transfer a nibble at a time, but the 3-wire handshake protocol (also used by the mouse) is one of the more reasonable ways to get generic data out of the controller port.
Sik wrote:Besides, the Sega multitap only supports the 3-pad and 6-pad, things will go haywire the moment somebody wants to use the mouse.
I haven't tried it personally, but the documentation suggests that it supports the mouse.

Anyway, I wasn't suggesting using the multitap protocol exactly, just something similar. In particular, the Sega multitap is responsible for polling the peripheral and then sends the formatted report about its state when requested rather than having some kind of multiplexing scheme for the 68K to handle polling the peripherals directly. This could be particularly advantageous for talking to an EEPROM or Flash as sending data a nibble at a time will be much faster than bit-banging SPI or I2C.
Sik wrote:
Mask of Destiny wrote:Except for the emulator-based clones, but nothing is likely to work with those anyway.
Yeah, those can't even run normal games properly =P I was thinking more about those unlicensed clones from Russia and China that tend to be about as good as real hardware for the most part, but also tend to lack the stuff needed for expansion. (except that 8MB ROMs tend to be a tad more reliable, there must be a reason why bootleg DRM is always on the >4MB address range)
Mask of Destiny wrote:Is there a summary anywhere of what cart signals are typically missing on clones?
Pretty much look at a model 3 and you'll get an idea, those clones aren't too far away from that.
So it looks like !AS might be available so at the very worst you should be able to do your own address decoding. !AS apparently isn't asserted for VDP DMA, but that's not really relevant for an SD card or EEPROM anyway.

KanedaFr
Administrateur
Posts: 1139
Joined: Tue Aug 29, 2006 10:56 am
Contact:

Re: Savegame drive idea

Post by KanedaFr » Wed Mar 09, 2016 10:24 pm

Before I knew /TIME signal, my idea was to create a pass through cart

genny <-> cart with everything you want <-> original cart

just my 2 cents ;)

now, I'm more in on-the-cart idea, using /TIME

Sik
Very interested
Posts: 939
Joined: Thu Apr 10, 2008 3:03 pm
Contact:

Re: Savegame drive idea

Post by Sik » Thu Mar 10, 2016 12:05 am

The whole thing would be a tad easier if port 3 was more commonplace. Then I'd just use that and be done with it =P (I doubt anybody will bring the Mega Modem back into usefulness)
Mask of Destiny wrote:Eh, it's not so bad. Controller ID + data for four controllers is a fair bit of data to have to transfer a nibble at a time, but the 3-wire handshake protocol (also used by the mouse) is one of the more reasonable ways to get generic data out of the controller port.
This is the part that handles the Sega multitap in Star Chaser. (note to self: release game source code) If I hadn't made a macro for the part that reads back a nibble, I'd have gone crazy probably.

The Ten Key Pad-style protocol (which is somewhat similar) lacks the timeout part, the device is supposed to respond in time (or at worst with a tiny delay), so the whole timeout loop mess can be avoided. I guess you could argue about some operation being slow, but note that there's a line that's still unused in the Ten Key Pad protocol, that could be used to signal reading instead of writing =P

But whatever would be needed to get this to work would probably end up notoriously complex anyway.
Mask of Destiny wrote:I haven't tried it personally, but the documentation suggests that it supports the mouse.
Will recheck later, but the point is that such a thing would never be able to support any peripheral it wasn't specifically designed for.

Actually wondering if there's a way to easily multiplex lines without a peripheral noticing. Any ideas? (but even then we need to ensure it goes both ways, i.e. not only-input or only-output) Or worst case we could just have a literal switch on the device to toggle between both and then expect the game to tell the players to switch as needed =P (although wouldn't that suffer from hotplugging issues, except maybe for VCC and GND being shared?)
Sik is pronounced as "seek", not as "sick".

MrTamk1s
Very interested
Posts: 75
Joined: Sun Jan 04, 2015 10:27 pm
Location: Pennsylvania
Contact:

Re: Savegame drive idea

Post by MrTamk1s » Sat Mar 19, 2016 5:34 am

Have you looked at Future Driver's/MtChocolate's Sweet Rammy project? It is a circuit that can dump SRAM from retail carts via a joypad serial port, running a ripper program (via a flashcart), swapping out with a target cart, and then saving the data via a USB port to a PC. Should just need some modifications to make it a generic Savegame drive...
SGDK homebrew dev and Unity3D Indie dev.
Sega does what Nintendont!

Sik
Very interested
Posts: 939
Joined: Thu Apr 10, 2008 3:03 pm
Contact:

Re: Savegame drive idea

Post by Sik » Sat Mar 19, 2016 9:04 pm

That's even more complex than the other stuff discussed here x_X

Really the crux of the problem here is that the only two ports we can really trust to be there are the joypad ports. If the modem port was more commonly accessible then I'd just use that (I doubt anybody will miss the modem). The Sega CD port is overkill and also missing on the model 3 (as well as not working in many superclones). Multiplexing comes with its own set of issues, and telling people to get multitaps probably won't work well =P

I'm not sure hotplugging is really that much of an issue, so we could just tell players to switch devices if needed... but I imagine those pins would suffer from wear really fast (unlike cartridge hotplugging, where removing a cartridge doesn't put much stress on the cartslot pins, if any). The alternative is to put a port on the cartridges themselves but then that starts becoming expensive on the cartridge side (i.e. the very thing we don't want).

Though, now wondering... how many games do saving in multiplayer?
Sik is pronounced as "seek", not as "sick".

TmEE co.(TM)
Very interested
Posts: 2440
Joined: Tue Dec 05, 2006 1:37 pm
Location: Estonia, Rapla City
Contact:

Re: Savegame drive idea

Post by TmEE co.(TM) » Sun Mar 20, 2016 5:06 pm

SD card slot on the cart is way cheaper than any dongle you can attach to the controller port. You don't need almost any logic to read and write the SD card, there's no strict timing requirements so you can bitbang all you want, no need for any CPLDs and FPGAs with serializer/deserializer and whatnot.
Mida sa loed ? Nagunii aru ei saa ;)
http://www.tmeeco.eu
Files of all broken links and images of mine are found here : http://www.tmeeco.eu/FileDen

Post Reply