20 Feb
2019
20 Feb
'19
5:38 a.m.
On Feb 19, 2019, at 10:26 PM, Charles Anthony
<charles.unix.pro at gmail.com> wrote:
On Tue, Feb 19, 2019 at 10:14 AM Paul Koning <paulkoning at comcast.net> wrote:
...
You're misinterpreting "spare". MSCP exposes the user address space as
contiguous LBAs, for which it uses 51 sectors per track. The spare sector is used to do
bad sector replacement. That is invisible to users, it doesn't affect the LBA
addressing. dd, like any other host-resident code, sees the user address space. It will
copy MSCP devices correctly.
paul
So indeed the correct sector count is 51 (the
other one is a spare, a technique used by DEC as far back as the RM80).
I am concerned that the spare is the issue. If the track has 52 sectors, and one is
reserved as a spare, is that spare included in the LBA calculation? If it is, then SIMH is
wrong; the first sector of the second track written in the spare sector, throwing all of
the remaining data out of alignment, with the symptom of RSTS booting but not being able
to find INIT.SYS.
If the spare sector exists and SIMH is not allocation space for it, then the disk image
will not copy correctly with 'dd'. (However, dd might be coereced into doing the
right thing with 'dd if=... of=... ibs=26112 obs=26624'; reading 512*51 byte
records (a SIMH track) and writing 512*52 byte records (a RA81 h/w track)).
-- Charles