On 3/20/25 12:21, Royce Taft wrote:
Has anyone else read through the disk, sector, and file format section of the
TPDD software manual? I’m not sure if it’s glossing over some key information
or if I’m just not understanding something. Most of my confusion is surrounding
the sector ID field.
I did enough to write client-side code in pdd.sh and server-side code in
dl2.
https://github.com/bkw777/dl2
https://github.com/bkw777/dl2#sector-access--disk-images
https://github.com/bkw777/pdd.sh
https://github.com/bkw777/dl2/blob/master/ref/search_id_section.txt
pdd.sh includes code for reading and parsing both the SMT and FCBs
though it may be hard to follow.
Both dl2 and pdd.sh I *somewhat* comment before most functions what the
data is for that function, which usually means either a packet on the
wire or a chunk of the disk. Including some minimal description of the
fcb and smt enough to parse them.
The comments and the code itself may be utterly useless as documentation
for anyone but me but there it is.
This is an explanation of my understanding of this with my assumptions and
questions interspersed:
The directory on track 0 sector 0 consists of a space management table and file
control blocks (FCBs) for up to 40 files. The info for an FCB contains
filename, attributes, file size, sector start, and sector end. Sector start and
end values are not numbered from 0 to 79. Instead those bytes consists of 7
bits for track number (0-39) and one bit for sector number (0 or 1). I’ll call
this “track, sector” notation, although I think “sector” is probably the MSB.
For every sector, there’s an ID section and a data section. The ID section
includes sector number. It’s not clear if the format for sector number is
“track, sector” such as in the FCB in the directory, or if it’s simply a 0 or
1, or if it’s a continuous count such as 0, 1, …, 79. Any thoughts? The ID
section also includes sector length. Not file length, sector length. Isn’t that
just a fixed number of bytes for all sectors? What could this actually mean?
The ID section also includes a “logical sector length code”. Once again, I’m
not really sure what this means.
The raw sector number bytes on that part of the disk are not necessarily
the same as what you ever see on the wire talking to the disk. It might
be the same, IDK, but it's not part of the data you can read or write,
even using raw sector commands, so the drive firmware is the only thing
that sees that part directly.
But when you issue commands to the drive or read responses from it, in
most cases (all maybe? I don't remember every command) you specify the
physical sector number 0-79 and the logical sector number 1-20 within that.
(from pdd.sh:)
# Read a logical sector
# A logical sector is a 64 to 1280 bytes long chunk of a physical sector
# fcmd_read_logical physical# logical#
# physical sector number 0-79 as plain ascii decimal integer
# logical sector number 1-20 as plain ascii decimal integer
# Valid values for L depends on the logical size code for the given physical
# sector. If LSC is 0 (64-byte logical sectors), then L may be 1 to 20.
# If LSC is 6 (1280-byte logical sectors), then the only valid L is 1.
That isn't just the interface to this shell function, that's what a
client needs to give to a drive.
That is documented in the software manual, this just restates it
specifically to document this fcmd_read_logical function in the script
which is just a wrapper for the drive firmware command to read a logical
sector.
There is no read-physical command, you do that by reading the logical
size code and then depending on what the LSC is you read anywhere from 1
1280-byte logical sector to 20 64-byte logical sectors.
The data section for track 0, sector 0 contains the directory, but for the rest
of the sectors the data section contains space for file data. To access a file,
the FCB in the directory can be used to access file name, length of file
(length-1 for text, but for basic file maybe it’s the true length?),
The true length is in the fcb. There is another length reported by the
directory-entry function which can vary by several bytes, always
smaller, and I have not deciphered the pattern, like maybe it's just
missing all CRs or LFs or something, maybe also trailing ^Z? Any/all
files can be off.
pdd.sh includes an option to display either file size in the directory
listing function, though the FCB option is only useful on a real drive.
The fcb option requires using the raw sector access commands to read the
fcb and decode it, but when accessing a drive emulator there is no fcb.
dl2 does support all the sector access commands to read/write a disk
image, so the fcb option could work with dl2, but only if you have
loaded a disk image of a real disk that exactly matches the files being
shared as normal files from a dir somewhere. dl2 doesn't yet have an
option to read or write files from a disk image. And besides, when using
a drive emulator instead of a real drive, the emulators all give the
true file size in their emulated dirent() function, not the shorter
filesize that a real drive would.
https://github.com/bkw777/pdd.sh/blob/c035c5054f283ce5f218e4d21fe631465c7ab93c/pdd.sh#L2161
sector start, and sector end. The example in the manual (figure 1-9)
shows a file which spans three sectors which are not in order physically
on the disk. The file head sector pointer from the FCB takes us to the
start sector for the file data. The diagram in Figure 1-9 claims that
information in the sector ID field for the file’s first sector will tell
us the sector number for the next sector of our file, and so forth until
maybe the last sector ID field uses “0xFF” as the next sector pointer to
act as a terminator? No where in the sector ID format section of the
manual do I see where these “next sector pointers” exist. I have
unanswered questions about this sector ID field above, so maybe that’s
where I’m missing something.
This gets a little confusing because a TPDD1 has two different modes of
operation, where one mode is raw data and one mode is essentially the
drive firmware implements a filesystem and a server to provide like a
FTP-over-serial to access the files.
The filesystem is like an extra layer on top of the raw sector mode, so
a filesystem disk is also a raw data disk, just with particular data in
the raw sectors which is created, managed, read by the drive firmwares
filesystem code.
Also there are parts of the physical disk that are entirely
managed/owned/read/written only by the drive firmware, they never pass
over the wire as part of any command and can't be either read or written
by a client, yet they are described in the software manual as part of
the disk and seem to be part of the various sector access commands
described later in the manual, but they're not.
So, the ID section (that a client can read or touch) is 12 bytes that
can have anything at all in it. There are leading and trailing bytes
before & after the 12 that you can't read or write. (not as a tpdd
client on the serial port anyway, not talking about fluxengine etc)
There is a write-id command that lets you write any 12 bytes you want to
it, and a read-id section that will return the 12 bytes no matter what
they are, and there is a search-id function where you specify 12 bytes
to search and the drive firmware looks at all ID sections on the whole
disk and returns the track & sector number of the first match if any.
(It's possible to write the same duplicate ID to multiple sectors, and
possible to read any/all IDs by sector number, but not possible to
search for anything but the first match. No way to specify "search
starting after this sector" and repeating the same search just returns
the same first match. And you don't have to use the search-id just to
use the id section. If you know what sector number you want, you can
just read or write any sectors id section the same as reading or writing
any sectors normal data.)
That's what the ID section does at the low level, like if you were to
use the sector access commands to make a raw data disk and use the
read_id, write-id, search-id functions.
For a filesystem disk, the drive firmware filesystem code uses the ID
section only to write a single byte to it, which is the next-sector
linked list pointer. The remaining 11 bytes are unused.
The comment for the search-id wrapper function in pdd.sh
https://github.com/bkw777/pdd.sh/blob/c035c5054f283ce5f218e4d21fe631465c7ab93c/pdd.sh#L1275
# Sector ID section - See the software manual page 11
# There is one ID section per physical sector.
# Ignore the leading 4 leading bytes and 2 trailing crc bytes, since
they don't
# exist outside of the drive. A client can neither read nor write them.
#
# The LSC byte is readable, but not individually or arbitrarily writable.
# The only control a client has over the LSC byte is the LSC parameter to
# FDC_format, which writes the specified size code to all physical sectors.
#
# Other than that, only the 12 byte reserve section is readable/writable
by the user.
# The read_id/write_id/search_id functions operate only on that field.
#
# The data can be anything.
#
# On a normal filesystem disk (rather than a raw data disk like the Sardine
# dictionary), the drives built-in filesystem uses this field for one byte:
# 00 = current sector is not used by a file
# ## = sector number of next sector in current file
# FF = current sector is the last sector in current file
# Search for sector ID matching $*
# si <up to 12 hex pairs of ID data>
#
# github.com/bkw777/dl2/blob/master/ref/search_id_section.txt
# Drive requires exactly 12 bytes of data. This right-pads with 0x00
# and truncates to 12 bytes as necessary. So you may ex:
# "si 04" and it will search for "04 00 00 00 00 00 00 00 00 00 00 00"
The matching server function in dl2 is not commented but here it is
https://github.com/bkw777/dl2/blob/0aed893cf86f90600ebe5b7b12686961ce70e9da/main.c#L1228
--
bkw
Any thoughts?
Regards,
Royce
Sent from my iPhone
On Mar 20, 2025, at 06:31, Brian K. White <[email protected]> wrote:
On 3/20/25 08:00, James Reed wrote:
Hi
Now I have the serial port working I'm wanting to move on to some new
challenges.
I had a Tandy 102 and TPDD (I think v1) many years ago, and I wrote a few
programs that I'd like to get access to. I still have the floppy disk and now a
Tandy 102 but I don't have the TPDD.
I have a Greaseweazle and can make an image of the disk, but what I can't work
out is how I can make use of this. All the utilities I've looked at seem to
need you to have the actual hardware to read or write images, and I can't see
any utilities which can extract the actual files.
I'd be grateful for any pointers or if anyone can suggest anything.
James
fluxengine has support for it, and can use the greaseweazel hardware.
I have not tested it.
https://cowlark.com/fluxengine/doc/disk-fb100.html
This will only get you raw sectors not files, but the disk format is well
documented in the software manual, and there are only 40 tracks on the whole
disk, so, you can piece the files back together manually.
http://tandy.wiki/TPDD#Documentation
https://archive.org/details/tandy-service-manual-26-3808-s-software-manual-for-portable-disk-drive/page/n5/mode/2up
It won't be exactly trivial, but I think there are no secrets making it
impossible.
If you want to risk snail-mailing it, I'll just read it in a real drive if you
want.
--
bkw
--
bkw
