| TIP: Click on subject to list as thread! | ANSI |
| echo: | |
|---|---|
| to: | |
| from: | |
| date: | |
| subject: | Re: Poor-man`s Catweasel |
mwillegal wrote: > HI Michael, > > I'm a bit concerned about immediately starting the data after the > header because it appears that the RWTS code takes over 100 > microseconds between reading the address header, before starting a > sector data read or write. That would equal to about 3 character > times on the disk. This may not leave enough time to get the "IWM" > back in sync for the data read, since a large part of the 5 byte data > sync leader would have already passed by, if there was no gap. Keep > in mind that the AVR I'm using is approximately 20 times faster than > the Apple ][, so I could essentially remove the entire gap, if I > pleased. I'm a bit puzzled how the normal read function can read a > raw formatted sector reliably, given the fact that the format > function, greatly compresses this gap, compared to the write and read > sector functions. You must re-write the sync nibbles on each data write. The sync nibbles must be completely synchronous with the following data to function, so any pre-existing sync nibbles must be written over by the write sector function. > I haven't had time to figure out the clobbered sector 1 problem, but > since there is no difference in gaps between various sectors (except > last to first), I'm thinking that there is a just an ordinary logic > bug at work here. If you are not currently writing sync nibbles before data, that could explain many errors. > Thanks and regards, > Mike Willegal > > On Feb 6, 4:30 pm, "Michael J. Mahon" wrote: >> mwillegal wrote: >>> I'm pretty far along on a "smart" version for DIsk ][ drives, >>> formatted in DOS 3.3 format. >>> http://www.willegal.net/appleii/appleii-disk-int.htm. >>> Note that properly formatting a disk and/or writing to individual >>> sectors on a disk demands knowing and decoding the disk format on the >>> fly. >> Mike, on your web page you wrote: >> >> >There is one final thing I need to do before actually testing out >> >this write sector function. That is to study the precise spacing >> >between the end of the sector header and the sector data in Apple's >> >RWTS. I'll adjust my code to match as closely as possible. >> >> and: >> >> >[I] have found that 2nd sector on a track can't be found after writing >> >sector 0 data. There is some special handling of sector zero in Apple's >> >RWTS format function. I'm in process of figuring out how that affects >> >the sector 0 to sector 1 spacing. >> >> When writing a sector, writing of sync nibbles should begin as soon as >> the epilog of the address is complete. (In fact, the second epilog >> nibble is clobbered because of too little delay during formatting.) >> >> So allow enough time to read the clobbered nibble, then start writing >> several (6-8?) sync nibbles before the data header. >> >> The object is to keep the data as close as possible to the address >> field so that it doesn't overwrite too many sync nibbles leading into >> the next address field--which is what I think is clobbering the next >> sector after a write to sector 0. -michael ******** Note new website URL ******** NadaNet and AppleCrate II for Apple II parallel computing! Home page: http://home.comcast.net/~mjmahon/ "The wastebasket is our most important design tool--and it's seriously underused." --- SBBSecho 2.12-Win32* Origin: Derby City Gateway (1:2320/0) SEEN-BY: 10/1 3 34/999 120/228 123/500 128/2 140/1 222/2 226/0 236/150 249/303 SEEN-BY: 250/306 261/20 38 100 1404 1406 1410 1418 266/1413 280/1027 320/119 SEEN-BY: 393/11 396/45 633/260 267 712/848 800/432 801/161 189 2222/700 SEEN-BY: 2320/100 105 200 2905/0 @PATH: 2320/0 100 261/38 633/260 267 |
|
| SOURCE: echomail via fidonet.ozzmosis.com | |
Email questions or comments to sysop@ipingthereforeiam.com
All parts of this website painstakingly hand-crafted in the U.S.A.!
IPTIA BBS/MUD/Terminal/Game Server List, © 2025 IPTIA Consulting™.