Rob Doyle wrote:
> One thought that should help: SIMH stores 36-bit data inside a 64-bit
> data word. There is plenty of unused whitespace inside the existing disk
> image. There is no reason for an incompatible change.
Of course! Thank you.
___
Simh
Johnny Billquist wrote:
> The fourth option is to treat this as a normal write. Essentially,
> unless I remember wrong, that is pretty much the end result on real
> hardware.
Agreed. If SIMH was updated to do this, I think SALV would be 99%
happy.
> I've played with a few disks back in the day
> RC25 ...
Thanks, but I was more interested in the details of LESI if they are
available. LESI was another mass storage "bus" that supported both disk and
tape (albeit with exactly one example of each).
RC25s never worked which, if you had an 11/725, was sad :(
Bob
My mistake entirely, I had no idea that such a thing existed but it
certainly did and played some very important roles. I mistakenly assumed
when Bob said that there was no documentation that it could have been a
failed experiment.
-Henry
On Tue, Jun 25, 2019, 20:54 Al Kossow wrote:
>
>
> On
On 6/25/19 5:49 PM, Henry Bent wrote:
> Was it actually used in production
yes
https://en.wikipedia.org/wiki/ROLM
we have one
https://www.computerhistory.org/collections/catalog/102717964
there are youTube videos of it
https://www.youtube.com/watch?v=XvUpfUj7pzA
and there was a 1603
On Tue, 25 Jun 2019 at 20:41, Bob Supnik wrote:
> Rolm & Haas made a militarized Nova-compatible minicomputer called the
> 1602 - a follow on to their 1601 Ruggednova system. It had an extended
> instruction set. I know this because I found the listings for the PDP10
> based 1602 simulator in my
Rolm & Haas made a militarized Nova-compatible minicomputer called the
1602 - a follow on to their 1601 Ruggednova system. It had an extended
instruction set. I know this because I found the listings for the PDP10
based 1602 simulator in my attic tonight. I've never seen any other
> On Jun 25, 2019, at 7:42 PM, Bob Supnik wrote:
>
> The RC25 (code named Aztec) got started as I was leaving Storage Engineering.
> ...
>
> The RC25 was pretty much a disaster, technically and financially, and the end
> of the line for DEC's removable disk program.
It was quite ugly,
I like Johnny's suggestion.
1. On write header, "eat" the two header words and then write normal data.
2. On read header, synthesize the two standard header words and then
read the pack data.
3. On write check header, skip the first two (header) words and then do
a normal write check.
This
The RC25 (code named Aztec) got started as I was leaving Storage
Engineering. Mike Riggle, VP of Storage Advanced Development (and later
Storage Engineering), recognized early on that to improve seek and
rotational performance, disk diameters (14" for the RA8X series) had to
shrink; 8" or 9"
> Bob Supnik [b...@supnik.org] wrote:
>Ah, yes, the Interconnect Task Force. 1980, perhaps?
>
Can you say anything about LESI, "Low End Storage Interconnect"? It was used
by the RC25 and the TU81+ and, AFAIK, that's it. It never really went anywhere
and there's basically no
Ah, yes, the Interconnect Task Force. 1980, perhaps? All my engineering
notebooks are entombed at the Computer History Museum now.
CI - computer interconnect - realized in the passive "star coupler" and
the CIxxx family of interfaces.
BI - backplane interconnect - realized in the BIIC chips -
> 3. Store header words out of band somehow. Last in the image file?
> In another file?
Perhaps the same name as the disk file with a . (dot) in front for the header
words. Ala Mac resource forks or NTFS alternate data streams. Since Unix has
no structure to its files, so you have to use the
Thanks for that insight, Bob.
I wasn't anywhere near DEC when this happened, but it do match my
perceptions of the whole thing very well.
MSCP was definitely an improvement on Massbus in pretty much every way.
Possibly with the exception of if you wanted to throw together some
small piece
On 2019-06-25 13:07, Lars Brinkhoff wrote:
David Brownlee wrote:
How about storing them only in memory - still an incomplete
implementation, but should be enough to pass the SALV tests...
I should clarify that to pass the tests, only the sector data needs to
be written. Rather than ignored
On 2019-06-25 10:32, Lars Brinkhoff wrote:
Mark Pizzolato wrote:
Is the data that is written in the headers by SALV predictable?
It writes the sensible sector geometry information, so that's not a
problem. It also writes the drive serial number to the first key field,
and a user-specified
On 2019-06-25 08:31, Lars Brinkhoff wrote:
Hello,
Some of DEC's disks allow reading and writing the sector headers. ITS'
disk formatting program, SALV (the Salvager), uses this to make a new
file structure on a pack, and to verify its integrity.
This isn't fully supported by SIMH. The file
> On Jun 25, 2019, at 11:43 AM, Bob Supnik wrote:
>
> True. My first assignment at DEC was managing the "New Disk Subsystem" (NDS)
> advanced development project, which led eventually to both the HSC50 and the
> UDA50. Among the goals of the project were
>
> 1. To move ECC correction off
On 6/24/2019 11:31 PM, Lars Brinkhoff wrote:
Hello,
Some of DEC's disks allow reading and writing the sector headers. ITS'
disk formatting program, SALV (the Salvager), uses this to make a new
file structure on a pack, and to verify its integrity.
This isn't fully supported by SIMH. The
True. My first assignment at DEC was managing the "New Disk Subsystem"
(NDS) advanced development project, which led eventually to both the
HSC50 and the UDA50. Among the goals of the project were
1. To move ECC correction off the host and into the disk subsystem, so
that much more powerful
> On Jun 24, 2019, at 5:27 PM, Timothe Litt wrote:
>>
> As is often the case, things turn out to be complicated. Here's a more
> detailed version. In an off-list note, Bob pointed out that MSCP originated
> in a project he managed that was to develop the "next generation" disk
>
David Brownlee wrote:
> How about storing them only in memory - still an incomplete
> implementation, but should be enough to pass the SALV tests...
I should clarify that to pass the tests, only the sector data needs to
be written. Rather than ignored as now.
SALV *also* uses the two key fields
On Tue, 25 Jun 2019 at 07:31, Lars Brinkhoff wrote:
>
> Hello,
>
> Some of DEC's disks allow reading and writing the sector headers. ITS'
> disk formatting program, SALV (the Salvager), uses this to make a new
> file structure on a pack, and to verify its integrity.
>
> This isn't fully
Mark Pizzolato wrote:
> Is the data that is written in the headers by SALV predictable?
It writes the sensible sector geometry information, so that's not a
problem. It also writes the drive serial number to the first key field,
and a user-specified pack number to the second key field. The pack
On 22/06/2019 20:21, paulhar...@btinternet.com wrote:
> My suspicion is that it is memory trampling in the font caching
> implementation in the emulated VCB02 device in SimH. The VCB02 device
> uses the same memory planes for font caches as for screen bitmaps -
> the manual says:
> 1.6.1.1 Font
Hello,
Some of DEC's disks allow reading and writing the sector headers. ITS'
disk formatting program, SALV (the Salvager), uses this to make a new
file structure on a pack, and to verify its integrity.
This isn't fully supported by SIMH. The file PDP10/pdp10_rp.c has the
comment "23-Aug-01
26 matches
Mail list logo
