You realize you're asking us normal people to vote on various options that we have no idea what they are?
I really like your wording, because it says much about what you want:
This would mean blind is out, because you can't guarantee or verify. You don't want to find out the game does not load the final boss on an archival copy... You would want to know before.As long as a copy works at least as good as the original
Hence we're asking.
Please simply write the ADF file back to disk; KryoFlux can do that for you as is.gsoravil wrote:@MrVince - Yes and no? As a for instance, I purchased a used copy of the Lattice C compiler for Amiga from a swap meet. All disks but one worked. Now I have a binder set plus disks but can't use it. I would like to be able to write a valid image back to the disk. Not piracy, but a need to write typical disks. O/S, user disks. Would like to try out cross-compiled projects, etc. Not necessarily games/protected disks.
e.g. dtc -w -f<mydiskname.adf>
Completely agreed and as I see it user-scripting gives the freedom of:gsoravil wrote:The Lattice C is just an example. The ADF write support is fantastic, actually.
I need some way of doing similar for other platforms besides C64 & Amiga. The main thing is I don't want to derail the project. I like its long-term goals.
I think the best way for me to articulate what I need, and I suspect many others too is provide an ordered list of my goals. So, in order (short term to long term):
- A means for "generic" (non-protected) disk writes across _common_ platforms using the most popular container (eg like D64) for each platform (Apple IIgs, IIe, MAC classic, TI, Atari 800k)
- A means for HQ/archival read of protected disks for each common platform
- A means to write platform-specific protected disks (for example IIgs games)
- A means to do custom disk formats / user scripting.
- Support for rare/uncommon formats (things like programmable pocket computers and the Nintendo Famicom come to mind)
HOWEVER, I voted for user scripting because I believe that collectively, it's the fastest path to accomplishing this list. If, however, user scripting is a monumental feature to provide then I would opt for the unprotected platform specific writes first, since that really is my immediate need (and I truly suspect I'm very much in line with many others here).
- reading and verifying the content of any kind of disk
- transforming the data read into some format for storage (including IPF!)
- use stored data to write any kind of disk with the ability to transform it as needed
- verify the content of the disk written
So this would resolve ALL the requests we have had so far or would have in the foreseeable future for reading/writing any kind of system; as long as the issue is not something that requires driving special hardware itself, e.g. reading Quick Disk - which is essentially a tape format used on a disk...
User-scripting is however not the fastest route to achieve a feature of this or that; it is an assured way that whatever feature/system can anyone ever think of will work - and would even enable doing things previously impossible or unfeasable, even the likes of tapes.
Practically, all users would have access to similar tools to what real mastering and duplicators used with the additional bonus of preservation aspects (ie check modifications etc) - obviously, there are features that duplicators would have no use of; a master by definition was modifed. Our focus here is quite different, as we are preserving now what was once done, so we need things and technology that did not exist then.
It would be the best of both worlds: preservation as well as mastering and duplicating capabilities - I can't think of any better way of merging the needs for both.
We'd call these User IPFs and maybe completely avoid the extension IPF for these. On the other hand UIPF or something like this could be used, too. We will add signing for this, so users can actually see where an IPF is coming from (us, someone else signed, or completely unsigned).sncboom2k wrote:Being able to create an IPF file in a generic manner would be great, however I fear that they could be mixed in with true preservation IPF's.
I think there's not much left, but of course you can just send in whatever dump you might have and we'll take a peek. Please keep in mind that those that are supported, are fully verified, and DTC has the ability to store tracks as RAW GCR (which are then blind of course).sncboom2k wrote:Of course DTC could use a bit more enhancement to cover the remainder of copy protections...
Yay, finallymr.vince wrote:We will add signing for this, so users can actually see where an IPF is coming from (us, someone else signed, or completely unsigned).
Now all we'd need is a "simple" analyzer that detects unformatted/copy protected tracks and creates the appropriate IPF track data for that (otherwise you'd just have nonworking IPF files, which wouldn't be a big help)
From what I've seen, keirf's disk-utilities could be used as starting point.
Thinking ahead, in my opinion, something that would be needed far more than writing images back to disk (at least in a few years) would be simulating/emulating a floppy drive directly. Simply because it's getting harder and harder to find working floppy disks, and in a few years all remaining stock will probably be sold out or scrapped. So here's the question: would it be possible (with the right firmware, of course) to drive the KF board "the other way round", i.e. have it read track data from USB and supply it to the 34pin FDC connector, responding to track change commands etc.? And yes, I am aware that this would only work for IBM PC (compatible) drives (PC, Amiga, Atari, etc.) and not e.g. on a C64, but for those other platforms there probably already exists hardware that simulates a floppy drive. And no, those "floppy emulators" that you can buy on eBay don't count, because they only support very limited emulation (sector images only for example)
How this works is that you find out the exact format the disk is in, then you either use an existing script as is (for popular formats) or modify an existing one (if the tool reports about some data inconsistency) or create a brand new one (if it is something completely new).
This is exactly how disks were duplicated/copy-protected at duplicators.
CTA that we use at SPS is very efficient for finding out about disk formats and the like, but it is very possible to create non-working IPF images with it; it does not complain much and trusts the user of knowing what they do...
Now, that's not exactly ideal, unless you want to battle millions of non-working IPF images suddently appearing as people start to convert their own files, not to mention you'll never ever be able tell what the source really was.
So should an analyser be part of the toolchain for KryoFlux it must be the exact opposite by design, complain about everything and share information with the user about the possibility of missing out on some data and the like.
I could imagine something like how G64 generation works now, but it is simply not feasible with thousands of formats available, so it can't be fully automatic, unless people are prepared to wait for hours for a disk... we'll see.
As for FDC emulation: the level shifters are unidirectional, so it is not possible, not to mention the way I'd imagine that would require quite some hardware upgrade - but I have high standards.
If there is significant interest, I could imagine it happening
It might be unfortunate but I think that most users are more interested in “saving” their own diskettes (or using diskettes from others) than just participating in a preservation operation for future generation!
In this context saving means either writing copy (backup) or using images in software or hardware emulators. By hardware emulator (as mention in Darkstar request) I mean FDrive hardware replacement devices like the HxC2001 project.
Now if both can be done at the same time this would be perfect.
Currently with the KryoFlux board you get none of these wanted features without the help of SPS. I have posted dumps of about 100 FD more than two years ago and I am still waiting for the IPF files. This perfectly acceptable for me, because I am not really expecting anything, but I understand that this might be frustrating to some people. Note that part of the problem also comes non supported protections.
Based on my experience I am convince that the only viable solution is “scripting”. I say scripting rather than user scripting because in most cases users are not inclined in writing this kind of file. This is exactly what was done some 20 years ago with the Discovery Cartridge hardware for the Atari platform. At the time when you wanted to create a backup of a FD with the DC you either had to find an already created script or ask Happy Computers to create one for you. This easy to use solution has allowed me always use backup of the protected floppies and keep the originals in safe place without “wearing” them.
I have done already several development around Stream (http://info-coach.fr/atari/software/pro ... alysis.php) and IPF files (http://info-coach.fr/atari/software/projects/IPF.php) and I am currently developing a new set of tools that target features similar to what’s described in this thread. The ultimate goal is to write automatically IPF file based on Stream inputs so that you can use these IPF files for writing backup floppies, or use in emulators (HW & SW). For that matter the program will detect the protection mechanisms used in a protected track (see for example KFPanzer at http://info-coach.fr/atari/software/pro ... p#kfpanzer) and automatically select the correct XML script among a predefined set. Note that I AM ONLY LOOKING AT THE ATARI PLATFORM (i.e. DD MFM) although the prototype works also for HD MFM (PC). The hard part is to create the set of predefined scripts because there are a large number of protections and usually a user (like me) have access to only a limited number of games. So this is where it could become a PARTICIPATIVE project (meaning both direction). Part of the analyzer are already working but still in very early phase. See some analysis examples here viewtopic.php?f=3&t=749.
A lot more can be said … but I said my two cents