Re: RX02 *.DSK convert to PDP11GUI Image format

[Jerry Weiss via cctalk]

> On Aug 15, 2017, at 2:33 PM, Don North  wrote:
> 
> On 8/15/2017 2:10 AM, Jerry Weiss via cctalk wrote:
>>> ...
>> 
>> As far as the DSK format, the files from at Alan’s site are logical
>> disk images.  Logical block 0,1,2,3 from from a DY sized volume starting at
>> Track 1.  In this case track 0 is ignored.
>> 
>> This is what RT-11 expects and uses for Logical Disks (LD:).
>> I’ve used Kermit and FTP to copy this file from my OSX disk to
>> a RT-11 DU type drive as a file. They mount and operate as
>> LD: drive without additional conversion.
>> 
>> 
>> SIMH on the other hand as I understand it, expects disk images to represent
>> the sectors of a disk.  I did a few checks and its appears faithful to the 
>> RX02 format.
>> It expects 256 byte sectors for track 0 (qty 26) and 512 byte sectors
>> for the rest of the disk as Don pointed out.  You need to prepend 6556. bytes
>> of zero to the above file to get things started. But this is not the entire 
>> story.
>> 
>> $  dd of=pad.dsk if=/dev/zero bs=256 count=26
>> 6656 bytes transferred in 0.000230 secs
>> $  cat pad.dsk tcpipm.dsk >tcpipm_V2.dsk
>>  When you attach tcpipm_V2.dsk in SIMH to an RY device (DY to RT-11), the 
>> expected
>> boot block is visible as (RT-11) Block #0.
>> 
>> .dump/rad50/ascii/end:0 dy:/term
>> DY:/X/E:0
>> BLOCK NUMBER  00
>> 000/ 000240 05 000404 00 00 041420 116020 000400 * 
>> ..C*
>>   D   E FT  J*HX82 FP
>> 020/ 004067 44 15 00 005000 041077 047517 026524 
>> *7.$...?BOOT-*
>>  ALW  6  M   AX JW9L$WGJD
>> 040/ 026525 067516 061040 067557 020164 067157 073040 066157 *U-No boot 
>> on vol*
>>  GJEQ2NO. Q3GEG.QZ1R6 QM9
>> 060/ 066565 006545 005012 000200 105737 177564 100375 112037 
>> *ume._.t.}…*
>> 
>> For an RT-11 Volume, the next logical block #1 should be the home block.  In 
>> this case,
>> its not. Instead it is found at block #7, but offset (early) -256. bytes 
>> from its normal location in the block.
>> The first directory block should start at block #6.  Here there directory 
>> blocks starting at block #3 and #4.
>> 
>> So the padding is not enough here.  The 6 sector skew and interleave 
>> implemented in the handler come
>> into play.  I haven’t looked at the code, but SIMH probably expects the disk 
>> to be sequential copies of
>> physical sectors for the floppy drives.  This makes sense, as the emulator 
>> presents them to the DY: handler
>> where it will de-skew the data.
>> 
>> Thus a DSK file representing logical blocks will not work for a floppy image 
>> in this case.
>> A small program can probably be written to skew/Interweave the data to make 
>> them usable directly in SIMH.
>> 
>> Images of most other DEC media probably don’t encounter the problem, as 
>> their device handler or driver doesn't
>> implement either skew or interleave directly.  Most of the ones I encounter 
>> leave that to the disk media formatting
>> and/or controller firmware.
>> 
>> 
>> Jerry
>> j...@ieee.org
>> 
> Jerry's analysis is spot on. What Alan generated on his site were 988. block 
> long logical container files, not RX02 device file images.
> 
> One could write a simple program that reads the binary ".DSK" file, and 
> implements the track 0 prepend, 2:1 sector interlave, and +6 sector track to 
> track offset to generate true ".RX2" disk images with the appropriate sector 
> interleaves, as an exact image of the RX02 media. This .RX2 file would be 
> mountable directly under SIMH (and presumably PDP11GUI) as an emulated RX02 
> device.
> 
> One simple (heh) way to do the conversion without having to do any 
> programming would be to use SIMH running RT11. Boot RT11 from some media (say 
> RL02) and then mount the .DSK file as an MSCP device image (MSCP supports 
> variable sized physical disks using logical block order). Then mount an RX02 
> device under RT11; it will use the native SIMH .RX2 file format. Then under 
> RT11 copy 988. blocks from the MSCP (DU) device to the RX02 (DY) device. RT11 
> thru its RX02 driver will handle all the low level details of skipping track 
> 0, sector-sector interleave, and track-track sector skew.
> 


I had just sent Ulrich a new copy of TCPIPM.DSK created using SIMH  to bridge 
between Logical disk images and Sector image files when Don’s note came in.
Ulrich reports that he was able download file attached via RY created in SIMH 
via PDP11GUI to a real RX02. He then was able to successfully read the files.   

Thanks to Don and others who sent in pointers that helped us sort this process 
out.   

Jerry
j...@ieee.org

RE: DECstation 220. Another Impasse

[Rob Jarratt via cctalk]

> 
> Some great ideas Peter, thanks! I will double check the scope, I wonder if
mine
> doesn't have the bandwidth to show a glitch that is occurring? I will
consider
> cutting the track, which is also a great idea. I really do have to hope
that it isn't
> the gate array, it is my last resort, although that was closer to the
leakage
> damage than the 74LS126.
> 

I was out most of this evening, but I just had a quick look again and think
I have found something significant. Comparing the gate array pins on the two
boards I have, I see that on the board where the video is corrupted, there
are two pins that appear connected to 0V that are not connected to 0V on the
spare motherboard.

I have yet to attempt to trace the connections to these pins, I will do that
tomorrow as it is late here now, but I suspect it does not bode well for the
gate array :-(

Regards

Rob

Re: RX02 *.DSK convert to PDP11GUI Image format

[Fred Cisin via cctalk]

Howzbout:

Make a metadata file that is exactly 6656 bytes long that provides 
identification information, including whether it is physical sector V 
logical block sequence, and even a short summary of why.

Re: RX02 *.DSK convert to PDP11GUI Image format

[Don North via cctalk]

On 8/15/2017 2:10 AM, Jerry Weiss via cctalk wrote:

On Aug 14, 2017, at 11:49 PM, Glen Slick via cctalk  
wrote:

On Sun, Aug 13, 2017 at 9:00 AM, Ulrich Tagge via cctalk
 wrote:

Hi all,

maybe someone can help.
I would like to install TCP/IP on my RT-11 system.
After a short search I have found the following, which I would use:
http://www.classiccmp.org/PDP-11/RT-11/freeware/decus11/110939/rthtml/tcpget.htm
But the images are in DSK format, but I can't write them with PDP11GUI,
which is the only way I have at the moment.

I would take a quick look at those .DSK images to see what I can make
of them, but none of the download links on that page work for me.

For example, I can't download this .DSK image. Do these links work for
other people?
ftp://shop-pdp.kent.edu/du3:/tcpip.pkg/tcpipm.dsk

Glen - Try this link  ftp://shop-pdp.net/pub/tcpip/tcpip/tcpipm.dsk

As far as the DSK format, the files from at Alan’s site are logical
disk images.  Logical block 0,1,2,3 from from a DY sized volume starting at
Track 1.  In this case track 0 is ignored.

This is what RT-11 expects and uses for Logical Disks (LD:).
I’ve used Kermit and FTP to copy this file from my OSX disk to
a RT-11 DU type drive as a file. They mount and operate as
LD: drive without additional conversion.


SIMH on the other hand as I understand it, expects disk images to represent
the sectors of a disk.  I did a few checks and its appears faithful to the RX02 
format.
It expects 256 byte sectors for track 0 (qty 26) and 512 byte sectors
for the rest of the disk as Don pointed out.  You need to prepend 6556. bytes
of zero to the above file to get things started. But this is not the entire 
story.

 $  dd of=pad.dsk if=/dev/zero bs=256 count=26
 6656 bytes transferred in 0.000230 secs
 $  cat pad.dsk tcpipm.dsk >tcpipm_V2.dsk
  
When you attach tcpipm_V2.dsk in SIMH to an RY device (DY to RT-11), the expected

boot block is visible as (RT-11) Block #0.

 .dump/rad50/ascii/end:0 dy:/term
 DY:/X/E:0
 BLOCK NUMBER  00
 000/ 000240 05 000404 00 00 041420 116020 000400 * 
..C*
   D   E FT  J*HX82 FP
 020/ 004067 44 15 00 005000 041077 047517 026524 
*7.$...?BOOT-*
  ALW  6  M   AX JW9L$WGJD
 040/ 026525 067516 061040 067557 020164 067157 073040 066157 *U-No boot on 
vol*
  GJEQ2NO. Q3GEG.QZ1R6 QM9
 060/ 066565 006545 005012 000200 105737 177564 100375 112037 
*ume._.t.}…*

For an RT-11 Volume, the next logical block #1 should be the home block.  In 
this case,
its not. Instead it is found at block #7, but offset (early) -256. bytes from 
its normal location in the block.
The first directory block should start at block #6.  Here there directory 
blocks starting at block #3 and #4.

So the padding is not enough here.  The 6 sector skew and interleave 
implemented in the handler come
into play.  I haven’t looked at the code, but SIMH probably expects the disk to 
be sequential copies of
physical sectors for the floppy drives.  This makes sense, as the emulator 
presents them to the DY: handler
where it will de-skew the data.

Thus a DSK file representing logical blocks will not work for a floppy image in 
this case.
A small program can probably be written to skew/Interweave the data to make 
them usable directly in SIMH.

Images of most other DEC media probably don’t encounter the problem, as their 
device handler or driver doesn't
implement either skew or interleave directly.  Most of the ones I encounter 
leave that to the disk media formatting
and/or controller firmware.


Jerry
j...@ieee.org

Jerry's analysis is spot on. What Alan generated on his site were 988. block 
long logical container files, not RX02 device file images.


One could write a simple program that reads the binary ".DSK" file, and 
implements the track 0 prepend, 2:1 sector interlave, and +6 sector track to 
track offset to generate true ".RX2" disk images with the appropriate sector 
interleaves, as an exact image of the RX02 media. This .RX2 file would be 
mountable directly under SIMH (and presumably PDP11GUI) as an emulated RX02 device.


One simple (heh) way to do the conversion without having to do any programming 
would be to use SIMH running RT11. Boot RT11 from some media (say RL02) and then 
mount the .DSK file as an MSCP device image (MSCP supports variable sized 
physical disks using logical block order). Then mount an RX02 device under RT11; 
it will use the native SIMH .RX2 file format. Then under RT11 copy 988. blocks 
from the MSCP (DU) device to the RX02 (DY) device. RT11 thru its RX02 driver 
will handle all the low level details of skipping track 0, sector-sector 
interleave, and track-track sector skew.


Don

Re: nassa tapes destroyed but the family left to dispose of the computer?

[Eric Christopherson via cctalk]

On Sun, Aug 13, 2017 at 7:19 PM, Al Kossow via cctalk  wrote:

> https://motherboard.vice.com/en_us/article/kzakkn/nasa-
> destroyed-hundreds-of-mystery-tapes-found-in-a-dead-mans-
> basement-apollo-era
>
> well, a metal scrapper contacted NASA, so I would imagine with him.
>
> at least we know now a little more about where the FOIA request came from
>

I haven't seen anything in the coverage about what the intent of the FOIA
request was. Does anyone know?


>
>
>
> On 8/13/17 4:01 PM, Ed via cctalk wrote:
> > wonder where it  ended up?
>
>


-- 
Eric Christopherson

RE: DECstation 220. Another Impasse

[Rob Jarratt via cctalk]

> -Original Message-
> From: cctalk [mailto:cctalk-boun...@classiccmp.org] On Behalf Of Peter
> Coghlan via cctalk
> Sent: 15 August 2017 09:48
> To: General Discussion: On-Topic and Off-Topic Posts

> Subject: RE: DECstation 220. Another Impasse
> 
> >
> > I have looked at this problem a little more. I have two motherboards,
> > neither of which work, but one at least produces a corrupted video
pattern.
> > The one that works best appears not to be writing to the video memory.
> > When I look at the EMEM pin on the Paradise PVGA1A chip I can see a
> > signal but the scope shows a trace that is very faint. When I look at
> > the same pin on the other motherboard, I get a nice clear bright trace
> > on the scope, using all the same settings on the scope. This pin is
> > driven by a non-inverting buffer (74LS126). The input side of the
> > buffer is tied to 0V, the enable signal comes from a custom gate
> > array. Comparing the buffer's enable signal on the two boards I see
> > the same dimming effect on the board with the corrupted video pattern,
and
> no dimming on the other board.
> >
> 
> A dim trace suggests that the trace is changing too rapidly to see it
properly.
> Try increasing the scope brightness and sweep rate and adjusting the
various
> triggering options to see if you can get a better trace that reveals what
is really
> happening at that pin.  It might be useful to try triggering the scope
from
> whatever clock is used locally as the signal might be synchronised to
that.
> Once you can see the trace properly, it should be easier to figure out
where it
> is coming from.
> 
> >
> > I have checked the other pins on both the buffer and the gate array
> > and I don't see anything suspicious.
> >
> 
> It may be worth looking very closely at the power supply pins for
difficult to see
> spikes that might be caused by decoupling failures.
> It would also be good to make sure ground is really ground at the chips in
> question.
> 
> >
> > I am thinking of speculatively replacing the 74LS126 because I can go
> > and buy replacement parts for it, I can't replace the gate array
> > (although I could conceivably swap the part on the two boards).
> >
> 
> If the 74LS126 has some fault at it's input which is affecting the signal
coming
> from the gate array, it seems to me that it would be more likely to load
it down
> or up rather than cause it to change rapidly (if that is in fact what it
is doing),
> unless it has somehow managed to turn itself into an oscillator.
> 
> On the other hand, if the gate array output is open collector, it could be
relying
> on the 74LS126 to provide a collector load and not getting it if the
74LS126 is
> faulty.  This seems unlikely though.
> 
> I suppose another possibility is that the gate array output could be
tristate and
> not enabled leading to noise pickup from nearby traces and components and
> perhaps across the PCB surface, given there was a battery leak at some
point.
> 
> Getting back to the oscillator theory, I wonder if it is possible that the
non-
> inverting buffer could be oscillating at a much higher frequency than
normally
> found on the board due to feedback from it's output to it's input as
result of the
> battery leakage?
> 
> I don't normally like suggesting cutting tracks but if the board already
has
> damaged and repaired tracks, you might feel ok about cutting the track
> between the gate array and the 74LS126 to determine which of them (or both
> together) is responsible for the unusual signal there.
> 
> I would be very wary of replacing the unobtainable gate array with your
only
> replacement until all other possiblities are eliminated in case the gate
array
> was damaged by a fault elsewhere.
> 
> Looks like I've provided more questions than answers :-(
> 


Some great ideas Peter, thanks! I will double check the scope, I wonder if
mine doesn't have the bandwidth to show a glitch that is occurring? I will
consider cutting the track, which is also a great idea. I really do have to
hope that it isn't the gate array, it is my last resort, although that was
closer to the leakage damage than the 74LS126.

Regards

Rob

RE: DECstation 220. Another Impasse

[Peter Coghlan via cctalk]

>
> I have looked at this problem a little more. I have two motherboards,
> neither of which work, but one at least produces a corrupted video pattern.
> The one that works best appears not to be writing to the video memory. When
> I look at the EMEM pin on the Paradise PVGA1A chip I can see a signal but
> the scope shows a trace that is very faint. When I look at the same pin on
> the other motherboard, I get a nice clear bright trace on the scope, using
> all the same settings on the scope. This pin is driven by a non-inverting
> buffer (74LS126). The input side of the buffer is tied to 0V, the enable
> signal comes from a custom gate array. Comparing the buffer's enable signal
> on the two boards I see the same dimming effect on the board with the
> corrupted video pattern, and no dimming on the other board.
>

A dim trace suggests that the trace is changing too rapidly to see it properly.
Try increasing the scope brightness and sweep rate and adjusting the various
triggering options to see if you can get a better trace that reveals what is
really happening at that pin.  It might be useful to try triggering the scope
from whatever clock is used locally as the signal might be synchronised to that.
Once you can see the trace properly, it should be easier to figure out where
it is coming from.

>
> I have checked the other pins on both the buffer and the gate array and I
> don't see anything suspicious.
>

It may be worth looking very closely at the power supply pins for
difficult to see spikes that might be caused by decoupling failures.
It would also be good to make sure ground is really ground at the chips
in question.

>
> I am thinking of speculatively replacing the 74LS126 because I can go and
> buy replacement parts for it, I can't replace the gate array (although I
> could conceivably swap the part on the two boards).
>

If the 74LS126 has some fault at it's input which is affecting the signal
coming from the gate array, it seems to me that it would be more likely
to load it down or up rather than cause it to change rapidly (if that is
in fact what it is doing), unless it has somehow managed to turn itself
into an oscillator.

On the other hand, if the gate array output is open collector, it could be
relying on the 74LS126 to provide a collector load and not getting it if
the 74LS126 is faulty.  This seems unlikely though.

I suppose another possibility is that the gate array output could be
tristate and not enabled leading to noise pickup from nearby traces and
components and perhaps across the PCB surface, given there was a battery
leak at some point.

Getting back to the oscillator theory, I wonder if it is possible that
the non-inverting buffer could be oscillating at a much higher frequency
than normally found on the board due to feedback from it's output to
it's input as result of the battery leakage?

I don't normally like suggesting cutting tracks but if the board already
has damaged and repaired tracks, you might feel ok about cutting the
track between the gate array and the 74LS126 to determine which of them
(or both together) is responsible for the unusual signal there.

I would be very wary of replacing the unobtainable gate array with
your only replacement until all other possiblities are eliminated in
case the gate array was damaged by a fault elsewhere.

Looks like I've provided more questions than answers :-(

Regards,
Peter Coghlan.

Re: RX02 *.DSK convert to PDP11GUI Image format

[Jerry Weiss via cctalk]

> On Aug 14, 2017, at 11:49 PM, Glen Slick via cctalk  
> wrote:
> 
> On Sun, Aug 13, 2017 at 9:00 AM, Ulrich Tagge via cctalk
>  wrote:
>> Hi all,
>> 
>> maybe someone can help.
>> I would like to install TCP/IP on my RT-11 system.
>> After a short search I have found the following, which I would use:
>> http://www.classiccmp.org/PDP-11/RT-11/freeware/decus11/110939/rthtml/tcpget.htm
>> But the images are in DSK format, but I can't write them with PDP11GUI,
>> which is the only way I have at the moment.
> 
> I would take a quick look at those .DSK images to see what I can make
> of them, but none of the download links on that page work for me.
> 
> For example, I can't download this .DSK image. Do these links work for
> other people?
> ftp://shop-pdp.kent.edu/du3:/tcpip.pkg/tcpipm.dsk

Glen - Try this link  ftp://shop-pdp.net/pub/tcpip/tcpip/tcpipm.dsk

As far as the DSK format, the files from at Alan’s site are logical
disk images.  Logical block 0,1,2,3 from from a DY sized volume starting at
Track 1.  In this case track 0 is ignored. 

This is what RT-11 expects and uses for Logical Disks (LD:). 
I’ve used Kermit and FTP to copy this file from my OSX disk to
a RT-11 DU type drive as a file. They mount and operate as 
LD: drive without additional conversion.


SIMH on the other hand as I understand it, expects disk images to represent
the sectors of a disk.  I did a few checks and its appears faithful to the RX02 
format.
It expects 256 byte sectors for track 0 (qty 26) and 512 byte sectors 
for the rest of the disk as Don pointed out.  You need to prepend 6556. bytes
of zero to the above file to get things started. But this is not the entire 
story.

$  dd of=pad.dsk if=/dev/zero bs=256 count=26
6656 bytes transferred in 0.000230 secs
$  cat pad.dsk tcpipm.dsk >tcpipm_V2.dsk
 
When you attach tcpipm_V2.dsk in SIMH to an RY device (DY to RT-11), the 
expected
boot block is visible as (RT-11) Block #0.

.dump/rad50/ascii/end:0 dy:/term
DY:/X/E:0
BLOCK NUMBER  00
000/ 000240 05 000404 00 00 041420 116020 000400 * 
..C*
  D   E FT  J*HX82 FP
020/ 004067 44 15 00 005000 041077 047517 026524 
*7.$...?BOOT-*
 ALW  6  M   AX JW9L$WGJD
040/ 026525 067516 061040 067557 020164 067157 073040 066157 *U-No boot on 
vol*
 GJEQ2NO. Q3GEG.QZ1R6 QM9
060/ 066565 006545 005012 000200 105737 177564 100375 112037 
*ume._.t.}…*

For an RT-11 Volume, the next logical block #1 should be the home block.  In 
this case,
its not. Instead it is found at block #7, but offset (early) -256. bytes from 
its normal location in the block.   
The first directory block should start at block #6.  Here there directory 
blocks starting at block #3 and #4.

So the padding is not enough here.  The 6 sector skew and interleave 
implemented in the handler come
into play.  I haven’t looked at the code, but SIMH probably expects the disk to 
be sequential copies of 
physical sectors for the floppy drives.  This makes sense, as the emulator 
presents them to the DY: handler
where it will de-skew the data.  

Thus a DSK file representing logical blocks will not work for a floppy image in 
this case.  
A small program can probably be written to skew/Interweave the data to make 
them usable directly in SIMH.

Images of most other DEC media probably don’t encounter the problem, as their 
device handler or driver doesn't
implement either skew or interleave directly.  Most of the ones I encounter 
leave that to the disk media formatting
and/or controller firmware.


Jerry
j...@ieee.org

Re: SOLVED: PDP-11/84 Bootstrap for TSV05 (Dilog DU142)

[Ulrich Tagge via cctalk]

Hi All,

It was possible to solve the issue with much help from Jerry and Paul.

1. Bootstrap Loader as printed in the Dilog Documentation is wrong and 
was fixed.


Here is the fixed and running version:

Device name = MS New =
Beginning address = 001000 New =
Last byte address = 001400 New =
Start address = 001000 New =
Highest Unit number = 1 New =
Device Description = TSV05 New =
Enter ROM ODT

xx/ = open word location xx if address even, byte if odd
RETURN = close location
. or LF = close location and open next
- = close location and open previous

ROM ODT> 001000/012700
ROM ODT> 001002/172520
ROM ODT> 001004/012701
ROM ODT> 001006/172522
ROM ODT> 001010/005011
ROM ODT> 001012/105711
ROM ODT> 001014/100376
ROM ODT> 001016/012710
ROM ODT> 001020/001064
ROM ODT> 001022/105711
ROM ODT> 001024/100376
ROM ODT> 001026/012710
ROM ODT> 001030/001104
ROM ODT> 001032/105711
ROM ODT> 001034/100376
ROM ODT> 001036/012710
ROM ODT> 001040/001104
ROM ODT> 001042/105711
ROM ODT> 001044/100376
ROM ODT> 001046/005711
ROM ODT> 001050/100421
ROM ODT> 001052/012704
ROM ODT> 001054/001102
ROM ODT> 001056/005000
ROM ODT> 001060/005007
ROM ODT> 001062/046523
ROM ODT> 001064/140004
ROM ODT> 001066/001074
ROM ODT> 001070/00
ROM ODT> 001072/10
ROM ODT> 001074/001116
ROM ODT> 001076/00
ROM ODT> 001100/16
ROM ODT> 001102/00
ROM ODT> 001104/140001
ROM ODT> 001106/00
ROM ODT> 001110/00
ROM ODT> 001112/001000
ROM ODT> 001114/00
ROM ODT> 001116/00

Boot Process:
Message 04 Entering Dialog mode

Commands are Help, Boot, List, Setup, Map and Test.
Type a command then press the RETURN key: B MS0

Trying MS0MSBOOT V05.04
▒*


2. The issues I had after the Bootstrap was fixed where related to my 
cable, where I had overall three Pins with bad/no contact depending on 
the cable movement.


Outcome:
Type a command then press the RETURN key: B MS0
Trying MS0
001116
@

.dir ms0:
?DIR-F-Error reading directory

COPY MS0: NL:
?PIP-F-Directory input error MS0:


2.1 Debugging via:

Examine 1116 +7:

@001116/100022
@001120/12
@001122/00
@001124/000310
@001126/01
@001130/10
@001132/00
@001134/00
Extended Status 0 at 001124 seams to be OK, as 000310 can be mapped to: motion, 
on-line, phase-encoded drive
Extended Status 1 at 001126 seams to be not OK, as 1 means read data Parity 
error

Related Pin's:
Connector P1: 14
Connector P2: 8, 32


So I'm quite happy to have a running Pertec 1/2" drive.

Again many thanks and Greetings
Ulrich

Re: RX02 *.DSK convert to PDP11GUI Image format

[Ulrich Tagge via cctalk]

Hi Glen,

a mirror is here: 
http://rtk.mirrors.pdp-11.ru/_pdp-11/shop-pdp.net/pub/tcpip/tcpip/

Please have a look onto my last reply, as the problem seams to be solved.

Many Greetings
Ulrich

Am 15.08.17 um 06:49 schrieb Glen Slick:

On Sun, Aug 13, 2017 at 9:00 AM, Ulrich Tagge via cctalk
 wrote:

Hi all,

maybe someone can help.
I would like to install TCP/IP on my RT-11 system.
After a short search I have found the following, which I would use:
http://www.classiccmp.org/PDP-11/RT-11/freeware/decus11/110939/rthtml/tcpget.htm
But the images are in DSK format, but I can't write them with PDP11GUI,
which is the only way I have at the moment.

I would take a quick look at those .DSK images to see what I can make
of them, but none of the download links on that page work for me.

For example, I can't download this .DSK image. Do these links work for
other people?
ftp://shop-pdp.kent.edu/du3:/tcpip.pkg/tcpipm.dsk

Re: RX02 *.DSK convert to PDP11GUI Image format

[Ulrich Tagge via cctalk]

Hi All,

After all the replays and discussions I was more and more the 
impression, that the images couldn't be in DSK, as this would mean some 
extra work, as this format can't be created on a PDP.
To be more or less sure I have tried to open them with some DSK capable 
tool, which I had on an older 486 based PC.

The outcome was a a message which told me, that the format is not supported.

So I have tied to reach Alan via Mail, and have asked about the format, 
and that I had the hope to write the Images with PDP11GUI.
After a very short delay, I had this replay with all needed details, and 
the OK, to post it here.

So you were right about Track0...

I will test it today's evening, and report back afterwards.

Many Greetings
Ulrich

Am 14.08.17 um 20:29 schrieb Alan R. Baldwin:

Ulrich,

  The RX02 DSK images were created using the following RT-11
command file script:

 create image.dsk/allocate:988
 mount ld3: image.dsk
 init ld3:

This results in a file of 988 blocks (505,856 bytes) in
length.  The program PDP11GUI wants a file of 512,512 bytes
in length ...  So this requires an explanation -

  An RX01 or RX02 floppy disk is based on the original IBM
8" disk format of 77 tracks with 26 sectors per track and
for a Double Density RX02 has 2,002 sectors of 256 bytes each
yielding 512,512 bytes (or 1,001 blocks each 512 bytes long.)

However, DEC chose NOT to use the first track of the disk on
any RX01 or RX02 disk.  Thus 76 tracks with 26 sectors per
track for the Double Density RX02 is 1,976 sectors of
256 bytes each yielding 505,856 bytes (or 988 blocks each
512 bytes long.)

  In RT-11 the following command copies a disk file created
with the above command file directly and correctly to a real
RX02 disk:

 copy image.dsk/file dy0:/dev

as the image disk has the same size as the active part of
the RX02 disk.

  To use the PDP11GUI program you will need to prepend a file
of length 6,656 bytes to the TCP/IP files.  The file content
is inconsequential.  Copy the image file you wish to fix up
into a new location.

1)  Open up a Command Prompt Window and
move to the directory containing the image file.

2)  Make the fix up file as follows:

 fsutil file createnew hdr.bin 6656

3)  Concatenate the fix up file with the image.dsk file:

 copy /b hdr.bin /b + image.dsk /b newimage.dsk /b

The newimage.dsk file will now load into the PDP11GUI program.

Since normally the RX01/RX02 drivers don't access track 0 I don't
know what the PDP11GUI program does with those extra 6,656 bytes.

Good Luck,

Alan 

RE: DECstation 220. Another Impasse

[Rob Jarratt via cctalk]

> -Original Message-
> From: Rob Jarratt [mailto:robert.jarr...@ntlworld.com]
> Sent: 13 August 2017 20:31
> To: General Discussion: On-Topic and Off-Topic Posts
(cctalk@classiccmp.org)
> 
> Subject: DECstation 220. Another Impasse
> 
> I have reached another impasse in my attempts to get my DECstation 220 to
> work. I have posted the details on my blog here: https://robs-old-
> computers.com/2017/08/13/decstation-220-update/
> 
> If anyone has any suggestions I would be interested to hear them.
> 


I have looked at this problem a little more. I have two motherboards,
neither of which work, but one at least produces a corrupted video pattern.
The one that works best appears not to be writing to the video memory. When
I look at the EMEM pin on the Paradise PVGA1A chip I can see a signal but
the scope shows a trace that is very faint. When I look at the same pin on
the other motherboard, I get a nice clear bright trace on the scope, using
all the same settings on the scope. This pin is driven by a non-inverting
buffer (74LS126). The input side of the buffer is tied to 0V, the enable
signal comes from a custom gate array. Comparing the buffer's enable signal
on the two boards I see the same dimming effect on the board with the
corrupted video pattern, and no dimming on the other board.

I have checked the other pins on both the buffer and the gate array and I
don't see anything suspicious.

I am thinking of speculatively replacing the 74LS126 because I can go and
buy replacement parts for it, I can't replace the gate array (although I
could conceivably swap the part on the two boards).

Can anyone offer any suggestions as to the best course of action?

Thanks

Rob