|Re: [hatari-devel] Possible 1.7 regression
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
On 08/09/2013 10:22, Troed Sångberg wrote:
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):
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.
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 :
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.