Re: [hatari-devel] hatari release tester

[Thomas Huth <th.huth@xxxxxx>]

Am Sun, 8 Jan 2012 22:49:09 +0200
schrieb Eero Tamminen <oak@xxxxxxxxxxxxxx>:

> Hi,
> 
> On lauantai 07 tammikuu 2012, Eero Tamminen wrote:
> > > (on a more general test case, I agree that comparing selected
> > > screenshots can help verifying regression in an automated way)
> 
> 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).


> I could also add autorunning of the VDI testers I wrote for EmuTOS.

I think that does not make much sense for Hatari. 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.

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

> > 
> > >> * tv, vga, rgb, mono, 1 plane vdi, 4 planes vdi
> >
> > ST:
> >   tv, mono, vdi-1, vdi-4
> > STE:
> >   rgb, mono, vdi-1, vdi-4
> > TT:
> >   rgb, mono, vdi-1, vdi-4
> > Falcon:
> >   rgb, vga, mono
> > 
> > Or does TT use VGA instead of RGB monitors?

TT uses VGA, but Hatari does not care (i.e. it always emulates a VGA
when you do not select mono mode).

> > VDI mode emulation doesn't work with TOS v4 and with Videl's
> > programmability it's anyway unnecessary.
> > 
> > >> * 1, 4, 14 MB of memory
> > 
> > ST & STE:
> >   1 & 4 MB
> > TT & Falcon:
> >   1 & 14 MB

IIRC Falcon was always shipped with 4 MB, so I'd suggest to use 4 & 14
MB here. Not sure about the TT, though.

Apart from that, your strategy sounds fine!

 Thomas