dillon@CORY.BERKELEY.EDU.UUCP (03/30/87)
I post it, and I find a bug already!. Well, not really a bug. When you use the right mouse button to iconify the window, make sure you are *NOT* holding the left mouse button down. If you are, DME takes a lot of cpu continuously even though it isn't doing anything. -Matt
ccplumb@watnot.UUCP (04/01/87)
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.
dillon@CORY.BERKELEY.EDU.UUCP (04/04/87)
>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. Fixed in V1.22, which I put on the net a couple of days ago. >ALSO: A question. (The question was on the Amiga's DISK format) The SYNC byte refers to a RAW MFM bit sequence which is illegal as far as sticking to the MFM conventions. Thus, it never occurs in the data portion of the sector. As far as I know, nobody currently uses the 16 byte label area for each sector (i.e. a sector actually has 528 bytes of OS usable data). This corrosponds to about 28Kbytes on a disk. -Matt