An OLB isn't an executable - it is the Fortran library. Time to go find some rsx doc and read up a little, maybe.
Paul Anderson <wackyvorlon at me.com> wrote:
>I've developed the itch to play with RSX-11/M, so I've setup simh using these instructions:
>
>http://home.earthlink.net/~n1be/pdp11/PDP11.html
>
>So far, so good. I've got it up and running. The problem is in trying to run fortran. There's a FOR.OLB in db0:[11,41]. When I try to run for, I get TASK NOT FOUND. When I run ins $for to load it, it reports not being to find the file. Being a total newbie at this, I'm not sure how to get it to run. Any ideas?
I've developed the itch to play with RSX-11/M, so I've setup simh using these instructions:
http://home.earthlink.net/~n1be/pdp11/PDP11.html
So far, so good. I've got it up and running. The problem is in trying to run fortran. There's a FOR.OLB in db0:[11,41]. When I try to run for, I get TASK NOT FOUND. When I run ins $for to load it, it reports not being to find the file. Being a total newbie at this, I'm not sure how to get it to run. Any ideas?
Is there any reason to use either a CMOS or TTL Crystal Oscillator for a
Cosmac computer? I assume it should accept either, any preference if
you had a choice? Thanks, and can't wait to showcase some of the DIY
computers I am working on at this years VCFMW!
I'm curious if anyone here has tried to boot rsts v10.1 with an emulex
UC07 qbus scsi controller.
I'll go ask on the google forums, but I thought I'd ask here also.
I made an ra81 disk image with simh and it boots fine, but when I
transfer the image to a scsi disk and and boot it on an 11/83 with a
UC07 scsi controller it fails (claims something about the cluster size
being wrong).
I'm just trying to get a rsts v10.1 image which will boot on a qbus
11/23 with an UC07. I'm wondering if the UC07's MSCP emulation is at
odds with rsts's MSCP driver.
-brad
I'm curious if anyone has ever debugged an QBUS MSV11 board.
I have one which appears to have a bad memory location - a single bit
error. I assume this means there
is one bad dram chip. But I've never debugged a memory board like this
before.
Is it possible to figure out which chip is bad? (it seems obvious the
answer is yes, but how?)
I know the location - is there some reasonable way to map that back to
the chip?
I guess I could hunt and peck by grounding or pulling high the outputs
of different chips and
running the memory diag.
any thoughts?
-brad
I just bought a SX64 and it has local pickup. Anyone nearby who might
offer my SX a home for a couple of months until I drive to Lombard in
late September for the ECCC/VCF show?
Jim
--
Jim Brain
brain at jbrain.comwww.jbrain.com
Got me another harddisk, also an old Connor, not sure if it works but can't seem to find anything like a working DOS floppy with a FDISK.EXE which allows the removal of non-DOS partitions.
A quick search for "remove non dos partition debug" should find an easy way to wipe the partition table using the MSDOS Debug command. Here's one such link:
http://forums.techguy.org/dos-other/36829-removing-dos-partition-debug.html
Hi there!
I know it's not as interesting as non-Intel-based stuff, but I just picked up an ex-NASA ThinkPad 760XD and thought I'd poke at it a while given it's connection to the Shuttle Program.
Does anyone know anything about these older IBM ThinkPads? This one came to me missing it's battery and hard drive/caddy assembly. The battery's not so big a deal, but finding the right hard drive and caddy has been pain. I'm a big fan of "stock", so I did some research and looks like the "high-end" drive for this thing back in the day was the 3.0GB IBM DLGA-23080. I'd also picked up an after-market drive caddy, but as it turns out the DLGA-23080 is too tall for the caddy... Anyone know if the DLGA-23080 had a special caddy, and where I might find the right one that's genuine IBM? Or, am I completely mistaken and the "stock" 3.0GB drive for the ThinkPad 760XD is a different model? I can't find a good FRU list anywhere...
Anyway, many, many thanks in advance for the help!!
-Ben
>How about ... "One ringie dingie"Ben.
Adding to the noise pollution, but why not merge this with those silly disclaimers and a surfeit of caps to be the following:
"If this e-mail message has reached anyone other than the person who is reading it, then be advised that it is privileged information and reading, divulging, or even thinking about doing that will attract the unmitigated ire of ... HOW DARE YOU! YOU READ IT ANYWAY!! NOW THINGS ARE GOING TO GET UNPLEASANT!!! LIKE YOUR SLEEP?? WELL, DON"T COUNT ON GETTING MUCH MORE OF IT! RINGY-DINGIES ALL NIGHT COMING RIGHT UP!
We're the phone company. We don't care. We don't have to.
Wonder if anyone is interested in this?
4 1/2 inch floppy prototype supposedly from IBM
htttp://www.ebay.com/itm/251110295055
really pricy, but if you are into weird media this might not be
something to miss.
Jim
Hello, all,
While not exactly on-topic for classic computers, it is indirectly
related due to electronic calculators being an enabling technology for
the first microprocessors.
On Friday, 20-July, Robert "Bob" Ragen, the father of the Friden EC-130
calculator (arguably the first all-solid-state electronic calculator)
passed away with his family around him. He was 83 years old, just three
days short of his 84th birthday. Ragen was responsible for bringing
Friden into the electronic age with the design of the EC-130, and a
number of follow on calculators, including the EC-132, and the 1150 and
1160-series calculators. He was a prolific inventor, with over 80
patents to his name.
The EC-130 exhibit in the Old Calculator Museum has been permanently
dedicated to this calculator pioneer.
Rick Bensene
The Old Calculator Museum
http://oldcalculatormuseum.com
Hi Everyone,
I'm thinking of a way to move as many of the PDP11 systems I have into
my attic office to a) get them going, and then b) run them
occasionally.
I've stripped the two low corporate racks to the chassis, and if I can
find a helping hand, I'm sure I can get them into the attic, then put
the tabletop of my electronics workbench on top of it (I'm a little
short on space). I'm thinking of bolting two pieces of rack profile to
one side of each rack, which would turn them into a single unit
comprising three racks. That way, I should be able to mount 6 10.5"
PDP's and 6 5.25" PDP's, and have them conveniently close to my
oscilloscope and logic analyzer to work on them.
Now for storage...
I have some RL02 drives, but I'm a bit reluctant to drag those
upstairs. I have Emulex scsi controllers for three of the PDP's (2 x
UC18, 1 x UC08), but the rest is without mass storage.
I read about the TU58 emulator that runs on Linux, and I'm thinking of
putting a DECserver into the rack with the PDP11's, and use virtual
TTY's on a Linux box that connect to the PDP11's over the DECserver,
then run multiple instances of the emulator so each PDP has one or
more emulated TU58's.
I know the "real" TU58 tapes can hold something like 256K of data. Are
the operating systems aware of this limit, or could you get by with
emulating a larger tape?
Thanks for any insight you may have to offer. Warnings like "That's a
really bad idea, because..." are also very welcome.
Cheers,
Camiel
As you already know I got this Tek 611 Thing working lately
and now I think about connecting that Beast to one of the PDP11 systems I
have. They all are QBUS 11's, (12,53,83).
Joachim gave me the hint to use a DRV11 or an DRV11-WA to connect the
needed D/A Converters to supply the Tek611.
I do have both DRV11 Variants.
Now I'm looked in the 2.11BSDs sources and found a driver for DR11 boards,
which looks like a similar parallel interface for the UNIbus.
(I'm a Unix guy, and using BSD may be the fastest way for me to get this to
work).
How similar are the 3 interaces to each other? Is is worth to begin with
the DR11 driver..?
I've don't looked deep in the DR11 Manual and I dont even have one for the
DRV11 Boards (...has someone a Hardware/Programming Manual?) so I'm
primarely asking here for some experiences from other people..
Kind Regards,
Holm
--
Technik Service u. Handel Tiffe, www.tsht.de, Holm Tiffe,
Freiberger Stra?e 42, 09600 Obersch?na, USt-Id: DE253710583
www.tsht.de, info at tsht.de, Fax +49 3731 74200, Mobil: 0172 8790 741
?In a mad fit I think I tossed a few. The cpu card for one, probably the disk controller also. Somehow the video cards and something else, and my Butler Flats Associates 5 1/4" disk controller board were spared. I have the chassis/card cage. I would like to replace what's missing. In the event you have an APC laying about, don't know what to do w/it, maybe you can help me out.
?I am _not_ looking to have an entire APC shipped to me though.
(apologies for long lines; posting from phone)
Is anyone interested in the above mentioned machine, chock full of DS0 modules and a few other things? My employer is moving office and is looking to offload it.
It's in the Germantown, MD area (near Washington, DC). I have pictures which I can post publicly once I'm back at an actual computer.
If you're interested, you'll probably need to get it by the end of the month, since that's when the old lease is done.
Feel free to contact me off-list.
- Dave
> On 7/23/12 1:12 PM, Richard wrote:
>> In article<500BAEE9.2090102 at gmail.com>,
>> Jonathan Gevaryahu<jgevaryahu at gmail.com> writes:
>>
>>> The Tech manual on bitsavers (
>>> http://www.bitsavers.org/pdf/dec/terminal/gigi/EK-VK100-TM-001_VK100_Techni…
>> l_Manual_Apr82.pdf
>>> ) is missing a lot of information I need, and is also rife with errors!
>> It would be good to have an errata to the technical manual. Can you
>> email up a list of the errors you've spotted so far?
> that would be a good thing
>
> GIGI documentation is very hard to find.
Ok here's a quick rundown of the errata so far (there's probably a lot
more I haven't noticed), some stuff might need to be done as
images/drawings due to errors in some figures:
page 4-19 subheading 4.4.4.1: Omission: PEEK(address) is perfectly valid
code and isn't in the list of valid basic operators.
(Tested on emulation and 10 print peek(0256) then run does print 194
(0xC2 appears at offset 0x100 in address space).)
page 5-3 figure 5-2: Error/Omission: the "DIP SELECTION" box next to
"SYSTAT A" should have a second arrow pointing to it from the address bus
(since DIP selection is based on the low 3 bits of the address (offsets
0x40-0x47))
page 5-10: Error: the rom 3 extends from 6000-67ff, not 6000-63ff as
listed. The chip contains 6000-6fff but the area between 6800 and 6fff
is blank, 0x00s.
page 5-14: Table 5-3 I/O Register Addresses:
Error: the write register decode for address 0x47 does not have the read
bit set to 1 (this is an obvious typo)
Error: The KYBDW write register is listed as if it is at offset 0x78; it
is actually at offset 0x68.
Error/Omission: the read register for SYSTAT A is listed as 0x40; it is
actually mirrored to 0x40-0x47 but the dipswitch bit read to d2 for each
of those addresses is different. (the switches read for each of the
addresses from 0x40 to 0x47 in d2 is, base-0, so switch 1 is 0, 2 is 1,
etc: 1,3,5,7,6,4,2,0 )
page 5-15: Table 5-4 Program RAM addresses:
Omission: the c000-ffff ram area is not populated on the vk100 board,
though ram is refreshed as if it was there. (it may have been intended
as an expansion kit by DEC but was never sold as far as I'm aware)
Error: Table 5-5 I/O ROM Microcode Address:
the address for the row read/column drive mapping of the keyboard ranges
>from 7000-700F, not 700. (actually it mirrors to the whole 7000-7fff
area every 16 bytes, and the firmware reads it at 7ff0-7fff)
page 5-27: Figure 5-17: the "translator input" left side of this figure
has some major row/column offset/duplication issues.
The correct contents should be:
11 10 9 8 7 6 5 4 3 2 1 0
(000) TA200 1 0 0 0 0 0 0 0 0 0
(001) TA200 1 0 0 0 0 0 0 0 0 1
(002) TA200 1 0 0 0 0 0 0 0 1 0
(003) TA200 1 0 0 0 0 0 0 0 1 1
---------------------------
(004) TA201 1 0 0 0 0 0 0 1 0 0
(005) TA201 1 0 0 0 0 0 0 1 0 1
(006) TA201 1 0 0 0 0 0 0 1 1 0
(007) TA201 1 0 0 0 0 0 0 1 1 1
---------------------------
(010) TA202 1 0 0 0 0 0 1 0 0 0
(011) TA202 1 0 0 0 0 0 1 0 0 1
(012) TA202 1 0 0 0 0 0 1 0 1 0
(013) TA202 1 0 0 0 0 0 1 0 1 1
---------------------------
(014) TA203 1 0 0 0 0 0 1 1 0 0
(015) TA203 1 0 0 0 0 0 1 1 0 1
(016) TA203 1 0 0 0 0 0 1 1 1 0
(017) TA203 1 0 0 0 0 0 1 1 1 1
---------------------------
The right table in the figure is correct.
Page 5-29, Table 5-7: Error:
The equation for "Overlay" should be M=AT(P+N) instead of M=A+(P+N)
Page 5-30, Figure 5-19: Error:
The labels on the two lines coming from the "SOPS" block are transposed;
The top one should be "WHAT COLOR IS THE SCREEN" and the bottom one
regarding the bit 0 reverse video bit.
Omission: the line which SHOULD be "what color is the screen" (the one
going to input B on the MUX) should have a note on the line noting that
it is 4 bits wide, not one bit as is implied by the figure. The "What
color is the data" line should have such a marking as well.
Page 5-32 Figure 5-21: Error: the clock source for the down counter is
NOT the "CHAR CLK" as listed, but the "DOT CLK".
(This had me confused for a good 15 minutes before I spotted the error)
Page 5-35: Omission/Ambiguity: The description of the "Screen Options
(SOPS)" register is missing the bit numbers for each part of the
described functions, and there are FOUR functions, not three.
This could be better written as:
1. Blink Control/Mask (bit 3)
2. Background Color + Blink (bits 7,6,5,4)
3. I/O port control (EIA, 20 mA, hardcopy and self-test) (bits 2,1)
4. Normal/Reverse Video (bit 0)
Page 5-38, Figure 5-23 Arbitrary Waveform Timing: Error: The Vector rom
addresses listed at the top have address 23 missing and 33 duplicated
twice; the correct pattern from left to right should be:
34 23 22 21 20 25 24 33 32 31 30 35 34 23 22 21 20 25 24 33 32 31 30 35
Page 5-42, Figure 5-26: Error/Ambiguity: the lines from "SOPS" to "I/O
PORT SELECTOR" are labeled SL1 and SL0; the actual bits in the SOPS
register these represent are bits d2 and d1.
Page 5-53, Figure 5-33 and Table 5-10: the same ambiguity with SOPS bit
labels SL1 and SL0 appears here. Nowhere in the tech reference does it
mention they are bits d2 and d1.
Page 5-57 Figure 5-37: Omission: the line from "ADDRESS LATCH" to
"DECODER" (which is labeled A6-A0) is missing its
(70<subscript>16</subscript>) marking; on figure 5-36 on the previous
page (page 5-56) the marking is present.
Page 5-62: Omission/Ambiguity: the description of SYSTAT A does not note
anywhere in the tech reference that the bits read appear in SYSTAT A
bits 6,5,4,3 for bits 3,2,1,0 of the nybble the current X and Y
registers point to in VRAM.
One possible error (I need to test this more), which appears on two
successive pages:
Page 5-66 Figure 5-42: *POSSIBLE* (Needs verify with keyboard and meter)
the pins for SHIFT and CAPS LOCK are reversed; capslock should be pin 35
and shift pin 33
Page 5-67 Figure 5-43: *POSSIBLE* the KBD-R latch implies that capslock
is D6 and shift is D7, when in reality they are the other way round.
Hope that helps, If I run into more I'll send to the list as well.
--
Jonathan Gevaryahu
jgevaryahu at gmail.com
jgevaryahu at hotmail.com
http://www.ebay.com/itm/251110295055 looks to me like a prototype cartridge
for the IBM 0341 Four-Inch Diskette Drive (aka 3.9-inch) which was announced
by IBM in 1983 but shortly thereafter withdrawn in favor of the MIC
(Microfloppy Industry Consortium) adaptation of the Sony 3.5-inch design.
I don't think any production units ever shipped but evaluation units may
have shipped. FWIW, it was a single sided 358 kilobyte FM zone recorded
device.
The media spec is at bitsavers and promotional material is at the CHM. I
have a drive photo in my files
Tom
someone kindly sent me a picture of the power supplies diagram/sticker.
the connector has 9vdc output, 6vdc charge, a grounded shield, and a 5 v signal.
what is the "5 v signal"? It's not labeled as an output, nor ac or dc. Is it a pin by which the p/s reads the voltage of the battery, so as to know when to stop charging? The specs state "Output 9V, 2 A max at supply, 6V, 1 A max at charging".
?Anyone have a spare that's surplus to their needs?
Anyone here going? I'll be landing in LV tomorrow afternoon.
I haven't seen any word whether they're doing the great "Retro Room"
PDP display again. I never made it there to see it in person.
Anything else classiccmp-related that is worth seeing in Las Vegas?
-jht
--
silent700.blogspot.com
Retrocomputing and collecting in the Chicago area:
http://chiclassiccomp.org
Does anyone have a copy of the DEC VK100 'GIGI' Maintenance print sheet set?
The mp sheets are DEC part number #MP-00893-00
These are needed for repairing a VK100 and for a project
reverse-engineering how the hardware worked.
The Tech manual on bitsavers (
http://www.bitsavers.org/pdf/dec/terminal/gigi/EK-VK100-TM-001_VK100_Techni…
) is missing a lot of information I need, and is also rife with errors!
I'd be more than willing to scan or photocopy them if anyone has a copy
they could lend me. Am fine paying shipping.
--
Jonathan Gevaryahu
jgevaryahu at gmail.com
jgevaryahu at hotmail.com
On Tue, Jul 24, 2012 at 8:59 PM, Tony Duell <ard at p850ug1.demon.co.uk> wrote:
>> Sent from my iPad
>
> Why does anyone need ot know this?
>
> -tony
It's code for:
"Forgive me if this message is more lucid than my usual communication.
I've typed it on a device with slightly less tactile feedback than a
Sinclair ZX-81, and the gnomes inside are drunk, attempting to subtly
replace any misspelt word with lewd innuendos as offensive as possible
in the given context."
Joe.
(Sent using a device which was clearly created on a dare: "Yo Steve, I
bet not even you can market that silly wireless chicklet keyboard that
the PC JR shipped with!" "Oh yeah? Watch my Reality Distortion Field!"
<zooooooong>)
(And it's actually quite useable, thank you very much...)
--
Joachim Thiemann :: http://jthiem.bitbucket.org