![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to readme.txt CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [HATARI the Atari ST Emulator] / hatari / tests / tosboot|
Return to readme.txt CVS log | Up to [HATARI the Atari ST Emulator] / hatari / tests / tosboot |
1.1.1.2 root 1: Files
2: -----
3:
4: Tools and data files:
5: Makefile -- builds the test program and floppy & HD images
6: containing it
7: disk/* -- sources, binaries and input files for test program,
8: directory is also used for GEMDOS HD emu testing
9: floppy/* -- files to autostart test program from floppy
10: tos_tester.py -- test driver, described below
11:
12: Generated files:
13: output/* -- Test report and screenshots, temporary output files
14: dummy.cfg -- Hatari config file generated by test driver
15: blank-a.st.gz -- blank floppy image to avoid TOS disk dialogs
16: bootauto.st.gz -- floppy image with the test files and test program
17: run from auto/-folder for TOS <1.04
18: bootdesk.st.gz -- floppy image with the test files and test program
19: run from *.INF desktop file
20: hd.img -- HD image with the the test program / files
21: and DOS partition table
22:
23: Other files and directories:
24: readme.txt -- this text file
25: tos/* -- TOSDIR in Makefile points here for your TOS images
26:
27: There's also "screenshot-report.sh" script to generate a HTML report
28: out of the screenshots saved by TOS tester which will list missing
29: tests and any differences in the produced screenshots. For that, you
30: need "reference" directory to contain screenshots from an earlier,
1.1.1.5 root 31: successful run of TOS tester.
1.1.1.2 root 32:
1.1 root 33:
34: Usage
35: -----
36:
1.1.1.5 root 37: NOTE: TOS tester works *only* with Hatari versions that are built with
38: raw MIDI device support, NOT with PortMidi support. This is because
39: TOS tester communicates to the emulated test programs through FIFO
40: file given to Hatari as MIDI input/output file, whereas PortMidi
41: allows communication only to real MIDI devices.
42:
1.1 root 43: If you want to test Hatari version that isn't in your PATH,
44: you need to give PATH for the Hatari binary you want to test,
45: like this:
1.1.1.2 root 46: PATH=../../build/src:$PATH make
47:
48: Before running that, tos/ subdirectory should have (symbolic links to)
49: TOS images you want to test, at least EmuTOS etos512k.img image.
50: Or add this before above command:
51: TOSDIR=<path to TOS images dir>
52:
53: Alternatively, you can call the TOS tester directly and specify
54: the TOS images it should test:
55: PATH=../../build/src:$PATH ./tos_tester.py <TOS images>
1.1 root 56:
57: To view the produced screenshots, either use ImageMagick:
1.1.1.2 root 58: display output/*.png
1.1 root 59:
60: Or use the script that creates a HTML page with them and opens
61: browser to view it.
62:
63:
64: What TOS tester tests
65: ---------------------
66:
1.1.1.2 root 67: These are the HW configuration combinations that TOS tester currently
1.1 root 68: supports:
69:
1.1.1.6 ! root 70: * ST, MegaST, STE, MegaSTE, TT and Falcon machine types
1.1 root 71:
1.1.1.6 ! root 72: EmuTOS 512k is tested for all the machine types. EmuTOS 256k and
! 73: TOS v2.x are tested with all machine types except TT / Falcon.
! 74: Rest of TOSes are tested only with a single machine type.
1.1 root 75:
1.1.1.2 root 76: * TV, VGA, RGB and monochrome monitors and 1, 2 & 4 plane VDI modes
1.1 root 77:
1.1.1.4 root 78: * Different amounts of ST-RAM from 0 (0.5MB) to 14MB
79:
1.1.1.6 ! root 80: * Different amounts of TT-RAM from 0 to 512MB
1.1 root 81:
1.1.1.2 root 82: * With and without GEMDOS harddisk directory emulation
1.1 root 83:
1.1.1.2 root 84: Test program is started either from a floppy or an emulated GEMDOS
85: HD (directory) using *.INF file, or in case of TOS v1.00 - 1.02,
86: from floppy auto/-folder. GEMDOS HD testing is done with more
87: extensive gemdos.prg test program, floppy testing with minimal.prg
88: test program which doesn't change the floppy content (to avoid its
89: repository file update).
1.1 root 90:
1.1.1.6 ! root 91: * ACSI, IDE and SCSI interface testing with EmuTOS
1.1.1.3 root 92:
1.1.1.2 root 93: * Arbitrary boolean Hatari command line options specified
94: with the "--bool" option
95:
96: You can use the command line options to specify which set of these
97: is used and TOS tester will go through all combinations of them.
98:
99: See "tos_tester.py -h" output for examples.
1.1 root 100:
101:
102: What to test
103: ------------
104:
105: For each Hatari release it would be good to test e.g. the following
106: TOS versions:
107: v1.00 de, v1.02 de, v1.04 de, v1.04 us, v1.62 de, v1.62 us,
108: v2.06 de, v3.06 us, v4.04, etos192k, etos512k[1]
109:
110: [1] Just the latest release of EmuTOS.
111:
1.1.1.2 root 112: And following monitor configurations:
113: ST: tv, mono, vdi-1, vdi-4
114: STE: rgb, mono, vdi-1, vdi-4
115: TT: vga, mono, vdi-1, vdi-4
116: Falcon: rgb, mono, vga
117:
118: Memory configurations:
119: ST: 0.5 & 2 MB
120: STE: 1 & 4 MB
1.1.1.4 root 121: TT: 2 & 10 MB ST-RAM, 0 & 32 MB TT-RAM
122: Falcon: 4 & 14 MB ST-RAM, 0 & 32 MB TT-RAM
1.1.1.2 root 123:
1.1.1.6 ! root 124: And both with GEMDOS HD and just floppy. For EmuTOS, also ACSI (with
! 125: ST/STe/TT), IDE (with Falcon) and SCSI (with Falcon/TT).
1.1.1.2 root 126:
127: Testing should be done both for old UAE CPU core and the new WinUAE
128: one. This should give good enough coverage of all the possible bootup
1.1 root 129: issues.
130:
1.1.1.6 ! root 131: Note that it's enough to give the whole set of HW configurations to
1.1.1.2 root 132: TOS tester, it will automatically select a suitable subset of HW
133: combinations to test, for each given TOS versions.
134:
1.1.1.5 root 135: Unless you're specifically testing FDC timings or memory detection
136: compatibility, you can use --fast option to speed up TOS bootup a lot.
137:
1.1.1.2 root 138:
139: Potential TODOs
140: ---------------
141:
142: Extend GEMDOS test program to test also:
143: * starting another program
144: * file redirection
145:
146: But only if all TOS versions support that properly.
147:
148: -
149:
1.1.1.6 ! root 150: Add testing of ASCI, IDE and SCSI drives with normal TOS in addition
! 151: to the GEMDOS HD and floppy tests.
1.1.1.2 root 152:
153: This isn't very straightforward because both need different drivers
154: and therefore different disk images and the drivers either have issues
155: with e.g. EmuTOS, or don't support all machines. Formatting and
156: installing the drivers requires using interactive Atari programs,
157: so these images cannot be automatically (re-)generated.
158:
1.1.1.6 ! root 159: (EmuTOS supports ACSI, IDE and SCSI directly, without any need for
! 160: drivers. Both HDs with DOS (not Atari) partition table, and ones
! 161: without partition table at all. That's why it can be already tested.)
1.1.1.3 root 162:
163: -
164:
165: Testing a HD disk having also MiNT (= WinUAE / MMU testing at the same time).
1.1.1.2 root 166:
167: -
168:
169: Machine type specific test programs e.g. for:
170: * ST color resolution overscan
171: * STE blitter and overscan
172: * TT FPU operations, could output e.g. speed
173: * Falcon DSP operations
174:
175: If pre-existing demo programs are used for these, it's better
176: if they're small.
177:
178: Such programs also needs to have some static screen which doesn't
179: automatically advance so that a screenshot can be taken of it.
180: Alternatively, test program could be accompanied with debugger
181: script(s) that stop the program at suitable point and take a
182: screenshot.
183:
184: -
1.1 root 185:
1.1.1.2 root 186: Current screenshot-report.sh script assumes that Hatari will always
187: create identical screenshots for the same screen content. This might
188: not be true if underlying libpng gets updated, so it would be better
189: to have some e.g. SDL binary that loads two images, compares their
190: uncompressed content and either reports that, or shows the difference.
1.1 root 191:
1.1.1.2 root 192: -
1.1 root 193:
1.1.1.2 root 194: Tester for DMA sound output and comparison for the produced sound.
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.