I'm not really sure how to make this one pass the tests. It appears there are two values the radio interprets as no-tone, 0x00 and 0xff. Channels programmed for no-tone with the Puxing software will have the value 0xff. Channels programmed for no-tone from the PX-777 front panel will have the value 0x00. When reading the radio, Chirp breaks when it encounters the 0x00 value. Hence my patch. When Chirp writes/copies a new channel, it sets the tone value to 0xff, just like the Puxing software. This means a copy operation changes 0x00 to 0xff. The radio doesn't care, but this breaks the Chirp tests.
If you look at why it breaks, I think you'll see the problem. Just change your check to looking at the low-order (i.e. field[1]) byte instead, which is never zero in a normal case. The way they store their tone, a 100.0 tone will be 0010, which triggers the "no tone" case the way you had it.
Ideally, we'd check both bytes for in [0x00, 0xFF] to be more explicit.
Thanks!