|Re: [hatari-devel] Adding Aranym features for Hatari?|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
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.
> > 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, there are quite a lot of them, but maybe at least at start,
those could just return an error.
 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
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?