18 May
2005
18 May
'05
7:40 a.m.
Tapes are an issue since they're really not a stream of bytes -- there
are tape marks and gaps. The simh virtual tape format seems to be
fairly complete in that respect
--
The big thing missing from the '.tap' format is it assumes all the blocks are
good. There is no way to describe a partially read block, or to encode any of
the CRC or LRC check data that was in the tape block on the physical medium.
18 May
18 May
3:13 p.m.
Re:
The big thing missing from the '.tap' format
is it assumes all the blocks are
good. There is no way to describe a partially read block, or to encode any of
the CRC or LRC check data that was in the tape block on the physical medium.
Ties in with problems I posted about last year in .tap :)
I have my own tape archiver (written on an HP 3000 under MPE/iX).
For each record read I record:
# bytes
any error information (if any)
Setmark (if any) (for DDS)
EOF (if any)
EOT (if any)
(And, I optionally compress the tape data, on a per-record basis,
to minimize .tap file size.)
At the start of the .tap file is a header, which records
the maximum read size I was issuing ... that's *important*
beause with many tape devices, if you have a record of N
bytes and ask to read K (where K < N) bytes, you'll silently
lose data.
Stan
--
Stan Sieler
sieler at allegro.com
www.allegro.com/sieler/wanted/index.html
7159
days inactive
7159
days old
1 comments
2 participants
participants (2)
-
aek＠bitsavers.org -
sieler＠allegro.com