[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