I've been testing a 35MB/s read and 20MB/s write usb thumb drive which works rather well. Pricing in order from low to high is:

usb thumb drive
compact flash
hard drive (expensive because it's impossible to find a small one)

I'm interested in a pro/con opinions.

I would be concerned about long term reliability of flash devices. They are rated for a finite number of write operations. Depending on how your software works (i.e. load once work from memory vs a constant read/write to the drive) that could be a real issue.

Of course, that issue could be mostly moot, if the user were given a way to easily produce a subsequent flash drive to replace a dead one. The prices on thumb drives do make that viable.

I dont think a cfcard has any upsides compared to a usb thumbdrive.

The upsides with a thumbdrive compared to a hd would be less heat production, better tolerance to shocks, smaller and lower accesstimes (?). The downsides would be as previously stated probably less writecycles and limited space.

How much storagespace does the "product" require?

USB thumbdrives are up to 16G now. Could P2K possibly be using that much?

ChadTower wrote:USB thumbdrives are up to 16G now. Could P2K possibly be using that much?

No, not even near it. We are working on making the complete build as small as possible. Smaller =quicker loading and lower price on storage device. I'm using a 4gb thumb drive now and have plenty of free space

Thumb drives are cheap and reliable. As long as they can easily be replicated by end users I'd go that route. With "limited" write cycles of 100k writes I don't see that as being a big issue, especially since a decent thumb drive will wear level the blocks. More of an issue would be future compatibility, since the technology keeps changing (p3, etc). Actually, if you stick with USB any mass storage class device would probably work, so if a customer wanted a USB hard drive they could probably go that route.

Kenbo wrote:With "limited" write cycles of 100k writes I don't see that as being a big issue

Depending on the IO details of their implementation it could be a major issue. If they are going heavy on disk IO a thumb drive may not last long at all.

ChadTower wrote:

Kenbo wrote:With "limited" write cycles of 100k writes I don't see that as being a big issue

Depending on the IO details of their implementation it could be a major issue. If they are going heavy on disk IO a thumb drive may not last long at all.

Maybe we should make it a 'request'. Design the system to not wear out Flash Drives. It strikes me that most of the time running the game is a 'read' operation and the data is stored in memory. However, logging could be a concern... some programs can produce a LOT of logging.

The most important thing, I think, would be making it easy to backup and restore the data from whatever device it is. This is the main problem with the exisiting ROM situation. Difficult or impossible to replace game and program data in the event of failure.

Andrew wrote: Maybe we should make it a 'request'. Design the system to not wear out Flash Drives. It strikes me that most of the time running the game is a 'read' operation and the data is stored in memory. However, logging could be a concern... some programs can produce a LOT of logging.

Have they made that info public yet? We have no idea what emulating the original platform may have forced them to do - they haven't reimplemented it, AFAIK, they have emulated it. A number of seemingly odd IO paths are possible depending on how the original was done. Emulation doesn't usually follow the common sense IO design paths.

The most important thing, I think, would be making it easy to backup and restore the data from whatever device it is. This is the main problem with the exisiting ROM situation. Difficult or impossible to replace game and program data in the event of failure.

Fully agreed. Doesn't make any sense to design a potentially expensive replacement solution around a $10 flash drive if it were a potential failure point.

It has always been my plan to make the software part of the solution available to customers via the web. No matter which drive type is chosen you could, and eventually would, have failure. We will provide a way for you to recover from that.

ChadTower wrote:

Kenbo wrote:With "limited" write cycles of 100k writes I don't see that as being a big issue

Depending on the IO details of their implementation it could be a major issue. If they are going heavy on disk IO a thumb drive may not last long at all.

It would be interesting to know the algorithm used by the p2k software. If it writes to storage each time a logged event occurs then writes could be heavy but if it accumulates stats and writes them at the end of each game or at some other predetermined interval then a decent flash wear leveling algorithm should minimize wear. Does the original implementation use battery backed SRAM or flash or eeprom or ??? Sorry, I haven't looked into details. But a USB solution should still support any mass storage class so if wear is an issue use a USB hard drive.

Kenbo wrote:

ChadTower wrote:

Kenbo wrote:With "limited" write cycles of 100k writes I don't see that as being a big issue

Depending on the IO details of their implementation it could be a major issue. If they are going heavy on disk IO a thumb drive may not last long at all.

It would be interesting to know the algorithm used by the p2k software. If it writes to storage each time a logged event occurs then writes could be heavy but if it accumulates stats and writes them at the end of each game or at some other predetermined interval then a decent flash wear leveling algorithm should minimize wear. Does the original implementation use battery backed SRAM or flash or eeprom or ??? Sorry, I haven't looked into details. But a USB solution should still support any mass storage class so if wear is an issue use a USB hard drive.

The original uses flash ram. We can count how many times the machine will write data during normal use and will take that into consideration.

Chuck wrote:

Kenbo wrote:

ChadTower wrote:
Depending on the IO details of their implementation it could be a major issue. If they are going heavy on disk IO a thumb drive may not last long at all.

It would be interesting to know the algorithm used by the p2k software. If it writes to storage each time a logged event occurs then writes could be heavy but if it accumulates stats and writes them at the end of each game or at some other predetermined interval then a decent flash wear leveling algorithm should minimize wear. Does the original implementation use battery backed SRAM or flash or eeprom or ??? Sorry, I haven't looked into details. But a USB solution should still support any mass storage class so if wear is an issue use a USB hard drive.

The original uses flash ram. We can count how many times the machine will write data during normal use and will take that into consideration.

The original also uses battery backed sram / nvram for most of it's settings. The flash ram is written to in case of losing the nvram data, but I have no idea if the code copies all of the nvram, or just some of it. Extensive logging of the emu would be required to find out, but it's a low priority.

Needless to say, as many of you guessed, most of the time, the usb key or whatever device we use will be doing read operations, with seldom writes. I doubt anyone would burn out their keys for many many years if ever.

Wouldn't it be possible to have linux load itself + the emulator from the usb to the ram, and run everything from there. And just write the important stuff to the usb once in a while?

JMX wrote:Wouldn't it be possible to have linux load itself + the emulator from the usb to the ram, and run everything from there. And just write the important stuff to the usb once in a while?

That's exactly what we're doing, it loads everything into memory and runs from there, so the key is only read when you turn the game on initially.

As for the writes, we're still working on a few things to see what the best way to handle it is, but we will certainly keep the writes to the key as minimal as we can get w.o jeopardizing losing settings/scores/audits etc..