Your proposition is "half" correct, a tap file is always read sequentially, the only thing needed it to have a "rewind" function.Chema wrote:Another option, I think, would be patching the CLOAD and CSAVE commands in a v1.1 rom so they work with the disc and load this modified rom in overlay ram. Then load the tap game stored in disk. Problem with this is the usual CLOAD¨¨¨statements, which would need to load the "next" fragment, but in the disk there is no "next" fragment: we need a name.
Take this just as initial thoughts, maybe completely wrong
The idea is that either by reading a specific floppy location (let's say, last sector of a floppy, or like the HxC something with an invalid head position (i.e. head to step 255)) we will read byte per byte the tap file, this will need slight modification to the ROM, use floppy to read byte instead of the tape hardware, and some modification in the cumulus firmware (set to "TAPE" mode and select a tap file)
The only draw back of this solution is when an app/game use a custom loading mechanism, or use custom function, we can redirect all the ROM function to read/write to a tape, but not custom one in the app.
But anyway, tape with custom storage format can't be converted to TAP file.
The problem with dump is that you will generally loose the intro, and you need to be sure that you did your dump exactly when the game start. You mat also by doing this "unrandom" the rand generator a game may use if you dump is too late (i.e. after the game initialize it's rand seed) etc..
And of course it does not work with app/game that try to save to tape, or load other part (I don't know if there is any game like this currently, but for large game that could be expected)