[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Disk Description Language Proposal??



Hi there!

Answers in quoted-style:

On Thursday, August 9, 2012 9:06:01 PM UTC-3, mmphosis wrote:
> * I remember reading discussions about this in past newsgroup postings.

I wasn't able to find anything on csa2 :-(.

> * isn't there already a format that would meet your requirements?
> 	- ie. fdi?  http://en.wikipedia.org/wiki/Formatted_Disk_Image

FDI yes. In fact, I did implement it in OpenEmulator. But I am not very satisfied with it... my explanation is on the openemulator forums.

> * the politics of format wars:
> 	- xml vs json vs text vs ...
> 	- zip vs gz vs bzip vs ...

Compression is gone now, so it's just the XML.
I'd say XML its pretty standard, not tied up to any language like Java, pretty neutral, easy to read by humans and decode by machines. There's libxml2 and expat.

> * how do you define more than 35 tracks on an "Apple" 5.25" disk:
> 	- 36 tracks (I remember formatting a dos 3.3 disk to use a 36th track)
> 	- 40 tracks (I think some non-Apple drives could format 40 tracks)

Easy. Use a <track index="39"> tag :-).

> * how do you define "overlapping" tracks, and partial tracks? fractional
> stepping?  Spiral tracks?  yuck.

* The areas of a track that are empty are full of zeroes (no magnetic inversions).
* You can specify half and quarter-tracks like <track index="11.75">.
* Fractional stepping with PWM (Michael J Mahon suggested that) is also possible. Use <track index="18.475">
* It seems spiral tracks protections used a quarter of every quarter-track, so that's not hard to encode in DDL.

> * how about defining what I call a "scratch" area on the disk?  Where the
> copy protection scheme used a part of the disk where writing would fail, but
> reading that area might have some predictable data, or maybe reading would
> always fail.

* You must enlighten me with what you mean by "scratch area". Do you mean parts of a disk that were ruined on purpose, but returned recognizable values? That is indeed interesting, and we should add it. Would that be like write protecting parts of a track? If that is the case, that is easy to do!
* DDL does specify weak bits, individual bits that are poorly magnetized and return a random 0 or 1 when read.

> * 18 sector disks.  I was just reading up on this copy protection scheme. 

DDL stores the actual bitstream read by the Disk II controller, not sectors. It's an extension of NIB.

> * maybe this is more about the emulator, but what about varying disk speeds?
> An emulator where you can adjust the speed just like when you open up a disk
> ][ drive and turn that little dial that changes the speed?  What about
> "drive speed fluctuations" as pointed out by mjm?

This was just added to DDL!

> * your emulator should still fully support (read and write) at least the
> popular disk formats like .dsk

It does. My point of introducing another format (and I don't like doing it) is:

* preserving any kind of weird modification you do to a disk image in the emulator
* being able to read copy protected disks as-is in the emulator
* do this in a way compatible with the GPL license

> * you could also support virtual file systems via faking dos 3.3, prodos,
> and maybe others into reading and writing to files in a folder on the
> filesystem of the computer.

If you feel like it, add a feature request to code.google.com/p/openemulator :-)

> * Antoine Vignau wrote: "That is an interesting spec to read. I wonder
> whether it answers to all kinds of protection schemes on the Apple II."
> 	- Well put Antoine, I think that this is what the format should be able to
> 	achieve.

Well, that's why I posted this "request for comments" on csa2 :-)

With the best wishes,

Marc.-