Very interesting! Can't wait to see the finished product!!!

The boards have finally arrived! I'm leaning more towards the Link plug being 'flying' as in an inch or two of cable to relieve stress from the PCB and enclosure. This way I can use my existing Gen2 Low Profile enclosures too.

I've coded a very basic GB ROM, Load/Save/Slot# and a confirmation screen. I'll finish up the firmware on the block this weekend and hopefully have a working demo unit by next week.

If I were capable I'd definitely help. This looks to be the most useful non-cart related gameboy accessory ever created.

Firmware complete, PCB's in production!

I've gone with 30 'Slots' on the stick (Using a 4mbyte Flash IC - Can be upgraded to 64 slots with an additional 4mb IC) Each slot can be used to load/store an entire 128k cart save, can be renamed and duplicated via the gameboy and is accessed on the PC as a USB drive.

The most convenient backup utility yet?

Still need to work on the Gameboy side ROM, some nice GUI. I was hoping someone would offer assistance for this part of the project. Spare time is getting harder to find

Woot! Sounding great. MicroSD would be great but maybe overkill. 8mb will already hold over 60 savs which is a crazy huge amount

Almost completed the prototype!

I've gone with a 32Bit ARM processor, USB Mass storage mode on the PC side so no drivers and works on all Operating Systems.

I'm thinking of adding a Micro SD card socket for flash storage. This will make the Sav storage pretty much limitless! It does add complexity to the code as it is all pure assembly. I'll stick with an 8mb Flash IC for now.

Cool. Either works for me and less to carry. 

Sockets are too hard to come by so It will either be DMG or the Pocket/Colour size plug. Possibly both

I don't want to complicate unnecessarily but after posting my orginal ideas I realized that using a male link plug would make the device pretty much dmg-specific.  With that in mind, a female link plug would probably be more flexible since the user could source the appropriate cable for the gb model they use. Make sense or am I over thinking it?

Edit: looks like you may have already addressed this

Sounds like a good idea.

I've got the hardware sorted, like egr suggested, a Link plug on one end, and usb male on the other.

One problem is adding the 5v pin to the link plug. Not an issue with GBC but DMG style plugs require sacrificing one plug to make upto 4 DMG plugs with the extra pin. (OR sacrifice the gnd pin and use the shield which is also grounded)

The price is slowly rising with the necessity of a higher rated MCU with a 3rd SPI port (for USB functionality) plus a USB-TTL module.

And there will be a bit of manual labour fitting the fifth pin in the link connector, cutting and grinding to make it pcb compatible. That will be up to the customer if they want to tackle it themselves or have me do it.

also going to embed the whole lot in polyurethane. I cant see any other reliable way to remove stress from the PCB-Connector infterface.

Very interested. You should talk to nitro and work out LittleFM compatibility, make it all just one big ips patch, or at least make sure the two patches don't conflict. It already supports sending save data through link cable so it shouldn't be too hard!

Yes, Mac wont be an problem with this hardware. A simple program to get all 16 128K saves off into a folder will be easy. Likewise for getting them back on.

This is exciting, will the usb part work like a
And will here be mac OS X compatibility? I'm still new to this, but I only have macs and would like to know about that.

I now supply all patches as an IPS Patch file. That isolates me from the whole 'registration' issue. I'd love to co-ordinate this project with Johan though unfortunately he doesn't have the time to respond to my emails. This really delays progress as I have to reverse engineer his code line by line to support my hardware requirements. It sure would be easier him adding 2 lines of code in his source and recompiling than me spending 8 hours digging through C "optimised" assembly. I'm sure he has his reasons.

Naming the save files is no problem, that is all in the GB code.

I'm thinking having the SPI Flash IC connected straight to the Link port with the AVR controlling its /CE line. Have the AVR snoop the data on the bus and when an enable string is detected, it allows data throughput to the flash IC. When transfer is complete, or an idle time has elapsed, disable the /CE line. This could allow the use of an ATTiny and just about halve the cost of the whole dongle. This would require some trickery with the AVR controlling the clock line and could just about halve the 128K transfer time. Something to look into

-Ben