|Re: [hatari-devel] Recent Hatari change problems|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
- To: hatari-devel@xxxxxxxxxxxxxxxxxxx
- Subject: Re: [hatari-devel] Recent Hatari change problems
- From: Thomas Huth <th.huth@xxxxxxxxx>
- Date: Sat, 21 Apr 2018 08:32:25 +0200
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.de; s=2017; t=1524292347; bh=LC9ynpL8oKZXjSYYRNsaCT9uhwzz9i+vR3CSKAiQYEY=; h=Date:From:To:Subject:From; b=naVx6lNU8dGqQTYxbZe/jyDIDGdFZSLtiGOviibklIR/5P+CQq3FIPL1b6ezheztF YAEDfeYgQVR+XBlWTdDT2RMBo9mgrXK3ey9j/wUFx4FSOpQtftZctTYeCdcSdZjD9L iBmGkSRADmkY7fbXLMj60vKkGW+EB8q3Uh8hi65RIh5OXzKGgmhafkDPinmM8B7KSA G1cpSISwiv7uOB/1CsikqOMddIVWbmS+byaGDBOSm0rDJj0dyTnI+sJyXRTfMSkFqV d/A/kJRN//Bvv5pd71iTKQcVHE2RXMvYdDT1OllDtQR2z6q/Rlwlbwm/eR9nfbNPSV llH0uf7G9CsGA==
Am Mon, 16 Apr 2018 01:53:44 +0300
schrieb Eero Tamminen <oak@xxxxxxxxxxxxxx>:
> On 04/15/2018 12:33 PM, Thomas Huth wrote:
> > schrieb Eero Tamminen <oak@xxxxxxxxxxxxxx>:
> >> On 04/14/2018 04:38 PM, Thomas Huth wrote:
> >> Giving a program to Hatari enables automatically GEMDOS HD
> >> emulation for the directory where that program is (Hatari
> >> autostarting would be pretty stupid feature without that).
> > Not sure, but I think this automatic enablement is bypassed in
> > "--tos none" mode since the program is not loaded by TOS, but by
> > Hatari here.
OK, I changed the behaviour so that now GEMDOS HD is enabled in --tos
none mode automatically for the given PRG, too.
> >> If "--natfeats yes" or "--bios-intercept yes" is missing, current
> >> test programs crash to double bus error and --run-vbls doesn't help
> >> for that. :-/
> > Hmm, maybe we should add a check in Dialog_HaltDlg if run-vbls is
> > active or if SDL_VIDEODRIVER is set to dummy, and exit immediately
> > in this case?
> Both sound a good idea.
I've added now --run-vbls to all test scripts, so together with your
modification of the HaltDlg, I think we should be fine now here.
> > The startup code would only be necessary if you compile a binary for
> > the "make test" regression test suite. If you compile a "normal"
> > binary (e.g. also with another C compiler than AHCC), you can use
> > the normal startup code of your C compiler.
> > So we only need to maintain a startup code for AHCC, and for the
> > well-known C code that we use for the regression tests. No need to
> > worry that this might break something in other programs.
> >> C-lib startup code is fixed, so for AHCC it would be enough just
> >> to implement the isatty() Fseek() support.
> > And if the next version of AHCC changes its startup code again and
> > uses additional GEMDOS calls? ... we'll always have to play GEMDOS
> > call whack-a-mole that way...
> Year ago Henk announced that AHCC v4.6 is the last release from him.
> So it should be stable unless somebody else starts maintaining it
> (or Henk gets back to it later).
I've now added our own small startup.s for AHCC, and the resulting
binary now shrunk to just 1310 bytes - and works without any further
modification to the GEMDOS emulation layer. So I think this is the
right way to go here.
> I don't think it bad idea if "--tos none" would be slightly more
> compatible. That would make it easier to use tests created for
> testing certain Hatari HW emulation features with real TOS
> (e.g. earlier FPU & blitter tests) also as regression tests.
If somebody comes up with such a new test, we can certainly consider
extending the GEMDOS emulation for the --tos none mode, but as long as
this did not happen yet, we also should not clutter the code with stuff
that is not really necessary.