TIP: Click on subject to list as thread! ANSI
echo: apple
to: comp.sys.apple2
from: Michael J. Mahon
date: 2009-02-07 01:24:38
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™.