Re: 2.11BSD on two RL02 drives? Probably not, but...

[emanuel stiebler via cctalk]

On 2017-08-05 08:55, David Bridgham via cctalk wrote:

On 8/5/17 04:29, emanuel stiebler wrote:



Xilinx Artix 7.  More specifically, we're using a ZTEX 2.13 FPGA module
for our prototyping.  Unless some good reason came up, I was thinking to
stick with the same FPGA.


Artix 7? Nice, use them a lot.

Vivado or ISE?


Vivado.  Another huge learning experience.  Does ISE even support the
Artix 7?


IIRC, the -100t and 200t were/are supported on ISE. But it isn't worth 
it. If you use artix, get the latest vivado ...


I didn't like to switch either, but in the meantime, starting with the 
last years releases it became more useful than ISE.

Re: 2.11BSD on two RL02 drives? Probably not, but...

[David Bridgham via cctalk]

On 8/5/17 04:29, emanuel stiebler wrote:


>> Xilinx Artix 7.  More specifically, we're using a ZTEX 2.13 FPGA module
>> for our prototyping.  Unless some good reason came up, I was thinking to
>> stick with the same FPGA.
>
> Artix 7? Nice, use them a lot.
>
> Vivado or ISE?

Vivado.  Another huge learning experience.  Does ISE even support the
Artix 7?

Re: 2.11BSD on two RL02 drives? Probably not, but...

[emanuel stiebler via cctalk]

On 2017-08-04 18:12, David Bridgham via cctalk wrote:

On 8/4/17 11:25, emanuel stiebler wrote:



What FPGAs are you using?


Xilinx Artix 7.  More specifically, we're using a ZTEX 2.13 FPGA module
for our prototyping.  Unless some good reason came up, I was thinking to
stick with the same FPGA.


Artix 7? Nice, use them a lot.

Vivado or ISE?

Re: 2.11BSD on two RL02 drives? Probably not, but...

[Christian Corti via cctalk]

On Fri, 4 Aug 2017, Guy Sotomayor Jr wrote:
Unfortunately PATA drives are becoming difficult to find and designing a 
SATA interface (not to mention layout issues) is not for the faint of 
heart.


That's why I suggest using dirt cheap external PATA<-->SATA bridges.

Christian

Re: 2.11BSD on two RL02 drives? Probably not, but...

[David Bridgham via cctalk]

On 8/4/17 11:25, emanuel stiebler wrote:

> http://ww1.microchip.com/downloads/en/DeviceDoc/1678B.pdf
> that the one I use a lot...

Oh, a USB PHY chip.  Yeah, that might be the way to go now that we're
not counting I/O pins.

>> 1:1 block mapping.  I'm going to have enough fun with trying to
>> implement the USB stack in the FPGA without doing FAT16 too.
>
> Yikes ;-)

Yeah, I know.  Partly it's a challenge and partly it's something I'd
like to have around for another project.

> Please do yourself a favor, and put a small micr0controller in the FPGA.
> Get it working, then you can optimize and write HDL for it.

We've talked about a soft microcontroller, an actual microcontroller,
and just writing it in some sort of microcode.  Want to get the SD card
working first so Noel can start using the prototype board as an actual
storage device.

> What FPGAs are you using?

Xilinx Artix 7.  More specifically, we're using a ZTEX 2.13 FPGA module
for our prototyping.  Unless some good reason came up, I was thinking to
stick with the same FPGA.

Re: 2.11BSD on two RL02 drives? Probably not, but...

[Guy Sotomayor Jr via cctalk]

> On Aug 4, 2017, at 1:27 PM, ben via cctalk  wrote:
> 
> On 8/4/2017 12:49 PM, Warner Losh via cctalk wrote:
>> On Fri, Aug 4, 2017 at 12:36 PM, Al Kossow via cctalk >> wrote:
>>> 
>>> 
>>> On 8/4/17 11:14 AM, Warner Losh via cctalk wrote:
 most SD cards can easily handle 100-200 writes
>>> 
>>> The issue would be things like the swap partition on a unix disk
>>> or whatever the equivalent is under RSX
>>> 
>> Right. But since Flash devices have a FTL that translates writes to new
>> locations in the NAND each time a logical block is written, there's no
>> issue here. This issue with swap hasn't been an issue with NAND flash since
>> early ~8MB CF cards (which is now almost 20 year old technology).
>> I have a lot of miles using CF and SD cards in embedded systems, using both
>> commercial grade and industrial parts since 2000 or so. I find it hard to
>> believe that RSX could generate 128GB of data enough times, even in a
>> swapping environment, to wear a card like that out. Even a more modest 8GB
>> would take a while to wear out under 100% write workload, which swapping
>> never is (since there's always readback for at least some of the pages
>> swapped out). Though I did base my computations on 1MB/s being the fastest
>> that Q-Bus can go, but that was my remembered performance from 3 decades
>> ago since I couldn't find an answer to that question with a quick google. I
>> shipped systems that were 100's if not 1000's times faster than the
>> pdp-11's that could generate much more data traffic to SD and CF cards, and
>> had very very few CF cards wear out. SD cards when we shipped needed to be
>> not the smallest capacity on the market to do well and even there only a
>> few cards wore out while I was doing this with them...
>> Warner
> 
> With everything @ 3.3 volts, you might as well use a ram dick cache
> and back up dirty blocks on power fail, or power down, or reboot, as
> a small battery would last forever, while main system is down.
> 
> 

Use MRAM (non-volatile) and behaves just as well as SRAM.  That way you don’t
have to deal with the battery issues.

TTFN - Guy

Re: 2.11BSD on two RL02 drives? Probably not, but...

[ben via cctalk]

On 8/4/2017 12:49 PM, Warner Losh via cctalk wrote:

On Fri, Aug 4, 2017 at 12:36 PM, Al Kossow via cctalk 

Re: 2.11BSD on two RL02 drives? Probably not, but...

[Paul Koning via cctalk]

> On Aug 4, 2017, at 3:46 PM, Noel Chiappa via cctalk  
> wrote:
> 
>> From: David Bridgham dab at froghouse.org 
> 
>> I'm going to have enough fun with trying to implement the USB stack in
>> the FPGA
> 
> ISTR discussing putting a PDP-11 into the FPGA (there are Verilog PDP-11's
> available), so we could write our USB code in C (I'd use the Unix V6 compiler
> to compile it, of course :-).

That's a possibility.  I've thought about using a rough approximation of a CDC 
6000 series PPU for this sort of stuff, since it's a nice small instruction set 
(and I have the VHDL for it already...)  A more likely answer would be to find 
a working Forth FPGA model and use that.

> ...
> I suspect the disk drive itself may be a big factor there. E.g. the PDP-11
> Peripherals Handbook lists the RK05 speed as 11 usec/word, so about 1.5
> Mbit/second.
> 
> But I _know_ the UNIBUS is a lot faster than that; to verify that, look at
> the speed of non-cache PDP-11s (on which most instructions are
> memory-bandwidth - AKA UNIBUS bandwidth - limited).

A useful data point to remember is that a Unibus cannot quite keep up with an 
Ethernet (10 Mb/s original one) receiving packets flat out.  If I remember 
right, Q-bus can, at least Q22 with its bust mode.  

paul

Re: 2.11BSD on two RL02 drives? Probably not, but...

[Noel Chiappa via cctalk]

> From: David Bridgham dab at froghouse.org 

> I'm going to have enough fun with trying to implement the USB stack in
> the FPGA

ISTR discussing putting a PDP-11 into the FPGA (there are Verilog PDP-11's
available), so we could write our USB code in C (I'd use the Unix V6 compiler
to compile it, of course :-).


> From: Phil Blundell

> I doubt you really need the hard gold fingers on a prototype board.

Good point...

> Not that I've ever actually built a Unibus card though so perhaps there
> is some complexity or something especially hostile about the sockets
> that I'm not realising.

Nah, not that I can think of.


> From: Emanuel Stiebler

> From an old email from Tim Shoppa who tested some QBUS SCSI controllers:
> ...
> Here are the peak data rates measured

I suspect the disk drive itself may be a big factor there. E.g. the PDP-11
Peripherals Handbook lists the RK05 speed as 11 usec/word, so about 1.5
Mbit/second.

But I _know_ the UNIBUS is a lot faster than that; to verify that, look at
the speed of non-cache PDP-11s (on which most instructions are
memory-bandwidth - AKA UNIBUS bandwidth - limited).

And even if not, the controller may have been engineered to not use
more than a certain %-age of the bus, to avoid blowing the CPU out of
the water when it starts running.

The 'maximum bus bandwith' is a very tricky concept - how much do you leave
for the CPU, how many DMA cycles do you do per bus acquisition, etc, etc.

Noel

Re: 2.11BSD on two RL02 drives? Probably not, but...

[emanuel stiebler via cctalk]

On 2017-08-04 15:18, Phil Blundell via cctalk wrote:

On Fri, 2017-08-04 at 15:04 -0400, Noel Chiappa via cctalk wrote:


And this path allowed us to get rolling without having to go through
the PC-board fab cycle... (including the complexity of doing boards
with gold fingers).


Just as an aside on that, I doubt you really need the hard gold fingers
on a prototype board.  You do need something to stop the copper from
tarnishing, and hard gold is almost certainly the most durable option,
but I can't think of any obvious reason that an ENIG or immersion
silver finish wouldn't work just fine on the fingers for a moderate
number of insertions.

I second that one. Most of the time, your card sits on the adapter 
board, so if you break anything, it would be the connectors on the 
extender. So make it cheap, you will need few shots at it ...

Re: 2.11BSD on two RL02 drives? Probably not, but...

[emanuel stiebler via cctalk]

On 2017-08-04 15:15, David Bridgham via cctalk wrote:

On 8/4/17 10:46, emanuel stiebler via cctalk wrote:



Definitely I'll stick with 12Mb/s USB to start (for sure on our
wire-wrapped prototype board) but I'd love to boost that to 480Mb/s
later.  The analog issue is one thing that made me dubious about going
to high-speed but also whether the FPGA without special serial hardware
can go that fast.  If it can, fantastic.  I'll take all the pointers I
can get.


http://ww1.microchip.com/downloads/en/DeviceDoc/1678B.pdf
that the one I use a lot...


You use container files in fat16, or simply 1:1 block mapping?


1:1 block mapping.  I'm going to have enough fun with trying to
implement the USB stack in the FPGA without doing FAT16 too.


Yikes ;-)

Please do yourself a favor, and put a small micr0controller in the FPGA.
Get it working, then you can optimize and write HDL for it.

What FPGAs are you using?


I agree some how with your approach, but it leads to debugging of
issues, you wouldn't have on real boards ...


No doubt.  It's been a learning experience and we still have a long ways
to go.


You will learn a lot on this way ...

Re: 2.11BSD on two RL02 drives? Probably not, but...

[David Bridgham via cctalk]

On 8/4/17 11:16, emanuel stiebler via cctalk wrote:

> Use the memory as disk cache locally. Otherwise you need to write
> drivers for all different versions of OSs out there. Transparent cache,
> write through ...
>
> Then no changes are needed on the system

Well, we are going to make the RAM look like an RK05 or RP03 so no
changes should be needed to the OS drivers.

I thought briefly about putting in caching but then the whole issue
arises of when I issue the interrupt is the write actually complete? 
The old systems expect that, I believe, and I'm not sure I'm ready to
break that assumption.  In any case, any serious consideration of
caching is also for later.  That's a software/firmware update.  :-)

Dave

Re: 2.11BSD on two RL02 drives? Probably not, but...

[emanuel stiebler via cctalk]

On 2017-08-04 14:54, Noel Chiappa via cctalk wrote:


> From: Warner Losh

> had problems finding out just how fast Q-Bus can go

Something like 700 nsec for a cycle (best case), so assuming 16-bit
transfers, a max of a little over 20 Mbit/sec.


From an old email from tim Shoppa who tested some QBUS SCSI controllers:

- cut --

I did (and published) some benchmarks of SCSI MSCP-emulating
controllers probably a decade ago. And indeed the CMD CQD 440 was the
winner. But they all beat the pants off a RQDX3!

Here are the peak data rates measured for read and write 64
blocks-at-a-time:


Read Write
-- --
Andromeda SCDC 2.298 MB/s 1.131 MB/s
CMD CQD440 2.397 MB/s 1.525 MB/s
CMD CQD220 1.418 MB/s 0.882 MB/s
CMD CQD220A 2.088 MB/s 1.409 MB/s
DEC RQZX1 1.379 MB/s 1.097 MB/s
Viking QDT 0.846 MB/s 0.704 MB/s
DEC RQDX3 0.164 MB/s 0.161 MB/s

The benchmarks were done under RT11FB 5.7 doing 1, 2, 4, 8, 16,
32, and 64 block-at-a-time READW's and WRITW's to 16384-block
data files. A KDJ11B (PDP-11/73) CPU with 2 Megabytes of Clearpoint
non-PMI memory was used for the bencharmks. With the SCSI
controllers a Barracuda 7200 RPM ST15230N drive was used; with
the RQDX3 a RD52 drive was used.

Re: 2.11BSD on two RL02 drives? Probably not, but...

[Phil Blundell via cctalk]

On Fri, 2017-08-04 at 15:04 -0400, Noel Chiappa via cctalk wrote:
> 
> And this path allowed us to get rolling without having to go through
> the PC-board fab cycle... (including the complexity of doing boards
> with gold fingers).

Just as an aside on that, I doubt you really need the hard gold fingers
on a prototype board.  You do need something to stop the copper from
tarnishing, and hard gold is almost certainly the most durable option,
but I can't think of any obvious reason that an ENIG or immersion
silver finish wouldn't work just fine on the fingers for a moderate
number of insertions.

Not that I've ever actually built a Unibus card though so perhaps there
is some complexity or something especially hostile about the sockets
that I'm not realising.

p.

Re: 2.11BSD on two RL02 drives? Probably not, but...

[Warner Losh via cctalk]

On Fri, Aug 4, 2017 at 1:04 PM, Noel Chiappa via cctalk <
cctalk@classiccmp.org> wrote:

>  > From: Paul Koning
>
> > flash storage devices do wear leveling. The fact that you're writing
> to
> > the same block number doesn't mean you're actually writing to the
> same
> > spot on the physical flash memory.
>
> Yeah, but why 'waste' writes on swapping/paging activity, if there's a
> RAM-disk ready to hand?
>

True. RAM is always preferred.

Just that at 20MB/s it would take a long time to write the 10TB-100TB of
data you can write to SD cards these days. 10TB of data takes ~130 days to
write at 20MB/s. 100TB takes almost 4 years. And you're rarely doing 100%
writes, so the effective rate over the long haul would be 10x or 100x
smaller than the theoretical max.

Warner

Re: 2.11BSD on two RL02 drives? Probably not, but...

[emanuel stiebler via cctalk]

On 2017-08-04 15:04, Noel Chiappa via cctalk wrote:


> From: Paul Koning

> flash storage devices do wear leveling. The fact that you're writing to
> the same block number doesn't mean you're actually writing to the same
> spot on the physical flash memory.

Yeah, but why 'waste' writes on swapping/paging activity, if there's a
RAM-disk ready to hand?


Use the memory as disk cache locally. Otherwise you need to write 
drivers for all different versions of OSs out there. Transparent cache,

write through ...

Then no changes are needed on the system

Re: 2.11BSD on two RL02 drives? Probably not, but...

[David Bridgham via cctalk]

On 8/4/17 10:46, emanuel stiebler via cctalk wrote:

>> > USB with 480MHz is fast enough
>>
>> I think our plan was to skip that speed, and go with the next one down,
> Probably sufficient for a start ...
> > on
>> the grounds that the analog part at that speed would be too tricky
>> for us.
>
> No, it isn't.

Definitely I'll stick with 12Mb/s USB to start (for sure on our
wire-wrapped prototype board) but I'd love to boost that to 480Mb/s
later.  The analog issue is one thing that made me dubious about going
to high-speed but also whether the FPGA without special serial hardware
can go that fast.  If it can, fantastic.  I'll take all the pointers I
can get.

> You use container files in fat16, or simply 1:1 block mapping?

1:1 block mapping.  I'm going to have enough fun with trying to
implement the USB stack in the FPGA without doing FAT16 too.

> I agree some how with your approach, but it leads to debugging of
> issues, you wouldn't have on real boards ...

No doubt.  It's been a learning experience and we still have a long ways
to go.

Dave

Re: 2.11BSD on two RL02 drives? Probably not, but...

[Noel Chiappa via cctalk]

> From: Emanuel Stiebler

>> on the grounds that the analog part at that speed would be too tricky
>> for us.

> No, it isn't.

You _are_ talking to two people who are so clueless about analog that we
didn't bother putting ground lines between each pair of signal lines in a
cable... ;-)

> You use container files in fat16, or simply 1:1 block mapping?

Haven't gotten that far yet. Probably the latter. (Implementing FAT in
Verilog no, I don't think so! :-)

> your approach, but it leads to debugging of issues, you wouldn't have
> on real boards ...

Yes, but if we tried to go straight to PC boards, we'd almost certainly have
had other issues, just different ones! (See above... :-)

And this path allowed us to get rolling without having to go through the
PC-board fab cycle... (including the complexity of doing boards with gold
fingers).


> From: Paul Koning

> flash storage devices do wear leveling. The fact that you're writing to
> the same block number doesn't mean you're actually writing to the same
> spot on the physical flash memory.

Yeah, but why 'waste' writes on swapping/paging activity, if there's a
RAM-disk ready to hand?

Noel

Re: 2.11BSD on two RL02 drives? Probably not, but...

[Warner Losh via cctalk]

On Fri, Aug 4, 2017 at 12:47 PM, Paul Koning via cctalk <
cctalk@classiccmp.org> wrote:

>
> > On Aug 4, 2017, at 2:36 PM, Al Kossow via cctalk 
> wrote:
> >
> >
> >
> > On 8/4/17 11:14 AM, Warner Losh via cctalk wrote:
> >> most SD cards can easily handle 100-200 writes
> >
> > The issue would be things like the swap partition on a unix disk
> > or whatever the equivalent is under RSX
>
> Probably not, because flash storage devices do wear leveling.  The fact
> that you're writing to the same block number doesn't mean you're actually
> writing to the same spot on the physical flash memory.
>

They must do wear leveling. The NAND erase block sizes are in the MB, while
the page size is a more modest 4-16kb. If you write 512 byte block, it's
not going to re-write the entire erase block since that's too slow, which
is the only way it would remain in the same physical location. Plus, since
erase blocks are good for between hundreds and thousands of writes each,
this would wear out a drive super-fast. So nobody does that (I had 3 years
writing NAND FTL for Fusion I/O), instead they create a write log and map
the logical pages into that. That's what spreads the wear around (that, and
garbage collection to deal with NAND data retention issues, plus to
compress the data). With TLC parts pushing the number of writes down into
the few hundred range, all these tricks become even more critical. And TLC
parts get the high-capacity parts to market, so they put of a lot of burden
on the sw to do the right thing...

Warner

Re: 2.11BSD on two RL02 drives? Probably not, but...

[Noel Chiappa via cctalk]

> From: Al Kossow

> The issue would be things like the swap partition on a unix disk or
> whatever the equivalent is under RSX

Which is why, as I mentioned, that we're including the ability to have
virtual disks which store their data in RAM, not on permanent storage - their
contents won't last throught a power cycle, but for paging/swapping that's
fine.

Also, on Unix, /tmp, and pipes - both sources of lots of writes that don't
need to be saved across power cycles - although the latter will require a tiny
system tweak, to move it off the root partition.

(It's like a one line change - refer to 'pipedev' instead of 'rootdev' in
pipe(). And a tiny system call to set 'pipedev', and a command to call it.
I'd rather do it that way, instead of just adding 'pipedev' to c.c, since one
doesn't want to switch to the RAM disk until one has 'mkfs'd a file system
on it.)


> From: Warner Losh

> had problems finding out just how fast Q-Bus can go

Something like 700 nsec for a cycle (best case), so assuming 16-bit
transfers, a max of a little over 20 Mbit/sec.

Noel

Re: 2.11BSD on two RL02 drives? Probably not, but...

[emanuel stiebler via cctalk]

On 2017-08-04 14:38, Warner Losh via cctalk wrote:

On Fri, Aug 4, 2017 at 12:18 PM, Noel Chiappa via cctalk <
cctalk@classiccmp.org> wrote:


> USB with 480MHz is fast enough

I think our plan was to skip that speed, and go with the next one down, on
the grounds that the analog part at that speed would be too tricky for us.



I did some googling, and had problems finding out just how fast Q-Bus can
go.


From the top of my head (which is not reliable at this temperature) it 
is either 3mbyte/s or 3mword/s ...

Re: 2.11BSD on two RL02 drives? Probably not, but...

[Paul Koning via cctalk]

> On Aug 4, 2017, at 2:36 PM, Al Kossow via cctalk  
> wrote:
> 
> 
> 
> On 8/4/17 11:14 AM, Warner Losh via cctalk wrote:
>> most SD cards can easily handle 100-200 writes
> 
> The issue would be things like the swap partition on a unix disk
> or whatever the equivalent is under RSX

Probably not, because flash storage devices do wear leveling.  The fact that 
you're writing to the same block number doesn't mean you're actually writing to 
the same spot on the physical flash memory.

paul

Re: 2.11BSD on two RL02 drives? Probably not, but...

[emanuel stiebler via cctalk]

On 2017-08-04 14:18, Noel Chiappa via cctalk wrote:


Exactly our plan (although the USB is left until after we get the SD running).

> USB with 480MHz is fast enough

I think our plan was to skip that speed, and go with the next one down,

Probably sufficient for a start ...
> on

the grounds that the analog part at that speed would be too tricky for us.


No, it isn't.


> the old 3v3 level, spi-derivative is very simple to implement. The
> 4-bit mode takes a little longer

I think we're using the SPI at the moment, not the 4-bit (we discussed both,
but I _think_ we went with the one-bit to start with), but I could be wrong -
Dave will hopefully pipe up if I blew that one.


You use container files in fat16, or simply 1:1 block mapping?


IIRC our reasoning was that the SPI was the very simplest one to do, for an
initial implementation; if we later need the speed, and go to the 4-bit, all
the init/etc will already be working.


Sure.


> Did you wire-wrap this thing?

Yes (for one card out of two - below), but that wasn't the problem.

The problem is that we're using two cards (one to plug into the QBUS, and one
with the FPGA on it - surprise, surprise, nobody makes an FPGA protyping card
that plugs into a QBUS :-), and the two are connected with a cable; it was
the cable that was causing the noise (cross-talk - we neglected to put a
ground line between each pair of signal lines).


I agree some how with your approach, but it leads to debugging of 
issues, you wouldn't have on real boards ...

Re: 2.11BSD on two RL02 drives? Probably not, but...

[Warner Losh via cctalk]

On Fri, Aug 4, 2017 at 12:18 PM, Noel Chiappa via cctalk <
cctalk@classiccmp.org> wrote:

> > USB with 480MHz is fast enough
>
> I think our plan was to skip that speed, and go with the next one down, on
> the grounds that the analog part at that speed would be too tricky for us.


I did some googling, and had problems finding out just how fast Q-Bus can
go.

Warner

Re: 2.11BSD on two RL02 drives? Probably not, but...

[Al Kossow via cctalk]

On 8/4/17 11:14 AM, Warner Losh via cctalk wrote:
> most SD cards can easily handle 100-200 writes

The issue would be things like the swap partition on a unix disk
or whatever the equivalent is under RSX

Re: 2.11BSD on two RL02 drives? Probably not, but...

[ben via cctalk]

On 8/4/2017 8:07 AM, Christian Corti via cctalk wrote:

On Fri, 4 Aug 2017, Noel Chiappa wrote:
But are SD cards really that unreliable? If they were, I'd have 
thought I'd


Yes they are. Just have look around in the world of cameras and 
smartphones where people suffer from losing their photos just because an 
SD card decides to fail. I have several failed SD and CF cards, as well 
as USB bars. And many flash cards will fall into a read-only mode when 
errors cannot be corrected anymore, in contrast to real disk drives 
where you can skip the bad areas.


I just had a look on some datasheets for industrial SD cards. ATP gives 
a value of 384 TBW (terabytes written) for SLC and 38.4 TBW for MLC 
devices. For a 32 GB SD card, this means a max. write count of 12,000 
for a byte. SanDisk give 192 TBW for their Industrial XT, that is even 
worse. A 64 GB SD card would only support 3000 writes per byte before 
you begin to play roulette...


S... here I come again with my preference of PATA/SATA drives. If 
you really want a non-rotating media, then I suggest that you use SATA 
SSDs.

Hence why I prefer a controller/interface with PATA/SATA connectors ;-)
You are totally free in using rotating or non-rotating media.

Christian



But where do find Industrial SD cards?
Even so, for most of DEC's PDP's they do so much core memory to disk
swapping of pages that better design to replace rotating media is needed.
Ben.

Re: 2.11BSD on two RL02 drives? Probably not, but...

[Warner Losh via cctalk]

On Fri, Aug 4, 2017 at 11:17 AM, David Bridgham via cctalk <
cctalk@classiccmp.org> wrote:
>
> So my question is: do industrial SD cards exist?
>

Yes. They have for about a decade. Almost all SD cards these days could
easily handle an I/O write rate that a PDP-11 is able to generate. It takes
about 30 days for a PDP-11 to generate enough traffic to fill a large SD
card, and most SD cards can easily handle 100-200 writes, which puts the
time to wear out a card in the decade plus range for 100% write duty cycle.

Warner

Re: 2.11BSD on two RL02 drives? Probably not, but...

[emanuel stiebler via cctalk]

On 2017-08-04 14:01, Noel Chiappa via cctalk wrote:

> From: Al Kossow

> but it looks like they are going EOL

Is that just this particular product (individual SD/etc products seem to go
out all the time, as new and bigger ones come out), or industrial SD cards in
general? I hope not that latter, that would blow a large hole in out strategy!


Don't worry, they stay around. Automotive/Industrial will be there for a 
while...



(Although we are going to include RAM disks as well, using the on-board RAM,
and suggest people configure their systems to do swapping/paging off the RAM
disk, to avoid wasting writes on 'temporary' data - although of course the
RAM disk should be faster, too.)


Now, we have to define on which system you are measuring it.
(pdp11/vax, local memory like 11/53 or 11/93?, etc.)

Re: 2.11BSD on two RL02 drives? Probably not, but...

[Noel Chiappa via cctalk]

> From: Al Kossow

> but it looks like they are going EOL

Is that just this particular product (individual SD/etc products seem to go
out all the time, as new and bigger ones come out), or industrial SD cards in
general? I hope not that latter, that would blow a large hole in out strategy!

(Although we are going to include RAM disks as well, using the on-board RAM,
and suggest people configure their systems to do swapping/paging off the RAM
disk, to avoid wasting writes on 'temporary' data - although of course the
RAM disk should be faster, too.)

Noel

Re: 2.11BSD on two RL02 drives? Probably not, but...

[emanuel stiebler via cctalk]

On 2017-08-04 13:51, Noel Chiappa via cctalk wrote:

> From: Paul Koning

>> do industrial SD cards exist?

> If you have a ready-made SD interface, these cards work nicely. If you
> need to build one from scratch it gets tricky, because the interface is
> fairly high speed serial (packet based) signaling, and the
> initialization sequence before you can do any I/O is fairly convoluted.

I'm not clear, reading this, if they use the standard SD-interface?

Yes.
Actually, whatever "standard" you just refer to. But the old 3v3 level, 
spi-derivative is very simple to implement. The 4-bit mode takes a 
little longer, the full speed 4-bit mode needs a nice layout.


If so, yes, it's non-trivial to interface to (as I previously mentioned, Dave
and I wound up defining a uengine, and writing a uassembler to produce code
for it, after Dave decided trying to do the init with a state machine was too
much pain).


Bit-Bang the setup, then think about DMA.


> It is reasonably well documented in the SD standard, but still, it
> takes a while to get all the code working. BTDT.

Tell _us_ about it! :-) (Of course, that issue we had with noise, and the
wierd latching inputs, made it even more painful...)


Really? Did you wire-wrap this thing?
;-)

Cheers

Re: 2.11BSD on two RL02 drives? Probably not, but...

[emanuel stiebler via cctalk]

On 2017-08-04 13:17, David Bridgham via cctalk wrote:


I don't think I'm up to going with a higher-end FPGA and trying to
implement SATA even though in many ways I think that's the right
answer.  If there's a SATA PHY chip, that's a maybe.


Forget about SATA, even if some people like it here;-)

If I would do it again, it would be USB only with some sd-card slots.
Why USB? Because then you can attach whatever you want, and you
have to write the USB stack only once, and then just improve.
And, USB with 480MHz is fast enough for the 3mbyte/s transfers on the 
QBUS/UNIBUS ...


And if you are really crazy or adventurous, put M2 modules on board ;-)

Re: 2.11BSD on two RL02 drives? Probably not, but...

[Noel Chiappa via cctalk]

> From: Paul Koning

>> do industrial SD cards exist?

> If you have a ready-made SD interface, these cards work nicely. If you
> need to build one from scratch it gets tricky, because the interface is
> fairly high speed serial (packet based) signaling, and the
> initialization sequence before you can do any I/O is fairly convoluted.

I'm not clear, reading this, if they use the standard SD-interface?

If so, yes, it's non-trivial to interface to (as I previously mentioned, Dave
and I wound up defining a uengine, and writing a uassembler to produce code
for it, after Dave decided trying to do the init with a state machine was too
much pain).

> It is reasonably well documented in the SD standard, but still, it
> takes a while to get all the code working. BTDT.

Tell _us_ about it! :-) (Of course, that issue we had with noise, and the
wierd latching inputs, made it even more painful...)

Noel

Re: 2.11BSD on two RL02 drives? Probably not, but...

[Al Kossow via cctalk]

On 8/4/17 10:34 AM, Phil Blundell via cctalk wrote:
> On Fri, 2017-08-04 at 09:17 -0800, David Bridgham via cctalk wrote:
>>
> So my question is: do industrial SD cards exist?
> 
> Yes they do.  Most of the big card manufacturers have an "industrial"
> range, for example:
> 
> https://www.sandisk.co.uk/oem-design/industrial/industrial-cards
> 


http://www.mouser.com/ProductDetail/SanDisk/SDSDAF-008G-XI/?qs=sGAEpiMZZMvJkDqKJH80dC3%2fakMVSTdqYK7SBaJv5DM%3d

but it looks like they are going EOL

Re: 2.11BSD on two RL02 drives? Probably not, but...

[Phil Blundell via cctalk]

On Fri, 2017-08-04 at 09:17 -0800, David Bridgham via cctalk wrote:
> 
So my question is: do industrial SD cards exist?

Yes they do.  Most of the big card manufacturers have an "industrial"
range, for example:

https://www.sandisk.co.uk/oem-design/industrial/industrial-cards

There are also specialist vendors who offer SLC cards.  For example:

https://swissbit.com/products/nand-flash-products/cards/sd-memory-cards
/

You can buy the Swissbit cards at Farnell.  I'm not sure if the Sandisk
industrial ones are easily available in small quantities.

Phil

Re: 2.11BSD on two RL02 drives? Probably not, but...

[David Bridgham via cctalk]

On 8/4/17 09:26, Paul Koning wrote:

>> So my question is: do industrial SD cards exist?
> Yes; we've been using them for years now in the products I work on.  While 
> you can still wear them out if you beat on them hard enough, they do have 
> good reliability.

Okay, that's good news then.  Any suggestions on what to look for when
looking for these SD cards?  That is, how to reliably distinguish them
from consumer grade?

> If you have a ready-made SD interface, these cards work nicely.  If you need 
> to build one from scratch it gets tricky, because the interface is fairly 
> high speed serial (packet based) signaling, and the initialization sequence 
> before you can do any I/O is fairly convoluted.  It is reasonably well 
> documented in the SD standard, but still, it takes a while to get all the 
> code working.  BTDT.

Yeah, I'm in the middle of figuring all that out.  I got it running
through the initialization sequence (as far as I can tell) and as soon
as I get home from my summer job I'll start working on doing data transfers.

Dave

Re: 2.11BSD on two RL02 drives? Probably not, but...

[Paul Koning via cctalk]

> On Aug 4, 2017, at 1:17 PM, David Bridgham via cctalk  
> wrote:
> 
> ...
> So my question is: do industrial SD cards exist?

Yes; we've been using them for years now in the products I work on.  While you 
can still wear them out if you beat on them hard enough, they do have good 
reliability.

If you have a ready-made SD interface, these cards work nicely.  If you need to 
build one from scratch it gets tricky, because the interface is fairly high 
speed serial (packet based) signaling, and the initialization sequence before 
you can do any I/O is fairly convoluted.  It is reasonably well documented in 
the SD standard, but still, it takes a while to get all the code working.  BTDT.

paul

Re: 2.11BSD on two RL02 drives? Probably not, but...

[David Bridgham via cctalk]

On 8/4/17 05:49, systems_glitch via cctalk wrote:

> Going with SLC/"industrial" Flash is indeed the key to avoiding random
> failures. I have many deployed systems using industrial Flash modules (IDE
> DOMs)

As Noel said, he initially talked using an IDE interface for the QSIC. 
I proposed SD cards to solve two problems.  First is that we were
worried about FPGA I/O pins.  Since we've decided we'll have to go with
a BGA part anyway, that problem has been dealt with (though we'd have to
think about how to wire it into the prototype board we have).   The
second was the 5V/3.3V issue.  Obviously that's fixable, we had to do so
for the QBUS interface, but it's always easier to not.

Dave Conroy told me about using these industrial flash IDE modules on
his PDP-10/x and running them on 3.3V.  That's great except it does
nothing for the people who want to run their old stock of IDE disks.

So my question is: do industrial SD cards exist?

I don't think I'm up to going with a higher-end FPGA and trying to
implement SATA even though in many ways I think that's the right
answer.  If there's a SATA PHY chip, that's a maybe.

Dave

Re: 2.11BSD on two RL02 drives? Probably not, but...

[Guy Sotomayor Jr via cctalk]

> On Aug 4, 2017, at 1:14 AM, Christian Corti via cctalk 
>  wrote:
> 
> On Thu, 3 Aug 2017, emanuel stiebler wrote:
>> On 2017-08-03 11:12, Al Kossow via cctalk wrote:
>>> It would be nice, though if someone just finished a MSCP controller with a 
>>> CF or SD on it.
>> 
>> I don't think there is enough demand for it. So to finish it would take some 
>> effort, and the boards wouldn't be cheaper than the SCSI controllers out 
>> there (CMD, Emulex, etc).
> 
> I don't like the idea of CF or SD at all. I'd pretty much prefer PATA or 
> SATA, because …
> 
Unfortunately PATA drives are becoming difficult to find and designing a SATA 
interface (not to mention layout issues) is not for the faint of heart.

TTFN - Guy

Re: 2.11BSD on two RL02 drives? Probably not, but...

[Al Kossow via cctalk]

the cheap bridges are actually based on the 20330

you can find a real data sheet if you search for JM20330_datasheet_v2.5.pdf
hard enough

some discussions of their use with ssd trim

https://forum.thinkpads.com//viewtopic.php?t=115329


On 8/4/17 8:08 AM, Al Kossow via cctalk wrote:
> 
> 
> On 8/4/17 7:57 AM, Christian Corti via cctalk wrote:
> 
>> http://www.dx.com/en/p/jm20330-2-5-3-5-sata-to-40-pin-ide-adapter-card-green-black-241466
> 
> these are the ones I'm using, all based on the same JMicron bridge
> this one is short enough you can fit it in a space designed for a 3.5" drive.
> 
> http://www.jmicron.com/product0206.html
> 

Re: 2.11BSD on two RL02 drives? Probably not, but...

[Christian Corti via cctalk]

On Fri, 4 Aug 2017, Al Kossow wrote:

Can you actually buy SATA PHYs in small quantities now
or even SATA to PATA bridges?


I would go for a cheap external bridge, something like this:
https://www.amazon.com/dp/B008X8NK0I
http://www.dx.com/en/p/jm20330-2-5-3-5-sata-to-40-pin-ide-adapter-card-green-black-241466

They are small and just work. There are also ones that can do both 
directions (switchable).


Christian

Re: 2.11BSD on two RL02 drives? Probably not, but...

[Al Kossow via cctalk]

On 8/4/17 7:44 AM, systems_glitch via cctalk wrote:
> There are indeed cheap SATA -> IDE bridge ICs.


yup, I'm running around 50 of them in my upgraded XServe RAIDs
when I converted to 1tb 2.5" SATA-2 drives in 2015.

Re: 2.11BSD on two RL02 drives? Probably not, but...

[Al Kossow via cctalk]

On 8/4/17 7:37 AM, Phil Blundell via cctalk wrote:
> ASSPs like TI's TUSB9260

which turns up a big fat nothing in a web search

is there a data sheet somewhere?

the 6250 is a SATA 2 to USB using an 8051 core, but I suspect you
can't get the code for that.

one of the common pata-sata bridges from a tailgate adapter would do
if you're willing to design it blind

Re: 2.11BSD on two RL02 drives? Probably not, but...

[systems_glitch via cctalk]

There are indeed cheap SATA -> IDE bridge ICs. I'm currently evaluating
some small, cheap IDE -> mSATA SSD adapters for disk replacements in
industrial systems. The module with a mSATA socket and 44-pin laptop sized
IDE connector is less than $10 from various online retailers.

Thanks,
Jonathan

On Fri, Aug 4, 2017 at 10:37 AM, Phil Blundell via cctalk <
cctalk@classiccmp.org> wrote:

> On Fri, 2017-08-04 at 07:20 -0700, Al Kossow via cctalk wrote:
> >
> > Can you actually buy SATA PHYs in small quantities now
> > or even SATA to PATA bridges?
>
> I can't think of anybody who makes discrete SATA PHYs, and there isn't
> a standardized interface for the other side of the PHY so I suspect
> there would probably be no market for a chip like that.
>
> Commodity FPGAs with 3Gbps SERDES channels are fairly readily available
>  and I think you could probably build a SATA interface in one of those
> without too much trouble.  It probably would not be very cheap though,
> and there would be hassle involved in implementing the SATA stack.
> Alternatively, there are ASSPs like TI's TUSB9260, which is actually
> intended for use as a USB-to-SATA bridge but could probably be bent
> into implementing PATA using its digital GPIOs.  It costs $6.44 from
> Mouser at quantity 1.
>
> Phil
>
>

Re: 2.11BSD on two RL02 drives? Probably not, but...

[Phil Blundell via cctalk]

On Fri, 2017-08-04 at 07:20 -0700, Al Kossow via cctalk wrote:
> 
> Can you actually buy SATA PHYs in small quantities now
> or even SATA to PATA bridges?

I can't think of anybody who makes discrete SATA PHYs, and there isn't
a standardized interface for the other side of the PHY so I suspect
there would probably be no market for a chip like that.

Commodity FPGAs with 3Gbps SERDES channels are fairly readily available
 and I think you could probably build a SATA interface in one of those
without too much trouble.  It probably would not be very cheap though,
and there would be hassle involved in implementing the SATA stack. 
Alternatively, there are ASSPs like TI's TUSB9260, which is actually
intended for use as a USB-to-SATA bridge but could probably be bent
into implementing PATA using its digital GPIOs.  It costs $6.44 from
Mouser at quantity 1.

Phil

Re: 2.11BSD on two RL02 drives? Probably not, but...

[Al Kossow via cctalk]

On 8/4/17 7:07 AM, Christian Corti via cctalk wrote:
> If you really want a non-rotating media, then I
> suggest that you use SATA SSDs.

Can you actually buy SATA PHYs in small quantities now
or even SATA to PATA bridges?

I remember looking for them in the past and either not
being able to buy them, or find data for them.

Re: 2.11BSD on two RL02 drives? Probably not, but...

[Christian Corti via cctalk]

On Fri, 4 Aug 2017, Paul Koning wrote:
On Aug 4, 2017, at 4:14 AM, Christian Corti via cctalk 
 wrote: I don't like the idea of CF or SD at 
all. I'd pretty much prefer PATA or SATA, because ...


CF is PATA, just a different connector.


If the board provides a PATA connector, I'm fine. Then you can choose 
between a CF card and a hard disk. The same applies to SATA (SSD vs. hard 
disk).


Christian

Re: 2.11BSD on two RL02 drives? Probably not, but...

[Christian Corti via cctalk]

On Fri, 4 Aug 2017, Noel Chiappa wrote:

But are SD cards really that unreliable? If they were, I'd have thought I'd


Yes they are. Just have look around in the world of cameras and 
smartphones where people suffer from losing their photos just because an 
SD card decides to fail. I have several failed SD and CF cards, as well as 
USB bars. And many flash cards will fall into a read-only mode when errors 
cannot be corrected anymore, in contrast to real disk drives where you can 
skip the bad areas.


I just had a look on some datasheets for industrial SD cards. ATP gives a 
value of 384 TBW (terabytes written) for SLC and 38.4 TBW for MLC devices. 
For a 32 GB SD card, this means a max. write count of 12,000 for a byte. 
SanDisk give 192 TBW for their Industrial XT, that is even worse. A 64 GB 
SD card would only support 3000 writes per byte before you begin to 
play roulette...


S... here I come again with my preference of PATA/SATA drives. If you 
really want a non-rotating media, then I suggest that you use SATA SSDs.

Hence why I prefer a controller/interface with PATA/SATA connectors ;-)
You are totally free in using rotating or non-rotating media.

Christian

Re: 2.11BSD on two RL02 drives? Probably not, but...

[Paul Koning via cctalk]

> On Aug 4, 2017, at 4:14 AM, Christian Corti via cctalk 
>  wrote:
> 
> On Thu, 3 Aug 2017, emanuel stiebler wrote:
>> On 2017-08-03 11:12, Al Kossow via cctalk wrote:
>>> It would be nice, though if someone just finished a MSCP controller with a 
>>> CF or SD on it.
>> 
>> I don't think there is enough demand for it. So to finish it would take some 
>> effort, and the boards wouldn't be cheaper than the SCSI controllers out 
>> there (CMD, Emulex, etc).
> 
> I don't like the idea of CF or SD at all. I'd pretty much prefer PATA or 
> SATA, because ...

CF is PATA, just a different connector.

paul

Re: 2.11BSD on two RL02 drives? Probably not, but...

[william degnan via cctalk]

On Fri, Aug 4, 2017 at 9:49 AM, systems_glitch via cctalk <
cctalk@classiccmp.org> wrote:

> Going with SLC/"industrial" Flash is indeed the key to avoiding random
> failures. I have many deployed systems using industrial Flash modules (IDE
> DOMs) running 24/7 in critical production environments, mostly running
> machine tools and semiconductor production line equipment. We still do
> regular backups, though!
>
> To compare, the typical industrial DOMs and CF cards I purchase are rated
> for 1-2 million rewrites per Flash block (from the datasheet). I assume
> this is SLC + wear leveling. *IF* you can find the write endurance on
> consumer stuff, it's often less than 10K.
>
> Thanks,
> Jonathan
>
>
I agree.  I remember Jon's demo of these at VCF East last year, we
discussed this stuff then.

Re: 2.11BSD on two RL02 drives? Probably not, but...

[william degnan via cctalk]

On Fri, Aug 4, 2017 at 9:42 AM, Phil Blundell via cctalk <
cctalk@classiccmp.org> wrote:

> On Fri, 2017-08-04 at 08:53 -0400, Noel Chiappa via cctalk wrote:
> >
> > But are SD cards really that unreliable?
>
> It depends on exactly how you measure "reliable".  There are a few
> different things going on, and it differs from one SD card to another.
>
> 
>


> capacity MLC one.  But otherwise, I would just make sure I had a backup
> and live with the possibility that the card might need replacing after
> a couple of years.
>
> Phil
>
>
I think one should just lump everything from 3.5 diskettes to today's min
SD's (and into the future) as temporary storage and one should never store
the only single copy of data on these.

The biggest issue I have run into with the mini SD's is that I crush them
with my fingers.  Bass player fingers.

Bill

Re: 2.11BSD on two RL02 drives? Probably not, but...

[systems_glitch via cctalk]

Going with SLC/"industrial" Flash is indeed the key to avoiding random
failures. I have many deployed systems using industrial Flash modules (IDE
DOMs) running 24/7 in critical production environments, mostly running
machine tools and semiconductor production line equipment. We still do
regular backups, though!

To compare, the typical industrial DOMs and CF cards I purchase are rated
for 1-2 million rewrites per Flash block (from the datasheet). I assume
this is SLC + wear leveling. *IF* you can find the write endurance on
consumer stuff, it's often less than 10K.

Thanks,
Jonathan

On Fri, Aug 4, 2017 at 9:42 AM, Phil Blundell via cctalk <
cctalk@classiccmp.org> wrote:

> On Fri, 2017-08-04 at 08:53 -0400, Noel Chiappa via cctalk wrote:
> >
> > But are SD cards really that unreliable?
>
> It depends on exactly how you measure "reliable".  There are a few
> different things going on, and it differs from one SD card to another.
>
> Firstly, there are multiple types of flash memory that can be used for
> the underlying storage.  The flash cells can be either SLC, MLC or TLC
> in decreasing order of cost per bit but also in decreasing order of
> robustness.  An SLC cell might tolerate 100,000 erase/write cycles,
> whereas an MLC cell might fail after only 10,000 and a TLC cell might
> be worn out after 3,000.  The act of reading from a flash cell also
> disturbs the charge in nearby cells: this effect is not particularly
> significant for SLC, which you can generally read without restriction,
> but on MLC and TLC the controller needs to keep track of how many times
> it has read from a particular block and periodically re-write the data
> to refresh it otherwise it will eventually become corrupt.  And
> finally, the charge in flash cells does eventually leak away: for MLC
> and TLC cards your data may disappear over a timescale of months to a
> few years.
>
> Consumer-grade cards will almost always use MLC flash, or possibly TLC
> at higher capacity levels.  SLC cards are available but typically they
> are the "industrial grade" ones and are only available in smaller
> capacities.
>
> Secondly, there are many different controller ICs and the behaviour of
> the controller has a significant effect on how well the card works
> overall.  Some controllers are better than others at managing bad
> blocks and bit errors in the flash.  Some deal better than others with
> unexpected power failures.  Some deal better than others with the "read
> disturb" effect.  Some deal better than others with random access,
> particularly random writes: it's fairly common for the cheaper consumer
> cards to only have enough buffer space for one output file to be open
> at a time, and if you start trying to write multiple files in parallel
> to different areas of the card then the write buffer will start
> thrashing and performance will be dismal.
>
> It's also worth remembering that most consumer-grade cards are used in
> a way that is not a very close match to a disk emulator.  Cameras
> (including cameras in phones) are generally writing a relatively small
> number of fairly large files.  They seldom read, and they virtually
> never modify a file in place.  Also, because all SD cards come
> preformatted as either FAT or exFAT, the pattern of accesses that the
> host will make to the filesystem is somewhat predictable and some
> controller ICs are specifically optimised for this.
>
> All the above said, although it probably is true that the average
> consumer-grade SD card is significantly less robust than the average
> SATA SSD that you can buy today, and probably also less robust than the
> average spinning hard disk, I suspect they are probably not all that
> much less reliable than the average 1980s or 1990s-era hard disk.
> Personally I would be quite happy to use an SD card to emulate mass
> storage in a classic computer, and in fact I was thinking just this
> morning about buying one of the scsi2sd boards for that very purpose.
> If you are going to be using it in an application that sees frequent
> writes then I would try to get an SLC card, or failing that a low-
> capacity MLC one.  But otherwise, I would just make sure I had a backup
> and live with the possibility that the card might need replacing after
> a couple of years.
>
> Phil
>
>

Re: 2.11BSD on two RL02 drives? Probably not, but...

[Phil Blundell via cctalk]

On Fri, 2017-08-04 at 08:53 -0400, Noel Chiappa via cctalk wrote:
> 
> But are SD cards really that unreliable? 

It depends on exactly how you measure "reliable".  There are a few
different things going on, and it differs from one SD card to another.

Firstly, there are multiple types of flash memory that can be used for
the underlying storage.  The flash cells can be either SLC, MLC or TLC
in decreasing order of cost per bit but also in decreasing order of
robustness.  An SLC cell might tolerate 100,000 erase/write cycles,
whereas an MLC cell might fail after only 10,000 and a TLC cell might
be worn out after 3,000.  The act of reading from a flash cell also
disturbs the charge in nearby cells: this effect is not particularly
significant for SLC, which you can generally read without restriction,
but on MLC and TLC the controller needs to keep track of how many times
it has read from a particular block and periodically re-write the data
to refresh it otherwise it will eventually become corrupt.  And
finally, the charge in flash cells does eventually leak away: for MLC
and TLC cards your data may disappear over a timescale of months to a
few years.

Consumer-grade cards will almost always use MLC flash, or possibly TLC
at higher capacity levels.  SLC cards are available but typically they
are the "industrial grade" ones and are only available in smaller
capacities.

Secondly, there are many different controller ICs and the behaviour of
the controller has a significant effect on how well the card works
overall.  Some controllers are better than others at managing bad
blocks and bit errors in the flash.  Some deal better than others with
unexpected power failures.  Some deal better than others with the "read
disturb" effect.  Some deal better than others with random access,
particularly random writes: it's fairly common for the cheaper consumer
cards to only have enough buffer space for one output file to be open
at a time, and if you start trying to write multiple files in parallel
to different areas of the card then the write buffer will start
thrashing and performance will be dismal.

It's also worth remembering that most consumer-grade cards are used in
a way that is not a very close match to a disk emulator.  Cameras
(including cameras in phones) are generally writing a relatively small
number of fairly large files.  They seldom read, and they virtually
never modify a file in place.  Also, because all SD cards come
preformatted as either FAT or exFAT, the pattern of accesses that the
host will make to the filesystem is somewhat predictable and some
controller ICs are specifically optimised for this.

All the above said, although it probably is true that the average
consumer-grade SD card is significantly less robust than the average
SATA SSD that you can buy today, and probably also less robust than the
average spinning hard disk, I suspect they are probably not all that
much less reliable than the average 1980s or 1990s-era hard disk. 
Personally I would be quite happy to use an SD card to emulate mass
storage in a classic computer, and in fact I was thinking just this
morning about buying one of the scsi2sd boards for that very purpose. 
If you are going to be using it in an application that sees frequent
writes then I would try to get an SLC card, or failing that a low-
capacity MLC one.  But otherwise, I would just make sure I had a backup
and live with the possibility that the card might need replacing after
a couple of years.

Phil

Re: 2.11BSD on two RL02 drives? Probably not, but...

[Noel Chiappa via cctalk]

> From: Christian Corti

> I don't like the idea of CF or SD at all. I'd pretty much prefer PATA
> or SATA, because ... Real drives are also much more reliable than flash
> drives,

I found this interesting/troubling, because Dave Bridgham and I decided to
use SD cards, after I initially suggested using IDE drives

(That was in part because those where what I had lying around, and because
one replaces a disk with a disk, no? - and in part because Brad Parker's RK11
emulator - the page for which appears to no longer be online, sadly - used an
IDE drive.)

But when Dave suggested using SD cards instead, I was immediately drawn to the
idea of using a memory card, because I have suffered greatly over the years
with disks failing from head crashes, etc (even IDE drives fail on occasion),
and going with non-mechanical storage, which could not (almost by definition)
have a mechanical failure attracted me greatly.

But are SD cards really that unreliable? If they were, I'd have thought I'd
have heard more about it - e.g. friends grousing about having lost things when
an SD card failed. But I don't recall ever hearing such a story? (I'm not
discussing their very long-term stability, that's different.)

Noel

Re: 2.11BSD on two RL02 drives? Probably not, but...

[emanuel stiebler via cctalk]

On 2017-08-04 04:14, Christian Corti via cctalk wrote:

On Thu, 3 Aug 2017, emanuel stiebler wrote:

On 2017-08-03 11:12, Al Kossow via cctalk wrote:

It would be nice, though if someone just finished a MSCP controller
with a CF or SD on it.


I don't think there is enough demand for it. So to finish it would
take some effort, and the boards wouldn't be cheaper than the SCSI
controllers out there (CMD, Emulex, etc).


I don't like the idea of CF or SD at all. I'd pretty much prefer PATA or
SATA, because ...


However, it would be nice to get rid of the noise of rotating rust ;-)


... I have tons of PATA and SATA drives. Real drives are also much more
reliable than flash drives,


Sorry to disagree, at least partially ;-)

Industrial grade sd-card are pretty good, and we are talking cards with 
less than 1gbyte per card. And still, backup is pretty easy, if you can 
take out the card, put it in another system and transfer the whole 
container file to you favorite backup media ...


That's also, why I always have at least two sd-card slots on the boards,
to have one "exchangeable" media in it, you can take out without 
stopping the system.



and the noise isn't an issue at all. Modern
drives just don't make any noise when used in a PDP-11 (or whatever
UNIBUS or QBUS system) ;-)


Probably listened to too many RD5x or similar in my life ;-)


BTW the problem with Fujitsu Eagle SMD drives is that they need a
complete lowlevel format from time to time. *All* Eagle drives I have,
have developed bad sectors that can't be read without errors even with
microstepping and other tricks.


replacing SMD drives would be a nice project too ...

Re: 2.11BSD on two RL02 drives? Probably not, but...

[Christian Corti via cctalk]

On Thu, 3 Aug 2017, emanuel stiebler wrote:

On 2017-08-03 11:12, Al Kossow via cctalk wrote:
It would be nice, though if someone just finished a MSCP controller with a 
CF or SD on it.


I don't think there is enough demand for it. So to finish it would take some 
effort, and the boards wouldn't be cheaper than the SCSI controllers out 
there (CMD, Emulex, etc).


I don't like the idea of CF or SD at all. I'd pretty much prefer PATA or 
SATA, because ...



However, it would be nice to get rid of the noise of rotating rust ;-)


... I have tons of PATA and SATA drives. Real drives are also much more 
reliable than flash drives, and the noise isn't an issue at all. Modern 
drives just don't make any noise when used in a PDP-11 (or whatever 
UNIBUS or QBUS system) ;-)


BTW the problem with Fujitsu Eagle SMD drives is that they need a complete 
lowlevel format from time to time. *All* Eagle drives I have, have 
developed bad sectors that can't be read without errors even with 
microstepping and other tricks.


Christian

Re: 2.11BSD on two RL02 drives? Probably not, but...

[Aaron Jackson via cctalk]

> On Wed, Aug 2, 2017 at 2:14 PM, Aaron Jackson via cctalk <
> cctalk@classiccmp.org> wrote:
>
>> >> On Aug 2, 2017, at 11:32 AM, Aaron Jackson via cctech <
>> cct...@classiccmp.org> wrote:
>> >>
>> >> Hi all,
>> >>
>> >> I will soon be getting a PDP-11/73 with 1MB of RAM, an RLV12 and DEQNA
>> >> controllers. I already have two RL02 and packs (which need a clean),
>> >> with thanks to Dave Wade on this list.
>> >>
>> >> Ideally I would like to run 2.11BSD, on two RL02 drives, I'm not sure
>> >> this is going to be possible. Does anyone know/think otherwise? Maybe by
>> >> removing *many* unnecessary and running strip on any binaries left from
>> >> my destruction? Ignoring spare for the user, for the time being...
>> >>
>> >> If not, what other UNIX options are there which I will be able to use,
>> >> supporting the DEQNA and running on two RL02 drives?
>> >>
>> >> Input much appreciated.
>> >
>> > Here’s what I did (but I wasn’t space constrained as I have the
>> equivalant
>> > of 4 RP06 drives).
>>
>> That is huge compared to my total of 20MB! :D
>>
>> > You’ll likely have to configure the kernel.  This is easiest done within
>> an emulator,
>> > as it took 24hours on my 11/70.  I decided that the emulator approach
>> was best
>> > after the 2nd time I screwed it up.  :-/
>> >
>>
>> Thanks for the suggestion. I have been playing with this already. I
>> recompiled the kernel and set a bunch of stuff to NO which I knew I
>> wouldn't need. It compiled fine, but then said:
>>
>> base segment is 47232, min is 49152, too small by 1920 bytes.
>> System will occupy 175264 bytes of memory (including buffers and clists).
>>
>>end {0054200}  nbuf {0012134}   buf
>> {0035352}
>>  nproc {0012122}  proc {0044344} ntext
>> {0012124}
>>   text {0053240} nfile {0012130}  file
>> {0051260}
>> ninode {0012126} inode {0012220}  ncallout
>> {0012132}
>>callout {0025764} ucb_clist {0012140}nclist
>> {0012136}
>>   ram_size {000}   xitdesc {0012216}  quotdesc
>> {000}
>>  namecache {0035070}   _iosize {000}  nlog
>> {0011206}
>>  SYSTEM IS NOT BOOTABLE. 
>>
>> If anyone can explain what this mean and possibly how to fix it, I'd be
>> very pleased.
>>
>
> The base segment is too small.  The 2.11BSD kernel is built as a base image
> plus a bunch of 8K segments that are overlaid as needed.  Usually what I
> end up seeing is that one of the overlay segments is too large rather than
> the base being too small.
>
> To fix it, edit the Makefile in your kernel's configuration directory.
> There is a line that starts with "BASE=" -- move an .o file from one of the
> overlay "OVX=" lines (something larger than 1920 bytes but not TOO big) and
> run make again.  You'll probably also end up needing to tweak some of the
> overlay definitions... it's a balancing act.
>
> - Josh

Ah I see - good to know. Thank you for the information!



>
>
>
>
>>
>> > Running on an emulator allows you to “play around” with the configuration
>> > and what will and won’t fit.  You’ll likely have to start with a
>> configuration larger
>> > than your target just to get started (but I haven’t done it in a long
>> time so YMMV).
>> >
>> > That will also tell you what you can reasonably fit on two RL02 drives.
>> Also it’s
>> > easier to “back up” and start over if you make mistakes (save a version
>> of the
>> > emulated disk files before making substantive changes and copy them back
>> if
>> > you screw up).
>> >
>> > Once you have something working reasonably well, you can transfer the
>> “bits”
>> > over to your 11’s RL drives though your preferred method.
>> >
>> > TTFN - Guy
>>
>> Thanks again,
>>
>> Aaron.
>>


-- 
Aaron Jackson
PhD Student, Computer Vision Laboratory, Uni of Nottingham
http://aaronsplace.co.uk

Re: 2.11BSD on two RL02 drives? Probably not, but...

[Josh Dersch via cctalk]

On Wed, Aug 2, 2017 at 2:14 PM, Aaron Jackson via cctalk <
cctalk@classiccmp.org> wrote:

> >> On Aug 2, 2017, at 11:32 AM, Aaron Jackson via cctech <
> cct...@classiccmp.org> wrote:
> >>
> >> Hi all,
> >>
> >> I will soon be getting a PDP-11/73 with 1MB of RAM, an RLV12 and DEQNA
> >> controllers. I already have two RL02 and packs (which need a clean),
> >> with thanks to Dave Wade on this list.
> >>
> >> Ideally I would like to run 2.11BSD, on two RL02 drives, I'm not sure
> >> this is going to be possible. Does anyone know/think otherwise? Maybe by
> >> removing *many* unnecessary and running strip on any binaries left from
> >> my destruction? Ignoring spare for the user, for the time being...
> >>
> >> If not, what other UNIX options are there which I will be able to use,
> >> supporting the DEQNA and running on two RL02 drives?
> >>
> >> Input much appreciated.
> >
> > Here’s what I did (but I wasn’t space constrained as I have the
> equivalant
> > of 4 RP06 drives).
>
> That is huge compared to my total of 20MB! :D
>
> > You’ll likely have to configure the kernel.  This is easiest done within
> an emulator,
> > as it took 24hours on my 11/70.  I decided that the emulator approach
> was best
> > after the 2nd time I screwed it up.  :-/
> >
>
> Thanks for the suggestion. I have been playing with this already. I
> recompiled the kernel and set a bunch of stuff to NO which I knew I
> wouldn't need. It compiled fine, but then said:
>
> base segment is 47232, min is 49152, too small by 1920 bytes.
> System will occupy 175264 bytes of memory (including buffers and clists).
>
>end {0054200}  nbuf {0012134}   buf
> {0035352}
>  nproc {0012122}  proc {0044344} ntext
> {0012124}
>   text {0053240} nfile {0012130}  file
> {0051260}
> ninode {0012126} inode {0012220}  ncallout
> {0012132}
>callout {0025764} ucb_clist {0012140}nclist
> {0012136}
>   ram_size {000}   xitdesc {0012216}  quotdesc
> {000}
>  namecache {0035070}   _iosize {000}  nlog
> {0011206}
>  SYSTEM IS NOT BOOTABLE. 
>
> If anyone can explain what this mean and possibly how to fix it, I'd be
> very pleased.
>

The base segment is too small.  The 2.11BSD kernel is built as a base image
plus a bunch of 8K segments that are overlaid as needed.  Usually what I
end up seeing is that one of the overlay segments is too large rather than
the base being too small.

To fix it, edit the Makefile in your kernel's configuration directory.
There is a line that starts with "BASE=" -- move an .o file from one of the
overlay "OVX=" lines (something larger than 1920 bytes but not TOO big) and
run make again.  You'll probably also end up needing to tweak some of the
overlay definitions... it's a balancing act.

- Josh




>
> > Running on an emulator allows you to “play around” with the configuration
> > and what will and won’t fit.  You’ll likely have to start with a
> configuration larger
> > than your target just to get started (but I haven’t done it in a long
> time so YMMV).
> >
> > That will also tell you what you can reasonably fit on two RL02 drives.
> Also it’s
> > easier to “back up” and start over if you make mistakes (save a version
> of the
> > emulated disk files before making substantive changes and copy them back
> if
> > you screw up).
> >
> > Once you have something working reasonably well, you can transfer the
> “bits”
> > over to your 11’s RL drives though your preferred method.
> >
> > TTFN - Guy
>
> Thanks again,
>
> Aaron.
>

Re: 2.11BSD on two RL02 drives? Probably not, but...

[Guy Sotomayor Jr via cctalk]

> On Aug 3, 2017, at 9:28 AM, Noel Chiappa via cctalk  
> wrote:
> 
>> From: Guy Sotomayor Jr
> 
>> Having several different Unibus board designs in various stages .. I can
>> tell you that producing a *reliable* Unibus board is *not* going to be
>> cheap.
> 
> Why not? Just the size, gold-plated fingers, and transceiver chips, or is
> there more?
> 

All of the above + getting the parts sourced and assembled (using a lot of SMD).

TTFN - Guy

Re: 2.11BSD on two RL02 drives? Probably not, but...

[Noel Chiappa via cctalk]

> From: Guy Sotomayor Jr

> Having several different Unibus board designs in various stages .. I can
> tell you that producing a *reliable* Unibus board is *not* going to be
> cheap.

Why not? Just the size, gold-plated fingers, and transceiver chips, or is
there more?

Noel

Re: 2.11BSD on two RL02 drives? Probably not, but...

[Mattis Lind via cctalk]

  I've heard that the Emulex UD33 and SC21 are the SMD controllers of
> choice, but do they do MSCP?   I'd love to head any comments from those "in
> the know" out there.  Are there other alternatives other than Emulex that
> may work well also?


Emulex UD33 is MSCP and is similar to QD32 and QD33. I have one. Sorry I
won't let it go. I have a long term project to do a SMD disk emulator and
need various controllers to test with. I have a few including a SC750
(which is Emulating RH750 with RM disks).


/Mattis


> Thanks for reading!
>
> -Rick
> --
> Rick Bensene
> The Old Calculator Museum
> http://oldcalculatormuseum.com
> Beavercreek, Oregon
>

Re: 2.11BSD on two RL02 drives? Probably not, but...

[emanuel stiebler via cctalk]

On 2017-08-03 11:12, Al Kossow via cctalk wrote:



It would be nice, though if someone just finished a MSCP controller with a CF 
or SD on it.


I don't think there is enough demand for it. So to finish it would take 
some effort, and the boards wouldn't be cheaper than the SCSI 
controllers out there (CMD, Emulex, etc).


However, it would be nice to get rid of the noise of rotating rust ;-)

Re: 2.11BSD on two RL02 drives? Probably not, but...

[Guy Sotomayor Jr via cctalk]

> On Aug 3, 2017, at 7:10 AM, Rick Bensene via cctalk  
> wrote:
> 
> That said, my PDP 11 is Unibus, and Unibus SCSI controllers are darned 
> expen$ive.

They’re desirable and not a lot around.  So it’s not terribly surprising.

Having several different Unibus board designs in various stages (not making a 
lot of progress because of this damned thing called “work”) I can tell you that 
producing a *reliable* Unibus board is *not* going to be cheap.

> 
> I do have some working Fujitsu SMD drives (now, these drives just keep on 
> running!), and I'd love to find a Unibus SMD controller (preferably Emulex), 
> so that I could run a couple of these drives on the 11.   Anyone out there 
> got one that emulates popular PDP-11 disk drives supported by most of the 
> OS's (RT-11, RSTS, and BSD Unix) that can make a given SMD drive "appear" 
> compatible that the would be willing to part with for a reasonable price?  
> I've heard that the Emulex UD33 and SC21 are the SMD controllers of choice, 
> but do they do MSCP?   I'd love to head any comments from those "in the know" 
> out there.  Are there other alternatives other than Emulex that may work well 
> also?
> 

If memory serves me correctly, the Emulex UD33 and SC21 emulate RP11 style 
controllers.  Which is a *good* thing.  For older Unibus systems RP11 (and 
OS’s) it’s better supported than MSCP.

TTFN - Guy

Re: 2.11BSD on two RL02 drives? Probably not, but...

[Al Kossow via cctalk]

On 8/3/17 7:10 AM, Rick Bensene via cctalk wrote:

> I've found much the same with ESDI drives...they tend to die just sitting, 
> and it's not stiction that seems to be the culprit...they simply quit working.

That isn't good news. I still have about 100 drives that came out of Apollo's 
development cluster to image. Mostly
Micropolis and Maxtor >300mb.

If I actually get this done, I should have a pile of tested drives when it's 
over.

--

It would be nice, though if someone just finished a MSCP controller with a CF 
or SD on it.

RE: 2.11BSD on two RL02 drives? Probably not, but...

[Rick Bensene via cctalk]

Glen S. wrote:

>QBus ESDI controllers are relatively cheap. I have several Emulex QD21, Dilog 
>DQ696, and Sigma SDC-RQD11 QBus ESDI controllers. The >problem I have with 
>them is that I now have more controllers than working ESDI drives. Some of the 
>drives that I had which were >working have died while sitting idle. Guaranteed 
>working ESDI drives don't seem to be cheap anywhere and shipping them isn't 
>cheap >either.

I've found much the same with ESDI drives...they tend to die just sitting, and 
it's not stiction that seems to be the culprit...they simply quit working.   
Not sure why, but at one time I had a stash of 18 ESDI drives of various makes 
and sizes, and I'm now down to 2 that still work.  The rest all just quit.  
When not in use, the drives are stored in anti-static bags with a dessicant bag 
inside, and then stored in a storage tote lined with anti-static pink poly 
sheeting.  The totes are stored in an environmentally controlled room.   I 
don't see any reason why they'd die due to environmental conditions.  Something 
else has to be going on with them.

>To me it seems a lot more cost effective and less trouble in the long run to 
>pay a little more for something like a CMD CQD-200/220 or >Emulex UC07 SCSI 
>controller. I've somehow managed to acquire a couple dozen or so QBus SCSI 
>controllers of various flavors over the >years.

That said, my PDP 11 is Unibus, and Unibus SCSI controllers are darned 
expen$ive.

I do have some working Fujitsu SMD drives (now, these drives just keep on 
running!), and I'd love to find a Unibus SMD controller (preferably Emulex), so 
that I could run a couple of these drives on the 11.   Anyone out there got one 
that emulates popular PDP-11 disk drives supported by most of the OS's (RT-11, 
RSTS, and BSD Unix) that can make a given SMD drive "appear" compatible that 
the would be willing to part with for a reasonable price?  I've heard that the 
Emulex UD33 and SC21 are the SMD controllers of choice, but do they do MSCP?   
I'd love to head any comments from those "in the know" out there.  Are there 
other alternatives other than Emulex that may work well also?

Thanks for reading!

-Rick
--
Rick Bensene
The Old Calculator Museum
http://oldcalculatormuseum.com
Beavercreek, Oregon

Re: 2.11BSD on two RL02 drives? Probably not, but...

[Glen Slick via cctalk]

On Wed, Aug 2, 2017 at 6:24 PM, systems_glitch via cctalk
 wrote:
> You might consider just adding another storage controller. I'd recommend
> something that talks MSCP. SCSI seems to be what most people are after
> nowadays, but ESDI controllers are much cheaper, and the drives aren't that
> hard to find. If you have SMD drives kicking around already, there are SMD
> MSCP interfaces that also work well. I've had excellent luck with Emulex
> MSCP controllers.
>
> Thanks,
> Jonathan
>

QBus ESDI controllers are relatively cheap. I have several Emulex
QD21, Dilog DQ696, and Sigma SDC-RQD11 QBus ESDI controllers. The
problem I have with them is that I now have more controllers than
working ESDI drives. Some of the drives that I had which were working
have died while sitting idle. Guaranteed working ESDI drives don't
seem to be cheap anywhere and shipping them isn't cheap either.

To me it seems a lot more cost effective and less trouble in the long
run to pay a little more for something like a CMD CQD-200/220 or
Emulex UC07 SCSI controller. I've somehow managed to acquire a couple
dozen or so QBus SCSI controllers of various flavors over the years.

-Glen

Re: 2.11BSD on two RL02 drives? Probably not, but...

[Aaron Jackson via cctalk]

>> On Aug 2, 2017, at 11:32 AM, Aaron Jackson via cctech 
>>  wrote:
>>
>> Hi all,
>>
>> I will soon be getting a PDP-11/73 with 1MB of RAM, an RLV12 and DEQNA
>> controllers. I already have two RL02 and packs (which need a clean),
>> with thanks to Dave Wade on this list.
>>
>> Ideally I would like to run 2.11BSD, on two RL02 drives, I'm not sure
>> this is going to be possible. Does anyone know/think otherwise? Maybe by
>> removing *many* unnecessary and running strip on any binaries left from
>> my destruction? Ignoring spare for the user, for the time being...
>>
>> If not, what other UNIX options are there which I will be able to use,
>> supporting the DEQNA and running on two RL02 drives?
>>
>> Input much appreciated.
>
> Here’s what I did (but I wasn’t space constrained as I have the equivalant
> of 4 RP06 drives).

That is huge compared to my total of 20MB! :D

> You’ll likely have to configure the kernel.  This is easiest done within an 
> emulator,
> as it took 24hours on my 11/70.  I decided that the emulator approach was best
> after the 2nd time I screwed it up.  :-/
>

Thanks for the suggestion. I have been playing with this already. I
recompiled the kernel and set a bunch of stuff to NO which I knew I
wouldn't need. It compiled fine, but then said:

base segment is 47232, min is 49152, too small by 1920 bytes.
System will occupy 175264 bytes of memory (including buffers and clists).

   end {0054200}  nbuf {0012134}   buf {0035352}
 nproc {0012122}  proc {0044344} ntext {0012124}
  text {0053240} nfile {0012130}  file {0051260}
ninode {0012126} inode {0012220}  ncallout {0012132}
   callout {0025764} ucb_clist {0012140}nclist {0012136}
  ram_size {000}   xitdesc {0012216}  quotdesc {000}
 namecache {0035070}   _iosize {000}  nlog {0011206}
 SYSTEM IS NOT BOOTABLE. 

If anyone can explain what this mean and possibly how to fix it, I'd be
very pleased.

> Running on an emulator allows you to “play around” with the configuration
> and what will and won’t fit.  You’ll likely have to start with a 
> configuration larger
> than your target just to get started (but I haven’t done it in a long time so 
> YMMV).
>
> That will also tell you what you can reasonably fit on two RL02 drives.  Also 
> it’s
> easier to “back up” and start over if you make mistakes (save a version of the
> emulated disk files before making substantive changes and copy them back if
> you screw up).
>
> Once you have something working reasonably well, you can transfer the “bits”
> over to your 11’s RL drives though your preferred method.
>
> TTFN - Guy

Thanks again,

Aaron.

Re: 2.11BSD on two RL02 drives? Probably not, but...

[Guy Sotomayor Jr via cctalk]

> On Aug 2, 2017, at 11:32 AM, Aaron Jackson via cctech  
> wrote:
> 
> Hi all,
> 
> I will soon be getting a PDP-11/73 with 1MB of RAM, an RLV12 and DEQNA
> controllers. I already have two RL02 and packs (which need a clean),
> with thanks to Dave Wade on this list.
> 
> Ideally I would like to run 2.11BSD, on two RL02 drives, I'm not sure
> this is going to be possible. Does anyone know/think otherwise? Maybe by
> removing *many* unnecessary and running strip on any binaries left from
> my destruction? Ignoring spare for the user, for the time being...
> 
> If not, what other UNIX options are there which I will be able to use,
> supporting the DEQNA and running on two RL02 drives?
> 
> Input much appreciated.

Here’s what I did (but I wasn’t space constrained as I have the equivalant
of 4 RP06 drives).

You’ll likely have to configure the kernel.  This is easiest done within an 
emulator,
as it took 24hours on my 11/70.  I decided that the emulator approach was best
after the 2nd time I screwed it up.  :-/

Running on an emulator allows you to “play around” with the configuration
and what will and won’t fit.  You’ll likely have to start with a configuration 
larger
than your target just to get started (but I haven’t done it in a long time so 
YMMV).

That will also tell you what you can reasonably fit on two RL02 drives.  Also 
it’s
easier to “back up” and start over if you make mistakes (save a version of the
emulated disk files before making substantive changes and copy them back if
you screw up).

Once you have something working reasonably well, you can transfer the “bits”
over to your 11’s RL drives though your preferred method.

TTFN - Guy

Re: 2.11BSD on two RL02 drives? Probably not, but...

[Eric Smith via cctalk]

On Wed, Aug 2, 2017 at 7:24 PM, systems_glitch via cctalk <
cctalk@classiccmp.org> wrote:

> You might consider just adding another storage controller. I'd recommend
> something that talks MSCP. SCSI seems to be what most people are after
> nowadays, but ESDI controllers are much cheaper, and the drives aren't that
> hard to find. If you have SMD drives kicking around already, there are SMD
> MSCP interfaces that also work well. I've had excellent luck with Emulex
> MSCP controllers.
>

I had good results on both Unibus and Qbus systems with using a CMD MSCP
SCSI controller and an Iomega ZIP drive. It was very convenient to be able
to stick the ZIP cartridge in a drive on a PC for access from simulators
etc.  I used it with RT11, RSTS/E, and BSD.

100MB might not be enough to be interesting for general purpose use on a PC
any more, but it's fine for a PDP-11.

Re: 2.11BSD on two RL02 drives? Probably not, but...

[systems_glitch via cctalk]

You might consider just adding another storage controller. I'd recommend
something that talks MSCP. SCSI seems to be what most people are after
nowadays, but ESDI controllers are much cheaper, and the drives aren't that
hard to find. If you have SMD drives kicking around already, there are SMD
MSCP interfaces that also work well. I've had excellent luck with Emulex
MSCP controllers.

Thanks,
Jonathan

On Wed, Aug 2, 2017 at 7:46 PM, william degnan via cctalk <
cctalk@classiccmp.org> wrote:

> I'd suggest using simH to load in UNIX 6 / 7 or BSD (assuming there an RL02
> BSD image(s)) onto a the PDP 11/? closest to what you have in actual
> hardware.  Emulate a system with RL02s attached.
>
> Using this method I have been able to build UNIX 6 onto RL02 media using
> the directions I found from gunkies.org.  I then used PDPGUI to copy the
> emulated disks to actual disks.  PDPGUI has tools to build actual RL02
> disks from RL02 images.  You have to have patience and functional
> hardware  Getting the build running on simH is very useful, helps save
> time.  You only move the disk pack once you're sure it's working in simH
> first.
>
> Bill
>
> On Wed, Aug 2, 2017 at 7:12 PM, Aaron Jackson via cctalk <
> cctalk@classiccmp.org> wrote:
>
> > > From: cctalk [cctalk-boun...@classiccmp.org] on behalf of Aaron
> Jackson
> > via cctalk [cctalk@classiccmp.org]
> > > Sent: Wednesday, August 2, 2017 2:32 PM
> > > To: cct...@classiccmp.org
> > > Subject: 2.11BSD on two RL02 drives? Probably not, but...
> > >
> > > Hi all,
> > >
> > > I will soon be getting a PDP-11/73 with 1MB of RAM, an RLV12 and DEQNA
> > > controllers. I already have two RL02 and packs (which need a clean),
> > > with thanks to Dave Wade on this list.
> > >
> > > Ideally I would like to run 2.11BSD, on two RL02 drives, I'm not sure
> > > this is going to be possible. Does anyone know/think otherwise? Maybe
> by
> > > removing *many* unnecessary and running strip on any binaries left from
> > > my destruction? Ignoring spare for the user, for the time being...
> > >
> > > If not, what other UNIX options are there which I will be able to use,
> > > supporting the DEQNA and running on two RL02 drives?
> > >
> > > Input much appreciated.
> > >
> > > Thanks,
> > >
> > > Aaron.
> > > ___
> > >
> > > Ultrix-11 works just fine on two RL02's.
> > >
> > > bill
> >
> > Hi Bill,
> >
> > Thanks for the suggestion. I dismissed Ultrix without much thought
> > unfortunately, but I actually see some pre-built images for two RL02
> > drives which should get me going.
> >
> > For anyone who is interested in my 2.11BSD progress: I managed to get it
> > to under 12MB, 8MB of which are in /usr. So, it is possible, the system
> > works, but I am left with no /usr/src, /usr/man, /usr/doc, /usr/dict. It
> > can compile stuff, it boots, but man pages are always nice to have.
> >
> > Thanks,
> >
> > Aaron.
> >
>

Re: 2.11BSD on two RL02 drives? Probably not, but...

[Aaron Jackson via cctalk]

> From: cctalk [cctalk-boun...@classiccmp.org] on behalf of Aaron Jackson via 
> cctalk [cctalk@classiccmp.org]
> Sent: Wednesday, August 2, 2017 2:32 PM
> To: cct...@classiccmp.org
> Subject: 2.11BSD on two RL02 drives? Probably not, but...
>
> Hi all,
>
> I will soon be getting a PDP-11/73 with 1MB of RAM, an RLV12 and DEQNA
> controllers. I already have two RL02 and packs (which need a clean),
> with thanks to Dave Wade on this list.
>
> Ideally I would like to run 2.11BSD, on two RL02 drives, I'm not sure
> this is going to be possible. Does anyone know/think otherwise? Maybe by
> removing *many* unnecessary and running strip on any binaries left from
> my destruction? Ignoring spare for the user, for the time being...
>
> If not, what other UNIX options are there which I will be able to use,
> supporting the DEQNA and running on two RL02 drives?
>
> Input much appreciated.
>
> Thanks,
>
> Aaron.
> ___
>
> Ultrix-11 works just fine on two RL02's.
>
> bill

Hi Bill,

Thanks for the suggestion. I dismissed Ultrix without much thought
unfortunately, but I actually see some pre-built images for two RL02
drives which should get me going.

For anyone who is interested in my 2.11BSD progress: I managed to get it
to under 12MB, 8MB of which are in /usr. So, it is possible, the system
works, but I am left with no /usr/src, /usr/man, /usr/doc, /usr/dict. It
can compile stuff, it boots, but man pages are always nice to have.

Thanks,

Aaron.

RE: 2.11BSD on two RL02 drives? Probably not, but...

[Bill Gunshannon via cctalk]

From: cctalk [cctalk-boun...@classiccmp.org] on behalf of Aaron Jackson via 
cctalk [cctalk@classiccmp.org]
Sent: Wednesday, August 2, 2017 2:32 PM
To: cct...@classiccmp.org
Subject: 2.11BSD on two RL02 drives? Probably not, but...

Hi all,

I will soon be getting a PDP-11/73 with 1MB of RAM, an RLV12 and DEQNA
controllers. I already have two RL02 and packs (which need a clean),
with thanks to Dave Wade on this list.

Ideally I would like to run 2.11BSD, on two RL02 drives, I'm not sure
this is going to be possible. Does anyone know/think otherwise? Maybe by
removing *many* unnecessary and running strip on any binaries left from
my destruction? Ignoring spare for the user, for the time being...

If not, what other UNIX options are there which I will be able to use,
supporting the DEQNA and running on two RL02 drives?

Input much appreciated.

Thanks,

Aaron.
___

Ultrix-11 works just fine on two RL02's.

bill