Re: [hatari-devel] Recent Hatari change problems

[ Thread Index | Date Index | More Archives ]


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:

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

Mail converted by MHonArc 2.6.19+