Re: [TUHS] Booting PDP-11's from RX02's

[Eric Smith]

On Tue, Nov 1, 2016 at 3:53 AM, allison  wrote:

> On 10/31/2016 07:45 PM, Al Kossow wrote:
> >
> > On 10/31/16 3:08 PM, Vincent Slyngstad wrote:
> >
> >> Isn't there some weird crap in track 0 on DECmate RX01s
>
> It also has the slushware code, aka front panel space code to do
> stuff on the IM6100 chip and peripherals.  the 6100/6120
> have two spaces front panel code space and normal PDP-8 memory.


Isn't the slushware on the last two tracks of the disk, rather than on
track 0?

Re: [TUHS] Booting PDP-11's from RX02's

[allison]

On 10/31/2016 07:45 PM, Al Kossow wrote:
>
> On 10/31/16 3:08 PM, Vincent Slyngstad wrote:
>
>> Isn't there some weird crap in track 0 on DECmate RX01s

It also has the slushware code, aka front panel space code to do
stuff on the IM6100 chip and peripherals.  the 6100/6120
have two spaces front panel code space and normal PDP-8 memory.


Allison

> It is IBM 3740 table of contents information.
> GA21-9182-5_Diskette_General_Information_Manual_Jul80.pdf for the details
>
>
>
>

Re: [TUHS] Booting PDP-11's from RX02's

[jim stephens]

On 10/31/2016 12:41 PM, allison wrote:

On 10/31/16 3:26 PM, Paul Koning wrote:

On Oct 31, 2016, at 2:58 PM, jim stephens  wrote:

If you cared about not erasing the drive manufacture's data on 
sealed media Winchester and the like you have to avoid any writes to 
cylinder 0 at all.


The drive formatting software could read that cylinder track 0 for a 
defect map.  Nothing to stop you from overwriting it, but you would 
then need to do a local media certification that is more complicated 
than just formatting the drive, and mapping out defective tracks / 
sectors.


I never worked with a system that had a controller or software that 
could read the defect track, so don't know how that was used.  Later 
drives with more intelligence in the drive are another matter, but 
in those cases, the hiding of the defect data can be a task assigned 
to that processor, and don't need magic handling of the addressing.
I haven't seen drives that put the defect data on track 0.  DEC put 
it at the very end of the drive (see DEC Std 144).  And as I recall, 
CDC did likewise in the 844 drives (RP04 lookalikes). As for software 
using that data, RSTS certainly did.


CDC MMD and cmd put the map on cylinder 0.  If you had a design that 
could read the track zero info, you could auto configure between MMD 160 
and MMD80.


Having the defect info on the last cylinder would have worked in that 
case, but in design meetings with the ANSI SCSI committee, the seek to a 
maximum cylinder would have meant the controller would need to know that 
in advance when powering up.


Having the info on cylinder 0 with the defect list would allow for auto 
config.  I don't know that it was used, but I don't recall any 
discussions with the info on the last cylinder, though I'm sure the DEC 
guys would have mentioned it were they in on the discussions.

paul

But its not done (defect mapping) on floppies.  defects on floppies 
are a media or drive issue.
Also drive that grind away track 000 usually have enough gunk on the 
head to take out other tracks.


Only talking about sealed media such ad MFM, SMD winchesters.  I guess 
it wasn't clear.  Maybe the discussion about starting @ track 1 was 
about floppies, and I missed that.



Allison

Re: [TUHS] Booting PDP-11's from RX02's

[Fred Cisin]

If you cared about not erasing the drive manufacture's data on sealed 
media Winchester and the like you have to avoid any writes to cylinder 0 
at all.


On a floppy?

It might not be relevant HERE, but SOME computers have a different 
physical format on track 0 (such as systems that evolved from FM to MFM 
and continued to have track 0 be single density)
Writing to track 0 could be hazardous to whatever is s'posed to be on 
track 0.

Re: [TUHS] Booting PDP-11's from RX02's

[Al Kossow]

On 10/31/16 3:08 PM, Vincent Slyngstad wrote:

> Isn't there some weird crap in track 0 on DECmate RX01s

It is IBM 3740 table of contents information.
GA21-9182-5_Diskette_General_Information_Manual_Jul80.pdf for the details

Re: [TUHS] Booting PDP-11's from RX02's

[Vincent Slyngstad]

   > From: Don North
   > Track 0 is not used by standard DEC software

I wonder why DEC did't use track 0. The thing is small enough (256KB in the
original single-density) that even 1% is a good chunk to throw away. Does
anyone know? (I had a look online, but couldn't turn anything up.)


Isn't there some weird crap in track 0 on DECmate RX01s, which has to be 
written in 8b mode instead of 12b mode?


   Vince 

Re: [TUHS] Booting PDP-11's from RX02's

[allison]

On 10/31/16 3:26 PM, Paul Koning wrote:

On Oct 31, 2016, at 2:58 PM, jim stephens  wrote:

If you cared about not erasing the drive manufacture's data on sealed media 
Winchester and the like you have to avoid any writes to cylinder 0 at all.

The drive formatting software could read that cylinder track 0 for a defect 
map.  Nothing to stop you from overwriting it, but you would then need to do a 
local media certification that is more complicated than just formatting the 
drive, and mapping out defective tracks / sectors.

I never worked with a system that had a controller or software that could read 
the defect track, so don't know how that was used.  Later drives with more 
intelligence in the drive are another matter, but in those cases, the hiding of 
the defect data can be a task assigned to that processor, and don't need magic 
handling of the addressing.

I haven't seen drives that put the defect data on track 0.  DEC put it at the 
very end of the drive (see DEC Std 144).  And as I recall, CDC did likewise in 
the 844 drives (RP04 lookalikes).  As for software using that data, RSTS 
certainly did.

paul

But its not done (defect mapping) on floppies.  defects on floppies are 
a media or drive issue.
Also drive that grind away track 000 usually have enough gunk on the 
head to take out other tracks.


Allison

Re: [TUHS] Booting PDP-11's from RX02's

[allison]

On 10/31/16 2:58 PM, jim stephens wrote:



On 10/30/2016 4:24 PM, Don North wrote:

On 10/30/2016 5:47 AM, Noel Chiappa wrote:

 > From: Don North 

 > .. the hardware bootstrap reads track 1 sectors 1, 3, 5, 7

Ah, thanks for that. Starting to look at the code, I had missed the
interleave.

So does DEC do anything with track 0, or is it always just empty?

Noel

Track 0 is not used by standard DEC software, block zero of the 
device (boot block)
starts at track 1 sector 1. Track 0 is not even accessible thru the 
standard drivers.


Applies to both PDP-11 (eg, XXDP, RT11) and PDP-8 (OS8).

Maybe specific software that reads/writes disks in IBM exchange mode 
accesses

track 0, but I've never used such s/w and am only guessing
If you cared about not erasing the drive manufacture's data on sealed 
media Winchester and the like you have to avoid any writes to cylinder 
0 at all.



Big difference between hard disk and floppy.
Floppy the track 0 is generally used for "system level" things like 
microcode load or boot block.

DEC varied on hardware (system) and OS and drive(media) as to its use.

The drive formatting software could read that cylinder track 0 for a 
defect map.  Nothing to stop you from overwriting it, but you would 
then need to do a local media certification that is more complicated 
than just formatting the drive, and mapping out defective tracks / 
sectors.


I never worked with a system that had a controller or software that 
could read the defect track, so don't know how that was used.  Later 
drives with more intelligence in the drive are another matter, but in 
those cases, the hiding of the defect data can be a task assigned to 
that processor, and don't need magic handling of the addressing.
Every system that had a MFM drive could format all tracks and even 
either enter the printed bad block list or recover it before format.
Most all could discover new bad blocks as well.   The RQDX1/2/3 ca with 
XXDP software and the controller in the Microvax2000
can as well.  THe higher level interfaces like SCSI can if the drive 
permits it or its terminated with a ADAPTEC or Xybec SCSI to
MFM or RLL controller.  All pre-IDE PCs could as well (WD1002/3/4/5/6 
controller with MFM or RLL drive).



Allison

Thanks
Jim

Re: [TUHS] Booting PDP-11's from RX02's

[Paul Koning]

> On Oct 31, 2016, at 2:58 PM, jim stephens  wrote:
> 
> If you cared about not erasing the drive manufacture's data on sealed media 
> Winchester and the like you have to avoid any writes to cylinder 0 at all.
> 
> The drive formatting software could read that cylinder track 0 for a defect 
> map.  Nothing to stop you from overwriting it, but you would then need to do 
> a local media certification that is more complicated than just formatting the 
> drive, and mapping out defective tracks / sectors.
> 
> I never worked with a system that had a controller or software that could 
> read the defect track, so don't know how that was used.  Later drives with 
> more intelligence in the drive are another matter, but in those cases, the 
> hiding of the defect data can be a task assigned to that processor, and don't 
> need magic handling of the addressing.

I haven't seen drives that put the defect data on track 0.  DEC put it at the 
very end of the drive (see DEC Std 144).  And as I recall, CDC did likewise in 
the 844 drives (RP04 lookalikes).  As for software using that data, RSTS 
certainly did.

paul

Re: [TUHS] Booting PDP-11's from RX02's

[jim stephens]

On 10/30/2016 4:24 PM, Don North wrote:

On 10/30/2016 5:47 AM, Noel Chiappa wrote:

 > From: Don North 

 > .. the hardware bootstrap reads track 1 sectors 1, 3, 5, 7

Ah, thanks for that. Starting to look at the code, I had missed the
interleave.

So does DEC do anything with track 0, or is it always just empty?

Noel

Track 0 is not used by standard DEC software, block zero of the device 
(boot block)
starts at track 1 sector 1. Track 0 is not even accessible thru the 
standard drivers.


Applies to both PDP-11 (eg, XXDP, RT11) and PDP-8 (OS8).

Maybe specific software that reads/writes disks in IBM exchange mode 
accesses

track 0, but I've never used such s/w and am only guessing
If you cared about not erasing the drive manufacture's data on sealed 
media Winchester and the like you have to avoid any writes to cylinder 0 
at all.


The drive formatting software could read that cylinder track 0 for a 
defect map.  Nothing to stop you from overwriting it, but you would then 
need to do a local media certification that is more complicated than 
just formatting the drive, and mapping out defective tracks / sectors.


I never worked with a system that had a controller or software that 
could read the defect track, so don't know how that was used.  Later 
drives with more intelligence in the drive are another matter, but in 
those cases, the hiding of the defect data can be a task assigned to 
that processor, and don't need magic handling of the addressing.

Thanks
Jim

Re: [TUHS] Booting PDP-11's from RX02's

[Pete Turnbull]

On 31/10/2016 13:55, Noel Chiappa wrote:

I wonder why DEC did't use track 0. The thing is small enough (256KB in the
original single-density) that even 1% is a good chunk to throw away. Does
anyone know? (I had a look online, but couldn't turn anything up.)

If I had to _guess_, one possibility would be that track 0 is the innermost
track, where the media is moving the slowest, and as a result it's more
error-prone.


Except that track 0 is the outermost track, where the media is moving 
fastest, and therefore perhaps the least error-prone.  Except that for 
many drives, it's where the heads end up after a reset or recalibration, 
and on drives where the heads are (almost) always loaded, the one that 
will wear most.  I've seen floppies with a transparent ring near the 
outer edge, and I'm sure many other listmembers have too.


--
Pete
Pete Turnbull

Re: [TUHS] Booting PDP-11's from RX02's

[Paul Koning]

> On Oct 31, 2016, at 9:55 AM, Noel Chiappa  wrote:
> 
>> From: Don North
> 
>> Track 0 is not used by standard DEC software
> 
> I wonder why DEC did't use track 0. The thing is small enough (256KB in the
> original single-density) that even 1% is a good chunk to throw away. Does
> anyone know? (I had a look online, but couldn't turn anything up.)
> 
> If I had to _guess_, one possibility would be that track 0 is the innermost
> track, where the media is moving the slowest, and as a result it's more
> error-prone. Another is that IBM used track 0 for something special, and DEC
> tried to conform with that. But those are pure guesses, I would love to know
> for sure.

I don't know either.  But for what it's worth, this odd addressing carries over 
to the RX50.  Not exactly, though.  Logical block 0 is the first sector on 
track 1, sectors are 2:1 interleaved, and there's a 3 sector skew from track to 
track.  The difference here is that track 0 does get used: it holds the last 10 
sectors of the logical address space.  In other words, physical track 0 follows 
physical track 79.

paul

Re: [TUHS] Booting PDP-11's from RX02's

[Noel Chiappa]

> From: Don North

> Track 0 is not used by standard DEC software

I wonder why DEC did't use track 0. The thing is small enough (256KB in the
original single-density) that even 1% is a good chunk to throw away. Does
anyone know? (I had a look online, but couldn't turn anything up.)

If I had to _guess_, one possibility would be that track 0 is the innermost
track, where the media is moving the slowest, and as a result it's more
error-prone. Another is that IBM used track 0 for something special, and DEC
tried to conform with that. But those are pure guesses, I would love to know
for sure.

Noel

Re: [TUHS] Booting PDP-11's from RX02's

[Don North]

On 10/30/2016 5:47 AM, Noel Chiappa wrote:

 > From: Don North 

 > .. the hardware bootstrap reads track 1 sectors 1, 3, 5, 7

Ah, thanks for that. Starting to look at the code, I had missed the
interleave.

So does DEC do anything with track 0, or is it always just empty?

Noel


Track 0 is not used by standard DEC software, block zero of the device (boot 
block)
starts at track 1 sector 1. Track 0 is not even accessible thru the standard 
drivers.


Applies to both PDP-11 (eg, XXDP, RT11) and PDP-8 (OS8).

Maybe specific software that reads/writes disks in IBM exchange mode accesses
track 0, but I've never used such s/w and am only guessing.

Re: [TUHS] Booting PDP-11's from RX02's

[Noel Chiappa]

> From: Don North 

> .. the hardware bootstrap reads track 1 sectors 1, 3, 5, 7

Ah, thanks for that. Starting to look at the code, I had missed the
interleave.

So does DEC do anything with track 0, or is it always just empty?

Noel

Re: [TUHS] Booting PDP-11's from RX02's

[Don North]

On 10/29/2016 2:32 PM, Ron Natalie wrote:

I think just like everything else the boot rom just pulls in the first
sector of the disk.   I had RX02s on many of the BRL Gateways (my
implementation that replaced your MIT Gateway while you were in exile).
We put a V6 file system and I must have had a regular V6 boot block on it
with a RX02.   There might be someone still at BRL who might remember where
this stuff is.   I certainly don't have it.

BRL PDP-11 kernels had both V6 and V7 file systems in them but I'd have to
believe I was booting off a V6 one.


For RX01 (and RX02) the hardware bootstrap reads track 1 sectors 1, 3, 5, 7
into memory. For RX01 with 128B sectors this yields 512B total (just like 
reading
one 512B block from most other disks). Their is a fixed 2:1 sector interleave.

For RX02 is does the same sector reads, but since the sectors are 256B the total
amount of data read is 1024B. In reality only sectors 1, 3 need be read, but the
bootstrap (M9312 anyway) just goes ahead and reads all four sectors always.
 

RE: [TUHS] Booting PDP-11's from RX02's

[Ron Natalie]

I think just like everything else the boot rom just pulls in the first
sector of the disk.   I had RX02s on many of the BRL Gateways (my
implementation that replaced your MIT Gateway while you were in exile).
We put a V6 file system and I must have had a regular V6 boot block on it
with a RX02.   There might be someone still at BRL who might remember where
this stuff is.   I certainly don't have it.

BRL PDP-11 kernels had both V6 and V7 file systems in them but I'd have to
believe I was booting off a V6 one.