Further development of writing functionality

All news about KryoFlux go here.

Which method would you prefer for disk duplication in DTC / KryoFlux?

completely independent duplication based on "best guess", creating more or less analogue copies
8
19%
image format dependent, like G64 dumping / writing works today
16
37%
user defined scripting
14
33%
don't care, I am interested in dumping / image creation only
5
12%
 
Total votes: 43

User avatar
mr.vince
Posts: 1870
Joined: Tue Oct 05, 2010 5:48 pm

Re: Further development of writing functionality

Post by mr.vince » Tue Oct 15, 2013 5:21 pm

drdanj wrote:(Speaking as an independent individual with no vested interests) - truth told, there have been competing things but they've never gotten off the ground. DiscFerret springs to mind? Despite what you might think, this is pretty niche, and in x number of years no one else has come up with something that does the job as well as a kryoflux. The IPF format is fairly well deconstructed and Kier has put up a utility that can create IPF files and is open - it's not to the specification of SPS, but it will create files that the kryoflux is happy to write, and it's quite hackable. The IPF read-library source is also downloadable, and that basically shows the inner workings of the format.
Thank you, pretty much sums it up. You might have noticed this thread heads into the direction of brining more user interaction / freedom and the idea of scripting would allow other tools to export data + description which KryoFlux could then write. The ultimate goal would be user generated IPFs (maybe called differently, but you get the idea), directly exported from DTC. G64 image creation is very much like this, but very focussed on a certain platform.

If more people had expressed their interrest in help and collaboration, things might be different today. But instead much of the feedback was like "when is it ready, I need working code for my project". We decided we would not get anywhere with this, especially since we had/have to cover research cost (buying certain types of computers / drives / media, measuring equipment, producing prototypes). Open source really does not help here, as our niche is neither sexy, nor does any fame come with the work done. So, the dice have fallen. For the time being.

I invite anyone interested in joining the team to contact us; but please no (more) GPL discussions for now.

roybridge
Posts: 7
Joined: Sun Oct 06, 2013 8:16 pm

Re: Further development of writing functionality

Post by roybridge » Tue Oct 22, 2013 9:54 pm

Having only had my hands on a KryoFlux for two days, it's far too early for me to even know what I'm talking about - let alone choose an option! I prefer to have whatever option allows me to produce (as) faithful (as possible) duplicates. At the same time, I want to contribute to the software preservation community by providing preservation dumps of as much as I can.

gsoravil
Posts: 4
Joined: Mon Oct 29, 2012 8:44 pm

Re: Further development of writing functionality

Post by gsoravil » Tue Oct 22, 2013 9:59 pm

I selected "user defined scripting" with the caveat that there becomes a good way to share our successes. Otherwise, the way the C64 images works best for me.

My driving force is the void of write options. I like the idea of archival using KryoFlux, but like many others, future write ability was a primary goal. I have Big Blue Reader for my FD-2000, as well as the wonderful uIEC from Jim Brain - but these only opened up the outside world to me C64. I used my KryoFlux to bootstrap my A1200, which has now opened up my A1200 to the world. I also can use it to finally preserve my copy-protected C64 disks. However, my Apple IIgs is barely able to be updated from the outside world. I also have absolutely no means to make disks for my classic MAC. I royally need more write support from the KryoFlux. My hope with "user scripting" is that with our collective willpower we can start to add write support for basic, non-protected disk writing for some of the missing systems.

Greg

lbickley
Posts: 1
Joined: Sat Nov 05, 2011 6:03 pm

Re: Further development of writing functionality

Post by lbickley » Tue Oct 22, 2013 10:03 pm

I, too, purchased KryoFlux for the purpose of preserving AND creating media for vintage systems. If I can't produce vintage media, KryoFlux is only doing half the job I need done. Unfortunately, I haven't used KryoFlux for a long while. I need to re-visit the its current status...

Lyle

User avatar
mr.vince
Posts: 1870
Joined: Tue Oct 05, 2010 5:48 pm

Re: Further development of writing functionality

Post by mr.vince » Tue Oct 22, 2013 10:32 pm

The latter posts sound like there's a need to produce user created disks, like system disks, demo disks, etc. - but not dupes of commercially created software. These two are very different things, so please let's get into detail here.

User avatar
NF6X
Posts: 15
Joined: Sat Aug 17, 2013 2:17 am
Location: Riverside, California, USA
Contact:

Re: Further development of writing functionality

Post by NF6X » Tue Oct 22, 2013 10:35 pm

BTW, I've successfully built the Kier's code that understands IPF from https://github.com/keirf/Disk-Utilities.git and it looks like it might not be too hard to modify to understand other MFM-based disk formats. Modifying it on my list of things to try pretty soon. If I can get that to work for the platforms that interest me, that could be pretty cool.

gsoravil
Posts: 4
Joined: Mon Oct 29, 2012 8:44 pm

Re: Further development of writing functionality

Post by gsoravil » Tue Oct 22, 2013 10:58 pm

@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.

User avatar
mr.vince
Posts: 1870
Joined: Tue Oct 05, 2010 5:48 pm

Re: Further development of writing functionality

Post by mr.vince » Tue Oct 22, 2013 11:07 pm

I am pretty sure the Lattice C disk is plain ADos, and you can write it with KryoFlux by writing an ADF file...

sncboom2k
Posts: 147
Joined: Sat Jul 21, 2012 5:33 am

Re: Further development of writing functionality

Post by sncboom2k » Tue Oct 22, 2013 11:10 pm

My vote is for user defined scripting. There are other ways to produce "blind" copies. 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. For preservation, I like the way the Commodore format is handled today. Of course DTC could use a bit more enhancement to cover the remainder of copy protections, but that's unfair to ask considering the number of other system formats that would like to have the same functionality. Not to mention the amount of development that has gone into that already. Thanks for that.

On a side note - I would still love to see flippy writing implemented so both sides of the disk could be written without flipping the disk over and running into the index hole issue.

Thanks for the hard work! I don't think anyone would prefer to pay for an add on, however I understand that development must go on, and it's not free.

gsoravil
Posts: 4
Joined: Mon Oct 29, 2012 8:44 pm

Re: Further development of writing functionality

Post by gsoravil » Wed Oct 23, 2013 6:02 am

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).

Post Reply

Who is online

Users browsing this forum: No registered users and 2 guests