https://github.com/cdhooper/amiga_devtest
AmigaOS block device test utility (trackdisk.device, scsi.device, etc)
https://github.com/cdhooper/amiga_devtest
Last synced: about 2 months ago
JSON representation
AmigaOS block device test utility (trackdisk.device, scsi.device, etc)
- Host: GitHub
- URL: https://github.com/cdhooper/amiga_devtest
- Owner: cdhooper
- License: bsd-2-clause
- Created: 2022-04-19T23:01:17.000Z (about 4 years ago)
- Default Branch: main
- Last Pushed: 2026-04-12T22:25:39.000Z (about 2 months ago)
- Last Synced: 2026-04-13T00:34:08.687Z (about 2 months ago)
- Language: C
- Size: 333 KB
- Stars: 15
- Watchers: 4
- Forks: 5
- Open Issues: 0
-
Metadata Files:
- Readme: README.md
- License: LICENSE
Awesome Lists containing this project
README
# Amiga block device test utility (devtest)
This utility interacts directly with an Amiga block device driver to test
the driver and physical device. There are several operation types that the
utility can perform:
* Device probe
* Performance
* Packet support
* Device Geometry
* Data integrity
## 1. Device probe
It can probe all targets and logical units of a device and report which
targets are responding. Example:
```
9.OS322:> devtest -p scsi.device
0 ZULUSCSI HARDDRIVE 1.1 Disk 512 2147 MB
5 ZULUSCSI CDROM 1.1 CDROM 2048 77 MB
```
You can also probe a specific target id. If that target id is not present,
devtest will exit with a non-zero code. Example:
```
9.OS322:> devtest -p scsi.device 0
0 ZULUSCSI HARDDRIVE 1.1 Disk 512 2147 MB
9.OS322:> echo $RC
0
9.OS322:> devtest -p scsi.device 1
Open scsi.device Unit 1: Fail 32 TDERR_BadUnitNum
9.OS322:> echo $RC
1
```
## 2. Performance
You can measure device read and write performance in the system, using
different Amiga memory types (default is fastmem).
**WARNING: The -d option enables the write benchmark, which is destructive to any data on the drive!**
Examples:
```
9.OS322:> devtest a4091.device 1 -bd
Test a4091.device 1 with Coprocessor RAM
read 512 KB xfers 5992 KB/sec
read 128 KB xfers 5783 KB/sec
read 32 KB xfers 4937 KB/sec
write 512 KB xfers 5821 KB/sec
write 128 KB xfers 4887 KB/sec
write 32 KB xfers 3913 KB/sec
```
Testing with Zorro memory
```
9.OS322:> devtest a4091.device 1 -bd -m zorro
Test a4091.device 1 with Zorro III RAM
read 512 KB xfers 7377 KB/sec
read 128 KB xfers 7063 KB/sec
read 32 KB xfers 5915 KB/sec
write 512 KB xfers 7350 KB/sec
write 128 KB xfers 5893 KB/sec
write 32 KB xfers 4031 KB/sec
```
Normally, the destructive test will still attempt to read the data
beforehand and write it back after completing the test. Adding a
second `-d` option will skip the read and restore. This will speed
up the test, but not affect the reported performance.
Sometimes there is a type of memory which is at a specific range
of addresses, and you want to run the benchmark specifally against
that memoory. You should use an address in that range which is not
currently allocated. With the -m option, you may both discover free
memory and specify the exact address to use. Use the `-m -` argument
to show memory blocks in the free list.
```
9.OS322:> devtest -m -
Coprocessor RAM at 0x8000000 size=0x8000000
0x86b6220 0x400
0x86d1ef0 0x230
0x87892c0 0x7876d40
MB RAM at 0x7000000 size=0x1000000
0x7000020 0xffffe0
Zorro III RAM at 0x40000000 size=0x10000000
0x40000020 0xfffffe0
Zorro III RAM at 0x60000000 size=0x10000000
0x60000020 0xfffffe0
Zorro II RAM at 0x2000000 size=0x2000000
0x200020 0x1fffe0
Chip RAM at 0x004000 size=0x1fc000
0x0202d8 0x1dfd28
```
Use the ```-m
``` option to specify a particular block or type
of memory.
Examples:
```
9.OS322:> devtest a4091.device 1 -bd -m 0x60000020
```
```
9.OS322:> devtest a4091.device 1 -bd -m zorro2
```
Adding a second `-b` option will cause devtest to also measure
latency of a variety of packets. Example:
```
9.OS322:> devtest -bbd a4091.device 1
Test a4091.device 1 with Coprocessor RAM
read 512 KB xfers 5995 KB/sec
read 128 KB xfers 5768 KB/sec
read 32 KB xfers 4906 KB/sec
write 512 KB xfers 5800 KB/sec
write 128 KB xfers 5027 KB/sec
write 32 KB xfers 4020 KB/sec
OpenDevice / CloseDevice 2.090 ms
OpenDevice multiple 0.003 ms
CloseDevice multiple 0.001 ms
TD_GETGEOMETRY sequential 2.021 ms
TD_GETGEOMETRY parallel 1.100 ms
TD_CHANGENUM 0.006 ms
TD_CHANGENUM quick 0.006 ms
CMD_INVALID 0.006 ms
CMD_START 1.001 ms
CMD_READ butterfly average 1.063 ms
CMD_READ butterfly far 1.057 ms
CMD_READ butterfly constant 1.058 ms
CMD_READ sequential 2.077 ms
CMD_READ parallel 2.059 ms
HD_SCSICMD read sequential 2.072 ms
HD_SCSICMD read parallel 2.058 ms
CMD_WRITE sequential 3.052 ms
CMD_WRITE parallel 3.034 ms
HD_SCSICMD write sequential 3.054 ms
HD_SCSICMD write parallel 3.036 ms
```
## 3. Packet support
Trackdisk-compatible drivers often don't support all request
packet types that a filesystem may use. This is especially true
if it's an older driver that can't handle the packet standards
which support larger (4GB+) media. Devtest will test most known
trackdisk commands and report whether they are supported.
**WARNING: The -d option enables the write benchmark, which is destructive to any data on the drive!**
Example:
```
9.OS322:> devtest -t a4091.device 1 -d
TD_GETGEOMETRY Success 4194304 x 512 C=8192 H=32 S=16 Type=0
TD_CHANGENUM Success Count=1
TD_CHANGESTATE Success Disk present
TD_PROTSTATUS Success Unprotected
TD_GETDRIVETYPE Fail -3 IOERR_NOCMD (unsupported)
TD_GETNUMTRACKS Fail -3 IOERR_NOCMD (unsupported)
TD_RAWREAD Fail -3 IOERR_NOCMD (unsupported)
SCSICMD Inquiry Success V='ZULUSCSI' P='HARDDRIVE' R='2.0' DT=0x0 Linked Sync
SCSICMD TUR Success Ready
NSCMD_DEVICEQUERY Success
CMD_READ Success
ETD_READ Success
TD_READ64 Success
NSCMD_TD_READ64 Success
NSCMD_ETD_READ64 Success
TD_SEEK Success
ETD_SEEK Success
TD_SEEK64 Success
NSCMD_TD_SEEK64 Success
NSCMD_ETD_SEEK64 Success
CMD_WRITE Success
ETD_WRITE Success
TD_WRITE64 Success
NSCMD_TD_WRITE64 Success
NSCMD_ETD_WRITE64 Success
TD_FORMAT Success
ETD_FORMAT Success
TD_FORMAT64 Success
NSCMD_TD_FORMAT64 Success
NSCMD_ETD_FORMAT64 Success
TD_MOTOR ON Success
TD_MOTOR OFF Success
```
Adding a second `-t` option will cause devtest to test additional
packet types. Some packets may cause your media to eject or trigger
known bugs in Amiga device drivers.
## 4. Device Geometry
On the Amiga, there are multiple methods to acquire a drive's physical
geometry, including direct SCSI commands. These methods are reported
by devtest.
```
9.OS322:> devtest -g a4091.device 1
SSize TotalSectors Cyl Head Sect DType Removable
TD_GETGEOMETRY 512 4194304 8192 32 16 0x00 No
Inquiry 0x00 No
READ_CAPACITY_10 512 4194304
READ_CAPACITY_16 - - Fail 52 ERROR_SENSE_CODE
Read-to capacity 512 4194304
Mode Page 0x03 512 63
Mode Page 0x04 261 255
```
TD_GETGEOMETRY is implemented by the Amiga device driver. It is the
responsibility of the driver to acquire details from the device to fill
the DriveGeometry structure. It is known that Commodore's scsi.device
for IDE is sometimes not able to acquire geometry information from CF
drives, and may fail this command.
Inquiry is a SCSI INQUIRY, sent to the drive using SCSI Direct. The only
details reported by INQUIRY which are relevant here are the drive type
and removable flag.
READ_CAPACITY_10 is the SCSI READ_CAPACITY_10 result. Some very old drives
(SASI) do not support this command, but nearly all drives from the 90's
and newer do.
READ_CAPACITY_16 is unnecessary and likely unimplemented for any drive
smaller than 2 TB. It first appeared in the SCSI specification in the early
2000's, so older drives will definitely not support it. This command is
supported by PiSCSI regardless of the exported device size.
Read-to capacity is implemented by devtest as a as-fast-as-possible means
to determine the actual readable capacity of the drive. It uses a search
based on power-of-two sector addresses.
Many SCSI drives support mode pages, and depending on the specific page,
provide details such as the number of cylinders, heads, and sectors that
are present on the device.
You may specify a device or volume name instead of a driver and unit.
Additional details are provided when a device or volume name is specified.
```
9.OS322:> devtest -g Work:
SSize TotalSectors Cyl Head Sect DType Removable
Partition 512 16738688 1042 1 16064 scsi.device 0
Partition-start 512 2104384 131
Partition-end 512 18843072 1173
TD_GETGEOMETRY 512 18874368 1174 255 63 0x00 No
Inquiry 0x00 No
READ_CAPACITY_10 512 18874368
READ_CAPACITY_16 - - Fail 45 HFERR_BadStatus
Read-to capacity 512 16738687
Mode Page 0x03 512 63
Mode Page 0x04 1174 255
```
## 5. Data integrity
The benchmark test is a good tool for verifying the Amiga's bus interface
and timing are being met, but it does no actual data verification. The
devtest utility can perform tests to verify that data can be reliably stored
to and retrieved from the device media.
> CAUTION: This test is destructive when the -d flag is given. Do not
operate on a drive with data that you intend to keep.
Example:
```
9.OS322:> devtest a4091.device 1 -i 1024 -d
```
The above command performs a single 1024 byte write to the device, and then
reads that data back. It will report any miscompares, and show the mismatching
data. The test always starts at the beginning of the device's storage. You can
loop on this operation, in which case, all device data will be sequentially
written and then read back.
Example (test 64 MB of device storage in 64KB chunks):
```
9.OS322:> devtest a4091.device 1 -i 65536 -d -l 1024
Pass 1 2024-07-07 00:32:46
Pass 2 2024-07-07 00:32:46
Pass 3 2024-07-07 00:32:46
Pass 4 2024-07-07 00:32:46
```
...
```
Pass 1023 2024-07-07 00:36:17
Pass 1024 2024-07-07 00:36:17
1024 passes completed successfully
```
As can be calculated from the above (about 300 KB/sec), the data integrity
test is significantly slower than the performance test.
When the data integrity test detects a failure, it automatically re-reads
the data. Example (512 byte transfers with 2-byte alignment):
```
9.OS322:> devtest scsi.device 1 -di 512,2
Miscompare at 0x0
0001fe: a5 != expected 29 [diff 8c]
0001ff: a5 != expected 86 [diff 23]
Re-read of data differs (floating data?)
0001fe: 5a != expected 29 [diff 73]
0001ff: 5a != expected 86 [diff dc]
0001fe: 5a != first read a5 [diff ff]
0001ff: 5a != first read a5 [diff ff]
```
The above test suggests that the last two bytes of the transfer are
consistently not being written by the SCSI controller. This might happen
in the case of the Amiga SDMAC-04 when paired with a Ramsey-04 (not confirmed).
Some items to note:
1) The pattern written to disk is pseudo-random.
2) The read back buffer is filled with 0xa5 values by the CPU before the
transfer is initiated.
3) If a miscompare is detected in the read back data, the same data will be
read again into a second read back buffer. That buffer is pre-filled with
0x5a values by the CPU before the transfer is initiated.
4) Since we see that both the primary and secondary read-back buffers appear
to have original pattern contents, we can conclude that those values were
never updated by the SDMAC on the read back from disk.
The default mode of the integrity test is to generate a pseudo-random pattern
for the write data, alternating between the random values and inverted random
values. There are two other generated data modes. If -ii is specified, the
written data will be the byte offset of the data within the buffer.
0x00, 0x01, 0x02, ... 0xfe, 0xff, 0x00, 0x01 ...
and alternate:
0xff, 0xfe, 0xfd, ... 0x01, 0x00, 0xff, 0xfe ...
If -iii is specified, the written data will be one of 7 specific values
in a rotating cycle. The fact that there are 7 values (a prime number) in
the -iii mode is by design. This will cause different power-of-two
addresses to experience different data patterns. Pattern values:
0xa5, 0x5a, 0xc3, 0x3c, 0x81, 0x00, 0xff
and alternate:
0x5a, 0xa5, 0x3c, 0xc3, 0x7e, 0xff, 0x00
The simple integrity test, as shown above, performs a sequential check of
all media on the device. At each pass in destructive mode, it writes a chunk,
reads back that chunk, and compares. In non-destructive mode, it reads a
chunk, reads the same chunk again, and compares.
The devtest utility offers another integrity test, butterfly. This test
is specified with the -k option:
```
-k butterfly
```
The butterfly integrity test alternates between low and high offsets on
the device, each iteration the test moves the low and high closer to the
middle of the device, until they cross over. At which point, the low and
high swap places and then the test moves the low and high further from
the middle of the device. In destructive mode, the test writes data to
the low offset, and different data to the high offset. It then verifies
the low and high data match what was written. In non-destructive mode,
the test reads data at the low and high offset, then reads it a second
time from the low and high offset. It then verifies the low and high
data match what was previously read.
```
8.SDH0:> devtest scsi.device 1 -i 256k -k butterfly -ddyv -l 300
Pass 1 2020-03-30 15:04:43
Zone sector 0 (0.0% of media check #1) 0 KB
Pass 2 2020-03-30 15:05:00
Zone sector 512 (1.5% of media check #1) 16 MB
Pass 3 2020-03-30 15:05:15
Zone sector 1024 (3.1% of media check #1) 32 MB
...
Pass 64 2020-03-30 15:20:44
Zone sector 32256 (98.4% of media check #1) 1023 MB
Pass 65 2020-03-30 15:20:59
Zone sector 0 (0.0% of media check #2) 1040 MB
Pass 66 2020-03-30 15:21:15
...
```
The above test ran at about 1 MB/sec.