Re: [hatari-devel] Audio Sculpture and disk access

[Nicolas Pomarède <npomarede@xxxxxxxxxxxx>]

Le 19/02/2015 00:17, Troed Sångberg a écrit :
> Hah - there we go! Thanks! :) Entering something as volume name and then
> retrying actually made it work here as well just now. Ok, then I think
> we're seeing the same thing finally. It's not like that on the real
> hardware. I just made several tests in a row and what happens is that
> first time I press "Load Module" the cursor changes to a clock, it
> accesses the floppy and changed to "Volume name". No disk list. Next
> time I press Load module it changes back to "Path A:\*.MOD" and the list
> is displayed.
>
> I also looked through the source for AS and there are plenty of file
> access TRAPs. That _might_ be different between internal test versions
> and final sent to production (it would take quite some time to
> understand the code at that level - I did no code on AS) though so I
> can't be sure. Disassembling the Replicants crack might be a lot faster ..
>
> I'm wondering if this might be a disk change thing. Volume name is the
> name of the disk and it seems to not understand that there's been a disk
> switch. Forcing volume name change might jog it.


Hi

I had a closer look to the disk accesses at the FDC level. Basically, 
the TOS loads the program, then the program check for protection by 
doing a read track, then the TOS gets control again when file selector 
is used.

Problem : the protection's check move the drive's head from track 0 to 
1, without restoring it after, so TOS is lost after that :(

This is after decrunching the program :

fdc type I restore spinup=on verify=off steprate=3 drive=0 tr=0x0 
head_track=0xe VBL=5428 video_cyc=61984 32@121 pc=e017e2
fdc type I seek dest_track=0x0 spinup=on verify=off steprate=3 drive=0 
tr=0x0 head_track=0x0 VBL=5482 video_cyc=140496 208@274 pc=e017e2
fdc type I restore spinup=on verify=off steprate=3 drive=1 tr=0x0 
head_track=0x0 VBL=5482 video_cyc=147472 16@288 pc=e017e2
fdc type I seek dest_track=0x0 spinup=on verify=off steprate=3 drive=1 
tr=0x0 head_track=0x0 VBL=5482 video_cyc=152088 24@297 pc=e017e2

fdc type I restore spinup=on verify=off steprate=6 drive=0 tr=0x0 
head_track=0x0 VBL=5752 video_cyc=30064 368@58 pc=3eacc
fdc type I seek dest_track=0x1 spinup=on verify=off steprate=3 drive=0 
tr=0x0 head_track=0x0 VBL=5752 video_cyc=30996 276@60 pc=3eaea
fdc type III read track spinup=on settle=off tr=0x1 head_track=0x1 
side=0 drive=0 addr=0x3ebbe VBL=5752 video_cyc=56088 280@109 pc=3eb22
fdc type III read track drive=0 track=1 side=0 VBL=5762 video_cyc=33288 
8@65 pc=3eb78
fdc type IV force int 0xd0 irq=0 index=0 VBL=5763 video_cyc=100 100@0 
pc=3eb32

We see some commands are made by tos (pc=e0xxxx), but the latest are 
made by AS (pc=3exxx).

After that, when file selector is opened, TOS try to seek on track 0. 
Here, I see a difference between tos 1.04 and 1.62.

With STE's 1.62, TOS will loop forever, trying to seek to 0 with verify 
bit=1 while already on track 0, expecting track0 bit in the status 
register to be set, which is not. This triggers an error and it will 
retry without success :

fdc type I seek dest_track=0x0 spinup=on verify=on steprate=3 drive=0 
tr=0x0 head_track=0x1 VBL=7534 video_cyc=14672 336@28 pc=e017e2
fdc type IV force int 0xd0 irq=0 index=0 VBL=7534 video_cyc=15764 404@30 
pc=e017ec
fdc type I seek dest_track=0x0 spinup=on verify=on steprate=3 drive=0 
tr=0x0 head_track=0x1 VBL=7534 video_cyc=22924 396@44 pc=e017e2
fdc type IV force int 0xd0 irq=0 index=0 VBL=7534 video_cyc=24016 464@46 
pc=e017ec
fdc type I restore spinup=on verify=off steprate=3 drive=0 tr=0x0 
head_track=0x1 VBL=7534 video_cyc=27536 400@53 pc=e017e2
fdc type IV force int 0xd0 irq=0 index=0 VBL=7534 video_cyc=28628 468@55 
pc=e017ec
fdc type I seek dest_track=0x0 spinup=on verify=on steprate=3 drive=0 
tr=0x0 head_track=0x0 VBL=7534 video_cyc=36168 328@70 pc=e017e2
fdc type IV force int 0xd0 irq=0 index=0 VBL=7534 video_cyc=37260 396@72 
pc=e017ec
fdc type I seek dest_track=0x0 spinup=on verify=off steprate=3 drive=0 
tr=0x0 head_track=0x0 VBL=7534 video_cyc=41940 468@81 pc=e017e2
fdc type IV force int 0xd0 irq=0 index=0 VBL=7534 video_cyc=43032 24@84 
pc=e017ec

On tos 1.04, tos will fail on the seek 0+verify (because head is 
physically on track 1), but after several attempts, tos will do some 
restore/seek without verify and will eventually go in a correct state, 
displaying the directory.

Possible explanation I could see : after protection check, when we 
eject/insert a module disk, the drive also physically move the head to 
track 0 ? This would be an effect of pushing the eject button on some 
model ?
I would need to check that on my STF, so far Hatari consider the head 
doesn't move in such case, but maybe the drive models used by Atari had 
such a behaviour ?


Additional question : from AS sources, do you see what conditions 
trigger a display of the "volume name" text appearing in the file 
selector ? Maybe it could also help understanding what fails in AS point 
of view.


Nicolas