I hope by now someone has fixed you up, but if not, send me the
picture and the pin spacing, and I'll see what I can find.
mike
----------------Original Message--------------
Date: Wed, 18 Sep 2002 10:28:53 -0400
From: MTPro(a)aol.com
Subject: An S-100 Power Plug - Please?!
One more time. Anyone?! Would anyone please have an extra power plug they
could sell me for my generic S-100 computer?
Thank you, David
-------------------------------------------
Introducing NetZero Long Distance
Unlimited Long Distance only $29.95/ month!
Sign Up Today! www.netzerolongdistance.com
>X-Server-Uuid: e4c4d26a-1188-11d5-b029-00508be35655
>X-Server-Uuid: 02753650-11b0-11d5-bbc5-00508bf987eb
>From: "Dwight K. Elvey" <dwightk.elvey(a)amd.com>
>Subject: Re: An S-100 Power Plug - Please?!
>To: cctalk(a)classiccmp.org
>MIME-Version: 1.0
>X-WSS-ID: 11960BE4991835-01-01
>X-BeenThere: cctalk(a)classiccmp.org
>X-Mailman-Version: 2.0.10
>X-Reply-To: "Dwight K. Elvey" <dwightk.elvey(a)amd.com>
>List-Unsubscribe: <http://www.classiccmp.org/mailman/listinfo/cctalk>,
<mailto:cctalk-request@classiccmp.org?subject=unsubscribe>
>List-Id: Classic Computers Mailing List -- Anything Goes
<cctalk.classiccmp.org>
>List-Post: <mailto:cctalk@classiccmp.org>
>List-Help: <mailto:cctalk-request@classiccmp.org?subject=help>
>List-Subscribe: <http://www.classiccmp.org/mailman/listinfo/cctalk>,
<mailto:cctalk-request@classiccmp.org?subject=subscribe>
>List-Archive: <http://www.classiccmp.org/pipermail/cctalk/>
>X-Original-Date: Wed, 18 Sep 2002 12:30:55 -0700 (PDT)
>Date: Wed, 18 Sep 2002 12:30:55 -0700 (PDT)
>X-WSS-ID: 11960AA5449089-01-02
>Content-MD5: SJYufKz8xm+8OEhEs7N1vg==
>Content-Transfer-Encoding: 7bit
>
>>From: "Dwight K. Elvey" <dwightk.elvey(a)amd.com>
>>
>>>From: Joe <rigdonj(a)cfl.rr.com>
>>>
>>>At 10:07 AM 9/18/02 -0700, you wrote:
>>>>>From: MTPro(a)aol.com
>>>>
>>>>>One more time. Anyone?! Would anyone please have an extra power plug
>they
>>>>could sell me for my generic S-100 computer? Somehow mine must have
>gotten
>>>>given away with other misc. cords. It's the kind with two sort of oval
>>>>female prong inputs on the computer end. Anyway, I'd be happy to furnish
>a
>>>>picture to anyone who needs to verify. I haven't had it up and running
>for
>>a
>>>>couple of years now, and I would like to. Thank you, David
>>>>>
>>>>
>>>>Hi
>>>> I have an Allied catalog that is a couple of years
>>>>old. They call these SVT cords.
>>>
>>> Are you sure? I looked up SVT pwer cords on the net and every site
>that
>>I looked at said that SVT was some kind of plastic and not a plug
>>configuration.
>>>
>>> I'm trying to figure out what David is looking for but I don't
remember
>>ever seeing a power cord with oval prongs.
>>
>> It looks like I may have been looking at the wrong thing. I thought
>>he was looking for the older type of HP instrument cord. I don't
>>know of anything that has oval prongs. I thought he meant oval
>>housing.
>> SVT is the power cord style, not the material.
>
> I'd like to modify that. I found a specific page that defines
>it as 18 guage stranded (S) vacuum cleaner (V) cord with plastic
>outsides (T). I see on closer looks, they are refering to the
>cable used. The only mention of the connector type is in
>one place, they call it a PH-163 which I think is a NEMA number.
>Dwight
>
>> Maybe he needs to be a little clearer. Is this an AC power
>>connector we are talking about?
>>Dwight
>>
>>>
>>> Joe
>>>
>>>
>>> They have several
>>>>listed:
>>>>
>>>>manuf Manuf# Allied# Length Price
>>>>Alpha 543 663-7082 7'6" 4.62
>>>>Belden 17952 612-3569 8' 5.38
>>>>Belden 17280 612-3677 7'6" 4.84
An interesting side note about the Belden cords that I found
in a web search:
"
The Eberline Instruments using the non-standard AC cord are listed on
page two of this bulletin. Belden power cord model #17280 has standard
polarity per UL 817 and CSA 895B and should NOT be used on the Eberline
instruments listed. Belden model #17952 has polarity, neutral and lines
reversed and is the only cord to be used on the Eberline Instruments
listed. The non-standard cords come from the manufacturer with a paper
label stating that they have reversed polarity but the labels are
susceptible to damage and are easily lost.
"
Later
Dwight
>>>>
>>>>Hope this helps
>>>>Dwight
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>>
>
>
>
I've finally got what I think is a good sysgen for my PDP-11, but I'm having
a hard time getting it to boot from an RA80. Here is the machine config:
PDP-11/24
Unibus Map
Memory Map
Floating Point Unit
Extended Instruction Set
DZ11 Async board
512 KW (1024 KB) Ram
Two RL02 Disk Drives
One RA80 Disk Drive with MSCP controller
Here is the sequence of commands I am using to transfer the system from the
RL02 (where it was sysgened) to the RA80:
>MOU DU0:/FOR
>ACS DL0:/BLKS=0
>INS $BRU
>INS $VMR
>INS $PIP
>DMO DL0:/DEV
>MOU DL0:/FOR
>BRU DL0: DU0:
(BRU Initializes DU0)
>DMO DU0:
>DMO DL0:/DEV
>MOU DL0:RSXM46
>MOU DU0:RSXM46
>SET /UIC=[1,54]
>PIP DU0:RSX11M.SYS/NV/CO/BL:2050=RSX11M.TSK
>ASN DU0: SY:
>ASN DU0: LB:
>VMR @SYSVMR
>BOO DU0:RSX11M.SYS
XDT> G
RSX11M V4.4 BL 46
> TIM XX:XX XX-XXX-XX
Note: A 'DEV' command at this point shows all the proper
devices and redirects.
> SAV /WB /MOU="DU0:RSXM46"
The RA80 Ready light flickers for a few seconds, then the channel select
light will go off and back on twice. Then the system hangs. If I boot from
the RL02 at this point, and then try to boot from the RA80, the system will
hang again. Booting from the ODT prompt (173204g) yields the same result.
The system hangs wether or not I specify the /MOU option to the 'SAV'
command. If I try the boot right after the BRU command, I get the expected
"Device does not contain a hardware boot block' message, so I know the MSCP
controller is working. I don't know why I can boot the first time with the
'BOO' command, but not subsequently.
Anyone out there have any clues?
Hi,
Does anyone have any information about a Kurz-Kasch Signature II made in Dayton, Oh? It seems to be a combination Signature Analyzer, Logic Probe and Logic Pulser. I'm guessing that it was made in the late 1970s or early 80s.
Joe
Hi,
On 09/19/2002 10:37:01 AM MST "Dwight K. Elvey" wrote:
>
> I suspect that I am either building the directory
>wrong or I got something wrong with the file. I'm
>not sure which it is. I feel I am really close to getting
>it to work but there is some little thing I missed.
> I what hoping is that someone could look at my image file
>and see something obviously wrong or could send me
>an image of a normal 5-1/4 CPM disk ( hopefully with the
>same parameters ). You don't have to know any Z8000.
>You do have to know the inners of CPM.
I'm no CPM guy, but I know there are many different floppy formats
there. I think it's important to mention that the M20 has 256 byte
sectors, 16 sectors/track and 35 tracks.
I also found a tool to access CPM disk images, it's at
http://www.moria.de/~michael/cpmtools/
Maybe that helps...
regards,
chris
On Sep 18, 17:16, Derek Peschel wrote:
> On Wed, Sep 18, 2002 at 08:05:27AM +0000, Pete Turnbull wrote:
> > Well, I'd say the "right thing to do" is to use absolute addressing
modes.
> > What modes 6/7 do is generate references which are relative to the
>
> Sorry, I meant "the right thing for MACRO to do". Jerome and you didn't
> seem to like the output format as it currently stands. How would you
> change it? Jerome apparently wants to add some kind of warning lines.
> Would you distinguish between ordinary relocation and PIC?
>
> I'm really asking what the situations are (what the loader is capable of,
> how you would define "relocatable" on the -11, tec.) as well as what
> algorithms make sense to you.
I'm not sure what LINK does, and what input it needs. It's a long time
since I used MACRO-11, but I'd have expected it to generate the "correct"
values, for a start. What Pat's output showed was:
7 001000 012767 000110 177566' MOV #110,XBUF
but if you were entering that in ODT, what you'd want would be
7 001000 012767 000110 176552' MOV #110,XBUF
In other words, you'd want MACRO to do the calculation for you, and have
LINK adjust that if the eventual loading address was other than 001000.
If I were redesigning MACRO from scratch, I'd have it mark the PC-relative
addresses more obviously, perhaps something like this:
7 001000 012767 000110 [176552] MOV #110,XBUF
but then it would be more reasonable to put the target address, 177566, in
the listing, rather than the offset, 176552. Maybe it could do both, but
it gets a bit clumsy:
7 001000 012767 000110 [177566] (+176552) MOV #110,XBUF
This is just for the listing, obviously; what it puts in the .OBJ file
would not change. However, I imagine any such changes would bring howls of
protest from generations of MACRO programmers :-)
> I tried the real MACRO (under RSX-11M) and it adds an apostrophe to the
> initial setting of . (which is what I'd expect, since . was never given
> a numeric value, only incremented from its default) but still no
apostrophes
> after the addresses later in the listing.
I don't have any listing readily to hand. Were the addresses shown as the
target addresses, or the offsets required to reach those tagets?
--
Pete Peter Turnbull
Network Manager
University of York
Not sure quite what it does -- I just pulled it out of a dumpster in the
Loop that has a ton (literally) of old video production equipment in it.
Don't know if it works, even. Has a nice 5 digit nixie display. Sticker on
the back says it was last calibrated in April of 1976.
Anyway, free for postage (about 10 pounds shipping weight, from Chicago). If
more than one person wants it, I'll draw slips from a hat, tomorrow at noon
(CST).
Reply directly to me at robert_feldman(a)jdedwards.com.
Bob
Hi
I've been working on bringing up a CPM-8000 on my
Olivetti M20. I've made quite a bit of progress but
I seem to have hit a stumbling block.
The code that was available on the net was found on
8 inch disk. The files themselves seem to be the
correct code to run on 5-1/4 inch disk. I've been
building a image disk on my PC and trying them out
on the M20. I've got to the point now ( after some
other failed attempts ) that it is running the
bootstrap code. This is the last part before it
reads CPM.SYS and transfers execution to it.
The bootstrap code expects there to be a file called
CPM.SYS in the normal CPM file space and looks in
the CPM directory for it. Right now, I get an error
message that says it has an error opening or reading
CPM.SYS ( this is how I know the bootstrap is running ).
Looking at the source code for this part, it doesn't
make the distinction between an error in reading the
directory or an error in reading/finding the file.
I suspect that I am either building the directory
wrong or I got something wrong with the file. I'm
not sure which it is. I feel I am really close to getting
it to work but there is some little thing I missed.
I what hoping is that someone could look at my image file
and see something obviously wrong or could send me
an image of a normal 5-1/4 CPM disk ( hopefully with the
same parameters ). You don't have to know any Z8000.
You do have to know the inners of CPM.
Thanks
Dwight
Hi
Since there was a bunch of CPM-8000 stuff showing up
lately, I've been trying to get it to work on my
Olivetti M20 ( what the release code is to run on ).
The code I got was originally from 8 inch disk. I have
both the 8 inch disk images and the files recovered
>from the disk. The 8 inch disk were not boot disk
but contained enough information to build a boot disk.
As near as I can tell, the code was to run on a
5-1/4 inch disk and not the 8 inch.
That is what I have been working on but I've reached
a stumbling block. It seems to be CPM related so people
that know CPM should be the most help ( I mean, know
what directory structures should look like and how
the disk blocks are referenced, not just, I can use
PIP or ED ).
I've been building a boot image from the files and what
I understand of how CPM should look. I've got it to the point
that it runs the low level bootstrap code but fails
to do the final load of CPM.SYS. I know it is running
the bootstrap because it prints the error message that
it has an error in opening or reading CPM.SYS. This
is only in the bootstrap code.
I have the files on my PC and I've written some code
to build the image. I then copy the image to a disk
for my M20 and try to boot it. So far it doesn't seem
to get the CPM.SYS file correctly. I can't tell if
it is an issue with the directory I built, the file
location or something about the file itself.
I hope one of you can help me by looking at my image
file and confirming that I am building the directory
and file correctly, for a CPM type file.
Thanks
Dwight
On Sep 16, 17:40, Derek Peschel wrote:
> On Tue, Sep 17, 2002 at 12:24:02AM +0000, Pete Turnbull wrote:
> > Pat is using PC-relative addressing -- probably inadvertantly. The 67
in
> > that opcode 012767 means mode 6, PC-relative, so the address actually
used
>
> Is that why the apostrophes show up after the data? I had noticed them
> and I know what they mean (relocatable data) but I thought it might be
> the lack of correct pseudo-ops. Now I see there are no apostrophes after
> the declarations at the beginning of the file, only after the later
> references.
> I'm not sure I would have defined "relocatable" that way. (Even though
the
> program never sets . it isn't marked as relocatable, and there aren't any
> external modules that can be relocated.) But it's still a useful
definition
> if it catches errors.
Well, addressing mode 6 and 7 aren't meant merely to generate relocatable
code -- given suitable information, any linker can relocate code. Mode 6
and Mode 7 generate position-independant code (PIC), code that can be moved
at any time without alteration. The PDP-11 was designed to make that easy.
On Sep 17, 4:26, Derek Peschel wrote:
> Pete, I replied to your other post in this thread. I'm just trying to
> understand what "the right thing to do" is here.
Well, I'd say the "right thing to do" is to use absolute addressing modes.
What modes 6/7 do is generate references which are relative to the
instruction address. They're meant for things that will move if the code
is moved (eg the target of a JSR). However, the address of a device
register doesn't move, so although it's possible to refer to using modes
6/7, it breaks the position-independance of the code. If you move the
code, you need to recalculate the address offset.
Once assembled, the first part of Pat's code, despite using mode 6, is not
PIC:
4 177564 XSR=177564
5 177566 XBUF=177566
6
7 001000 012767 000110 177566' MOV #110,XBUF
8 001006 105767 177564' L1: TSTB XSR
9 001012 100375 BPL L1
10 001014 012767 000064 177566' MOV #64,XBUF
11 001022 105767 177564' L2: TSTB XSR
12 001026 100375 BPL L2
13 001030 012767 000130 177566' MOV #130,XBUF
The actual values in the finally-assembled code would be (if I've done my
arithmetic correctly):
7 001000 012767 000110 176552 MOV #110,XBUF
8 001006 105767 176550 L1: TSTB XSR
9 001012 100375 BPL L1
10 001014 012767 000064 176536 MOV #64,XBUF
11 001022 105767 176534 L2: TSTB XSR
12 001026 100375 BPL L2
13 001030 012767 000130 17652 2 MOV #130,XBUF
Note that the pointers to XSR and XBUF change according to their position
in the code, because they're PC-relative (even if my PC-relative arithmetic
is wrong, the differences are correct).
Now if he'd written it using absolute addresses:
7 001000 012737 000110 177566 MOV #110,@#XBUF
8 001006 105737 177564 L1: TSTB @#XSR
9 001012 100375 BPL L1
10 001014 012737 000064 177566 MOV #64,@#XBUF
11 001022 105737 177564 L2: TSTB @#XSR
12 001026 100335 BPL L2
13 001030 012737 000130 177566 MOV #130,@#XBUF
... they don't change. Moreover, since there are no JMPs or JSRs, only
(relative) BRanches, this is PIC.
Now if he wanted to write it using a subroutine, and he used the simple
method:
7 001000 012701 000110 MOV #'H', R1
8 001006 004537 JSR R5, @#PUT
9 001012 012701 000064 MOV #'4', R1
10 001014 004537 JSR R5, @#PUT
11 001022 012701 000130 MOV #'X', R1
12 001026 004537 JSR R5, @#PUT
:
:
35 001100 105767 177564 PUT: TSTB @#XSR
36 001104 100375 BPL PUT
37 001106 010137 177566 MOV R1, @#XBUF
38 001112 000205 RTS R5
That's hand-assembled, in a hurry, so don't rely on the opcodes being
correct! but the point is that the subroutine is referred to by its
absolute address, so the first part of the code can be moved but not the
subroutine (because its address is fixed). However, if it were written
using relative addressing, ie
8 001006 004567 JSR R5, PUT
:
35 001100 105767 177564 PUT: TSTB @#XSR
then the whole thing can be placed anywhere in memory without alteration
(so
long as the subroutine stays in the same position relative to the rest).
Of
course, the subroutine still uses absoute addresses for the registers.
Does that make it clear what the point of the two types of addressing is?
My example is a bit contrived; that's not really how I'd do it. Instead,
I'd write a subroutine that wrote out a whole string, the string being
stored immediately after the JSR, and returning to the word after the
string. But that's another story.
--
Pete Peter Turnbull
Network Manager
University of York