On 1/8/24 12:22, [email protected] wrote:
The TPDD2 service manual in all of its glory...
https://archive.org/details/tpdd-2-service-manual
<https://archive.org/details/tpdd-2-service-manual>
Jeff Birt
Oh man awesome. A real reference for the error codes and other software
bits...
There is an actual explaination of "mystery command 0x23" !!
https://github.com/bkw777/pdd.sh/blob/6f75515c1c5b8aa74c701c0cf61069c3cd126de2/pdd.sh#L1043
There is an "execute program" command to run arbitrary machine code!
Well we already saw that in tpdd1 right in the bootstrap directions, but
that uses dip switch setting to put the drive into a special mode, while
this is just a normal function like any other.
Already cleared up a few mysteries. A while back I really dug in to
stuff like the TPDD2 sector modes to add to the work KenP and KurtM and
others already did. I was very satisfied to be able to figure some stuff
out that were still unknown, but I was still left with some real mysteries.
What I call "cache_load" pg 96 in the service manual,
is for moving data between the disk media and the drives ram.
(here I say "load" to mean media-to-ram
and unload to mean ram-to-media)
I had:
# 5-byte request data
# 00|02 action 0=load 2=unload
# 00 unknown
# 00-4F track
# 00 unknown
# 00-01 sector
Now I know it is:
# 5-byte request data
# 00-02 action 0=load 1=unload 2=unload+verify
# 00 track MSB (always 00)
# 00-4F track LSB
# 00 side (always 00)
# 00-01 sector
Well, in the end, it's gratifying to see it doesn't change anything,
that although we didn't know what the the two 00 bytes really were,
in the end they never would be any other value and they were being
handled correctly.
Another example, reading data from the drives ram to the client.
(pg 89)
I had:
# 4-byte request data
# 00 area 0=data 1=meta
# 0000-04C0 offset
# 00-FC length
I assumed it was both incomplete and probably wrong for the "meta" mode.
I called the first byte "mode" because it seemed to be some kind of mode
switch where it did two different things depending on that byte,
and now it was in fact called mode.
And I just assumed there might be other modes but nope, just those two.
And what I called "meta" really just means reading from the drives own
working memory vs the disk cache. So although the guesswork label isn't
a good fit, the usage was still right.
It did seem like something like that.
I had assumed that in mode 1 that the 2 bytes in the address or offset
field probably had some other meaning in "meta" mode, but no, it still
means address, just now it's from the cpus working space instead of the
sector buffer.
The "meta" mode I just got from seeing that the backup program uses this
mode to read 4 bytes from a certain address, but using pdd.sh to poke at
the drive and see what it does, I noticed that you can read as many
bytes as you want from any address you want, and get back unknown random
seeming data.
Doesn't really answer all questions. What IS the whole memory map that
those 4 bytes come from, and what even do those 4 bytes mean? Is there
really a larger field that just always happens to be only 4 out of 16
bytes used, or are those 4 bytes all there are? I can clone disks by
copying them, but I still don't know what they mean. I couldn't craft a
totally synthetic sector & metadata for instance like I could for TPDD1.
Anyway it will be very satisfying to update everything to fill in these
little missing mystery bytes in pdd.sh, dl2, & PDDuino.
Thank you for getting this scanned. Nice clean job to, thanks.
--
bkw
