Re: Disk Description Language Proposal??

[mmphosis <mmphosis@macgui.com>]

here are a bunch of thoughts and questions...

* I remember reading discussions about this in past newsgroup postings.

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

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

* format lock-in:
	- I can give reasons why xml and zip are bad.
	- but, I can also give lots more reasons why they are good.

* compression can be problematic
	- see Blurry's comment

* 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)
		-- not something I recommend, but a full-blown emulator should be able to
		do this
	- 40 tracks (I think some non-Apple drives could format 40 tracks)

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

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

* 18 sector disks.  I was just reading up on this copy protection scheme. 
But, I imagine that the DDL format supports this.  Or, more than 18 sectors?
Or no sectors, just one big track of data?

* 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?

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

* 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.
	- being able to open a binary file from the host system which opens the
	emulator, loads the binary and runs it.
             -- and how do you determine what address the binary file starts
             at?
	- Applesoft programs stored as a text file on the host system, currently I
	use IN# and PR# to send listings back and forth
	- lock/unlock might actually do that to the file on the host system!

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