Re: [hatari-devel] Recent Hatari change problems

[Thomas Huth <th.huth@xxxxxxxxx>]

 Howdy,

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.

 Thomas