Re: pdp-8/e restoration the next step.

[Jon Elson via cctalk]

On 08/04/2017 05:31 PM, Rod Smallwood via cctalk wrote:

Hi Guys

Thanks for the info so far. Well I have moved on. 
I now have the minimum configuration.


Programmers console, M8300,M8310,M8320,M8330,M849 and 4k 
of core memory.


The M8320 is at the far end of the bus.

Well much as I feared I cant write to memory using Load 
Address , set data to 0001, lift DEP.


Then set address to  again and press EXAM. I should 
see the contents of MD with the selector switch set to MD. 
I don't.


I have checked the correct bus signals go low when the DEP 
switch is lifted.


This is so fundamental somebody must have come across it 
before.


OK, try reading a few locations and see if you can find a 
non-zero one.  If so, go back and read it again.  If it 
still reads the same value, that is a GOOD sign.  it means 
the write-back after a read worked.  If the 2nd read comes 
up zero, it means the write-back failed.  This would tell 
you that the write function of the memory is bad, but the 
read function is OK.


If some portion of the memory CAN read/write, then that 
indicates that either some decode logic or some select 
drivers are not working.  If nothing works, then it could be 
a configuration issue (the plugged-in memory module is not 
set at address zero, for instance) .  But, eventually, you 
would have to trace it through the prints.  Fortunately, the 
PDP-8 is not a terribly complex CPU.


Jon

Re: IBM 5280

[Sam O'nella via cctalk]

What are the 4 games?
null

Re: WTB: RX02 Floppy Disks

[Jerry Weiss via cctalk]

> On Aug 4, 2017, at 1:09 PM, Ulrich Tagge via cctalk  
> wrote:
> 
> Hi Jerry,
>> You’ve made pretty good progress.
> Yes with the right input and help this can happen. ;-)
> And all the help is much appreciated!

Glad to share.

>> 
>> If you haven’t already, Google for and look at the manual for the SQ739. I 
>> think you will find that most of the
>> commands for the on-board diagnostics are the same.  The unibus controller 
>> will have a
>> different layout and perhaps a physical vector switch, but you should be 
>> able to sort out the differences.
>> 
> Not done by now, but is now noted and on the plan for the weekend, I'm also 
> interested to know about the jumper settings as there are some of them

Fortunately the vendor likely used the same firmware for several models and 
across Q + Unibus.  

> .
>> 
>> What version of RT11 do you have?  The later versions would show the
>> CSR that the hander is set to.
> Its: RT-11SJ (S) V04.00I ... quite old.

Each different version of RT11 has its own charms.   In V4 the device handler 
was no longer
bound directly to the OS Monitor.  No more compiling a new monitor for each new 
device.

> 
>>  
>> You mention a RC25.  Is that on another machine? If you have two MSCP
>> controllers in the same backplane (KLESI? + SU723) then that is more complex.
>> 
>> My guidance below assumes the SU723 and a bootable RX02 device are
>> the only disks.  Do not follow if you have two MSCP controllers installed.
> That's the right assumption, I have two /84 one with lesi and working RC25 
> where I have created the Floppy disks, and a playground mostly empty, but now 
> equipped with SCSI and RX211.
>> The address 160340 is not what is normally expected “standard” CSR for a 
>> MSCP.
>> Its is easy to change the handler address.
>> 
>> First make a copy of the DU.SYS handler to preserve it.
>> 
>>copy/sys du.sys duorg.sys
> Done
>> The set the CSR that you are using
>> 
>>set du csr=160340
> Output:
> .SET DU CSR=17760340
> ?DU-W-Patch handler bootstrap, put CSR at 3264

As you may have already learned, use only 16bit addresses for this.

> 
>> Try vector address 154 first, unless you know the board is configured 
>> differently.
>> It appears already set for this, but here is how you change it.
>> 
>>set du vector=154
> Output:
> .SET DU VECTOR=154
> 
> .
>> You should then be able to install and load the handler.
>> 
>> install du
> Output:
> .INSTALL DU
> .
>> load du
> Output:
> .LOAD DU
> 
>> Depending on the DU handler, it is possible to map a large MSCP image to 
>> multiple
>> partitions.  If the handler installs, try the following.  It show a basic 
>> mapping.
>> Single controller, single drive and in this case 8 partitions.   The first 
>> partition
>> should be the same as below.  An RZ22 would normally only have space
>> sufficient for 1 partition.
>> 
>> show de:du
>> 
>> DeviceStatus   CSR Vector(s)
>>-- --   ---
>> -
>>  DU Resident172150   154
>> 
>>  DU0: is set PORT =  0, UNIT =  0, PART =  0
>>  DU1: is set PORT =  0, UNIT =  0, PART =  1
>>  DU2: is set PORT =  0, UNIT =  0, PART =  2
>>  DU3: is set PORT =  0, UNIT =  0, PART =  3
>>  DU4: is set PORT =  0, UNIT =  0, PART =  4
>>  DU5: is set PORT =  0, UNIT =  0, PART =  5
>>  DU6: is set PORT =  0, UNIT =  0, PART =  6
>>  DU7: is set PORT =  0, UNIT =  0, PART =  7
> Output:
> .SHOW DE:DU
> ?KMON-F-Illegal command
> .SHOW DEV:DU
> ?KMON-F-Illegal command
> 
> (RT11 Version to old?)

Yes, bummer but not a blocking gap.

> 
> 
> .SHOW DEV
> 
> Device  Status   Vector
> ---
>  US  Not installed  410
>  DL  Not installed  160
>  RK  Not installed  220
>  DY  Resident   264
>  DX  Not installed  264
>  LP  146676 200 204
>  SC  143332 000
>  HC  Not installed  330 334
>  BS  Not installed  300 304
>  VW  Not installed  270 274
>  NL  Installed  000
>  LS  Installed  200 204
>  MS  Not installed  224
>  MM  Not installed  224
> *  DU  141440 154*
> 
> So something happens and we have a first progress.
> 
>> Since you already did a SCSI format from the controller or if the drive
>> was previously formatted, you will not need to repeat this. The RT11 FORMAT
>> command does NOT support this as an MSCP device.  Note: the handler can be
>> configured to more partitions and disk space than actually exist on the 
>> drive.
>> 
>> You can examine the contents of the drive to see if it readable.
>> 
>> dump/term du0:/end:1
> Dump is unfortunately not available on my disk by 

pdp-8/e restoration the next step.

[Rod Smallwood via cctalk]

Hi Guys

Thanks for the info so far. Well I have moved on. I now have 
the minimum configuration.


Programmers console, M8300,M8310,M8320,M8330,M849 and 4k of core memory.

The M8320 is at the far end of the bus.

Well much as I feared I cant write to memory using Load Address , 
set data to 0001, lift DEP.


Then set address to  again and press EXAM. I should see the contents 
of MD with the selector switch set to MD. I don't.


I have checked the correct bus signals go low when the DEP switch is lifted.

This is so fundamental somebody must have come across it before.

I have a good Tek 475A scope available.

Answers please

Rod


--
Wanted one pdp-8/i rocker switch leaver to copy.

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: IBM 5280

[Al Kossow via cctalk]

On 8/4/17 9:23 AM, Al Kossow via cctalk wrote:

> weird, it doesn't look like I scanned these. I thought I did..

I did, it's under "528x" but OS X collation puts it with 3 digit part numbers 
(grrr..)

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: SPARCstation 20 and dual CPUs

[Mike Loewen via cctalk]

On Fri, 4 Aug 2017, systems_glitch via cctalk wrote:


Indeed, you'll need 2.25R if you want to use some Ross HyperSPARC modules.
I don't know if the ROM image is available on the Internet nowadays, but
I've got a 2.25R ROM in one of my SS10s, I could dump it for you if you
can't find it elsewhere.


   There's a Ross 2.25r image on this page:

http://home.earthlink.net/~reif/

   Not sure if it's the right one for a SS20.


Mike Loewen mloe...@cpumagic.scol.pa.us
Old Technology  http://q7.neurotica.com/Oldtech/

Re: pdp-8/e restoration.

[Ian S. King via cctalk]

Yes, the 8/e has the 'keep-alive current'.  The lamps are driven by an 8V
line that runs from the power supply to the programmer's panel.  -- Ian

On Fri, Aug 4, 2017 at 8:23 AM, Doug Ingraham via cctalk <
cctalk@classiccmp.org> wrote:

> On Fri, Aug 4, 2017 at 1:24 AM, Rod Smallwood via cctalk <
> cctalk@classiccmp.org> wrote:
>
> > 1. Should the run light glow dimly?
> >
>
> Without looking at the schematics I can't tell you if they bothered to put
> the resistor in there to make
> it glow dimly but I can tell you that it isn't necessary for the run lamp.
> The reason to make it glow
> dimly when off is to reduce the filament thermal shock when turning on and
> off.  This makes the bulbs
> last a lot longer.  The run lamp does not flicker in operation so not
> necessary on that one.
>
> --
> Doug Ingraham
> PDP-8 SN 1175
>



-- 
Ian S. King, MSIS, MSCS, Ph.D. Candidate
The Information School 
Dissertation: "Why the Conversation Mattered: Constructing a Sociotechnical
Narrative Through a Design Lens

Archivist, Voices From the Rwanda Tribunal 
Value Sensitive Design Research Lab 

University of Washington

There is an old Vulcan saying: "Only Nixon could go to China."

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: IBM 5280

[Al Kossow via cctalk]

and we do have a 5285
http://www.computerhistory.org/collections/catalog/102633515

I need to see if that floppy in the picture is still in the left-hand drive


On 8/4/17 11:34 AM, Al Kossow via cctalk wrote:
> I just uploaded GA21-9353-1_5280_Functions_Reference_Manual_Apr81 w/o OCR
> to bitsavers.org/pdf/ibm/5280 mirrors should have it in an hour
> 
> that is essentially the architecture manual
> 
> I'll do some more work on the manuals once a big OCR batch job finishes
> 
> The floppies we have are utils, comm utils, and DE/RPG
> I'll see if I can get to those this weekend.
> 
> On 8/4/17 9:23 AM, Al Kossow via cctalk wrote:
>>
>>
>> On 8/4/17 9:20 AM, Al Kossow via cctalk wrote:
>>> https://halsoft.wordpress.com/2008/06/02/the-next-generation-key-punch-the-ibm-5280/
>>>
>>> http://www.computerhistory.org/collections/catalog/102675777
>>>
>>> i'll see what's there..
>>>
>>
>> weird, it doesn't look like I scanned these. I thought I did..
>>
>> http://www.computerhistory.org/collections/search/?s=ibm+5280
>>
>>
> 

Re: SPARCstation 20 and dual CPUs

[systems_glitch via cctalk]

Indeed, you'll need 2.25R if you want to use some Ross HyperSPARC modules.
I don't know if the ROM image is available on the Internet nowadays, but
I've got a 2.25R ROM in one of my SS10s, I could dump it for you if you
can't find it elsewhere.

IIRC, the standard TI SuperSPARC modules don't require a different ROM.

Thanks,
Jonathan

On Fri, Aug 4, 2017 at 2:57 PM, Erik Baigar via cctalk <
cctalk@classiccmp.org> wrote:

>
>
> On Fri, 4 Aug 2017, John P. Willis via cctalk wrote:
>
> Does anyone know if there is some physical jumper or OpenBoot parameter
>> required in order to enable multiprocessor support on a SPARCstation 20?
>>
>
> I do not know of such a switch/jumper. Both my SS2 I upgraded
> to 2-CPU and 2*2 CPU did not require some change to the
> NVRAM settings or changing a jumper. But there was a FirwarePROM
> with the CPU-Sets (HyperSPARC). Probably you should try moving
> not only the CPU but also the EPROM with firmware to check this...
>
> Best regards from Germany,
>
> Erik.
>
>

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: SPARCstation 20 and dual CPUs

[Erik Baigar via cctalk]

On Fri, 4 Aug 2017, John P. Willis via cctalk wrote:

Does anyone know if there is some physical jumper or OpenBoot parameter 
required in order to enable multiprocessor support on a SPARCstation 20?


I do not know of such a switch/jumper. Both my SS2 I upgraded
to 2-CPU and 2*2 CPU did not require some change to the
NVRAM settings or changing a jumper. But there was a FirwarePROM
with the CPU-Sets (HyperSPARC). Probably you should try moving
not only the CPU but also the EPROM with firmware to check this...

Best regards from Germany,

Erik.

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: WTB: RX02 Floppy Disks

[Ulrich Tagge via cctalk]

Hi Jerry,

You’ve made pretty good progress.

Yes with the right input and help this can happen. ;-)
And all the help is much appreciated!


If you haven’t already, Google for and look at the manual for the SQ739. I 
think you will find that most of the
commands for the on-board diagnostics are the same.  The unibus controller will 
have a
different layout and perhaps a physical vector switch, but you should be able 
to sort out the differences.

Not done by now, but is now noted and on the plan for the weekend, I'm 
also interested to know about the jumper settings as there are some of them.


What version of RT11 do you have?  The later versions would show the
CSR that the hander is set to.

Its: RT-11SJ (S) V04.00I ... quite old.

  


You mention a RC25.  Is that on another machine? If you have two MSCP
controllers in the same backplane (KLESI? + SU723) then that is more complex.

My guidance below assumes the SU723 and a bootable RX02 device are
the only disks.  Do not follow if you have two MSCP controllers installed.
That's the right assumption, I have two /84 one with lesi and working 
RC25 where I have created the Floppy disks, and a playground mostly 
empty, but now equipped with SCSI and RX211.

The address 160340 is not what is normally expected “standard” CSR for a MSCP.
Its is easy to change the handler address.

First make a copy of the DU.SYS handler to preserve it.

copy/sys du.sys duorg.sys

Done

The set the CSR that you are using

set du csr=160340

Output:
.SET DU CSR=17760340
?DU-W-Patch handler bootstrap, put CSR at 3264


Try vector address 154 first, unless you know the board is configured 
differently.
It appears already set for this, but here is how you change it.

set du vector=154

Output:
.SET DU VECTOR=154

.

You should then be able to install and load the handler.

 install du

Output:
.INSTALL DU
.

 load du

Output:
.LOAD DU


Depending on the DU handler, it is possible to map a large MSCP image to 
multiple
partitions.  If the handler installs, try the following.  It show a basic 
mapping.
Single controller, single drive and in this case 8 partitions.   The first 
partition
should be the same as below.  An RZ22 would normally only have space
sufficient for 1 partition.

 show de:du

 DeviceStatus   CSR Vector(s)
-- --   ----
  DU Resident172150   154

  DU0: is set PORT =  0, UNIT =  0, PART =  0
  DU1: is set PORT =  0, UNIT =  0, PART =  1
  DU2: is set PORT =  0, UNIT =  0, PART =  2
  DU3: is set PORT =  0, UNIT =  0, PART =  3
  DU4: is set PORT =  0, UNIT =  0, PART =  4
  DU5: is set PORT =  0, UNIT =  0, PART =  5
  DU6: is set PORT =  0, UNIT =  0, PART =  6
  DU7: is set PORT =  0, UNIT =  0, PART =  7

Output:
.SHOW DE:DU
?KMON-F-Illegal command
.SHOW DEV:DU
?KMON-F-Illegal command

(RT11 Version to old?)


.SHOW DEV

Device  Status   Vector
---
  US  Not installed  410
  DL  Not installed  160
  RK  Not installed  220
  DY  Resident   264
  DX  Not installed  264
  LP  146676 200 204
  SC  143332 000
  HC  Not installed  330 334
  BS  Not installed  300 304
  VW  Not installed  270 274
  NL  Installed  000
  LS  Installed  200 204
  MS  Not installed  224
  MM  Not installed  224
*  DU  141440 154*

So something happens and we have a first progress.


Since you already did a SCSI format from the controller or if the drive
was previously formatted, you will not need to repeat this. The RT11 FORMAT
command does NOT support this as an MSCP device.  Note: the handler can be
configured to more partitions and disk space than actually exist on the drive.

You can examine the contents of the drive to see if it readable.

 dump/term du0:/end:1
Dump is unfortunately not available on my disk by now, but will add 
them, when I have moved the RX02 back to the other PDP.

If the handler loads but doesn’t access the drive, check the vector address 
first.

Once you are sure the contents are not needed, you can try an initialize.


Good luck.

Jerry
j...@ieee.org


Is it maybe better to start with a newer version of RT11?
In the meantime I have managed to test RX02 Imaging with Joeg Hoppe's 
PDP11GUI. Works perfect and looks like a great tool.
If I load the MSCP driver via PDP11GUI and use address 160340 I can also 
dump the DU0 (RZ22) disk to my PC, so it seams to be working.


I have not found a newer RX02 RT11 Distribution Set by now, do you have 
some tip were I can find and download one?  Google doesn't return any 
rx02 files, only ready to use images for 

SPARCstation 20 and dual CPUs

[John P. Willis via cctalk]

Hello all,

Does anyone know if there is some physical jumper or OpenBoot parameter 
required in order to enable multiprocessor support on a SPARCstation 20?


Have tried two sets of known-good, matching processors, both sets of which
worked in another SS20, but this SS20 shows only CPU#0.

Thanks!

--
JP Willis j...@chivanet.org Voice 575/520-9542 Fax 
575/449-4122
ChivaNet Internet Services, 425 S. Telshor Blvd., Ste. C202, Las Cruces, NM  
88011
Hardware, n.:  The parts of a computer system that can be kicked.   
(Borrowed)
--

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: IBM 5280

[Al Kossow via cctalk]

I just uploaded GA21-9353-1_5280_Functions_Reference_Manual_Apr81 w/o OCR
to bitsavers.org/pdf/ibm/5280 mirrors should have it in an hour

that is essentially the architecture manual

I'll do some more work on the manuals once a big OCR batch job finishes

The floppies we have are utils, comm utils, and DE/RPG
I'll see if I can get to those this weekend.

On 8/4/17 9:23 AM, Al Kossow via cctalk wrote:
> 
> 
> On 8/4/17 9:20 AM, Al Kossow via cctalk wrote:
>> https://halsoft.wordpress.com/2008/06/02/the-next-generation-key-punch-the-ibm-5280/
>>
>> http://www.computerhistory.org/collections/catalog/102675777
>>
>> i'll see what's there..
>>
> 
> weird, it doesn't look like I scanned these. I thought I did..
> 
> http://www.computerhistory.org/collections/search/?s=ibm+5280
> 
> 

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.

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

[Noel Chiappa via cctalk]

> From: Emanuel Stiebler

> If I would do it again, it would be USB only with some sd-card slots.

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, on
the grounds that the analog part at that speed would be too tricky for us.

> 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.

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.

(That's the general approach I prefer for prototyping - get the very simplest
possible thing working, then add things. That seems to be better, overall;
probably because i) the first stage is easier to debug, because you're dealing
with the least complicated possible system, and ii) when adding things, you
know the rest of the system is functioning, so any problems have to be in the
piece you just added.)

>> (Of course, that issue we had with noise, and the wierd latching
>> inputs, made it even more painful...)

> 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).

Noel

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: IBM 5280

[Al Kossow via cctalk]

On 8/4/17 9:20 AM, Al Kossow via cctalk wrote:
> https://halsoft.wordpress.com/2008/06/02/the-next-generation-key-punch-the-ibm-5280/
> 
> http://www.computerhistory.org/collections/catalog/102675777
> 
> i'll see what's there..
> 

weird, it doesn't look like I scanned these. I thought I did..

http://www.computerhistory.org/collections/search/?s=ibm+5280

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: pdp-8/e restoration.

[Doug Ingraham via cctalk]

On Fri, Aug 4, 2017 at 1:24 AM, Rod Smallwood via cctalk <
cctalk@classiccmp.org> wrote:

> 1. Should the run light glow dimly?
>

Without looking at the schematics I can't tell you if they bothered to put
the resistor in there to make
it glow dimly but I can tell you that it isn't necessary for the run lamp.
The reason to make it glow
dimly when off is to reduce the filament thermal shock when turning on and
off.  This makes the bulbs
last a lot longer.  The run lamp does not flicker in operation so not
necessary on that one.

-- 
Doug Ingraham
PDP-8 SN 1175

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: Convex documentation online (C220 arrived)

[Ethan via cctalk]

My Convex C220 arrived about a week ago, so I now have a C1, C1 XL, and a
C220. A C240 will follow in a few weeks. Along with the C220 came some
installation tapes, and a large volume of documentation (some 300
documents). As long as I don¹t receive any objections to the being online
from HP (current owner of Convex), I¹ve put most of the loose-leaf hardware
documentation online at


Amazing! I saw a Convex system at auction many years ago, didn't think I 
would ever see another one in the wild let alone being restored to working 
condition. Kudos!


- Ethan


--
Ethan O'Toole

Re: Convex documentation online (C220 arrived)

[Al Kossow via cctalk]

On 8/3/17 2:45 PM, Curious Marc via cctech wrote:
> Wow, that's mighty impressive. I knew about your FPGA 360/65 project but had 
> never seen your website before.

There is also a simulation book in the works in cooperation with 'vaxman' 
http://www.analogmuseum.org/english/about_me/

https://www.lehmanns.de/shop/mathematik-informatik/33158923-9783110413199-simulation-of-computers

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: pdp-8/e restoration.

[Jon Elson via cctalk]

On 08/04/2017 02:24 AM, Rod Smallwood via cctalk wrote:



Programmers console is in its slot. Bad bulbs (not LEDs)  have been 
replaced


Power up and all the lamps come on either bright or dim (off) except 
the RUN light.


So questions:

1. Should the run light glow dimly?

Probably all lights should glow very dimly.  DEC put a resistor across 
the transistor to put a slight warming current through the bulb.  This 
reduces shock to the filament every time it is turned on.
(This info is from other DEC machines, not PDP-8, but I'm pretty sure 
they would do the same there.)


Jon

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: WTB: RX02 Floppy Disks

[Jerry Weiss via cctalk]

> On Aug 3, 2017, at 4:28 PM, Ulrich Tagge via cctalk  
> wrote:
> 
> Hi All,
> All my 8" SSDD /SSSDdisks are non formatted, which was the reason for my 
> initial troubles.
> Nevertheless, my IBM System /23 (Type 5324) can format disks in three 
> different formats:
> 
> _1. IBM System /23 Format_
> 512 Bytes per Sector
> Possible Disk: SSSD, SSDD, DSDD
> 
> _2. Standard Format_
> 128 Bytes per Sector
> Possible Disk: SSSD, SSDD
> 
> _3. H- Format_
> 258 Bytes per Sector
> Possible Disk: DSDD
> 
> _So option 2_ was the right one, also when nothing in the docs point to the 
> IBM 3740 format.
> After booting the System/23 with the inserted maintenance Disk VOL002 the 
> formatter program can be started with the following command: link prepare
> 
> 
> By now I have 20 RX02 Disks formatted, and was also able to create a bootable 
> RT11 Disk via my running RT11 installation on my RC25.
> It is RT-11SJ (S) V04.00I ...
> >>>
> .FORMAT DY1:
> DY1:/FORMAT-Are you sure?Y
> ?FORMAT-I-Formatting complete
> <<<
> >>>
> .INIT/BAD DY1:
> DY1:/Initialize; Are you sure? Y
> ?DUP-I-No bad blocks detected DY1:
> <<<
> 
> Next step would be to install RT11 on my SCSI Disk, which is presented 
> through a Dilog SU726A as MSCP Device 0 (Address 160340 (will be 1760340 on 
> my PDP-11/84)) to the system.
> Disk is an DEC RZ22 and was also formatted and mapped, through the Dilog 
> "BIOS" (Jumper J14 in to boot Maintenance Address ... and @175000g followed 
> by FT)
> Now it looks like I need the SU726A manual, as I have no clue as which device 
> RT11 should recognize the Dilog, I assume DU0: but RT11 doesn't load the 
> Device.
> 

Hi Ulrich,
You’ve made pretty good progress.

If you haven’t already, Google for and look at the manual for the SQ739. I 
think you will find that most of the 
commands for the on-board diagnostics are the same.  The unibus controller will 
have a 
different layout and perhaps a physical vector switch, but you should be able 
to sort out the differences. 



> *SHOW DEV*
> 
> Device  Status   Vector
> ---
>  US  Not installed  410
>  DL  Not installed  160
>  DU  Not installed  154
>  RK  Not installed  220
>  DY  Resident   264
>  DX  Not installed  264
>  LP  146676 200 204
>  SC  143332 000
>  HC  Not installed  330 334
>  BS  Not installed  300 304
>  VW  Not installed  270 274
>  NL  Installed  000
>  LS  Installed  200 204
>  MS  Not installed  224
>  MM  Not installed  224

What version of RT11 do you have?  The later versions would show the 
CSR that the hander is set to.   

You mention a RC25.  Is that on another machine? If you have two MSCP 
controllers in the same backplane (KLESI? + SU723) then that is more complex.

My guidance below assumes the SU723 and a bootable RX02 device are
the only disks.  Do not follow if you have two MSCP controllers installed.

> 
> 
> 
> Any Hint how I get RT11 load the correct device so that I can format and init 
> the SCSI Disk?
> Is maybe Someone here with an Manual of the Dilog? A SU723 could be also 
> helpful, …


The address 160340 is not what is normally expected “standard” CSR for a MSCP. 
Its is easy to change the handler address.

First make a copy of the DU.SYS handler to preserve it.

   copy/sys du.sys duorg.sys 

The set the CSR that you are using

   set du csr=160340

Try vector address 154 first, unless you know the board is configured 
differently.
It appears already set for this, but here is how you change it.

   set du vector=154

You should then be able to install and load the handler.

install du
load du

Depending on the DU handler, it is possible to map a large MSCP image to 
multiple
partitions.  If the handler installs, try the following.  It show a basic 
mapping.
Single controller, single drive and in this case 8 partitions.   The first 
partition
should be the same as below.  An RZ22 would normally only have space
sufficient for 1 partition.

show de:du

DeviceStatus   CSR Vector(s)
   -- --   ----
 DU Resident172150   154

 DU0: is set PORT =  0, UNIT =  0, PART =  0
 DU1: is set PORT =  0, UNIT =  0, PART =  1
 DU2: is set PORT =  0, UNIT =  0, PART =  2
 DU3: is set PORT =  0, UNIT =  0, PART =  3
 DU4: is set PORT =  0, UNIT =  0, PART =  4
 DU5: is set PORT =  0, UNIT =  0, PART =  5
 DU6: is set PORT =  0, UNIT =  0, PART =  6
 DU7: is set PORT =  0, UNIT =  0, PART =  7

Since you already did a SCSI format from the controller or if the drive 
was previously formatted, you will not need to repeat this. The 

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: 90s Computers to a good home.

[Kristian Valind via cctalk]

I'd also be interested in one of the rs/6000 machines, though i'm located
in Sweden making shipping a potential issue for me as well.

Best regards,
Kristian Valind

ons 2 aug. 2017 kl. 02:16 skrev Henry via cctalk :

> So in good news I'm getting married, to a beautiful American I'm stealing
> to more temperate climates. South East UK. Long story short it's her or the
> PCs, especially as I have to take on all of "stuff" and I'm quite sure
> donating my two rs/6000-f50s gives me the space.
> I am not using this as surrogate eBay, more if I can give a PC I've had
> rather than selling it to an unknown on eBay.
>
> I also have single core , 128mb ram, SPARCstation, running openbsd.
>
> And a DEC vt510
>
> Throw me an email if anything interests you here,
>
> Regards
> -- H
>
> Sent from my Blackphone with K-9 Mail. Please excuse my brevity.
>

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 ...

IBM 5280

[Christian Corti via cctalk]

So, we've got an IBM 5285 (5280 series) programmable data station. This is 
a *heavy* and nice beast ;-) Its architecture is a bit unusual but 
interesting. Problem is, I don't have any software for it expect one disk 
that IPLs and that contains four more or less crappy games.

(can be found at ftp://computermuseum.informatik.uni-stuttgart.de/ibm/ibm5285/)

I would be very thankful for any disk images for that system, especially 
the diagnostics, utilities and SCP, but also the assembler and other 
languages.


Christian

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