Re: [hatari-devel] IPF disk swap question

[Bob Carpenter <hatari@xxxxxxxxxx>]

Nicolas,

Your patch works great. It fixed the problems in both IPF files. I have one unrelated question. Recently, I discovered that Lethal Xcess supports the blitter if you use Hatari in STE mode. However, if I try to do this, the screen flickers horribly and has all sorts of artifacts. I tried using a UK version of TOS 1.62, but the same problem occurs. I checked the compatibility list and it looks like it should work.

Is there something I am doing wrong, is this a regression, or did I misunderstand that Hatari supported the blitter in that game? Thanks. I look forward to trying out STX support when it arrives.


Bob C

On Mar 3, 2014, at 5:41 PM, Nicolas Pomarède <npomarede@xxxxxxxxxxxx> wrote:

> Le 02/03/2014 23:00, Nicolas Pomarède a écrit :
>> Le 02/03/2014 05:38, Bob Carpenter a écrit :
>>> Nicolas,
>>> 
>>> You may have seen on Atari-Forum where DrCoolZic has started posting
>>> IPF files for testing. I have had problems using the IPF files if it
>>> requires swapping disks. Both Awesome and Back to the Future III
>>> require disk swapping, but Hatari will not recognize the new disk when
>>> I insert it. I have disabled drive B and shut off the auto insert for
>>> drive B as well. I went back to TOS 1.0 and 512K of RAM. Once, Awesome
>>> did recognize the disk swap completely. However, the last time I
>>> played it, I was able to get one disk to be recognized (disk 1 to disk
>>> 3), but Awesome would not recognize disk 2 when I inserted it. It did
>>> recognize it one other time.
>>> 
>>> With Back to the Future, simply select the Practice Duck Shooting
>>> option which asks for disk 2. When I insert disk 2 into drive A, the
>>> game does not recognize it and asks me for disk 2 again. There is
>>> nothing I can do to get disk 2 accepted by the game.
>>> 
>>> As I look at the IPF files I have tested, only Mean 18 had more than 1
>>> disk. It worked fine though.
>>> 
>> 
>> Hello
>> 
>> thanks for reporting, I can reproduce the problem with Back to the
>> future, so I should be able to fix this (note that if you save a memory
>> snapshot when disk 2 is not detected and then restore that memory image,
>> then disk 2 is detected :) )
>> 
> 
> There was a missing call to invalidate current track/side when disk was inserted  / ejected. It should work with the following patch (I will commit it later to main repo with the rest of the stx support), but you can try it now :
> 
> diff -r ba19661fee92 src/floppy_ipf.c
> --- a/src/floppy_ipf.c  Wed Feb 26 00:17:39 2014 +0100
> +++ b/src/floppy_ipf.c  Tue Mar 04 00:36:11 2014 +0100
> @@ -328,6 +328,8 @@
> 
>        IPF_State.Drive[ Drive ].diskattr |= ( CAPSDRIVE_DA_IN | CAPSDRIVE_DA_WP );     /* Disk inserted and write protected */
> 
> +       CAPSFdcInvalidateTrack ( &IPF_State.Fdc , Drive );                 /* Invalidate previous buffered track data for drive, if any */
> +
>        return true;
> #endif
> }
> @@ -346,6 +348,8 @@
> #else
>        fprintf ( stderr , "IPF : IPF_Eject drive=%d imageid=%d\n" , Drive , IPF_State.CapsImage[ Drive ] );
> 
> +       CAPSFdcInvalidateTrack ( &IPF_State.Fdc , Drive );                 /* Invalidate previous buffered track data for drive, if any */
> +
>        if ( CAPSUnlockImage ( IPF_State.CapsImage[ Drive ] ) < 0 )
>        {
>                fprintf ( stderr , "IPF : error CAPSUnlockImage\n" );
> 
> 
> 
> 2 calls to CAPSFdcInvalidateTrack are needed in IPF_Insert / IPF_Eject. With this, back to the future correctly detects disk 2.
> 
> 
> Nicolas
> 
> 
> 
> 
>