Is there a Stratus simulator out there? Maybe this is another project
someone can work on for SIMH.
Rich
-----Original Message-----
From: cctalk-bounces at classiccmp.org [mailto:cctalk-bounces at classiccmp.org]
On Behalf Of Vintage Computer Festival
Sent: Thursday, July 28, 2005 1:43 PM
To: General Discussion: On-Topic and Off-Topic Posts
Subject: Re: QuantumLink
On Thu, 28 Jul 2005, Jeff Davis wrote:
> I have some baubles (qlink keychain, install disks); I don't think anyone
kept
> backup tapes of the server software, since it ran on Stratus minis, not
> exactly something people had in their basements. Plus it was company
> confidential, etc.
Someone somewhere has to have backup tapes laying about.
--
Sellam Ismail Vintage Computer
Festival
----------------------------------------------------------------------------
--
International Man of Intrigue and Danger
http://www.vintage.org
[ Old computing resources for business || Buy/Sell/Trade Vintage Computers
]
[ and academia at www.VintageTech.com || at http://marketplace.vintage.org
]
Charles,
VERY IMPORTANT:
get the disk pack out of the drive before shipping.
You must lock the heads!
If the cover is closed, there are 2 ways to open it.
1) apply power. The FAULT light will go on, but what is
more important is that the cover latch is unlocked.
2) without power, open the small "cover" at the right
side. Now you have mechanical access to the latch.
When you have removed the pack, look at the opening in
the middle at the rear end (inside the cartridge space).
You will see a small square plate that is held by one screw.
Turn the screw some 4-5 times. Now you can rotate the
square plate 90 degrees. It will cover the opening from
which the heads come out. Tighten the screw. Now the heads
are locked, and you are safe to ship the drive.
Not sure if it is necessary to lock the spindle ... maybe
others can shed a light on this issue?
Cleaning becomes an issue when you have the drive :~)
See www.pdp-11.nl (peripheral -> disk -> RL01/RL02").
gd luck,
- Henk, PA8PDP.
-----Original Message-----
From: cctalk-bounces at classiccmp.org
[mailto:cctalk-bounces at classiccmp.org]On Behalf Of
charlesmorris at direcway.com
Sent: woensdag 27 juli 2005 17:08
To: cctech at classiccmp.org
Subject: "New" RL02 on the way - how to power up?
I have just purchased an RL02 and while waiting for it to arrive, I am
wondering what to do for cleaning and lubrication before power-up. I don't
know how long it's been sitting (indoors). I have downloaded the manual from
bitsavers. I know there has been some discussion on this list recently but I
think that was on the care and feeding of RK05's...
Also, the seller tells me he can't get the pack out:
>When I had the disk pack cover off, the release handle on the pack did
>not release the disks and I did not want to force it. Does the drive
>need to be powered on and is there a way to remove them without powering
>it on?
He does know about the shipping screws and will install them before
Fedexing.
So, what should I do first?
thanks for any assistance.
Charles
>
>Subject: Serial Configurations (was Devilish Altair Serial ConfigurationProblem)
> From: "Richard A. Cini" <rcini at optonline.net>
> Date: Sun, 31 Jul 2005 12:35:05 -0400
> To: "'General Discussion: On-Topic and Off-Topic Posts'" <cctalk at classiccmp.org>
>
>All:
>
> The problems I'm having have to be related to status bits and
>device initialization. The board is an SSM 2p+2s which is based on the
>TMS6011 (which has lots of equivalent UARTs such as the COM2502, 2017,
>TR1402, AY3-1015). The SSM board is very flexible -- I can change status
>bit order and polarity to match almost any configuration need. Right now
>I have it strapped to match the Altair Revision 1 SIO board (ports 0/1,
>RxStat=bit0, TxStat=bit1, active high polarity). I've also tried TxStat
>at bit7.
That should work.
>
> Does someone have sample working code for initialization, input
>and output? I have a few datasheets but none of them give sample code
>sequences. I'm missing something here and I'd appreciate a push.
OH, one more detail.. Most of the MITS software when loaded inits
based on the front pannel sense switches (IN FFh). The configuration
sets the board in use and bits. T he setting are in the MITS software
manuals.
Allison
I'm replying to several postings at once here, since I'm in digest mode
anyway... We all know the subject by now, doing bignum arithmetic in F77
on a PDP-11, and all the side topics this have generated...
> From: "Jerome H. Fine" <jhfinexgs2 at compsys.to>
>
> Johnny Billquist wrote:
>
> >>Jerome H. Fine wrote:
> >
> >
> >>As for endian issues, I can define the most significant word to be
> >>at either end, but I tend to think that I will place the most significant
> >>at the high end of the word since this allows FORTRAN 77 to use
> >>octal to output the value correctly with 64 bit floating point values.
> >>
> >??? Not sure what you actually say here. Floating point values hardly have
> >anything to do with this. Pick whatever byte order you want, and stick
> >with it. Output is something you'll have to figure out anyway, and you
> >deal with any byte order you decided on then. Either way is not that
> >difficult. However, I'd recommend using little-endian, since that is the
> >"natural" order of the PDP-11, and F77 on the machine. That means you can
> >let it deal with 16-bit quantities natively without having to to byte
> >swapping.
> >
> Jerome Fine replies:
>
> Please define little-endian and big endian.
This have now been covered, so I think I can safely skip this. If you
really need some help in figuring out what little and bigendian is, then
say so, and we'll take a crash course.
> Also, I should have explained what I meant! Specifically,
> it should be possible to use floating point variables
> as arguments to subroutines and let FORTRAN 77 take
> care of allocating the actual storage by doing so:
And I don't see the need. When you pass arrays as arguments in FORTRAN,
you only pass pointers, and actually access the parameters in the callers
address space. So no allocation is done, nor need to be done.
Using REAL*8 as a return value from the function is actually what you are
most interested in anyway when you go down this lane, since it's the
result you might want to allocate space for automatically. However, it
will not help you beond 64 bits anyway, so it's a dead end. Bite the
bullet and do it in a way that will deal with arbitrary large values, if
that's what you want.
> 1000 FORMAT ( O25, O25 )
> REAL * 8 Value1, Value2
> CALL I64ADD ( Value1, Value2 )
> TYPE 1000, Value1, Value2
>
> I64ADD::
> Mov R0,-(SP)
> Mov R1,-(SP)
> Mov 2(R5),R0
> Mov 4(R5),R1
> Add (R0)+,(R1)+
> Adc (R1)
> Add (R0)+,(R1)+
> Adc (R1)+
> Add (R0)+,(R1)+
> Adc (R1)+
> Add (R0)+,(R1)+
> Mov (SP)+,R1
> Mov (SP)+,R0
> Return
> .End
This code has a bug in it, as has been pointed out. You actually needs to
do the ADC for all subsequent words after each add step, since every ADC
in turn also can generate a carry.
> If I am correct, the above code assumes that the low order
> words/bytes are the least significant and the high order
> words/bytes are the most significant. Is this little-endian
> or big-endian?
Yes, and that is little-endian.
Well, actually, your code only assumes that the *words* are little endian.
You don't look at individual bytes, and thus the CPU can have them either
little or bigendian without you knowing.
> NOTE that if the most significant bit is in the most
> significant word and byte (as per the above MACRO-11
> subroutine), then the most significant of everything
> is in the highest address of everything. HOWEVER, from
> looking at the order of bytes, words and bits in the
> PDP-11 manual (Chapter 10 of Microcomputer Processor
> Handbook), when the most significant bit is in the
> word with the lowest address, the most significant
> bit (actually the sign bit and the exponent of real
> floating point numbers) is in byte 1 rather than byte 0.
Please stop looking at floating point data, since it's a whole other game.
I'll even repeat this: DON'T TRY TO USE FP, IT'S A WHOLE OTHER ISSUE IN
ALL ASPECTS! Even endianess don't actually apply to fp.
If you look at how 16-bit integers are stored in memory, you'll see that
the most significant bit of the 16 is stored in bit 7 of byte 1. And thus,
the least significan bit is stored in bit 0 of byte 0, which is a
small-endian machine.
[...]
> Date: Sat, 30 Jul 2005 21:54:05 -0400
> From: "Jerome H. Fine" <jhfinexgs2 at compsys.to>
> Subject: Re: FORTRAN 77 on PDP-11
> To: General Discussion: On-Topic and Off-Topic Posts
> <cctalk at classiccmp.org>
> Message-ID: <42EC2F3D.1080901 at compsys.to>
> Content-Type: text/plain; charset=us-ascii; format=flowed
>
> >Johnny Billquist wrote:
>
> >>Jerome H. Fine wrote:
> >
> >
> >>More seriously, if I am using all 16 bits as unsigned integers, then
> >>the high order bit can't be easily eliminated.
> >>
> >True. And if you don't use all 16 bits, then the MUL instruction deals
> >with the sign itself anyway, so there is no need to take absolute values
> >and so on either... In short, a good suggestion in theory, but one that
> >don't work in real life.
> >
> >But of course you still haven't reflected on the fact that in FORTRAN-77
> >you can do 32-bit integer multiplication already...
> >
> Jerome Fine replies:
>
> OK. I just checked how FORTRAN 77 internally handles:
> INTEGER * 4 ITest1, ITest2, ITest3
> REAL * 8 RTest1, RTest2, RTest3
> ITest1 = 65536
> ITest2 = 10
> ITest1 = ITest1 * ITest2
> The integer instruction Mul allows only 2 signed 16 bit numbers
> that then produce a 32 bit number. When 2 signed 32 bit numbers
> are multiplied, FORTRAN 77 first converts them to floating point
> numbers, multiplies them as 2 real 64 bit numbers and converts the
> result back to an integer.
What FORTRAN 77 are you using??? You gotta be kidding. Here is my small
example code:
-----------
PDP-11 FORTRAN-77 V5.4-26 20:35:33 31-JUL-05 Page 1
TMUL.FTN;1
0001 PROGRAM TEST
0002 INTEGER*4 X,Y,Z
0003 X = 42
0004 Y = 4711
0005 Z = X*Y
0006 END
PDP-11 FORTRAN-77 V5.4-26 20:35:33 31-JUL-05 Page 2
TMUL.FTN;1
.TITLE TEST
.IDENT 31JUL
000000 .PSECT $CODE1
000000 JSR PC,OTI$
000004 MOV #76400,-(SP)
000010 MOV #76733,R4
000014 JSR R4,@$NAM$
; 0003
000020 MOV #-3,$SEQC
000026 MOV #52,X
000034 CLR X+2
; 0004
000040 MOV #11147,Y
000046 CLR Y+2
; 0005
000052 MOV X+2,-(SP)
000056 MOV X,-(SP)
000062 MOV Y+2,-(SP)
000066 MOV Y,-(SP)
000072 JSR R4,MLJS$
000076 MOV (SP)+,Z
000102 MOV (SP)+,Z+2
; 0006
000106 JSR PC,EXIT$
------------
Notice how the compiler pushes two 32-bit integers on the stack and calls
MLJS$
Where did you find any FP stuff???
The rest of your questions about F77 are irrelevant, since you are asking
things on the compiler, but the compiler clearly don't do what you say.
> Johnny (or anyone else), can you please comment on if it is
> necessary for FORTRAN 77 to use the stack? If it is not
> needed, why does FORTRAN 77 use this approach?
The reason for using the stack is that FORTAN-77 have a calling convention
using R4 as the argument pointer. And since the function for doing 32-bit
multiplications is just a function, the parameters needs to be passed
somehow, and the stack is a very good choise.
As for the algoritm for the sieve, I'll skip that part, since I haven't
given it enough thought to see if what you say make sense or not. And I'm
not overly interested in primes, so please don't ask me. I remember from
my math classes that a sieve is both memory inefficient and slow. Doing
factorization is rather fast in comparision, so unless you want to print
all primes you can think of, it would be faster. Doing them all will be
slower, but will use a fixed, very small amount of memory anyhow.
[---]
> Date: Sat, 30 Jul 2005 22:28:28 -0400 (EDT)
> From: der Mouse <mouse at Rodents.Montreal.QC.CA>
> Subject: Re: FORTRAN 77 on PDP-11
> To: "General Discussion: On-Topic and Off-Topic Posts"
> <cctalk at classiccmp.org>
> Message-ID: <200507310254.WAA18849 at Sparkle.Rodents.Montreal.QC.CA>
> Content-Type: text/plain; charset="iso-8859-1"
>
> > Please define little-endian and big endian.
>
> Little-endian and big-endian apply whenever you have a multi-digit
> value broken up into smaller ordered multi-digit units. (Usually this
> is for base-2 digits, but it doesn't have to be.) Most often, the
> smaller units are 8-bit bytes, with the order being memory addressing,
> but this doesn't have to be so. (An example that violates all of those
> assumptions is sending multi-bit bytes over a bit-serial line, where
> the "smaller..units" are individual bits, ordered by chronology on the
> wire.)
[...]
Good enough that we hopefully can terminate that question?
> The PDP-11 is an odd case. The hardware is little-endian, but the
> hardware is 16-bit. Some languages store 32-bit integers in what we
> might call "schizophrenic endian": that 12345678 value is stored in
> four consecutive bytes as 34 12 78 56: it is broken into two 16-bit
> words with the more-significant one stored first, but those 16-bit
> words are then stored little-endian in the bytes making them up.
The (I believe) official term is "middle-endian". :-)
And like I believe I said before, FORTRAN-77 on the PDP-11 is pure
little-endian. FORTRAN IV however, is middle-endian.
I think I've written a small test program in most languages that have
32-bits integers on the PDP-11, which shows what byte order they use, if
someone is interested.
[...]
> > I64ADD::
> > Mov R0,-(SP)
> > Mov R1,-(SP)
> > Mov 2(R5),R0
> > Mov 4(R5),R1
> > Add (R0)+,(R1)+
> > Adc (R1)
> > Add (R0)+,(R1)+
> > Adc (R1)+
> > Add (R0)+,(R1)+
> > Adc (R1)+
> > Add (R0)+,(R1)+
> > Mov (SP)+,R1
> > Mov (SP)+,R0
> > Return
>
> I see two problems here. First, you have to eliminate the
> postincrement on the second and third ADC instructions.
Yup.
> Second, this
> loses carries resulting from the ADCs.
Yup.
> (Also,
> the return instruction is normally spelled "ret", not "return".)
Nope.
The PDP-11 don't have a RET instruction. RETURN is actually a macro, and
is the usual name used for this.
If you want the actuall assembler mnemonic, it's "RTS PC" :-)
CALL is the same deal... Don't exist either, and is instead a macro, so
"CALL nnn" gets translated to "JSR PC,nnn"
Johnny
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at update.uu.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
Charles Fox posted a message a couple weeks back about a bunch of stuff he
was getting rid of. There were a few stacks of magazines that nobody
wanted but that I would really like to add to my archive. The problem is
Charlie doesn't have the time to pack and ship them.
Is there anyone near Windsor, Ontario, that could go meet Charlie and take
the magazines away for shipping to me? I'll of course reimburse the kind
volunteer for time and trouble.
Please reply directly.
Thanks!
--
Sellam Ismail Vintage Computer Festival
------------------------------------------------------------------------------
International Man of Intrigue and Danger http://www.vintage.org
[ Old computing resources for business || Buy/Sell/Trade Vintage Computers ]
[ and academia at www.VintageTech.com || at http://marketplace.vintage.org ]
>From: "Zane H. Healy"
>>Hi,
>>
>>Check this out:
>>
>>http://dreher.net/?s=projects/CFforAppleII&c=projects/CFforAppleII/mai
>>n.php
>>
>>Great way to do instead of relying on aging floppies.
>>
>>Cheers, Wizard
>Interesting, anyone have any experience with this?
Zane
Works fine in Apple II, II+, 2e, IIGS under PRODOS and GS/OS
Good quality product.
Hans
>
>Subject: Devilish Altair Serial Configuration Problem
> From: "Richard A. Cini" <rcini at optonline.net>
> Date: Sat, 30 Jul 2005 22:40:19 -0400
> To: "'CCTalk'" <cctalk at classiccmp.org>
>
>All:
>
> This problem has been beating me up all day so I wanted to throw
>it out to the group for ideas.
>
> In my 8800b, I have a Vector Graphics Bit Streamer serial board
>(8251 chip) set for standard ports (0/1 parallel, 2 serial data, 3
>serial command/status). I modified the Turnkey Monitor to use the ports
>based on the VG instruction manual. The manual outlines initialization
>and moving characters in and out. Works perfectly.
the base altair boards were com2502 based on the RXrdy and TXempty bits
sis not corrospond with 8251.
> Now, I want to get standard Microsoft BASIC paper tapes (8k or
>Extended 4.0) working with this board. However, when I look at the sense
>switch options, none fit using the Bit Streamer -- the parallel ports
>are swapped with the serial ports in the order, and the data port comes
>before the status port (all basically the opposite of what BASIC
>expects). I also can't seem to find a toggle loader that works properly.
Will not work. The MITS loader was specific to the mits boards unless
you modified them. However then the loaded image (BASIC) will still
need the drivers patched. The expected boards were either MITS SIO
or the 2SIO.
> So, I decided to pull out a Solid State Music 2p/2s board and
>try to configure it to work with BASIC. I spent the better part of a day
>trying different options with no success. Based on some basic testing of
>the board I believe it works.
The board may be ok but it will not solve the basic problem of
correct IO address and bits within BASIC.
> Has anyone configured an SSM board to successfully work with
>Microsoft Tape BASIC? What loader did you use? How about getting a
>standard VG Bit Streamer working with standard MS Basic?
Neither, never had them.
Back when faced with the MITs IO and some of the problems of
storage I took a different route until I got a disk.
I used a MITS SIO-B for the console (address 0/1). The
original load was done using a MITS ACR from audio tape for
the 8K and the extended 12k. Then the system was stopped
and a hand loaded program saved the image to a different
tape system as a binary save. The goal being to get away
>from MITS ACR (unreliable on a good day) or PTape (SLOW!!!).
The audio tape system was homebrew and ran NRZI at 4800 and
later 9600 using a Redactron digital casette tape deck (saturation
recording, not audio). The inital load file was straight
binary with a loader that looked for a leader byte and then
stuffed memory till byte count equaled zero. Later versions
evloved to CPU control of the tape drive and blocked files.
> As an aside, I'm using Procomm from DOS on an old PC. Can one
>use the "ASCII Upload" option to move the tape image over the line or
>should I do something from DOS like "copy 8kbas40.tap com1:"?
Using todays tech (a PC) I'd render the BASIC to a binary image
on the PC (using a sim if needed) and download it using straight
binary transfer (8n1 terminal) to a simple binary loader. At
9600 baud it's plenty fast and low error. Also using a SIM
you can get inside the BASIC and find all the IO instructions and
change the relevent routines. I had to do that using the
ALTAIR8800 front pannel.
I stopped using all that when I started using NS* MDS with NS*dos
and NS*BASIC back in late 1977.
Allison
I found these three items listed in an upcoming auction. Anybody know
what they might be?
'VAX model 83k03820102 cost $537,300',
'Digital Computer model 7FBMAXA cost $467,850',
'Digital Computer model 7FAMXA cost $433,750'
Joe
Does anyone know if the M8357 (the RX-01 controller for the PDP-8) will
work with the DSD-440 drives? Someone here needs to read some RX-01 disks
on a PDP-8 >>>ASAP<<< and they think that this combination will work but I
don't think so. I have a good DSD-440 drive system but I don't have the DSD
controller for the PDP-8. I also have a M8357 but no RX-01 drive system!
Anybody have a DSD controller for the PDP-8 that they want to sell or do
some horse trading for?
Joe