| Author: | Pete Rittwage (registered user: 558 posts ) |
|---|---|---|
| Date: | Thu, Jul 14th, 2011 @ 19:22 ( . ) |
Hi Nate, and all, (I am cross-posting this to the Nate's XUM-1541 devel list also to see if there is any interest in my helping to implement something like this on another level.) Thanks very much for taking your valuable time for old hobbies. I am sorry for my brain-dump format of this message, as it will be long and rambling. The 'nibedit' idea reminds me of something I've been thinking about for a while with regard to NIB files as Markus created, and all the different formats of emulator files we have to deal with (not to mention X cables). It seems to me that the image formats as passed down over the years are inherently inflexible. I've considered getting rid of the NIB format altogether and converting to a more modern XML-tagged "description" of the disk data that is in the file as we captured it. These files could contain lots of different tags to describe everything down to whatever level we have access to and at any level of detail. For example, a NIB image as read now into an XML format would contain tags with the timestamp, OS, program version, interface/cable type, interface firmware revision, drive type, drive speed, drive ROM hash, switches used, IHS or no, SRQ or parallel, halftracks, publisher, copyright, etc. (down to incredible detail). Some of this is currently in an accompanying "log" file that most people unfortunately don't submit to me. Track or sector tags would contain: *) detected density *) detected track types (nosync/killer) *) length as measured. *) description of following data chunk A data chunk could be: *) a "NIB" revolution, which is 1.x disk revolutions of GCR as read from the shifter (raw GCR) *) a "track cycle" of data from IHS pulse to IHS pulse (hole start or hole end?) *) fully decoded GCR data (D64-type data) *) separate raw sector headers and raw data sectors (breakout) *) HEX-formatted values of GCR data *) a single non-standard, or sync-to-sync GCR run *) description of "signature track". (So replace Pirateslayer track data with <tr>2<sig>pslayer1</sig></tr> *) flux transition timings, used with different imaging hardware *) compression type of any of the above The benefits are endless, and it could be used to convert to existing format, so it's backwards-compatible. You could "patch" the images using tags which we would could just be a another tag later in the XML file that supercedes the other tag. So edit a track, sector, or just a pattern of bytes using a description. This could be used for high score tracks/sectors, protection descriptions or patches, image differentials (alternates), or simple editing. If you want to "edit" a track, just define a new track at the end of the file with the new data. This could really be an "open" emulator media format like we've never had before. For any media for any emulator type. -Pete |
--- 0 Users Online --- 0 Recent Unique Posters |