Let's develop an open-source media archive standard

you have to think beyond emulators and think of just getting the data. You started this whole thing out by asking for ideas and concepts to make sure that disks could be made in years to come. I challenge you to expand the horizon and suggest that what you need is a way to get the data out easily and make disks. Personally, I have zero use for a image file format that can only be used to make disks and makes getting data out of it a pain in the backside. Maybe in years, I will need to make a floppy disk, but I believe that getting the data out (files or whatever you choose to call them) is more important and will be that way in the future also. Where small things can get lost, having a "standard" image file format that let's me do both makes more sense to me. As for emulators, Microfast by Simeon Cran uses an import from ms-dos and the emulator runs great. The original BabyBlue card wrapped the cp/m program in a ms-dos wrapper and then you didn't even have to think twice about running a compiler, linker, etc. Would it do direct disk access? No, but that is what the original platforms are for. Most programs went through the OS for disk access because they were file oriented. I can't recall how Fred arranged his emulator, but I have a copy of that to. Your arguement about emulator programmers wondering "why" about binary is a non-issue. The spec defines ascii and that is the way data is represented. They will probably more appreciate the the standard then complaining about such things. If they do, then they certainly don't need to write anything. A user could easily write the utility or someone who is part of the standards group will make software templates and simple utilities available. Writing the utilities would be something that I wouldn't mind helping with for example. The image file that you are discussing is only good as a "how to" to write arbitrary data to arbitrary media. It is only good for creating a final media image because the format being contemplated (mixing data into the physical spec) will preclude the file from standing on its own. I was proposing identifying data blocks as files if that is what they were. The data blocks would have been sequential and trivial to retrieve. That is hardly what I would call defining a file system as part of the image file. best regards, Steve Thatcher Original Message: ----------------- From: Vintage Computer Festival vcf(a)siconic.com Date: Thu, 12 Aug 2004 10:25:20 -0700 (PDT) To: cctalk(a)classiccmp.org Subject: RE: Let's develop an open-source media archive standard On Wed, 11 Aug 2004, Steve Thatcher wrote: Steve, All emulators for 8-bit machines today that I'm aware of use disk images. Emulators like SIMH can read in individual files by, for instance, turning the file into a virtual paper tape reader. Your point, again, is taken, but so is Dwight's. I think it depends on what emulators you spend most of your time playing with which defines your outlook on this. One problem I did think of after I sent my last message concerning this is that if you do start including filesystems, people (probably emulator writers in particular) will start to wonder why you didn't store the data in binary. "Why," they ask, "do I have to convert the data from ASCII when the file is fully capable of holding binary data?" Then you might get some joker making unauthorized extensions to the spec with binary data fields. Perhaps I'm getting carried away here, but I do see this as potentially problematic. Isn't the specification itself a "how to" for writing an image file? Also, the image file we are discussing is *NOT*, again, intended to serve the emulators. Emulator usage is a SECONDARY concern. -- Sellam Ismail Vintage Computer Festival ---------------------------------------------------------------------------- -- International Man of Intrigue and Danger http://www.vintage.org [ Old computing resources for business || Buy/Sell/Trade Vintage Computers ] [ and academia at www.VintageTech.com || at http://marketplace.vintage.org ] -------------------------------------------------------------------- mail2web - Check your email from the web at http://mail2web.com/ .