Re: [hatari-devel] Recent Hatari change problems

[ Thread Index | Date Index | More Archives ]


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.


Mail converted by MHonArc 2.6.19+