Gary,
5 years later, I am looking at your excellently formatted tpdd2 backup
logs and it's totally providing answers. Thank you for making them.
http://trs80stuff.net/tpdd/tpdd2_boot_disk_backup_log_hex.txt
<http://trs80stuff.net/tpdd/tpdd2_boot_disk_backup_log_hex.txt>
I'm still in the middle of writing it into my script but I think I see
enough already to at least clone existing disks where you don't have to
know *why* there are N bytes at address Y to copy them.
A few of the mysteries in the TPDD2 sector access docs can be filled in.
For load_sector, the 2 bytes RsvdA appear to really be two separate
fields, and the first byte is an access mode where 00=read_disk_to_ram
and 02=write_ram_to_disk
For read_fragment, the single byte RsvdA is another mode flag. I don't
know how to interpret the data it's reading and writing, but I can see
how to use it to read from one disk and replicate it on another disk.
The backup util reads 4 bytes from a particular address with that flag
set to 01, once for every sector, and then writes the same 4 bytes back
using a write_fragment command with that same mode flag set to 01.
It's some sort of metadata that is probably something like the ID data
in the TPDD1 fdc commands.
The basic process goes:
load a sector into drive's ram
read 4 bytes of metadata with read_fragment mode 1
read 1280 bytes of normal data in 64-byte chunks
load next sector into ram
repeat 4 bytes metadata, 1280 bytes normal data
repeat for some number of sectors (in this case, it's 12 sectors and
it's also all sectors, as the disk has only 15k used and the total job
fits in the client 100's ram)
write the previously saved 4-byte metadata from one of the previously
loaded sectors to the drive's ram
write 1280 bytes of normal data in 64-byte chunks to the drive's ram
two mode 1 mystery "writes" of 0 bytes to two particular addresses
flush the drive's ram to disk using the load_sector command but with the
mode flag 2 instead of 0
repeat write 4-bytes metadata and 1280 bytes normal data for the next
sector,
same 2 mystery writes (same addresses, same values every time)
flush ram to disk
repeat for all sectors previously read
To write a sector, you just start writing to the drive's cache. You
don't do anything to say what track or sector it is until the end. After
you've filled up the drive's cache ram with data, then you say "write
the cache to track 3 sector 1"
The following are the commands, shown without the leading 5A 5A or the
trailing checksum bytes, or the responses from the drive, or the
check-condition commands the backup program did along the way (probably
at disk-change events)
load track 0 sector 0 into ram
load_sector, mode 0, track 0, sector 0
30 05 00 00 00 00 00
read metadata
read_fragment, mode 1, offset 8004, 4 bytes (32772-32776)
this is one new command we didn't know before, because of the mode flag
being 1 instead of 0
32 04 01 80 04 04
read normal data
read_fragment, mode 0, offset 0000, 64 bytes
32 04 00 00 00 40
... repeat, reading 19 more 64-byte fragments to fill 1280 bytes...
read final 64-byte fragment of track 0 sector 0, 1216-1280
32 04 00 04 C0 40
The backup utility reads track 0 sector 0 once first, learns about the
contents of the disk from that somehow, then jumps to reading track 6
sector 1 and works backwards from there to 0:0, then goes from 6:1 to
0:0 when writing the new disk, and that's it. It never touches the rest
of the disk, not counting a format)
... once, after completing reading all of track 0 sector 0 before
jumping to track 6 sector 1, it does something odd one time, it reads a
particular set of 20 bytes from the middle of the final 64-byte fragment
for the sector it just read...
read 20 bytes from 1240-1260, these same bytes were just read already,
they are included within the immediately previous read of bytes
1216-1280, so, for some reason FLOPPY is asking the drive for those
bytes again instead of just reading them from the 100's own ram.
32 04 00 04 D8 14
Now it reads track 6 sector 1, repeating the sequence above, the same 4
bytes of metadata (same offset & length for every new sector loaded),
same 20x64bytes of normal data.
And repeats that for sector 6 track 0, then 5:1, 5:0 ... back down to
0:0, and it does read 0:0 again even though it has already read it once
at the beginning.
After reading the final chunk of track 0 sector 0...
32 04 00 04 C0 40
It immediately starts writing to cache
the commands don't show it yet, but the data it's writing is from track
6 sector 1, but at this point, it's just writing data to the cache, and
you don't see the destination track or sector until later when it issues
the flush-to-disk command.
This "31" is a new command not documented before.
write metadata
write_fragment, mode 1, offset 8004, length 4
31 07 01 80 04 96 FF 46 75
write normal data
write_fragment, mode 0, offset 0000, 64 bytes (the length byte, 0x43 =
67, first 3 bytes of the 67 bytes are mode 00 offset 0000, remainder is
64 bytes)
31 43 00 00 00 AC A7 0A 00 3A 8E FF 46 52 45 4D 45 4D 00 B4 A7 14 00 B0
3A A3 00 DF A7 1E 00 A3 22 4B 69 6C 6C 20 74 68 65 20 27 46 4C 4F 50 50
59 27 20 61 6E 64 20 66 72 65 65 20 74 68 65 20 73 70 61 63 65
Repeat write_fragment next 64 bytes, offset by 64,
Repeat until 1280 bytes written
the next two mystery commands are repeated verbatim for every sector
written. They are done for every sector, and they always have the same
values.
"mystery write 1"
write_fragment, mode 1, offset 0083, length 0
31 04 01 00 83 00
"mystery write 2"
write_fragment, mode 1, offset 0096, length 0
31 04 01 00 96 00
flush the cache to disk, to track 6 sector 1
(we should probably change the name we use for this command since it's
kind of like the dirent command where the same command is used for both
reads and writes)
load_sector, mode 2, track 6, sector 1
30 05 02 00 06 00 01
immediately write the 4-byte metadata for the next sector to cache
write_fragment, mode 1, offset 8004, 4 bytes...
31 07 01 80 04 96 FF 46 75
Repeat all the same cache writes, mystery writes, and final flush to the
next track & sector.
One other thing, I didn't show the drive responses here but one thing
about that to note is the new "31" write_fragment command has the same
"38" response as "30" load_sector, so "38" isn't really just "Load
Sector Response" like it's been called up to now.
From this I should have pdd.sh doing full disk sector-access-based
cloning for TPDD2 in no time, and it already has that for TPDD1.
Even though I have no idea what the 2 mystery writes do, since they are
the same every time, I can just issue the same commands without knowing
what they are.
Same goes for the 4 metadata bytes. I don't know how to interpret them,
don't now how to generate them, but it's no problem to just copy them.
--
bkw
On 8/17/16 4:28 AM, Gary Hammond wrote:
I have changed the setup for capturing of the backup process for the
TPDD2 boot disk from USB/serial adapters on a laptop to PCI quad com
card along with purchasing a copy of DockLight. The results are much
cleaner than before.
The log of the TPDD2 boot disk backup is at
http://trs80stuff.net/tpdd/tpdd2_boot_disk_backup_log_hex.txt
<http://trs80stuff.net/tpdd/tpdd2_boot_disk_backup_log_hex.txt>
Reading of the boot disk starts at 17/08/2016 20:02:13.778 and
finishes at 17/08/2016 20:02:38.897.
Writing of the new disk starts at 17/08/2016 20:02:56.492 (Line 666
?!?) and finishes at 17/08/2016 20:03:32.795
An interesting note is that the copied boot disk will not boot until
you open the write protect tab. Had me stumped for a while.
The booting from a TPDD2 boot disk after entering the RUN”COM:98N1ENN”
command has been captured in the file
http://trs80stuff.net/tpdd/tpdd2_boot_log_hex.txt
<http://trs80stuff.net/tpdd/tpdd2_boot_log_hex.txt>
The booting from a TPDD boot disk after entering the mini program in
the manual has been captured in the file
http://trs80stuff.net/tpdd/tpdd_boot_log_hex.txt
<http://trs80stuff.net/tpdd/tpdd_boot_log_hex.txt>
I have not yet succeeded in capturing the TPDD backup of the boot
disk. There is just enough bleed to the serial sniffer to stop the
backup process commencing after the destination disk has been
formatted. The backup program hangs at the end of the format routine
and there is no disk activity after the heads return to the start
position. Normally there looks like a head seek to read a directory at
the end of the format. If I take the serial sniffer out of the
circuit, the backup process works fine. I have tried with 2 different
TPDD’s and I get the same result. Maybe the serial com circuit is more
sensitive in the TPDD’s. I may need to make up an external serial
buffer to boost the RS-232 levels.
Cheers,
Gary
