00 42 039 004 DOS     SYS
01 42 014 043 INFOBITSBAS
02 40 080 085 STING
03 42 150 165 MALAGUEN
04 42 092 315 FLIGHT
05 42 069 416 ELEPHANT
06 42 185 485 QUEST   32K
07 42 031 670 TARGETS BAS
08 42 017 701 ENEMY   BAS
09 42 010 057 INFOBITSTXT
10 42 012 067 MAIL    BAS

Notice that the file STING has a status byte of 0x40 instead of 0x42 like the rest of the files. The 0x02 bit indicates a DOS2.0 format file, so this file is in DOS 1.0 format.

What is DOS 1.0 format? Well, it's very similar to DOS 2.0 format, except the byte count field is instead a sector index (0 in the first sector, 1 in the second, …) in all but the last sector, where it is the traditional byte count again but with the 0x80 bit set as well.

For parsing a DOS 2.0 file we handled the last three bytes in the following way:

    my ($nextSector, $nBytes) = link_data($sectorData);
    $out .= substr($sectorData, 0, $nBytes);
    $sector = $nextSector & 0x3ff;
    last if $sector == 0;

We can support DOS 1.0 files as well by adding this after the first line:

    $nBytes = ($nBytes & 0x80) == 0 ? 125 : ($nBytes & 0x7f) if $dos10;

Which is the Perl code to implement the following code you can find in DOS 2.0S:

104C 68     5040        PLA            ;GET LEN
104D 3002   5041        BMI  RDNS2     ;BR IF OLD SHORT SECTOR
104F A97D   5042        LDA  #125      ;ELSE SET FULL SECTOR
1051 297F   5043 RDNS2  AND  #$7F      ;TURN OFF MSB
1053 48     5044        PHA            ;BALANCE STACK

Notice that this design means the sector index has to wrap every 128 sectors, but that's not a problem. The problem with this design (and likely why it was changed with DOS 2.0), is that the sector size can't be larger than 128 bytes, since you only have 7 bits to store the length of the last sector. DOS 2.0S supports 256 byte sectors, so something had to change. There are many possible changes they could have made, making the last byte the actual byte count is just one solution.