Re: [hatari-devel] Fforce strangeness

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

Hi,

Sorry for the late reply.

On 6/23/20 9:56 PM, Thorsten Otto wrote:
> While doing some tests with fVDI, i'm encountering some strange behaviour:
>
> Looks like every 2nd character that was intended to be redirected to the
> GEMINI console is lost. This happens on startup, and when switching between
> file windows and the console. Pressing return in the console almost fixes it,
> but there are still a few characters missing.

Does "--trace gemdos --log-level info" show anything interesting?


> By adding some printf, i see that Gemini does a few Fforce() on startup: > GEMDOS 0x46 Fforce(0, 65535) at PC 0x1C5732
> GEMDOS 0x46 Fforce(1, 65535) at PC 0x1C5732
> GEMDOS 0x46 Fforce(2, 65535) at PC 0x1C5732
> GEMDOS 0x46 Fforce(3, 65533) at PC 0x1C5732
>
> (This is actually Fforce(0, -1) etc)

What this is *supposed* to do?

Looking at TosHyp:
http://toshyp.atari.org/en/005009.html#Fforce
http://toshyp.atari.org/en/About_the_BIOS.html#Bconout

* Under TOS, -1 would be invalid file handle, so
  I guess above calls would all give EIHNDL errors
  (-37)

* Under MiNT, it would redirect all of above to
  console


> The code in GemDOS_Force() looks rather strange, why are the 2 handles swapped
> there?

Looking at commit 6782eaf1bf, I think it's remains
from the original commit that just identified
whether either handle is GEMDOS HD one, so that it
could tell that forcing them isn't supported.

I probably just missed that when adding the real
Fforce implementation in:
https://git.tuxfamily.org/hatari/hatari.git/commit/?id=8d35d0913de100b9d9840d5f35165604b925c077


> Fforce(2, -1) is perfectly valid, but Fforce(-1, 2) is not.

I think both would be valid under MiNT/Magic, and
invalid under normal TOS?  (GEMDOS HD is TOS-only)


As I don't have any good test-cases for Force behavior, could you come 
up with a patch that fixes the behavior for you?


> Oh, and don't ask me why that happens only with fVDI, i have no idea :( It
> works with TOS or EmuTOS, but fVDI does not hook any output vectors yet.

One difference fVDI has to TOS, is that it's
a resident program.

There are some things nowadays in GEMDOS HD
emulation which rely on identifying programs
by their basepage, such as file force()ing.

I'm not sure what's supposed to happen basepage
on Ptermres().  According to compedium, at least
"Any files opened by the process are closed",
which I assume to concern also fforced ones.

(Hatari closes all files, including forced ones.)


> I'm booting from an emulated GEMDOS drive c:


	- Eero