Re: [hatari-devel] Emulation of the TT second MFP

[Nicolas Pomarède <npomarede@xxxxxxxxxxxx>]

Le 12/03/2021 à 17:24, Markus Fröschle a écrit :
> Am Freitag, den 12.03.2021, 14:27 +0100 schrieb Nicolas Pomarède:
> > Le 12/03/2021 à 10:29, Markus Fröschle a écrit :
> > What kind of alarm does the ASV Unix code use ? Alarm after 'n' seconds
> > or alarm on a specific date/time ? (maybe the required precision is less
> > than 1 sec, I haven't check the nvram datasheet)
>
> Neither. Hopefully I didn't make a mistake using Hatari's debugger, but 
> this is what I found out so far:
>
> *** skipping NVRAM reads done by TOS ***
>
> Now we are in the ASV boot loader
>
> Returning to emulation...
>    $ffff8963 = $29
> 1. CPU breakpoint condition(s) matched 29 times.
> ( $ffff8963 ) . b ! ( $ffff8963 ) . b
>
> CPU=$4fb74, VBL=2384, FrameCycles=47704, HBL=53, LineCycles=216, DSP=N/A
> $0004fb74 : 13fc 000b ffff 8961                move.b    #$b,$ffff8961
>  > m b $ffff8961
> FFFF8961: 0a 00 29 00 00 00 00 00 00 00 00 00 00 00 00 00   ..).............
>
> Returning to emulation...
>    $ffff8963 = $6
> 1. CPU breakpoint condition(s) matched 30 times.
> ( $ffff8963 ) . b ! ( $ffff8963 ) . b
>
> CPU=$4fb82, VBL=2384, FrameCycles=47736, HBL=53, LineCycles=248, DSP=N/A
> $0004fb82 : 0000 0040                          ori.b     #$40,d0
>  > m b $ffff8961
> FFFF8961: 0b 00 06 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
>
> Returning to emulation...
> WARN : Write to unimplemented RTC/NVRAM interrupt enable bits 0x40
>    $ffff8963 = $46
> 1. CPU breakpoint condition(s) matched 31 times.
> ( $ffff8963 ) . b ! ( $ffff8963 ) . b
>
> CPU=$4fb94, VBL=2384, FrameCycles=47784, HBL=53, LineCycles=296, DSP=N/A
> $0004fb94 : 4cee 003c fff0                     movem.l   $fff0(a6),d2-d5
>  > m b $ffff8961
> FFFF8961: 0b 00 46 00 00 00 00 00 00 00 00 00 00 00 00 00   ..F.............
>
> According to my MC146818A documentation, the following appears to be 
> done by ASV:
>
> RTC register $a = $29  # = %00101001
> RTC register $b = $06  # = %00000110
> RTC register $b = $46  # = %01000110
>
> Register $a: $29: clock = 32.768 kHz clock rate, rate select 1001 <> 8 x 
> 1 + 4 x 0 + 2 x 0 + 1 = 9, resulting in a frequency of 32768 Hz / 2^8 = 
> 128 Hz.
> Register $b: PIE (periodic interrupt enable) on, BCD off, 24hrs on, 
> Daylight saving off
>
> The periodic (free running) interrupt is supposed to trigger with 128 Hz.
>
> The VBL doesn't seem to be granular enough, I reckon.


I don't know it the program just set PIE to set a watchdog to trigger on 
a regular basis (and choosing 128 Hz to not take too much cpu time too 
often) or if it really matters to have an exact 128 Hz freq.

For a watchdog, I would say the freq might not be really important as 
long as the watchdog is waken up on a regular basis.

So, a first proof of concept could be to trigger the RTC interrupt on 50 
Hz, even if the program wrote 128 Hz in reg A (taking into account that 
some video resolution might use a different rate than 50 Hz)

If this allows the program to work, then a better approach could be to 
call the RTC's update function from the HBL handler. This gives approx a 
15 kHz base freq (for st low/med resolution), which should be enough to 
simulate a 128 Hz signal (by calling the RTC's function every 122 HBL 
for example)

Using VBL or HBL interrupt handler under emulation might seem a little 
complicated, but it would really allow to not slow down emulation too 
much (instead of adding a dedicated interrupt handler for RTC)

Nicolas