Re: [hatari-devel] Re: Boot time

[ Thread Index | Date Index | More lists.tuxfamily.org/hatari-devel Archives ]


On 09/06/2013 20:00, Eero Tamminen wrote:
Hi,

On sunnuntai 09 kesäkuu 2013, Nicolas Pomarède wrote:
IMHO it would be nicer if you would investigate why EmuTOS is still
slow although it gets error immediately... :-)

I don't know what EmuTos does. It's up to the program to decide what to
do when a read sector command reports "record not found" ; you can retry
1 time, 2 times, 10 times, ... Maybe Emutos retries too many times or
add some unnecessary pauses between retries.

According to "--trace fdc"...

First EmuTOS repeats this 16 times:
-------------
fdc reset dma VBL=85 video_cyc=126484 20@247 pc=fc53c6
fdc write 8606 ctrl=0x98 VBL=85 video_cyc=126500 36@247 pc=fc53cc
fdc reset dma VBL=85 video_cyc=126500 36@247 pc=fc53cc
fdc write 8604 data=0x1 VBL=85 video_cyc=126516 52@247 pc=fc53d0
fdc write 8604 dma sector count=0x1 VBL=85 video_cyc=126516 52@247 pc=fc53d0
fdc write 8606 ctrl=0x88 VBL=85 video_cyc=126532 68@247 pc=fc53d6
fdc write 8604 data=0x8 VBL=85 video_cyc=126548 84@247 pc=fc53dc
fdc write 8606 ctrl=0x80 VBL=90 video_cyc=97120 352@189 pc=fc5464
fdc write dma address ff860d val=0x08 address=0x1a508 VBL=90 video_cyc=97424
144@190 pc=fc5d6c
fdc write dma address ff860b val=0xa5 address=0x1a508 VBL=90 video_cyc=97464
184@190 pc=fc5d74
fdc write dma address ff8609 val=0x01 address=0x1a508 VBL=90 video_cyc=97484
204@190 pc=fc5d7c
fdc write 8606 ctrl=0x98 VBL=90 video_cyc=97536 256@190 pc=fc53c0
fdc write 8606 ctrl=0x198 VBL=90 video_cyc=97552 272@190 pc=fc53c6
-------------

This part inits the HDC (bit 3 of ff8606=1)


Then it repeats this 16 times:
----------
fdc reset dma VBL=165 video_cyc=132104 8@258 pc=fc602a
fdc write 8604 data=0x1 VBL=165 video_cyc=132120 24@258 pc=fc6030
fdc write 8604 dma sector count=0x1 VBL=165 video_cyc=132120 24@258
pc=fc6030
fdc write 8606 ctrl=0x80 VBL=165 video_cyc=132192 96@258 pc=fc5e26
fdc write 8604 data=0x80 VBL=165 video_cyc=132248 152@258 pc=fc5e36
fdc write 8604 command=0x80 VBL=165 video_cyc=132248 152@258 pc=fc5e36
fdc type II read sector sector=0x1 multi=off tr=0x0 head_track=0x0 side=0
drive=0 dmasector=1 addr=0x3460 VBL=165 video_cyc=132248 152@258 pc=fc5e36
fdc motor already on VBL=165 video_cyc=132248 152@258 pc=fc5e36
fdc read sector addr=0x3460 dev=0 sect=1 track=0 side=0 VBL=165
video_cyc=145072 176@283 pc=fc5da2
fdc read sector failed
fdc type II read sector=1 track=0 drive=0 RNF VBL=215 video_cyc=153748
148@300 pc=fc5daa
fdc complete command VBL=215 video_cyc=153748 148@300 pc=fc5daa
fdc write 8606 ctrl=0x90 VBL=215 video_cyc=153852 252@300 pc=fc6070
fdc write 8606 ctrl=0x80 VBL=215 video_cyc=153916 316@300 pc=fc5f52
fdc read 8604 ctrl status=0xd0 VBL=215 video_cyc=153968 368@300 pc=fc5f5c
fdc write 8606 ctrl=0x84 VBL=215 video_cyc=154156 44@301 pc=fc5e26
fdc write 8604 data=0x1 VBL=215 video_cyc=154212 100@301 pc=fc5e36
fdc write 8604 sector=0x1 VBL=215 video_cyc=154212 100@301 pc=fc5e36
fdc write dma address ff860d val=0x60 address=0x3460 VBL=215
video_cyc=154332 220@301 pc=fc5d6c
fdc write dma address ff860b val=0x34 address=0x3460 VBL=215
video_cyc=154372 260@301 pc=fc5d74
fdc write dma address ff8609 val=0x00 address=0x3460 VBL=215
video_cyc=154392 280@301 pc=fc5d7c
fdc write 8606 ctrl=0x90 VBL=215 video_cyc=154440 328@301 pc=fc601e
fdc write 8606 ctrl=0x190 VBL=215 video_cyc=154456 344@301 pc=fc6024
----------

program tries to read track 0 sector 1, but we can see the FDC returns RNF. If you look at the VBL value in the 1st read sector (here 165) and the one in the last read sector (not shown in this trace), you can see how many time was spent in this part.

Retrying 16 times for HDC/FDC seems overkill to me ; you can retry a few times for 4-5 seconds, but if it still doesn't work, let's continue instead of insisting. Highest probability is that there's no disk in drive ; if it's due to a HW failure, the user will certainly reset later because its disk doesn't work. So in both case, this looks like a waste of time to retry that much.


Normal TOS seems to do quite a bit of FDC operations too, but only
FDC resets done by normal TOS are 2 they do right at start:
----------
Building CPU table for configuration: 68000 (compatible mode)
fdc reset dma VBL=0 video_cyc=0 0@0 pc=0
fdc reset dma VBL=0 video_cyc=16 16@0 pc=e00034
fdc write 8606 ctrl=0x82 VBL=25 video_cyc=130968 408@255 pc=e03fea
fdc write 8604 data=0xff00 VBL=25 video_cyc=131772 188@257 pc=e0403c
...
----------

Does FDC reset take a long time?

No, it's nearly immediate (a few cycles in reality, but we don't emulate this as the RESET instruction itself already takes some cycles)

Nicolas




Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/