Re: [hatari-devel] Trapping OS call accesses under MiNT

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

Hi,

On tiistai 16 lokakuu 2012, Vincent Rivière wrote:
> BTW, FreeMiNT access the drives using NEWFATFS by default (using XHDI
> block device interface), but it can also use TOSFS (direct access to ROM
> GEMDOS functions).

I was checking READMEs for different MiNT versions and
apparently TOSFS had disappeared already in v1.16.0 beta:
-----
FreeMiNT 1.16.0 doesn't use the underlying TOS for file system
access anymore. The kernel will only use it's own (V)FAT(32)
file system driver. The old TOSFS is removed, the NEWFATFS
directive in the MINT.CNF file will be ignored if present.
------

When grepping MiNT sources, there seems to be OLDTOSFS define
though, but it's disabled by default so apparently although
there might be some support still, it's not available with
MiNT binaries (and likely therefore to be bitrotten).


> I don't know of the latter currently works or not on Hatari.

Is there anywhere a build of 68k (non-Aranym) MiNT that
is built with OLDTOSFS enabled, so that one could test
whether it works at all with Hatari GEMDOS emulation?

--

Regarding OS call trapping, BIOS/XBIOS/AES/VDI calls Hatari catches
when their traps are called, but GEMDOS it catches by overwriting
the TOS GEMDOS vector (0x84) address with its own.

However, MiNT will overwrite all trap vectors (and much more) when
it starts up.  For more info, see init_intr() in init_intr.c in MiNT 
sources.

(While I don't think implementing just TOS subset of GEMDOS calls
under MINT, such as Hatari's GEMDOS emulation, would be completely safe,
this also disables GEMDOS tracing under MiNT which shouldn't cause
any problems for MiNT.)

One can catch the GEMDOS vector overwrite with:
	b (0x84) ! (0x84)

And restore it back to Hatari one after MiNT changes it:
---
> info gemdos 
Current GEMDOS handler: (0x84) = 0x4873c, emu one = 0xfa002a
Stored GEMDOS handler: (0xfa0024) = 0xfc9332
....
> w 0xfa0024 $00 $04 $87 $3c
> w     0x84 $00 $fa $00 $2a
---
This will set Hatari handler for GEMDOS again and tell Hatari
to call MiNT's new gemdos handler after that.

I don't know whether MiNT+Hatari will call the TOS stuff then
correctly though, but at least I was able to boot a MiNT setup
on HD image with this and see GEMDOS output tracing.

Because MiNT refers to things through u:/, you cannot boot
MiNT setup from Hatari GEMDOS driver, it needs to happen
from a disk image.  Opening GEMDOS emulation drive on u:
naturally fails also.


Hatari GEMDOS emulation stores current TOS basepage as
that's used in some operations for accessing file DTA info,
but ROM TOS and MiNT would seem to share same basepage address.


Additionally, although MiNT does call original TOS for some things,
it doesn't to that through traps, but by jumping directly:
----
; The functions enter_bios() and enter_gemdos() are called on entry
; to the kernel, and the function leave_kernel() is called on exit.
; These functions are responsible for setting stuff up so that MiNT
; can trap out to TOS directly, but programs can only trap to MiNT.
;
; NOTICE: trap #1 handler NO LONGER redirects calls to ROM. This is
; done by an indirect jump in trap_1_emu().
;
; we also call certain BIOS functions directly if these are known
; not to require saving/restoring of context
....
// NOTICE: MiNT *no longer ever* traps to ROM GEMDOS, because even
//         the TOSFS *jumps* (not traps) there.
....
syscall.spp.new:
        trap #1 handler no longer wraps to ROM. This makes TOSFS no 
        longer valid. Underlying functions not supported by MiNT are 
        still called via wrapper trap_1_emu(). Also similar wrappers 
        are done for BIOS and XBIOS (now commented out for future 
        usage). This also causes a (very small) reduction of GEMDOS 
        call overhead.

        To still be able to use old TOSFS XFS, one will have to 
        change TOS bindings so that they do jsr _tos_1_emu instead of 
        trap #1.
----

This means that while Hatari can catch BIOS/XBIOS/AES/VDI with
MiNT without trouble, that works only for user-space programs,
not for calls within kernel.

And same would apply to GEMDOS emulation if it's done with trap handler.

-> Even with TOSFS, it might be better to use a HD
   image for booting...


The MiNT TOS call implementation (with coldfire bits left out)
for GEMDOS looks like this:
----
/*
 * initialize all interrupt vectors and new trap routines
 * we also get here any TOS variables that we're going to change
 * (e.g. the pointer to the cookie jar) so that rest_intr can
 * restore them.
 */

void
init_intr (void)
{
....
        new_xbra_install (&old_dos, 0x84L, mint_dos);           /* trap #1, 
GEMDOS */
....
_trap_1_emu:
#ifdef M68000
        tst.w   (0x059e).w              // test longframe
        beq.s   TE_D
#endif
        move.w  (sp),-(sp)
        move.w  4(sp),2(sp)
        clr.w   4(sp)
TE_D:
        move.w  sr,-(sp)
TE_D_JMP_OLD:
#if !(defined(M68000) || defined(__mcoldfire__))
        jmp     ([_old_dos])
#else
        move.l  _old_dos.w(pc),-(sp)
        rts
#endif
----


According to tosfs.c, these are the GEMDOS functions used by TOSFS:
 * Fsetdta(dta)
 * Dfree(buf,d)
 * Dcreate(path)
 * Ddelete(path)
 * Fcreate(fn,mode)
 * Fopen(fn,mode)
 * Fclose(handle)
 * Fread(handle,cnt,buf)
 * Fwrite(handle,cnt,buf)
 * Fdelete(fn)
 * Fseek(where,handle,how)
 * Fattrib(fn,rwflag,attr)
 * Fsfirst(filespec,attr)
 * Fsnext()
 * Frename(zero,old,new)
 * Fdatime(timeptr,handle,rwflag)
 * Flock(handle,mode,start,length)


Because MiNT does additional things with files and has
many additional file system calls, trapping things at
MiNT GEMDOS trap level probably doesn't work properly
like it does with TOS.

If interception with MiNT would still be done at GEMDOS
level, it would need to be extended to cover all additional
file system related GEMDOS calls (mentioned in my previous
mail).


Whereas with TOSFS and MiNTs direct jumps to TOS code, either
Hatari would need to intercept these jumps, or in addition to
enabling OLDTOSFS in MiNT sources, its way of calling above
listed functions would probably need to be changed to be
through NatFEATs (or something similar).

The only difference between this and Aranym-like NatFEATs
file system implementation is the width of the FS API.
TOSFS on reduced NatFEATS FS would implement just
TOS FS API and could probably be done on Hatari side
with some additional gemdos call wrapper.

Pexec loader asm-code might also need some extra support
for this.


	- Eero