Re: [hatari-devel] Possible 1.7 regression

[Nicolas Pomarède <npomarede@xxxxxxxxxxxx>]

On 08/09/2013 10:22, Troed Sångberg wrote:
> Hi,
>
> Since the demo I was working on has now been released -
> http://www.pouet.net/prod.php?which=61839 - I'll happily revisit this
> topic ;) During development Hatari v1.7 seldomly could execute the
> patched screens from the menu - but it seems to me to be completely
> random whether a given .ST image would work or not. Please read my old
> posts in this thread to get up to speed.
>
> Link to image that shows the problem (press either 1 or 2 in the menu):
> https://dl.dropboxusercontent.com/u/669647/hatari17issue.st
>
> The image works fine in Hatari 1.6.2 and on target ST and STE hardware.
>
> I haven't done further analysis from the previous posts to this list
> with regards to how the file content gets replaced with track data.
>
> regards,
> Troed

Hello

I was able to get the same crash as you had.

Using "hg bisect" (a really great feature of mercurial !) helped me to 
isolate the problematic changelog :

changeset:   4015:35c8f4ef893f
user:        Nicolas Pomarede
date:        Fri Sep 21 19:27:44 2012 +0200
summary:     When the RESET instruction is called, we must also reset 
the MFP and the FDC

This just added a call to FDC_Reset in the case of the CPU's RESET 
instruction, which on 1st sight seems quite unlikely to create such a crash.

Problem is that FDC_Reset is also resetting the physical position of the 
head for each emulated drive, so while TOS expects the head to be on a 
given position, it will now be at track 0, which explains why the buffer 
you got is in fact sector 2 of track 0 :(

From what I see in my traces, when you press 1 or 2, the reset 
instruction is called by your program ? Can you confirm you used 'reset' 
at some point ?
Then track is wrongly reset from 38 to 0, and ... booomm !!

Thanks for providing this case, it could have been hard to spot (well, 
fact is that as I'm also rewriting some fdc parts at the moment, so this 
head position problem would be solved, because I already planned to move 
it outside of the reset part, as resetting the FDC clearly doesn't 
affect the head ; it would just appear to be magically fixed in next 
Hatari version ; at least now we know the reason :) )

Fix will be committed to dev repo soon.


Nicolas