In article <1gh55xq.ad72g01oor7z2N%dempson@actrix.gen.nz>, David Empson wrote: > "Bill Garber" wrote: > >> Thank you David. I really must take some time >> and read through all these books. After all, >> I did buy them to learn from. What programs >> can I use to convert a 13 sector disk image to >> a real disk? > > No idea. I haven't done anything signficant with emulators. I only use > the real thing. :) > >> From what you wrote above the 16 sector controller should be >> able to still write one? > > Yes. The 16-sector controller (and the 13-sector one) can write > anything, even disk bytes which can't be read back by the same > controller: any 8-bit data pattern is possible, but if the written byte > doesn't follow the rules, it won't read back reliably (or at all). You > can even write mistimed bytes, by waiting longer than 32 microseconds > between writes. (I'm not sure what would happen if you waited less than > 32 microseconds - probably get a partial byte followed by the next > byte.) Most likely, yes. What happens when writing to disk is this: once writing is turned on, bits are written all the time. They're taken from an 8-bit shift register, and as the bits are used up, zero bits are poured in from the other side of the shift register, unless the 6502 explicitly writes a new value into the shift register. So to write bytes in a controlled way to the disk, the shift register must receive new contents from the 6502 every 32 clock cycles. If the shift resiter is updated too quickly, parts of the previous byte won't be written to the disk but will be lost. And if the shift resiter is updated too slowly, extra zero bits will be written to the disk. And that's the way the FF self-sync bytes/nibbles are written to the disk: the 6502 fills the shift register with an $FF every 40 clock cycles instead of every 32 clock cycles -- this will produce those two extra '0' bits after the eight '1' bits. Actually, any byte on the disk can be made a "self-sync" byte in this way -- those two extre '0' bits at the end of the byte will be invisible to the normal disk read routines. The book "Bag of tricks" had an accompanying diskette which was "copy protected" in this way: some bytes in the address field had those extra '0' bits at the end, and the utility on that disk checked for the presence of those extra '0' bits (this is done by, instead of the normal looping until the hi bit read is '1', read the next byte a suitable fixed number of clock cycles after reading the previous byte, and then check that the hi bit is '0'). Sure, the disk could boe copied with any normal DOS 3.3 disk copy utility, or with Locksmith, Nibbles Away, etc, but the copy would not work since that check would fail on the copy. So you can write anything to the Apple II disk -- but you won't be able to (reliably) read anything back from it. > Copy protection techniques have been known to pull these sort of tricks, > and use other tricks such as timing measurement to determine whether the > disk has been written with the correct special rules. -- ---------------------------------------------------------------- Paul Schlyter, Grev Turegatan 40, SE-114 38 Stockholm, SWEDEN e-mail: pausch at stockholm dot bostream dot se WWW: http://www.stjarnhimlen.se/ http://home.tiscali.se/pausch/ Dan Foster wrote: >The *DEFINITIVE* work that explains how DOS works, including its RWTS >(read/write track/sector) routine and the tight timing loop involved was >in, I think, an article that Dr. Sandy Mossberg wrote for Nibble in the >'80s? Although Mossberg does a nice job of disassembling DOS and explaining its logic, the definitive work on the low-level encoding and the state machine that decodes it is undoubtedly Sather's "Understanding the Apple II" and "Understanding the Apple //e". There were earlier reverse-engineered explanations of the state machine, but Sather puts it all together, providing a clear and thorough explanation of both the earlier and the later controllers. >Well, one chapter is devoted to DOS 3.3. I'm going to presume that Mr. >Irwin will forgive me for significant quotations from his excellent book >since it's been 20 years (and if you can locate a copy -- do so!). Unfortunately, Mr. Irwin also misunderstands both the actual magnetic encoding on the disk and the way that DOS converts data bytes to "disk nibbles" for writing. Making the same error as the early editions of "Beneath Apple DOS", Irwin says that all bits are written to disk interleaved with clock pulses. This is false. Apple's (Wozniak's) GCR scheme was designed precisely to _avoid_ having to use clock bits, thereby increasing the data capacity of a track by 50%. Also, the method he describes for converting a stream of 8-bit data bytes to 6-bit chunks for encoding is incorrect. DOS 3.3 actually takes the upper 2 bits from three data bytes to create another 6-bit chunk, rather than taking a "moving" 6 bits from the concatenated stream. It is unfortunate that this many years after the fact, so many misconceptions about the Apple disk technology still persist. I have long regarded the Disk ][ controller as Wozniak's engineering masterpiece, surpassing even the Apple ][+ in the creativity and simplicity of its design. -michael Check out parallel computing for 8-bit Apples on my Home page: http://members.aol.com/MJMahon/