Re: [hatari-devel] EKO system regression

[Thomas Huth <th.huth@xxxxxxxxx>]

Am Sun, 6 Oct 2019 00:51:17 +0200
schrieb Laurent <laurent.sallafranque@xxxxxxx>:

> Hi all,
> 
> 
> I've noticed a regression with EKO system with the last source code.
> 
> I've bissected it and here is the result.
> 
> laurent@laurentux:~/Atari/hatari$ git bisect good
> b65a1bf1c9c1baf1efd1ba6b901aa3445325805f is the first bad commit
> commit b65a1bf1c9c1baf1efd1ba6b901aa3445325805f
> Author: Thomas Huth <huth@xxxxxxxxxxxxx>
> Date:   Sun Aug 25 12:16:40 2019 +0200
> 
>      Handle GEMDOS HD emulation without code in the cartridge

Oh well, looks like this demo changes the GEMDOS vector to its own
handler:

> m 0x84
00000084: 00 02 01 9a 00 e3 46 a8 00 e0 0f b6 00 e0 0f b6   ......F.........
[...]
> d 0x0002019a
$0002019a : 0c6f 0000 0008                     cmpi.w    #0,8(sp)
$000201a0 : 6720                               beq.s     $201c2
$000201a2 : 0c6f 0031 0008                     cmpi.w    #$31,8(sp)
$000201a8 : 6718                               beq.s     $201c2
$000201aa : 0c6f 004c 0008                     cmpi.w    #$4c,8(sp)
$000201b0 : 6710                               beq.s     $201c2
$000201b2 : 0c6f 0020 0008                     cmpi.w    #$20,8(sp)
$000201b8 : 6718                               beq.s     $201d2
$000201ba : 4ef0 01f1 0002 01d4                jmp       ([$201d4])
$000201c2 : 46f9 0002 01d8                     move      $201d8,sr
$000201c8 : 2e79 0002 01da                     movea.l   $201da,sp
$000201ce : 6000 fbde                          bra       $1fdae
$000201d2 : 4e73                               rte       

That does not work with the current approach for the GEMDOS HD
emulation anymore. The GEMDOS HD functions are now handled first,
before the trap chaining on the 68k side. So Hatari sees a Pterm0 here
and closes the file - while this custom trap handler code rather
"ignores" the Pterm0 instead.

I have to think about that for a while ... maybe it's better to do the
"trap chaining" again first, and then call the GEMDOS HD code at the
end via an illegal opcode, like we did before. But that likely means
that we need some cartridge code again, which we rather wanted to get
rid off... Another option would be to declare that this demo now only
works with hard disk images and is incompatible with the GEMDOS HD
emulation ... GEMDOS HD emulation will never be perfect, either
some programs fail 'cause they do not work with a cartridge, or
they fail since they mess around with the GEMDOS vector, so we
will always have a list of programs that do not work with
GEMDOS HD. Opinions?

 Thomas