|Re: [hatari-devel] Adding Aranym features for Hatari?|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
Am Mon, 15 Oct 2012 10:40:28 +0300
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've had this discussion a couple of times already in the past. I
> > personally don't like yet another illegal opcode abused in Hatari,
> > we already had enough trouble with the others already: Some games
> > or demos sometimes use illegal opcodes to trap to the illegal
> > instruction handler, and when the emulator does not handle these
> > illegal opcodes the program won't work anymore. So NatFeats is fine
> > for an emulator like Aranym, which is only designed for running
> > "clean" applications, but it just does not fit well to an emulator
> > like Hatari.
> 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
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
> 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. In that case
it also adds yet another entry to the GUI - and you have to explain the
users the differences between GEMDOS HD emulation and NatFeats
filesystem... not sure whether I like that idea...