[Coco] [COCO] Proposed HDBDOS Patch
David Ladd
davidwladd at gmail.com
Mon Jan 26 22:10:59 EST 2015
On 1/26/2015 6:56 PM, William Astle wrote:
> There is one problem when doing this:
>
> After the first DSKINI pass, DSKCON's notion of which track the drive
> is on is wrong. The drive will be at 34 but DSKCON will think it's at
> 0 (from the reset to 0 at the start of formatting). Thus, with the
> modification below, the first read in this case will bang the head.
>
> The saved track value also has to be set TRKMAX-1 which isn't quite as
> simple. This is the part that doesn't fit in the existing code space.
>
> For those confused: I'm not referring to DCTRK which is the requested
> track. I'm referring to the drive track table at DR0TRK.
So basically then my original idea of using the track 0
reset/calibration request would be the best option in this case at least?
>
> On 15-01-26 05:01 PM, Darren A wrote:
>> On Mon, Jan 26, 2015 at 4:36 PM, David Ladd <davidwladd at gmail.com>
>> wrote:
>>
>>> On Mon, Jan 26, 2015 at 5:20 PM, Darren A <mechacoco at gmail.com> wrote:
>>>>
>>>> A better way to do this might be to have the verify loop work its way
>>>> backwards through tracks so it finishes on track 0. Looking at the
>>>> code
>>> in
>>>> Disk Basic Unravelled, I think the loop could be modified to do this
>>>> without requiring any additional code space.
>>>>
>>>
>>> Darren, thanks for the info. I will look at that option and see
>>> how best
>>> to work that in.
>>>
>>>
>> I figured the simplest approach would be:
>>
>> 1. Change the CLRA preceding LD66F to LDA #TRKMAX-1
>>
>> 2. Change:
>> INCA
>> CMPA #TRKMAX
>> BLO LD66F
>> to:
>> NOP
>> DECA
>> BPL LD66F
>>
>>
>> This will change the actual location of labels LD66F and LD672 to
>> $D670 and
>> $D673.
>>
>> - Darren
>>
>
>
More information about the Coco
mailing list