|Re: [hatari-devel] Adding Aranym features for Hatari?|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
- To: hatari-devel@xxxxxxxxxxxxxxxxxxx
- Subject: Re: [hatari-devel] Adding Aranym features for Hatari?
- From: Paul Wratt <paul.wratt@xxxxxxxxx>
- Date: Tue, 16 Oct 2012 22:13:54 +1300
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=kmU5s/x2K9DB2QwecWRYQylDt1M3T0di6wy1Stvq70w=; b=AkpgqTveFH42GTghkFF7Np7535jTOJsoe00Tz9AQRI9jD1KkSi6N5oy/3PxxbBLwOK EU7gz0H666tjULLtvXmRs0145S5X98VzXez+eIaH3unH4P6Gm6ZpIuR/VB0ICsPWlsMz axyaFHuViyi6wlVxIeHH4um7/IdgGHtqofnv99Cv7H2J5l7aAsHxd9Bp8k6BdrLzm37Q QMc06cizzzqE9Onts1PyvL4J1Y+giRGVqC3nciS8BY6h29GDyJkN5do49Duvx+UQ3QFE XAM1xW1L0Z9i/5xutYnxVHvMXRmoeGeT9z7u6R9GkXkUryaKgpLHK6Q3fMAKNposedO+ cD7g==
a generic GEMDOS XFS would work (in theory) with other emulators as,
incl. Gemula8r, STEem (3.2) and TOSBOX
STonC impliments NF HOSTFS at XBIOS level, so it worked in MiNT 1.15
without any NF drivers
note that current GEMDOS usage (Path as Drive) in the above mentioned
emulators all produce CAP only 8.3 filesystems
NF filesystem drivers on the other hand allow LFN, Case Dependant
(trailing ':' in path), and (default) Case Irrelevant (converted to
lower case in the case of creating a dev file/folder)
ATM there is an issue with File Locking and Piping when using NF
HOSTFS drives, which means those drives can not be used with a lot of
build scripts (anything with console piped into CAT - incl. FreeMiNT
build scripts), and some command line tools (RPM - requires
"proper/real file locking")
If Hatari were to implement NF, and presuming the above mentioned NF
driver issues were fixed, a full SpareMiNT and GentooMiNT install and
development environment would be possible, without the use drive
images (same for ARAnyM)
A GEMDOS XFS would allow similar on most emulators (that dont have NF
support), presented as Caps only 8.3 filesystem
On Tue, Oct 16, 2012 at 9:12 PM, Eero Tamminen <oak@xxxxxxxxxxxxxx> wrote:
> 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, 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
> 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