Re: [hatari-devel] Adding Aranym features for Hatari?

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

Hi,

On maanantai 15 lokakuu 2012, Thomas Huth wrote:
> schrieb Eero Tamminen <oak@xxxxxxxxxxxxxx>:
> > On maanantai 15 lokakuu 2012, Thomas Huth wrote:
> > > schrieb Eero Tamminen <oak@xxxxxxxxxxxxxx>:
> > > > I might try looking into implementing the basic NatFeats functions
> > > > (name, version, stderr, shutdown) for Hatari.
> > > > 
> > > > Thomas, what do you think?
....
> > I wasn't thinking of having it enabled by default, but as a feature
> > which one can enable from command line with a "--natfeats" option.
> > And one of course shouldn't enable it for anything else than clean
> > applications.
> 
> Ok, as long as it can be disabled, I'm fine with that.

Great! :-)


> > In the long run, I would also consider implementing stuff needed
> > for natfeats hostfs so that one can use MiNT natfeats driver for that
> > on Hatari, to make MiNT work also with something else than disk images
> > which are a real pain to deal with...
> 
> You could also write a MiNT XFS that uses the GEMDOS-HD interface of
> Hatari ;-)

Right, if it were Hatari specific, it could directly use the illegal
opcode for Hatari's GEMDOS HD emulation...

One problem with that could be implementation of MiNT specific GEMDOS
calls[1], there are quite a lot of them, but maybe at least at start,
those could just return an error.

[1] Fxattr(), Fsymlink(), Freadlink(), Flock(), Flink(), Fcntl(),
    Fchown(), Fchmod(), Drewinddir(), Dreaddir(), Dpathconf(),
    Dopendir(), Dlock(), Dgetcwd(), Dclosedir() (,Foutstat(), Finstat())

Later on, GEMDOS HD emulation would probably need to check presense
of MiNT and under that enable some extra GEMDOS functions and work a bit
differently, maybe even pass through long filenames with mixed case.


In the NatFeats case I was hoping that most of the code could
be lifted from Aranym as as.


> > That would make utilization of Hatari's better emulation and debugging
> > features much easier with MiNT stuff.  Which in turn would mean better
> > testing for Hatari features which get used by MiNT SW. :-)
> > 
> > Would these make it more acceptable?
> > 
> > Or do you see some downsides for Hatari also when --natfeats would
> > be disabled?
> 
> This certainly adds complexity to the Hatari code base ... especially
> when you consider to implement the filesystem part, too.

I think only:
* the generic natfeats stuff of implementing the 2 illegal opcodes, and
* an option (similar to --trace one) for specifying what natfeats features
  are enabled

require modifying current Hatari code.  The actual natfeats features can
be completely separate from the rest of Hatari code.


> In that case it also adds yet another entry to the GUI

I wasn't thinking of adding natfeats stuff to the GUI.  MiNT using
Hatari users aren't that numerous and they're power users, using
command line options shouldn't be a problem for them.


> - and you have to explain the users the differences between
> GEMDOS HD emulation and NatFeats filesystem...

Explaining that would be easy because the use-cases don't overlap.

GEMDOS HD emulation doesn't work at all with MiNT,
whereas NatFeats FS works only with MiNT.


> not sure whether I like that idea...

For now I was just thinking of doing the ID, stderr and shutdown
part of NatFeats...


Your idea of Hatari GEMDOS-HD XFS for MiNT interesting, but I've never
looked at XFS code and currently I don't even have MiNT devel environment. 

Have you already thought of implementing something like that yourself?
:-)


	- Eero