|Re: [hatari-devel] Automated testing of Atari software with Hatari - Some tips|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
On 3/9/19 11:04 AM, Christian Zietz wrote:
Eero Tamminen schrieb:
I forgot to mention that one more option besides midi/serial/printer,
is using NatFeats STDERR:
That would work with Aranym too, but requires on Hatari
"--natfeats on" option.
Just a small question: I assume that the "TODO: test this" in the ASM
driver for NatFeats can be safely ignored,
I removed it.
i.e., the code is proven to
work? I don't want to debug the NatFeats driver but my own routines.
I'm pretty sure I've tested it, and some others have used it too.
If you diff it against AHCC and VBCC versions, you'll notice that
they're identical except for the syntax.
C-code and AHCC assembly is actually used in automated Hatari testing
for NatFeats (try "make test").
BIOS intercept is deprecated (because it provides too much control
for a thing running under emulation; if it wants, it could use that
to overwrite any file which Hatari process has write access to).
It was clear to me that I must only use BIOS intercept with trustworthy
code. In that case I see no security risk.
Suggestion: please mention that fact that it's deprecated the in the manual.
If you want more speed, use also:
--fastfdc on --timer-d on --sound off
Thanks, I'll add that.
Did you consider just forking Hatari's tos_tester.py?
Afaik, it relies on functions not provided by the Python standard
library under Windows.
I see. No FIFOs I guess?
I decided it would be faster to write my own test
rig than to figure out what needs to be changed in code that is not
mine. Yet, tos_tester.py looks like a really feature-rich test program,
so if someone is considering automated testing, he should definitively
check it out.