Re: [hatari-devel] hatari release tester

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

Hi,

On maanantai 09 tammikuu 2012, Thomas Huth wrote:
> Am Sun, 8 Jan 2012 22:49:09 +0200
> schrieb Eero Tamminen <oak@xxxxxxxxxxxxxx>:
> > On lauantai 07 tammikuu 2012, Eero Tamminen wrote:
> > With GEMDOS emulation, a better way to detect TOS startup could be
> > to auto-run some Atari program that writes to a predefined file, which
> > in actuality is a FIFO that the tos-tester listens on.  If there's no
> > write within some long timeout, the tester would conclude boot to have
> > failed.
> > 
> > This would be more robust than timeouts and would test also reading
> > desktop.inf, starting a program and writing to a file (i.e. test
> > GEMDOS emu a bit more).  Downside is that it always requires GEMDOS
> > emu, but maybe a non-GEMDOS boot with otherwise same HW config could
> > follow which uses the time it took to start the test program as TOS
> > boot timeout.
> 
> You could also redirect MIDI or RS232 to a file, and then boot a floppy
> disk with a program that writes something to the corresponding
> interface. That way you do not depend on GEMDOS HD emulation (which
> could influence the behaviour of the emulation quite a bit since it
> uses a cartridge and trap-bending mechanisms internally).

Excellent idea!


> > I could also add autorunning of the VDI testers I wrote for EmuTOS.
> 
> I think that does not make much sense for Hatari.

OK.


> Either screen output
> works (and so all VDI functions should behave like on a real Atari), or
> it does not work at all since TOS did not boot. I don't think that we
> will see something like a partly broken VDI due to Hatari bugs.

Actually there is one Hatari problem with VDI mode, reported by Uwe:
http://lists.berlios.de/pipermail/hatari-devel/2010q4/002684.html

But I don't have a test-case for it.  Should I add description of
that bug to todo.txt (before BerliOS goes down)?


If Hatari would at some point support NatFEATS and native VDI like
Aranym does, VDI tests could be useful, currently it would be mainly
useful for testing EmuTOS.

I would like to have the tests somewhere in upstream, but EmuTOS people
didn't really answer when I asked whether they would be interested about
them.  Maybe because the automation would depend on Hatari / hconsole. :-/



> > > So, any comments on what combinations would be good to test? :-)
> > > 
> > > If e.g. "--fast-boot off" would more robust, the tester could be
> > > used to verify that it works fine with all combinations below.
> > > 
> > > >> The attached version will go through:
> > > >> * given TOS images
> > > 
> > > I would propose testing following versions to get good enough
> > > 
> > > coverage:
> > >   v1.00 de, v1.02 de, v1.04 de, v1.04 us, v1.62 de, v1.62 us,
> > >   v2.06 de, v3.06 us, v4.04, kaostos, etos192k, etos512k[1].
> 
> You can certainly omit kaostos, I think hardly any user uses
> this for Hatari.

OK.   I also added this stuff to TOS tester readme.


Do you think there's anything else that should be tested (by default)
in combination with the TOS images, like:
* --fullscreen on/off
* --fast-boot on/off
* --timer-d on/off
* --rtc on/off
* --compatible CPU on/off
* ASCI/IDE images
?

	- Eero