Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watnot!ccplumb From: ccplumb@watnot.UUCP Newsgroups: comp.sys.amiga Subject: Re: DME1.20 Message-ID: <12756@watnot.UUCP> Date: Tue, 31-Mar-87 17:41:16 EST Article-I.D.: watnot.12756 Posted: Tue Mar 31 17:41:16 1987 Date-Received: Wed, 1-Apr-87 06:49:29 EST References: <8703301654.AA13157@cory.Berkeley.EDU> Reply-To: ccplumb@watnot.UUCP (Colin Plumb) Organization: U. of Waterloo, Ontario Lines: 51 Perhaps I'm dim, but could you be more explicit about the bug in DME? Does DME eat cycles only while you hold down both buttons, or does holding down both buttons trigger something that eats cycles from then on? Since you say this isn't really a bug, the first (not very serious) case sounds likely, but I'd like to be sure. ALSO: A question. In the May (they're kinda ahead of themselves) issue of The Transactor (Vol. 7, Issue 06) there's an article about the Amiga disk structure, and I'm wondering about something mentioned in it. (Aside: There's lots of good stuff in the article. I can post a summary if there's demand. Also, a plug: all of The Transactor is really good. It covers all Commodore computers, not just the Amiga, but the S/N ratio is so incredibly high it's one of the best *Amiga* magazines around.) Okay, my question: I'm told Amiga sector headers are 32 bytes, 16 of which are `operating system recovery info,' currently unused. The first 4 bytes are 00 00 A1 A1 (A1 is a `symc byte' in MFM). These are then MFM encoded to produce the bit stream: ?0101010 10101010 10101010 10101010 01010010 10101001 01010010 10101001 where the ? depends on the bit before it. However, this bit pattern could also easily show up in a data block. (Owing to the encoding scheme, it would take something like 00 00 00 00 A0 02 A0 02 to produce it, but...) Since the Amiga doesn't have inter-sector gaps (that's how it gets the high density), and it doesn't sync up to the gap of nulls that appears on the disk (also from the article), how does it find the start of a sector? MFM encoding allows no adjacent 1's and no runs of more than 3 0's, so if the 4 bytes I mentioned weren't encoded, they'd provide a unique bit pattern, but that would make headers 240 (encoded) bits long instead of 256 bits, so that seems unlikely. Can someone enlighten me? aTdHvAaNnKcSe. For advanced students: the article's author is still wondering about one thing: The RKM says that there is a 16-byte section of descriptive data for each sector. It also says that the drive does not interpret these sections unless the programmer instructs it to do so. This doesn't sound like the `operating system recovery info' area (which it otherwise sounds a lot like) because the drive interprets that when it loads it in. So is there an undiscovered section of data in a sector or not? -- -Colin Plumb (watmath!watnot!ccplumb) Silly quote: It's steel wool and a yard wide.