TIP: Click on subject to list as thread! ANSI
echo: apple
to: comp.sys.apple2
from: mwillegal
date: 2009-02-08 18:57:26
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™.