Re: [hatari-devel] Recent Hatari change problems

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

Hi,

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:
[...]> Ok, actually, I really don't care that much about hconsole and
> python-ui, since I never use them. If you really think that Hatari
> should spam the console here, feel free to change the last parameter of
> the Opt_ParseParameters call in change.c so that it runs the option
> parsing in verbose mode here again.

I do agree that most of the options don't need the feedback
by default, my worry was mostly about options that are more
complicated, or which do some extra interpretation on what
user gave.  Like the VDI size options I mentioned earlier,
or --auto.


> [...]
> > 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.

Enabling is done in options.c, not TOS handling code.

(And I tested it, -d is not needed.)


> > > ctest also seems to have a "--test-timeout" option, but the man page
> > > says that it is "internal only".
> >
> > Any idea why?
>
> I apparently looked not far enough in the man page. There is also a
> "--timout" option that can be used for ctest, and you can also specify
> individual test timeouts in the CMakeLists.txt files, see:
>
> https://stackoverflow.com/questions/45009595/how-to-overwrite-ctest-default-timeout-1500-in-cmakelists-txt

In case stuff below isn't enough, it would probably be good idea
to have some (long) timeout for each test invoking the emulation.


> > 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.

Please print out something (unconditionally) when this happens.
E.g. something like:
	Double bus error -> hang!
	Dummy video driver / --run-vbls used -> exiting.

[...]> 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 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.

In the Fseek() case, gemdos.c code just needs to set a suitable
return value instead of calling TOS for the special file handles.

For Fwrite() special handles, it should be enough to handle just
console write as printf(), and treat other handles as no-ops?


	- Eero