Apple II disk Grrr.....

[spags]

A good question to which I don't have an answer to.

No the DSK and PO disk images are only sector-based (which is why a lot of Apple // archived titles that had copy protection are cracked versions). My understanding is that NIB is a layer above this - more like what the floppy controller would actually see. Presumably STREAM is like a layer above NIB (what the head sees).

There is some discussion of NIB images at viewtopic.php?t=1075

Once upon a time I was going to learn the STREAM file format (for which documentation is readily available) and then do likewise for the NIB format to make a crude converter. Alas I never got around to it and certainly don't expect to.

There is a very basic description of the format at http://apple2.info/wiki/index.php?title ... S3.3_Order but that is really all it is (ie. not a specification).

Perhaps someday, someone with the necessary knowledge will read this (and hopefully for them it may be an almost trivial exercise).

[BarryB]

I'm not a programmer so that's me out! Maybe asking Jeff to support for NIB in HxC could be doable, feed in STREAM export NIB? Also read on a 'competitors' forum he was working on a converter for NIB files but to date, no converter!

[IFW]

It will be possible much easier with user defined formats - which is the focus of the forthcoming DTC releases (hence no new hard-coded formats have been added to DTC itself, as they'll just complicate the transition to user defined formats)

[IFW]

A stream file is the flux transitions recorded directly from the drive, without any kind of processing applied.
So depending on the features of the decoder the processing can get very complex.
With user defined formats the complexity (related to the applied signal processing and analysis) will be hidden, while the actual data decoding process (which is really the last step of the pipeline) will be user script driven.

[BarryB]

Again, counts me out as I won't be able to write scripts. So once the new dtc is released we'll see how many people start creating/sharing their own scripts and hopefully, making scripts on request and creating a nice library of 'off the shelf' formats

[IFW]

Count me in on the other hand
Manually programming each and every format is extremely time consuming, writing a script instead (like you do in CTA, just simpler) is quite a huge difference!
But of course the idea is everyone (who wants to/can) could do a quick script adding a new format for everyone - like you said.

[IFW]

btw: regarding the data.
When dumping such a disk make sure to switch the drive to low density mode (if the drive supports it...), otherwise the AGC will totally mess up the flux transitions, and the correct data won't be recoverable.
There are loads of forum threads about that, ie -dd0 vs -dd1 mode and I think it's explained in the recent manuals as well.

[IFW]

This is also true for pretty much any 8-bit platform using user programmable formats on 5.25 disks, e.g. C64, A2.

[BarryB]

How much prior 'knowledge' do you require before you can attempt to write your own scripts though and how much info will there be in the documentation to explain this?

[IFW]

Prior knowledge: understanding the disk format. This is usually done by reverse-engineering the loader of the game. When I worked a lot on Amiga formats though I could guess changes to known formats just by looking at the data... but that was a long while ago
Documentation: initially, sample format scripts, commented.