| TIP: Click on subject to list as thread! | ANSI |
| echo: | |
|---|---|
| to: | |
| from: | |
| date: | |
| subject: | Re: Poor-man`s Catweasel |
I solved the write issue - turns out the head positioning stepper motor apparently hadn't totally settled down in the originally alloted time. I extended the time while holding the last phase on, and it now writes cleanly, every time. I have been able to write every sector on a disk and then test it by duplicating it on a real Apple, without errors. Reads are also more reliable, with this change. Now onto the format function. Regards, Mike Willegal On Feb 7, 4:24=A0am, "Michael J. Mahon" wrote: > 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 =A0address header, before starting a > > sector data read or write. =A0That would equal to about 3 character > > times on the disk. =A0This 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. =A0Keep > > 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. =A0 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), =A0 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: > > >> =A0>There is one final thing I need to do before actually testing out > >> =A0>this write sector function. =A0That is to study the precise spacin= g > >> =A0>between the end of the sector header and the sector data in Apple'= s > >> =A0>RWTS. =A0I'll adjust my code to match as closely as possible. > > >> and: > > >> =A0>[I] have found that 2nd sector on a track can't be found after wri= ting > >> =A0>sector 0 data. There is some special handling of sector zero in Ap= ple's > >> =A0>RWTS format function. =A0 I'm in process of figuring out how that = affects > >> =A0>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. =A0(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: =A0http://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™.