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
Tothwolf <tothwolf at concentric.net> wrote:
>On Mon, 23 Jul 2012, Kevin Reynolds wrote:
>
>> Hey guys and gals,
>>
>> I have tried and failed to get a successful connection between my uvax
>> II and a pc rs-232 serial port. The H8751-B didn't seem to work, so I
>> pulled it off and wired my own MMJ-DB9 connector. I have tested the MMJ
>> cable, and it works flawlessly.
>>
>> For my connectors I have followed "The Cable" documentation at
>> http://www.mcmanis.com/chuck/computers/vaxen/panels.htm (chucks house of
>> vax), under "The MicroVAX II" section but it hasn't helped. I have
>> tested the MMJ-DB9 connection from my uvax III consoles and from the
>> microvax 3100 and it works fine, so I think the PC side is working
>> correctly.
>
>The pinout for the cable at Chuck's House of VAX is correct. I just opened
>up the connector shells on my own cable which I assembled more than 10
>years ago and verified that it matches the information given there.
>
>Your other option would be to use a H8571-B on the VAX side connected with
>an MMJ cable to a H8571-J (or equiv.) on the PC side. While the two
>adapters are both DE-9, the pinouts for each are very different.
>
>I've used both solutions for my own systems, and I used to make and sell
>H8571-J "work alike" adapter cables on eBay (DE-9F adapter with crimpped
>pins to 6P6C jack, wired the same as a H8571-H, along with a 6P6C to MMJ
>modular cable; I sold 100s of those things).
>
>If you'd rather not butcher an MMJ cable, I'd suggest finding an H8571-J
>adapter (useful with an MMJ cable for many other purposes as well). If
>someone else can't supply you with a second hand H8571-J, I do still have
>some NOS inventory (still in the original DEC bags) stored away (but not
>/too/ difficult to get to) but I paid a good bit for them so I can't just
>give those away.
> 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.
I'm working on a list of errata (which are currently just pencil notes
on a printout of the tech manual), I'll post it when I'm done.
--
Jonathan Gevaryahu
jgevaryahu at gmail.com
jgevaryahu at hotmail.com
Hi Everyone,
I'm looking for a decent primer on Unibus termination. I'm a little
confused about M9300, M9301, M9302 and M9312. Which is to be used
where?
Camiel.
I have the power supply tested and reassembled and am ready to power
up the 11/04.
I am looking to limit the number of installed boards initially.
Certainly the RK05 controller boards can go as I haven't got the
drives operational yet.
The configuration of the 11/04 as I received it is as follows
(hopefully this is readable):
M7257 M7257 M9302
M7256 M7256 -
M7255 M7255 -
M7254 M7254 M920
M7258 M7258 M920
M7856 M7856 -
M7860 M7860 -
GRANT M9202
GRANT M9202
M7856 M7856 M7850
GRANT
M7847 M7847 M7847
GRANT
M7847 M7847 M7847
M7859 M7859 M9301
GRANT
M7263 M7263 M7263
Looking for some guidance if the following is a valid configuration:
GRANT M9302
M7856 M7856 M7850
GRANT
M7847 M7847 M7847
GRANT
M7847 M7847 M7847
M7859 M7859 M9301
GRANT
M7263 M7263 M7263
I am also looking to confirm my understanding of the M9301 card. I
have read the maintenance and operators manual for the M9301. I think
it is saying that the Console Emulator startup message from the M9301
and the console emulator commands will be available on the terminal...
which I take to mean the terminal connected to the M7856 in this
machine. Am I understanding that right.
Thanks everyone for your help.
Regards
Andrew
I shot an Tek 611 Storage display lately (230820230720), is there
documentaion available somewhere? Has someone a left over D/A converter
Card for an QBUS 11? I've found a pdf for an AA11-K card which should be
connected to such a display but this is a unibus card it seems..
I only have QBUS-gear.
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
>
>I have tried and failed to get a successful connection between my uvax II and
> a pc rs-232 serial port. The H8751-B didn't seem to work, so I pulled it of
>f and wired my own MMJ-DB9 connector. I have tested the MMJ cable, and it
>works flawlessly.
>
>[snip]
>
I didn't really follow your description of what you have tried. I suspect the
DE9 connector you have is not wired for plugging into a pc serial port but is
intended for a DE9 connector on some DEC equipment which is wired differently
(a VAX 2000 for example).
My suggestion for an MMJ to other serial device connection is as follows:
Cut an MMJ to MMJ cable in two. Take one end and strip off a bit of the outer
insulation. Strip back the two centre conductors and join them together and to
signal ground on the pc side. Strip back the next two outer conductors
and connect one to TX on the pc and the other to RX on the pc. Ignore the two
outer conductors.
Plug in and test. If it doesn't work, swap the conductors going to TX and RX
and try again.
Regards,
Peter Coghlan.
Hi! Several builders have asked about the XT-IDE V2 PCBs and I have
reordered a batch. They should be here the second week of August. They
will be identical to the previous batch of boards. I will announce when the
PCBs arrive. Please do not send any funds until the boards arrive.
They will be $12 each plus $2 shipping in the US and $5 shipping elsewhere.
After I announce the boards have arrived please send a PayPal to
LYNCHAJ at YAHOO.COM and I will send your boards right away!
Thanks and have a nice day!
Andrew Lynch
sometime ago when I offered a non-working unit. I have one, the only problem is it's missing the plastic "whistles", or at least that's what they resemble, that allow you to set it at an angle on a table. I don't think I have them anywhere unfortunately. If you're interested, as is, should work (it was my original!), 5$ plus shipping from 08758.
Hi! Some of the N8VEM builders have gotten their N8's assembled and tested.
They are working fairly well and the new SD circuitry seems to check out
fine.
There is a new MSX BIOS and CP/M ROM image posted and photos of one of the
builds on the wiki. There is actually quite a bit of information and
ongoing discussions on the N8VEM mailing list. Here is a sample photo one
of about a dozen or so.
http://n8vem-sbc.pbworks.com/w/file/55421880/NS-2312_working_with_Floppy_DSK
Y.JPG
http://n8vem-sbc.pbworks.com/w/browse/#view=ViewFolder¶m=N8-2312%20Marti
n%20Lukasek
I still have some N8 PCBs so if anyone would like to build their own
complete home brew computer from scratch please let me know. Please see
the N8 description below for what it can do.
http://n8vem-sbc.pbworks.com/w/page/54039670/N8%20announcement
Thanks and have a nice day!
Andrew Lynch
Hi everyone,
we have finally received our first Nova. It was installed in a classroom
at a school where they taught some basics of computer science. They bought
it new in 1978 and used it until 1986. All parts still look like new, no
obvious yellowing or worn fronts. The system consists of the Nova 3/12 and
6050-2 cartridge disk drive in a 19" high-boy cabinet and two terminals, a
Dasher 6042 printing terminal and a Dasher 6052-2 CRT terminal - both have
a very cool design!
Now to my question ;-) The system came with several cartridges
(containing RDOS and BASIC, as far as I can tell), but *no* manuals. I
haven't found any manual for our system components on the net (nothing on
bitsavers, too). Does anyone have scans/images? I would need at least the
Nova 3 printset and diagnostics (e.g. papertape images) in case it needs
repair or maintenance. After all, even if the power supply and CPU seem to
work, I'd like to be sure everything is ok after 26 years. (The former
user, a teacher, didn't even know that you could dismantle the rack, nor
did he ever pull out the CPU or the power cable from the rack...).
Christian
PS:
Repairing the key switches in the terminal keyboards (disintegrated
foam) is another story...
It looks like I'm back in business collecting vintage computers. I went to the town dump today and found what looks like an H89 but the model number tag on the back says NN89-29. I haven't tried opening it up to see what's inside yet but it has a floppy drive so I assume it isn't just a H19 terminal. Also, on the front it says "Heathkit Computer". Even though I've had vintage computers before I've never followed good procedures when trying to bring them up. Usually, I just plug in the power cord and hope for the best. I'd like to do a little better this time. Can anyone suggest an approach to bringing this beast to life that minimizes the chances that I'll fry it the first time I power it on?
Thanks,
David
I have some of what you may need, but will need to scan it in. I do not have a full print set - unlike Dec, those are more rare in the dg world. But I won't be able to do anything until mid august. Check bitsavers.org, and also contact wildharecomputers.com
Christian Corti <cc at informatik.uni-stuttgart.de> wrote:
>Hi everyone,
>
>we have finally received our first Nova. It was installed in a classroom
>at a school where they taught some basics of computer science. They bought
>it new in 1978 and used it until 1986. All parts still look like new, no
>obvious yellowing or worn fronts. The system consists of the Nova 3/12 and
>6050-2 cartridge disk drive in a 19" high-boy cabinet and two terminals, a
>Dasher 6042 printing terminal and a Dasher 6052-2 CRT terminal - both have
>a very cool design!
> Now to my question ;-) The system came with several cartridges
>(containing RDOS and BASIC, as far as I can tell), but *no* manuals. I
>haven't found any manual for our system components on the net (nothing on
>bitsavers, too). Does anyone have scans/images? I would need at least the
>Nova 3 printset and diagnostics (e.g. papertape images) in case it needs
>repair or maintenance. After all, even if the power supply and CPU seem to
>work, I'd like to be sure everything is ok after 26 years. (The former
>user, a teacher, didn't even know that you could dismantle the rack, nor
>did he ever pull out the CPU or the power cable from the rack...).
>
>Christian
>
>PS:
>Repairing the key switches in the terminal keyboards (disintegrated
>foam) is another story...
>
> This might be a second post, I got a weird error message the first time.
>
>
> I just scanned my technical manual for the GNT 4604/5 which has many
references to the 4601.
>
> It does include schematics. You can find it here:
>
> http://www.dvq.com/docs/GNT/
>
> Bob
>
Many, many, many thanks! I bought a new-old-stock GNT-4604 about a decade
ago. It was so exciting to open the foil seal and --- nothing worked. I
did find the problem. It had cold solder joints on the control board. But
having the service manual means I can keep it running for years to come.
I also have a GNT-4601 so I'm doubly appreciative. Your work will not have
been in vain!
Amardeep
Date: Sat, 21 Jul 2012 21:31:20 +0100 (BST)
From: ard at p850ug1.demon.co.uk (Tony Duell)
To: cctalk at classiccmp.org
Subject: USB to GPIB interface
Message-ID: <m1SsgKj-000J4gC at p850ug1>
Content-Type: text/plain
It's of no real interet to me at the momnet (obivously) but this
month's
Elektor magazine (the summer double issue, so it's not cheap!) has a
project to make a USB to GPIB interface. It's little more than a
programemd PIC which directly drives the GPIB lines without buffers. I
don't like that much, but...
I think you can get source code for the firmware (apart from the USB
routines, which are standard routins from Microchip).
I have successfully controlled some GPIB gear with just a parallel
port, not even a pullup resistor needed.
Jon
With reference to my reply to Chuck's message, I've now dug out the
schematics.
The Sirius printer interface uses a 6522 VIA (at location U15L o nthe
mainboard). Port A is bufferec by a 75160 and fet ot the data pins on the
'Centronics' connector. Port B is used for the handshake lines, in
ascending bit order : DAV, EOI, REN, ATN, IFC, SRQ, NRFD, NDAC. Tese are
bufferec by a 75161, always in controller mode (DC is grounds). NRFD and
NDAC (o nthe 'host' side of the buffer) also go to CA1 and CA2
(respsecviely) of the VIA
The 'Talk' (buffer direction) line is controlled by PB0 of the 'system
VIA' at loccation U12L
The pinout of the 'Centroics' socket is :
DAV 1 19 Gnd
D0 2 20 Gnd
D1 3 21 Gnd
D2 4 22 Gnd
D3 5 23 Gnd
D4 6 24 Gnd
D5 7 25 Gnd
D6 8 26 Gnd
D7 9 27 Gnd
NRFD 10 28 Gnd
SRQ 11 29 Gnd
N/C 12 30 N/C
NDAC 13 31 N/C
J 14 32 NDAC
EOI 15 33 Gnd
Gnd 16 34 REN
FG 17 35 ATN
NC 18 36 IFC
A couple of non-obvious ones : 'J' (pin 14' is connected to ground via
the jumper E26-E27 (which is not normally fitted I think). FG is frame
ground (mains earth), not logic ground.
I/O chips i nthe Sirius seem ot be memory mammed for some odd reason. I
think the addresses are :
GPIB VIA : 1110 1xxx xxx0 001x rrrr
System VIA : 1110 1xxx xxx0 010x rrrr
where rrrr is selexts the VIA register in the obvious order.
-tony
Hi everyone,
I'm getting ready to see if I can get all those PDP-11's running
properly. I have most of the test equipment I'm likely to meet -
multimeter, oscilloscope, current tracer, logic analyzer - but figured
that extender cards for Qbus and Unibus might come in very handy. Does
anyone have any they'd be willing to part with?
Camiel.
I spotted a listing for the TNIX user manuals and a set of floppies in Tucker's manual
list, so there is a standalone disk and a dump of the file system with the native tools
package on bitsavers now, along with the manuals.
The standalone formatter seems to be really fussy about what kind of disk it will format.
I tried a Seagate ST4096 and a Maxtor 1140, and couldn't get either to go even though they
had more heads and cylinders than the Micropolis 1304.
It's of no real interet to me at the momnet (obivously) but this month's
Elektor magazine (the summer double issue, so it's not cheap!) has a
project to make a USB to GPIB interface. It's little more than a
programemd PIC which directly drives the GPIB lines without buffers. I
don't like that much, but...
I think you can get source code for the firmware (apart from the USB
routines, which are standard routins from Microchip).
May be of interest to somebody here....
-tony
Just spreading the word amongst a few of the groups that may have interest and talent in older and more efficient programming past. http://minigamecompo.weebly.com/index.html has begun and will be accepting submissions I believe until November 30th (2012).
For those who aren't familiar this is a competition to write the best game they can in the category of under 1k, 2k, or 4k of code for various (usually 8-bit) platforms. They have some screen shots of previous programs that have competed to see what sort of stuff comes out of it. I always find it entertaining.
I have no affiliation with them, just helping spread the word since I haven't seen it announced in my usual hangouts yet.
- John
sigh
theres a buisnes partner fight going on and i am caught in the midle
GAH!!!!!!! to tune of 1300 bucks..........
something i paid for has been relisted under the partners new account sent
him a msg unhappy don't bid
http://www.ebay.com/itm/Vintage-Computer-Equipment-Pertec-T6840-9-45-U2-DEC…
an ebay complaint has been filled and reported blah blah blah i have now
got a paypal dispute finally txs to this re-listing and its pretty esay to
prove its the same item
the origonal listing i won from user uncolect whos sold me many things
befor this happened and shipped them so i am upset wish he coulda phoned me
i only left him my number half a dozen times.........
http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=160748462238&ssPageName=…
i feel like crying all i wanted was my rk05's and pertec god damit why did
it have to come to this now what am i guna do with my pertect interface
card i got :"(
Hello robo
Are you still interested in information about FOX MT80?
I could provide You with original manual and schematics.
With best regards
Heinrich
____________________________________________________________________________
_________
INFATEC
Ingenieurb?ro f?r Automatisierungstechnik GmbH
Leo-Rosenblatt-Weg 2b
D-30453 Hannover
Heinrich S?llner
Telefon +49 (0) 511/8094048
Telefax +49 (0) 511/8092310
home <http://www.infatec-gmbh.com/> www.infatec-gmbh.com
E-Mail <mailto:INFATEC-Klebl at t-online.de> INFATEC-Soellner at t-online.de
Gesch?ftsf?hrer: Rolf Klebl
Sitz der Gesellschaft: Hannover
Registergericht: Hannover HRB 54 193
Hannoversche Volksbank
4813 499 600 (BLZ 251 900 01)
____________________________________________________________________________
_________
DIESE EMAIL IST VERTRAULICH UND KANN DEM BERUFSGEHEIMNIS UNTERLIEGEN. WENN
SIE NICHT DER VORGESEHENE ADRESSAT SIND, BENACH -
RICHTIGEN SIE UNS BITTE UNVERZUEGLICH MITTELS EMAIL UND LOESCHEN SIE DIESE
NACHRICHT AUS IHREM SYSTEM.
THIS EMAIL IS CONFIDENTIAL AND MAY ALSO BE LEGALLY PRIVILEGED. IF YOU ARE
NOT THE INTENDED RECIPIENT, PLEASE NOTIFY US IMMEDIATELY
BY EMAIL AND THEN DELETE THIS MESSAGE FROM YOUR SYSTEM.
____________________________________________________________________________
_________
One of my sons will be driving to the Denver area next week and will
have a limited amount of space and time to drop things off if I have
anything you might need.
Also, If you have some DEC items, I might be interested in working out a trade.
Please contact me off list.
Thanks, Paul
Hi Guys,
Today me and my brother (truck driving license, no interest in old
iron) had the biggest haul of DEC stuff I ever had (ex-collector
moving to a smaller apartment). I'm picking up a second load in a week
or two. Pictures at
http://www.flickr.com/photos/7816395 at N04/sets/72157630422540146/
A quick inventory:
PDP stuff:
- PDP 11/44
- PDP 11/84
- 3 x RL02
- Professional 325
- Professional 350
VAX stuff:
- 12 x BA213/BA440 pedestal VAX systems (MV3400, VAX 4000/200,300,500A, ...)
- 3 x R400X storage pedestal
- 3 x R215F storage pedestal
- 47 x pizzabox VAX systems (MV3100, VAXstation 4000, Infoserver 150, ...)
- 22 x pizzabox storage expansion
- 4 x lunchbox VAX systems (MV/VAXserver/VAXstation 2000)
- 11 x lunchbox storage expansion
MIPS stuff:
- DECsystem 5400 (pedestal)
- 2 x Personal DECstation 5000/25
- DECstation 2100
- DECstation 5000/133
- DECstation 5000/200
Alpha stuff:
- 2 x DEC3000
Miscellaneous stuff:
- VAXmate PC500 w/RCD31 expansion box
- 2 x HSZ40
- 18 x StorageWorks BA350
- 6 x StorageWorks BA353
- DECNIS 600 w/ DNSAN, DNSAM,W614/618,L602
- 5 x DECserver 700
- 3 x DECserver 200/MC
- LANbridge 200
- Lots of DEChub stuff
- Lots of manuals, cables, spare cards, spare disks, etc...
I need to remind people not to send any more donations for the next
few months while I sort this stuff out. I won't keep it all, so I'll
probably post some messages here in the next few months to sell or
give away some of it. Some of it may have to end up in the bin
eventually (like storage expansion boxes with broken drives)
Does anyone here have any experience with the Professional systems and
the VAXmate? I believe the latter is an 8086 system, is that correct?
Would the DECNIS stuff still be of use to anyone?
Cheers,
Camiel
denigration was nowhere in my thinking when I uttered the unspoken term. In fact I think there's a person on one of these forums that adopted the nickname Chuckster. But in any event it won't happen again.
I have two cables that I've been trying to figure out what they're for. They're both commercial, with molded-in ends.
The one that I've gotten furthest on is a video/keyboard cable of some sort, 8-ft long, DA-15F on one end with a box on the other end splitting out into what appears to be PS/2 keyboard and mouse ports (Mini-DIN 6, labelled "KBD" and "MOUSE") and 3BNC R/G/B video connectors. If it was LK-style I'd think DEC, as it is I was thinking X-Terminal, but all the X-terminal pictures I've seen have local keyboard ports and more "ordinary" graphics connectors. There is a part number, 012-1369-00, that when Googled comes up as Tektronix 4200/4300 workstation, but again those don't seem to have the right ports. No manufacturer name.
Second has no markings. 9-ft 13W3F to 13W3M, which seems simple enough, but the signals are put through two separate cables and the RGBS portion is broken in the middle and there are two sets of BNC M connectors on them. Other pins are wired straight through. Perhaps connects to some sort of splitter?
link here
http://www.beinamovie.com/movie.php?mtitleid=115
for Monday and Tuesday 7/16 and 7/17 in Pasadena.
I didn't send earlier notes for this movie, but figured that this note
would be of slight interest to anyone who could make it.
The scenes we're part of will be the 1983 PC Conference (Monday the 16th)
and the 1977 Computer Jobs Faire (Tuesday the 17th)
Maybe some here were at those conferences, and won't barf at the thought
of being in a movie about Jobs.
Jim
Hello, all,
I have four DEC W021B cables with FlipChip paddles at both ends. The
cables are roughly 8 feet long including the paddle boards at both ends.
The cables are nine coaxial (signal and ground) cables bonded together
into a single flat black cable. The paddle fingers are gold plated,
have light surface corrosion on them, and have light signs of
insertion/removal from backplane sockets. Each W021B cable has nine
signal lines, each with a separate ground. These cables were originally
used to connect and RF11 Unibus Disk Controller chassis to an RS11 disk
drive based on labels on the paddle boards. The same cables were used to
connect peripherals (such as DF32 or RF08/RS08 disk) to the original
Flip-Chip based PDP-8 processors (Straight 8, 8I and 8L). The cables
are untested.
I also have a single RS11 disk drive "Write Lockout" switch panel with
cable and paddle connector for connecting it to an RS11 disk drive
backplane. This panel provides sixteen toggle switches that can be set
to provide write protection for sixteen separate blocks of 16K words on
the disk. The panel has a flexible ribbon cable that is about 12 inches
long that connects to a Flip Chip paddle connector with a white handle
with designation of W033. The switch panel itself is in very good
condition, with very clear legends with no dings or dents. The ribbon
cable has some slight delamination in some areas, and one trace may not
have electrical continuity based on a visual observation. The W033
paddle connector is in very good condition, with virtually no sign that
it has ever been plugged into a Flip Chip slot. All of the very high
quality switches move freely, and are original switches from the era,
with no sign of replacement. The unit is untested.
I would like to sell these items. Please read carefully below the
"rules" before bidding. Sorry they are so detailed, but I want to make
sure that the rules are clearly understood by all.
I am accepting offers for each individual item on a per unit basis.
For example, bids will be accepted for each of the W021B cables and the
RS11 Write Lockout panel assembly separately. Bids must be sent in
individual Emails, e.g., do not send a bid giving an offer for all four
W021B cables, or one cable and the RS11 write lockout panel. Such bids
will be dismissed without notice. Bidders need to send separate Emails
with bids for each of the individual items of interest.
The items will sell to the highest offer received via Email to me
(i-t-e-m-s *at* b-e-n-s-e-n-e *dot* c-o-m [no dashes and substitute
correct symbols for *at* and *dot*]) for each item by 11:59 PM Pacific
Daylight Time on Sunday 22-July.
Bids received at Email addresses other than that listed above will be
dismissed without notice. Duplicate bid amounts for an item will be
arbitrated by the first Email received in my inbox prior to the
deadline. A flat rate charge of $15 will be paid by the winning bidder
for packing/shipping unless arranged otherwise. Once the high bidder is
determined, they will be notified by return Email on Monday 23-July.
Payment shall only be accepted by PayPal, and must be paid in full
including shipping within two business days once final costs
notification is sent to the winner. If a winner does not respond to
notification Emails within the deadline, backs out or fails to pay, the
sale is considered to have failed, and the item will not be awarded to
lower bidders. If an individual provides the high bid on multiple
items, packing/shipping can be combined to minimize costs. Shipping
will be done by USPS Flat Rate Priority Mail unless arranged otherwise.
Items will ONLY be shipped to continental US locations. I will not ship
overseas, or to Alaska, Hawaii, Mexico, or Canada.
If you are not from the continental US, please do not bid.
Photos of items can be Emailed upon request.
Sales shall be final with no returns.
If no high bids are received, the items will be auctioned on eBay. I
wanted to give the Classic Computer mailing list members first
opportunity to acquire these unusual vintage items.
Please don't hesitate to write if you have questions about the items. I
will do my best to respond promptly.
Rick Bensene
On 2012-07-14 16:04, cctalk-request at classiccmp.org wrote:
> Message: 26
> Date: Sat, 14 Jul 2012 09:31:41 -0400
> From: Rick Murphy<rick at rickmurphy.net>
> To:cctalk at classiccmp.org
> Subject: Re: OS/8 dates (was TECO ^B on OS/8 and RT-11)
> Message-ID:<201207141331.q6EDVgHs011761 at rickmurphy.net>
> Content-Type: text/plain; charset="us-ascii"; format=flowed
>
> At 05:17 AM 7/13/2012, Johnny Billquist wrote:
>> >Ooo. So TECO-8 actually lie in their documentation... Even worse.
>> >A year in the range 1986-1994 would just have looked like 1970-1977.
>> >That's ugly of them.
> You're quite correct. Clearly this*is* a TECO-8 bug - I thought it was
> at least following the docs but they're just ignoring the high-order
> date bit. Unfortunately, fixing this (as in making it compliant with
> the documentation) isn't easy as that page is full. And "fixing" it
> would just give different wrong values since you can't squash 14 bits
> into 13.
>
> Mea culpa. TECO Fail, indeed.
Yeah... I tried to figure out a fix to atleast do what the doc says, but
I end up using one more word than the current code. :-(
Hmm, possibly I can get away with it, if there is a free location, or a
constant 0060 on the current page, or page zero already, and the link is
already clear at entrance of the routine... But it's hacky.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
under http://bitsavers.org/bits/Tektronix
Changed 856x to 8560 and created 8550 and 8562 directories
There is an untested DOS/50 boot disk image under 8550
It's probably OK. The files extracted correctly on the 8562
Under 8562:
The boot block for the 8562 (which appears to be different from the one on the V2
update floppy from the 8560) and a small program to create an IMD file with a payload
>from stdin, so you can, for example, make a floppy with a tarball that can be read on
/dev/rfd0 on the 8562.
Curiously, Tek didn't include dd with Tnix, so I'm going to tar over the source and
stock V7 dd binary to see if an unmodified binary will run, and if not, compile it
over there.
I'm a little nervous that the 8562 stanalone utilities disk may be needed to restore the
disk instead of the one from the 8560, since the boot doesn't work quite the same way (the
8562 reads /boot from the disk, while the 8560 just loads 'tnix')
Has anyone heard from Grant Stockly recently? The Altair Kit forums have
fallen into the hands of spammers, and I haven't been able to reach him
through email. He announced a new sale of kits in early June, but I
didn't find out about it until last week. I was hoping to get in on
it.
-Seth
Over the weekend, having gotten a beautiful, perfectly circular round
tuit, I cracked the root password on my SGI Indy (tip of the hat to Doc
Shipley) and got the system fully operational. It's a little poky, so I
suppose the next thing is to upgrade the CPU module and get a 24-bit video
card in it (8-bit is yugly).
However, in the meantime, I'm using a cheapo 13w3 to VGA converter that works
okay with my NEC monitor, but there is still a sync signal on the green
line, leaving me with a persistent green tint. Reducing green gamma in IRIX
helps some, but I'd like to get my black back (because once you go black,
well, you know). What are people using to turn SOG into a more conventional
sync signal an off-the-shelf multisync monitor like my NEC XV15+ VGA display
will accept?
--
------------------------------------ personal: http://www.cameronkaiser.com/ --
Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckaiser at floodgap.com
-- Diamonds are forever. ------------------------------------------------------
Does somebody knows what I can use as replacement ?
One of the 5V rectifier diodes from my HP 2113 PSU (HP 5061-3476) died, and
I can't find the equivalent part number for it.
-Rik
Date: Sun, 15 Jul 2012 13:23:38 +0200
From: Camiel Vanderhoeven <iamcamiel at gmail.com>
To: "General Discussion: On-Topic and Off-Topic Posts"
<cctalk at classiccmp.org>, "General Discussion: On-Topic Posts Only"
<cctech at classiccmp.org>
Subject: Dilog and ACT UNIBUS module identification
Message-ID:
<CA+0-H5QfbaQUMRa8zK7N91Bft+NVJqkZhD6y+kCARnC2NjPkKg at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
I can't find anything on these two UNIBUS modules:
- ACT 10197-0
- DILOG 153078
I believe a Dilog DQ153 is a Pertec-formatted mag tape controller.
I used one in my system. The label you are reading is probably
the blank board part #, there should be a silkscreen label on
the front of the board.
Jon
... for one of the Teletype ASR33's in the danish IT museum
I'm located in Denmark (obviously!) where we use 220VAC. However, the TTY
runs off an 220/117V transformer, so there should not be any problems
building the controller into the stand
Thanks
Nico
--
I am using the free version of SPAMfighter.
SPAMfighter has removed 415 of my spam emails to date.
Get the free SPAMfighter here: http://www.spamfighter.com/len
Do you have a slow PC? Try Free scan http://www.spamfighter.com/SLOW-PCfighter?cid=sigen
I'd like to mount a couple of SSDs on top of a couple of unused card slots in a server
and figured someone must have made a bracket for doing this. Has anyone seen one, and if
so, what is it called?
It's easy enough to make with a piece of aluminum and a bracket with two long L flanges
but I'd like to just buy the things if they exist.
I've finally reached the stage of my PDP-11/35 restoration where I'm
ready to turn it on and debug logic.
A copy of the PDP-11/40 Maintenance Printset would be INCREDIBLY
helpful, as would a bus extender and a KM11.
Ideally, I don't want to buy these - this is a one-off project for me,
I'd really like to borrow them for about 1-2 months and then return
them. I'd be happy to pay a "rental" fee, even.
I'm located in the SF Bay Area, if someone local can let any of these go
for a little while, I'd be quite grateful.
Thanks!
-Seth Morabito
PDP-11/35 Restoration Blog: http://www.loomcom.com/blog/
I have the following items for sale
Apple II SCSI Card- Works great, will include a copy of the SCSI
Utilities disk $175.00
Apple II MicroDrive- Made by ReactiveMicro, Allows you to use IDE or
CF Cards with your Apple II or IIGS. Will include a IDE-CF Adapter $250.00
Kaypro II- Mint condition with all books and software $200
Commodore SX64 Mint condition with FastLoad Cartridge, original
software, carry bag, owners manual $250.00
2 SGI Indigo Systems with monitor, keyboard and all kinds of
manuals/software- FREE If you pick up
1 Sun Blade 2000- FREE If you pick up
1 IBM RS/6000 43P Model 150- FREE If you pick up
Will have more as I get through it.
Shipping is extra, Local Pickup is welcomed in Flushing Michigan
PayPal Preferred
On 2012-07-13 19:00, "Jerome H. Fine" <jhfinedp3k at compsys.to> wrote:
>Johnny Billquist wrote:
>> >[Snip]
>> >Ooo. So TECO-8 actually lie in their documentation... Even worse.
>> >A year in the range 1986-1994 would just have looked like 1970-1977.
>> >That's ugly of them.
> What seems even more evident to me is that DEC took
> (as most other companies did as well) the attitude that
> even the internal representation of date and time was
> not important enough to allow the same information to
> be exchanged between operating systems on a consistent
> basis.
Sorry, but I fail to see the point. The internal representation of a
date will almost by necessity be different between different OSes and
hardware. Having a bunch of 16 bit values represent a date on a PDP-8
would be incredibly stupid and difficult, not to mention that OS/8 have
no concept of time to more detail than a day. And even that needs to be
updated manually every day.
So, ignoring the internal format, which can't really be portable anyway,
you then get to representation. There will always be dates that cannot
be represented in whatever format you choose. So what is the point of
bringing up that argument? It is nice if the dates that you might
reasonably expect to be processes be possible to express on the system.
As for communicating with other systems, in the communication I would
suspect/expect that you use an intermediate format (a nice text string
for example) that both agree on. And then you can convert from the
internal format to and from this intermediate format, as long as the
date is within a range expressable on that system.
When you go outside the date range for the system, you can either try to
do something reasonable, or give an error. I think that is a choice that
is best left to the writers of the code to decide on a case by case basis.
By the way, Unix express time as a number of seconds since Jan 1, 1970,
00:00 UTC.
And time is horribly complex. You know that even if we keep it fairly
modern, different countries switched from Julian dates to Gregorian
dates at different times, the last being Russia, in the early 20th century.
If you really think that you can come up with a reasonable, portable
design, that is "universal", I think I know of a few organizations that
would like to hear from you.
Until then, I'm pretty much satisfied with things the way they already
are. Yes, OS/8 have been broken for 10 years now. But to fix it require
more than just changing the internal storage for the date.
RSX got fixed, and depending on which bits you look, it might stop
working right 2070(?), 2099, 2155 or 34667.
I don't know about RT-11, but I do know that RT-11 is totally separate
>from RSX, and any problems are not shared, but unique.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
I'm getting around to doing some work on my veneered and generated
HP5307A frequency counter. Looking at all the gold-plated PCB
goodness inside, the first thing that jumps out at me is a bulging
electrolytic. It's a 940 uF, 40V unit. Not 1000 uF, but 940. Not
50V, but 40V. I'm going to substitute a pair of 470uF, 50V units
paralleled as a substitute, but this had me wondering if anyone knows
why the strange values, particularly since +/-20 percent tolerances
are common on electrolytic caps.
--Chuck
OK, here's what I believe is a correct macro for inserting the
current date and time as an HTTP Date header, portable across
different TECO environments as best I can make it. I tried to login
to the TOPS-10 machine at pdpplanet, but encountered difficulties.
Therefore, I have only tested this end-to-end on a Win32 environment
where I'm running TECOC. I started with DATE.TES in the TECOC
distribution and changed things around to try and make it as small as
possible when squished. Right now I'm at 1,109 bytes of squished
TECO. I could squeeze out 33 more bytes if I change the code that
builds up a string containing the days within a month by replacing
the 31 at I// commands with an insert using literal control characters
but I'm trying to keep my source file free of control characters, with
a small concession for ESC characters.
If others are willing to try this on their TECOs and tell me the
results, that would be great. The environments that are different
>from my test environment are:
PDP-8, OS/8 Different date, time encoding
PDP-11, RT-11 Different date encoding
PDP-11, RSTS/E Different date, time encoding
TOPS-10 Different date, time encoding
TOPS-20 Different date, time encoding
<http://user.xmission.com/~legalize/vintage/http-date.zip>
If you're not in my time zone (Salt Lake City, -0600 from GMT), you
will want to change -0600 in the macro to the appropriate offset.
Some observations from doing this little sub exercise:
- nQq extracts the nth character code from the string portion of
Q-register q. Using another Q-register as the numeric argument to this
command confused the parser of my TECO, hence the use of an intermediate
Q-register by doing 'Q0QM U1'. It didn't uniformly confuse my TECO,
so there were some cases where I could use QqQq directly in some
expressions. This might cause a portability issue for other TECOs.
- I could make this macro much shorter if I hard-coded the date and
time decoding for a particular OS.
- I could make this macro much shorter if I hard-coded the time zone
offset from GMT, or even just lied and pretended my web server's local
time *was* GMT.
- Indexing the string %SunMonTueWedThuFriSatSun% and inserting 3 chars
was much less code than doing a comparison for each value.
- Extracting repeated code into a macro was most effective in reducing
squished size.
- The string portion of a Q-register can be viewed as an array of bytes;
I use this to build an array of days in each month. This reduced
the size of code computing day-in-a-year from day/month and day/month
from day-in-a-year. The array is also used to handle underflow and
overflow when applying the GMT offset.
- I made the labels reasonably small in order to squeeze out more
bytes, but since I don't use more than 96 labels, I could have reduced
them to a single character. I decided against this.
- SQU.TEC will recursively squish my macro definitions, but I kept
running into a problem with the day and month strings I was loading
into 1.str until I re-read the SQU.TES source and learned that if
I use % as the delimiter, then SQU will not treat these Q-register
string loads as macro definitions, but as literal text.
- Computed goto @O!tag0,tag1,tag2! made it easier to handle decoding
the different date/time formats in different environments.
- You can't insert or append character codes directly into a Q-register,
but you can insert character codes into the buffer and pull a portion
of the buffer into a Q-register.
- DATE.TES reports the wrong day of the week, probably because it uses
an algorithm that is no longer valid for years > 1999. I switched
to the Sakamoto, Lachman, Keith and Craver algorithm published in
Wikipedia. This also eliminated me having to compute day-within-year.
- n%q can be used to add n to Q-register q, avoiding the Qq + n Uq
phrase, but n%q leaves the result as a numeric argument to the next
command, so ESCs must be inserted to gobble these up.
- TECO numeric expressions have no operator precedence and are
evaluated strictly left to right. Sometimes this means that extra
parenthesis are necessary to get the right evaluation order and
other times parenthesis can be omitted and still retain the proper
evaluation order.
Squished output, made printable:
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
!HTTP-DATE.TEC![M[D[Y[H[N[S[0[1@^UY\0J31I$QY&3"=29I$|28I$'31I$30I$31I$30I$31
I$31I$30I$31I$30I$31I$0XM0K\@^US\U1Q1*3U13<Q1Q1I$1%1$>\@^U0/U0Q0-10"<I0$'Q0\/
^BU0-1EJ/256OD1,D8,DT$ODG$!D1!Q1-7"=Q0"<Q0&32767U064UY|0UY'(Q0/16384*32)+
(Q0&31)+1972%Y$MYQ0/32&31UDQ0/1024&15UM|-1EJ&255-4"=Q0-(Q0/1000*1000)UD
Q0/1000+1970UYMY0U01UM12<Q0QMU1QD-Q1U1Q1">Q1UD1%M$'1%0$>|ODG$'''OD$!D8!Q0&7
+2010UYMYQ0/8&31UDQ0/256&15UMOD$!DT!Q0-(Q0/31*31)+1UDQ0/32U0Q0-(Q0/12*12)+1
UMQ0/12+1964UYMYOD$!DG!Q0&31UDQ0/32&15UMQ0/512+1900UYMY!D!-1EJ/256
OT1,T8,TT$^H*2U0OTG$!T8!12UH00UN00USOO$!T1!-1EJ-4"=(24*60-^H)*60U0OTG$'^H*2U0
OTG$!TT!^H*60U0!TG!Q0/3600UHQH*3600U1(Q0-Q1)/60UNQ0-Q1-(QN*60)US!O!-600U0Q0
"<-Q0U1Q1-(Q1/100*100)%N$QN-59">1%H$-60%N$'Q1/100%H$QH-23">1%D$-24%H$QM-1QMU1
QD-Q1">1%M$1UDQM-12">1%Y$MY1UM'''|-Q0+(Q0/100*100)%N$QN"<-1%H$60%N$'-Q0/100
%H$QH"<-1%D$24%H$QD"=-1%M$QM"=-1%Y$MY12UM31UD|QM-1QMUD''''IDate: $
^U1SunMonTueWedThuFriSat$QYU0QDU1QM-3"<Q0%1$-1%0$|Q0-2%1$'23*QM/9+Q1+4+
(Q0/4)-(Q0/100)+(Q0/400)U0Q0-(Q0/7*7)MSI, $QDM0I $
^U1JanFebMarAprMayJunJulAugSepOctNovDec$QM-1MSI $QY\I $QHM0I:$QNM0I:$QSM0
I GMT
$]1]0]S]N]H]Y]D]M$$
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Source file, made printable:
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
!HTTP-DATE.TEC!
! ------------------------------------------------------------------------- !
! Insert the current date and time as an HTTP Date: header !
! ------------------------------------------------------------------------- !
! The date and time varies by computer and OS, encoded in -1EJ: !
! -1EJ=256*m+n Computer (m) Operating System (n) !
! 0 PDP-11 0 RSX-11D !
! 1 RSX-11M !
! 2 RSX-11S !
! 3 IAS !
! 4 RSTS/E !
! 5 VAX/VMS !
! (compatibility mode) !
! 6 RSX-11M+ !
! 7 RT-11 !
! 1 PDP-8 0 OS/8 !
! 2 DEC-10 0 TOPS-10 !
! 3 DEC-20 0 TOPS-20 !
! 4 VAX-11 0 VAX/VMS !
! (native mode) !
! 100 Unix 0 Unix !
! 101 IBM PC 0 MS-DOS !
! 1 Win32, OS/2 !
! 102 Amiga 0 AmigaDOS 1.3 !
! ------------------------------------------------------------------------- !
[M [D [Y [H [N [S [0 [1 ! save used Q-reg's !
! M.num = month in year, 1-12 !
! M.str = days in months as characters adjusted for leap years !
! D.num = day in month, 1-31 !
! Y.num = 4-digit year !
! Y.str = macro to build M.str from Y.num !
! H.num = hour in day, 0-23 !
! N.num = minute in day, 0-59 !
! S.num = second in minute, 0-59 !
! S.str = macro to insert 3 chars from 1.str !
! 0.num = scratch value !
! 0.str = macro to insert 2-digit number with leading zero !
! 1.num = scratch value !
! 1.str = argument to S.str !
! <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< !
! Y.str = macro to build M.str = days in month as characters !
! using Y.num = current year !
@^UY\
0J ! Go to start of buffer !
31 at I// ! January !
QY&3 "= 29 @I// | 28 @I// ' ! February !
31 @I// ! March !
30 @I// ! April !
31 @I// ! May !
30 @I// ! June !
31 @I// ! July !
31 @I// ! August !
30 @I// ! September !
31 @I// ! October !
30 @I// ! November !
31 @I// ! December !
0XM ! M.str = temporary string !
0K ! delete temporary string !
\
! >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> !
! <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< !
! S.str = macro to insert 3 chars from 1.str !
@^US\
U1 ! 1.num = 0-based word index !
Q1*3 U1 ! 1.num = char offset in 1.str !
3< ! for 3 chars... !
Q1Q1 @I"" ! insert one char !
1 %1$ ! 1.num++ !
> ! end !
\
! >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> !
! <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< !
! 0.str = macro to insert two digit number, with leading zero !
@^U0/
U0 ! 0.num = arg !
Q0 - 10"< ! if 0.num < 10? !
@I"0" ! insert zero !
' ! end if !
Q0\ ! insert 0.num !
/
! >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> !
^B U0 ! 0.num = encoded date !
-1EJ/256 @O!D1,D8,DT! ! handle special date decodings !
@O!DG! ! handle general date decoding !
!D1!
Q1 - 7 "= ! RT-11? !
! ------------------------------------------------------------------------- !
! RT-11: ^B = ((((year-2003)*16+month)*32)+day)*32)+(year-1972)&31 !
! ------------------------------------------------------------------------- !
Q0 "< ! if high bit set? !
Q0&32767 U0 ! strip high bit !
64 UY ! Y.num = corresponding year !
| ! else !
0 UY ! Y.num = 0 !
' ! end if !
(Q0/16384*32) + (Q0&31) + 1972 %Y$ ! Y.num += remaining part of year !
MY ! M.str = days in months !
Q0/32 & 31 UD ! D.num = day !
Q0/1024 & 15 UM ! M.num = month !
| -1EJ & 255 - 4 "= ! if RSTS/E? !
! ------------------------------------------------------------------------- !
! RSTS/E: ^B = ((year-1970)*1000)+day within year !
! ------------------------------------------------------------------------- !
Q0 - (Q0/1000*1000) UD ! D.num = day in year !
Q0/1000 + 1970 UY ! Y.num = year !
MY ! M.str = days in months !
0U0 ! U.num = 0 !
1UM ! M.num = January !
12< ! for 12 months... !
Q0QM U1 ! 1.num = days in month 0.num !
QD - Q1 U1 ! 1.num = D.num - 1.num !
Q1 "> ! if D.num > days in month? !
Q1 UD ! D.num -= days !
1 %M$ ! M.num++ !
' ! end if !
1 %0$ ! 0.num++ !
> ! end !
! D.num = day in month !
! M.num = month in year !
| ! otherwise, !
@O!DG! ! general case !
' ! end if !
'
'
@O!D!
! ------------------------------------------------------------------------- !
! OS/8: ^B = (((month*32)+day)*8)+((year-1970)&7)+k !
! where k = 4096 if year>1977 !
! and k=0 otherwise !
! ------------------------------------------------------------------------- !
!D8!
Q0 & 7 + 2010 UY ! Y.num = year !
MY ! M.str = days in months !
Q0/8 & 31 UD ! D.num = day !
Q0/256 & 15 UM ! M.num = month !
@O!D!
! ------------------------------------------------------------------------- !
! TOPS-10, !
! TOPS-20: ^B = (((year-1964)*12+month-1)*31+day-1) !
! ------------------------------------------------------------------------- !
!DT!
Q0 - (Q0/31*31) + 1 UD ! D.num = day !
Q0/32 U0 ! 0.num /= 32 !
Q0 - (Q0/12*12) + 1 UM ! M.num = month !
Q0/12 + 1964 UY ! Y.num = year !
MY ! M.str = days in months !
@O!D!
! ------------------------------------------------------------------------- !
! RSX-11: ^B = ((year-1900)*16+month)*32+day !
! VAX/VMS: ^B = ((year-1900)*16+month)*32+day !
! Amiga: ^B = ((year-1900)*16+month)*32+day !
! Unix: ^B = ((year-1900)*16+month)*32+day !
! Win32: ^B = ((year-1900)*16+month)*32+day !
! OS/2: ^B = ((year-1900)*16+month)*32+day !
! MS-DOS: ^B = ((year-1900)*16+month)*32+day !
! ------------------------------------------------------------------------- !
!DG!
Q0 & 31 UD ! D.num = day !
Q0/32 & 15 UM ! M.num = month !
Q0/512 + 1900 UY ! Y.num = year !
MY ! M.str = days in months !
!D!
! Get HH:MM:SS in Q-reg's H,M,S !
-1EJ/256 @O!T1,T8,TT! ! handle special decodings !
^H*2 U0 ! 0.num = seconds since midnight !
@O!TG! ! handle general decoding !
! ------------------------------------------------------------------------- !
! OS/8: ^H = 0 !
! ------------------------------------------------------------------------- !
!T8!
12 UH ! H.num = 12 !
00 UN ! N.num = 0 !
00 US ! S.num = 0 !
@O!O! ! output time !
! ------------------------------------------------------------------------- !
! RSTS/E: ^H = minutes until midnight !
! ------------------------------------------------------------------------- !
!T1!
-1EJ -4 "= ! RSTS/E? !
(24*60 - ^H)*60 U0 ! 0.num = seconds since midnight !
@O!TG! ! handle general decoding !
'
^H*2 U0 ! 0.num = seconds since midnight !
@O!TG! ! do general case !
! ------------------------------------------------------------------------- !
! TOPS-10: ^H = 60ths of a second since midnight !
! (or 50ths of a second where 50 Hz power is used) !
! ------------------------------------------------------------------------- !
!TT!
^H*60 U0 ! 0.num = seconds since midnight !
! fall through to general case !
! ------------------------------------------------------------------------- !
! RT-11: ^H = (seconds since midnight)/2 !
! RSX-11: ^H = (seconds since midnight)/2 !
! VAX/VMS: ^H = (seconds since midnight)/2 !
! Amiga: ^H = (seconds since midnight)/2 !
! Unix: ^H = (seconds since midnight)/2 !
! Win32: ^H = (seconds since midnight)/2 !
! OS/2: ^H = (seconds since midnight)/2 !
! MS-DOS: ^H = (seconds since midnight)/2 !
! ------------------------------------------------------------------------- !
!TG!
Q0/3600 UH ! H.num = hours !
QH*3600 U1 ! 1.num = hours (in seconds) !
(Q0 - Q1)/60 UN ! N.num = minutes !
Q0 - Q1 - (QN*60) US ! S.num = seconds !
!O!
-600 U0 ! offset from GMT !
Q0 "< ! if offset < 0? !
-Q0 U1 ! add offset to local time !
Q1 - (Q1/100*100) %N$ ! N.num += minute offset !
QN - 59 "> ! if minutes overflowed? !
1 %H$ ! H.num++ !
-60 %N$ ! N.num -= 60 !
' ! end if !
Q1/100 %H$ ! H.num += hour offset !
QH - 23 "> ! if hours overflowed? !
1 %D$ ! D.num++ !
-24 %H$ ! H.num -= 24 !
QM-1QM U1 ! 1.num = days in month !
QD - Q1 "> ! if days overflowed? !
1 %M$ ! M.num++ !
1 UD ! D.num = 1 !
QM - 12 "> ! if month overflowed? !
1 %Y$ ! Y.num++ !
MY ! rebuild M.str !
1 UM ! M.num = 1 !
' ! end if !
' ! end if !
' ! end if !
| ! else !
! subtract offset from local time !
-Q0 + (Q0/100*100) %N$ ! N.num -= minute offset !
QN "< ! if minutes underflowed? !
-1 %H$ ! H.num-- !
60 %N$ ! N.num += 60 !
' ! end if !
-Q0/100 %H$ ! H.num -= hour offset !
QH "< ! if hours underflowed? !
-1 %D$ ! D.num-- !
24 %H$ ! H.num += 24 !
QD "= ! if days underflowed? !
-1 %M$ ! M.num-- !
QM "= ! if months underflowed? !
-1 %Y$ ! Y.num-- !
MY ! rebuild M.str !
12 UM ! M.num = 12 !
31 UD ! D.num = 31 !
| ! else !
QM-1QM UD ! D.num = last day of month !
' ! end if !
' ! end if !
' ! end if !
' ! end if !
@I"Date: " ! Insert Date: header !
! Insert DAY, DD Mon YYYY !
@^U1%SunMonTueWedThuFriSat%
QY U0 ! compute day within week from !
QD U1 ! methods of Sakamoto, Lachman, !
QM-3 "< ! Keith and Craver !
Q0 %1$
-1 %0$
|
Q0 - 2 %1$
'
23*QM/9 + Q1 + 4 + (Q0/4) - (Q0/100) + (Q0/400) U0
Q0 - (Q0/7*7)
MS ! Insert DAY !
@I", " ! Insert ,<SP> !
QD M0 ! Insert DD !
@I" " ! Insert <SP> !
@^U1%JanFebMarAprMayJunJulAugSepOctNovDec%
QM - 1 MS ! Insert name of month !
@I" " ! Insert <SP> !
QY\ ! Insert YYYY !
@I" " ! Insert <SP> !
! Insert HH:MM:SS !
QH M0 ! Insert HH !
@I":" ! Insert : !
QN M0 ! Insert MM !
@I":" ! Insert : !
QS M0 ! Insert SS !
@I" GMT
" ! Insert <SP>GMT<CR> !
]1 ]0 ]S ]N ]H ]Y ]D ]M ! restore used Q-reg's !
$$
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
The Terminals Wiki <http://terminals.classiccmp.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
I have another card I can't identify:
It's a Q-bus card; in copper on the front of the card it's marked
"BSW-Q". on the back, it's marked "4522 111 89361". On the front,
there's a sticker that reads "4522 117 0825" and "1996830". I think
the latter might be a date code. The 4522 numbers look suspiciously
like 12NC numbers, which to me suggests that this is not a DEC part
(maybe Philips?)
Camiel.
The RICM is still wrestling with the core in the PDP-8.
After replacing some diodes on the core stack we have all addresses working.
We observed an interesting core memory behavior during our debugging
last Saturday.
We started the memory alignment procedure by looking at the
STROBE FIELD 0 signal and the amplifier output on pin E1 of the sense
amplifier. The STROBE signal was very late compared to Figure 5-6 in
the 8/L Maintenance Manual. We ran a short JMP loop and adjusted the
relationship with the trimpot on the M360 delay module. When we halted the
processor and tried a examine core we only got just zeros.
We adjusted the M360 delay back where it was and single step worked
again. We found that the strobe-to-one-bit relationship was almost
100ns earlier when in single-step than it was with the processor
running. We checked the whole timing path from MEM START at pin N2 of
the M113 in slot C03, through all of the gates, delays, and
flip-flops, and found no timing difference between single-step and
running. Right now it looks like there is a 100ns delay difference
between the READ(1) signal that turns on the current in the core and
the bit signal showing up on the E1 pin of the sense amplifier when in
the single-step and running.
Is this normal behavior?
--
Michael Thompson
On 2012-07-15 12:29, Richard<legalize at xmission.com> wrote:
> In article<4FFEAC19.2080507 at update.uu.se>,
> Johnny Billquist<bqt at update.uu.se> writes:
>
>> >However, with only 13 bits for integers in TECO, I'm not sure how you
>> >would go about to solve it in a reasonable way...
> I'm not sure why you think TECO has 13-bit integers on a 12-bit
> machine...
Maybe because it does...? :-)
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
On 2012-07-12 12:11, Rick Murphy <rick at rickmurphy.net> wrote:
> At 12:12 PM 7/11/2012, Richard wrote:
>> >For OS/8, you only get *3* bits for the year plus a high 4K bit set if
>> >the year is out of range? Does this mean years higher than 1977 are
>> >encoded as 4096+(year-1977)?
>> >...
>> >Can anyone with RT-11 or OS/8 and TECO v40 verify what is described above?
> As already mentioned, this is consistent with OS/8 date code - 3 bits
> of year and two of extension.
>
> You can't enter dates later than 1999:
>
> .DATE 31-DEC-99
>
> .DATE
> Friday December 31, 1999
>
> .DATE 1-JAN-00
> BAD DATE
> .DATE 1-JAN-2000
> BAD DATE
Right. But that is a limitation of the command decoder, and have very
little to do with any other part of OS/8 date handling. The date
encoding in OS/8 itself actually worked until 2002.
> What 31-DEC-99 gives you from TECO:
> .R TECO
> *^B==$$
> 16375
>
> (12 * 32) + 31) * 8 = 3320
> (1999 - 1970) & 7 = 5
> 3325 DEC, 6375 OCT plus 4096 gives 16375.
>
> You can't tell what this really means (it could be 1983, 1991, or 1999)
> but that's an OS/8 failure, not TECO.
No. That is a failure in TECO. OS/8 obviously knows if it is 1975, 1983,
1991 or 1999. The information is not preserved in TECO. TECO fail.
The problem is that OS/8 keeps two bits for the extension of the years,
while TECO compressed that into just one bit. Loss of information follows.
However, with only 13 bits for integers in TECO, I'm not sure how you
would go about to solve it in a reasonable way...
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
I am hoping that one of you might be able to shed some light on a
strange behavior in the RICM PDP-8/L.
It looks like we have everything working OK except for a strange
behavior when the processor is run at full speed.
Single-stepping Instruction Test 1 works OK, so at least the processor
logic is mostly functional.
We tried just running Instruction Test 1 at full speed, but it halted at 0501.
We looked at the code in that area and found that the contents of
location 0500 was all zeros.
We loaded a little program consisting of: IAC, IAC, JMP .-2 and found
that it would replace the first IAC with zeros.
More experimenting showed that if any of the address bits 6-11 were
on, the program would work OK.
If you run the processor at full speed through an instruction at xx00,
that location is replaced with zeros.
We swapped all of the G221s, G228s, and G224s. None of the module
changes affected the strange behavior.
We swapped the M617 in slot A9, but that didn't make a difference.
The read/re-write current waveforms look OK for all addresses.
At this point we really don't know what is causing this behavior, so
any ideas would be helpful.
--
Michael Thompson
On 2012-07-13 07:25, Rick Murphy <rick at rickmurphy.net> wrote:
> At 06:51 AM 7/12/2012, Johnny Billquist wrote:
>> >Right. But that is a limitation of the command decoder, and have very
>> >little to do with any other part of OS/8 date handling. The date
>> >encoding in OS/8 itself actually worked until 2002.
> What you mean is that you can set the system date information to
> correspond to dates as late as 2002 if you either do it by hand (ODT)
> or with some other program. However, being able to set the date to
> something in 2001 doesn't help you much, because nothing that I know of
> that's shipped with the OS handles dates past 1999. (Note: I don't know
> if any of the OS/78 or OS/278 kits did anything here.)
Correct. The command decoder is not the only piece of software that
can't handle dates beyond 1999, but the example you gave showed the
specific limitation of the command decoder.
But I never claimed that OS/8 was Y2K safe. I only pointed out that the
internal representation of a date in OS/8 was in fact good until 2002.
> For example, setting the date to 31-DEC-77 then setting the two
> extended date bits on gives you:
> .DATE
> Monday December 31, 19 1
>
> OK, that's still the Command Decoder. How about DIR?
No, it's not the command decoder (as in the decoding and parsing of the
command), but it's the date command output itself that do not handle
dates beyond Y2K.
> .DIR 2000.*
>
> 31-Dec-101
>
> 2000 .TX 1 31-Dec-101
>
> 1 Files in 1 Blocks - 615 Free blocks
>
> Looks like the date handling is pretty broken. Unless you're aware of
> something that actually displays the right date for such things.
No. It is broken. In this case DIRECT. I would suspect every utility
that ever existed, more or less, in OS/8 to not handle dates beyond Y2K.
But that could be fixed, and it's a separate issue from the date command
accepting years beyond 1999 as input.
Just for information, older versions of RSX, for example, have exactly
the same bug. 2001 shows up as 101 in various places, even though RSX
itself is actually good until the year 34667.
In a way though, 101 is pretty logical. Program that displayed years as
two digit numbers were actually often just showing an offset from the
year 1900, and 2001 is, by that view, 101. But it's not pretty. Nor
actually a correct display of the year.
> Oh, and the other fun aspect:
> .DATE 1-JAN-77
>
> .DIR 2000.*
>
> 01-Jan-77
>
> 2000 .TX 1 31-Dec-77
>
> 1 Files in 1 Blocks - 615 Free blocks
>
> When you change the date, you might also be changing the creation dates
> for files by one or more multiples of 8 years.
Right. That is a known limitation that is documented. Dates on files do
only cover a 8 year span, so they simply guess which 8-year span to
apply to file dates. It was a "problem" already in 1978.
> The failure to include extended date bits in directories means that
> whatever date your files were created in, they're assumed to be within
> eight years of the current date. Changing the date changes what the OS
> thinks the creation date is for a file.
Correct.
>>> >>What 31-DEC-99 gives you from TECO:
>>> >>.R TECO
>>> >>*^B==$$
>>> >>16375
>>> >>
>>> >>(12 * 32) + 31) * 8 = 3320
>>> >>(1999 - 1970) & 7 = 5
>>> >>3325 DEC, 6375 OCT plus 4096 gives 16375.
>>> >>
>>> >>You can't tell what this really means (it could be 1983, 1991, or 1999)
>>> >>but that's an OS/8 failure, not TECO.
>> >
>> >No. That is a failure in TECO. OS/8 obviously knows if it is 1975,
>> >1983, 1991 or 1999. The information is not preserved in TECO. TECO fail.
> It's also a failure in OS/8. 12 bits gives you potentially 11 years of
> date range (4096 days at 365 days per year); the 14 bits they're using
> could have given almost 45 years of date range if DEC had decided to
> change the date format to be days since 1-jan-1970. It would have made
> sense given that the current format has so many problems (can't be
> compared using simple arithmetic, for example).
This is a different issue, but sure. Different date formats could have
made the system work for longer. There is actually no reason why you
need to stuff all the information into just one 12-bit word either. But
it's all a tradeoff between speed, space, and complexity. DEC chose
initially to store the date in one 12-bit word, with different bitfields
reserved for different parts of the date. Not super compact, but easy to
deal with. It ran out of range in 1978, they did the simplest form of
extension by reserving two more bits in another word in memory, while
not doing anything at all about dates on files.
That scheme in turn ran out in 2002, but I suspect DEC was happy enough
with that, since at Y2K, a lot of other things would break anyway (as
you showed above), so an extension of the date format that carried
longer would not be very useful anyway without going through and fixing
all other code there was, which is a lot, and which they didn't do.
But the fact that TECO can't tell a date from beyond 1985 is not
something you can blame OS/8 for anyway. TECO made its own choice on how
to represent dates. Information in OS/8 gives you unique dates until
2001, but TECO does not. You can't possibly blame OS/8 for that.
>> >The problem is that OS/8 keeps two bits for the extension of the
>> >years, while TECO compressed that into just one bit. Loss of
>> >information follows.
>> >
>> >However, with only 13 bits for integers in TECO, I'm not sure how you
>> >would go about to solve it in a reasonable way...
> True, there's not much that can be done given the data type. 13 bits
> packed just doesn't get you enough range.
>
> The TECO source doesn't say anything about this limitation, but it just
> ignores the high-order date bit:
>
> CTL.B, TAD I (7777
> RTL
> RTL
> RAL /PUT EXTENDED DATE BIT IN LINK
> L7200, 7200 /CLA
> CDF 10
> TAD I (7666
> CDF 0
> JMP I (NCOM
Ooo. So TECO-8 actually lie in their documentation... Even worse.
A year in the range 1986-1994 would just have looked like 1970-1977.
That's ugly of them.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
I have found a TK50 tape which has written 'VMS 2.5' on it.
I have no read the tape so I do not know if contains anything
at all. If it does contain something, it could be an installation
duplicate or just a backup of some system.
Free for who wants it, I only ask for the postage fee to be paid
(approx $10 - $15 for worldwide shipping)
Ed
--
Dit is een HTML vrije email / This is an HTML free email.
Zeg NEE tegen de 'slimme' meter.
The Seattle Retro-Computing Society meets in Paul Allen's Living Computer
Museum the forth Saturday of the month.
(http://www.seattleretrocomputing.com ) We missed a couple of meetings
because the building was being remodeled. Work is starting on museum
exhibits for the general public. There is no announced opening date yet.
You can request a tour of the existing site on their web site.
http://www.pdpplanet.com
I have posted some photos of the museum and our club meetings.
http://www.swtpc.com/mholley/Living_Computer_Museum/SRCS.html
Michael Holley
(There may be a duplicate of this message.)
Stuck them on eBay, no one bid. I've never actually used Paradox. Are these worth saving? Anyone need them (hopefully w/the intention of sharing them wif the community)?
youre both morons you know
------------------------------
On Thu, Jul 12, 2012 8:48 PM PDT Chuck Guzis wrote:
>On 12 Jul 2012 at 22:41, Dan Gahlinger wrote:
>
>>
>> Why would I need a Paradox when I don't even own a boat?
>
>Seems to me that a Paradox would come in handy if you wanted a second
>opinion on your condition...
>
>
>On second thought, I concur. The fingers seem to match the Apple II
>slot (power and data lines in the correct positions), so it is very
>likely an Apple II card.
Naaah, I disagree.
Sure, it yelled "Apple" at me immediately.
But it looks like the power is in the middle, by C1... and Apple II power
is at the (what would be in this pic) right hand side, and those look like
signals going to the 244.
On an Apple the pins 45 and 47 (the way this card is numbered) would be
daisy chained to the other side.
Not Apple IMO.
W
According to the documentation for TECO v40:
^B <CTRL/B> (caret/B) is equivalent to the current date
via the following equations:
OS/8: ^B = (((month*32)+day)*8)+((year-1970)&7)+k
where k = 4096 if year>1977
and k=0 otherwise
RT-11: ^B = (((month*32)+day)*32)+year-1972
RSTS/E: ^B = ((year-1970)*1000)+day within year
RSX-11: ^B = ((year-1900)*16+month)*32+day
VAX/VMS: ^B = ((year-1900)*16+month)*32+day
TOPS-10: ^B = (((year-1964)*12+month-1)*31+day-1)
Notice how the year is added as the least significant bits for OS/8
and RT-11.
For OS/8, you only get *3* bits for the year plus a high 4K bit set if
the year is out of range? Does this mean years higher than 1977 are
encoded as 4096+(year-1977)?
For RT-11, notice how year-1972 is packed into *5* bits (0..31), so
years after 1972+31=2003 start carrying over into the bits for the month
and day.
Can anyone with RT-11 or OS/8 and TECO v40 verify what is described above?
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
The Terminals Wiki <http://terminals.classiccmp.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
Does anyone know of any adaptors to fit a "modern" drive (be it IDE,
SCSI, ATA, CompactFlash etc) into a machine with an ST-506/412
interface?
Or more reasonably knowing this list, does anyone know of schematics
and board kits? :)
My dad turned this up the other day. He'd been tidying his desk and
come across it! He's no idea where it came from, or what it's out
of...
Anybody got any ideas?
Picture at http://www.irrelevant.com/rob/IMG_3002.JPG (708KB)
It look a bit like an ISA card missing it's bracket but I've not got
one to hand to compare it too. Label shows a horse, CP Computer
Products, Power Products Division and a matrix printed "PM671R".
Underside has "Artwork PC19640, REV.B. Detail PC19641. Assembly
PC19642. G T P 244" in copper.
Main chip is an AMD Z8530PC. There's a PAL and a MC1488 & 9,
otherwise the rest is 74LS TTL. All socketed. 26 pin internal header.
No external sockets. Date codes are mostly 1987.
It certainly feels like some sort of RS232 serial card, based on the
chips, but I've not seen one without an D-type socket on before.
Any ideas? Anybody have a use for it? FTGH just pay postage.
Rob
>
>Wasn't there a short-lived "S-50" bus once upon a time?
There was an SS-50 bus which was a 680x bus by as far as I remember mostly
SWTPC and Gimix, and that was based on 0.1" headers with the sockets on the
motherboards. There was also an SS-30 bus for I/O -- similar to the Apple
II in that each slot had a decoded select signal.
Dave Dunfield knows more than most of us about this :-)
W
We're moving, and I need to down-size considerably.
I want to sell the following DEC gear as a lot for $2000.
You must be able to pick it up in Colorado Springs.
Everything goes together, please - no cherry-picking. You take it all, and you can dispose of the stuff you don't want.
Here's the highlights:
PDP-8E. Years ago, I was able to key in stuff from the front panel, but it didn't seem to execute. But I think it's not too far from working.
PDP-11/05. The 5V power rail doesn't work, and the core memory is flakey, but years ago I hooked up an external 5V supply, cabled the Unibus to an external DD11 with MOS memory, and booted and ran RT-11 using my RX01 emulator board. The front panel is ugly, but all the switches and lights work. Includes spare CPU and memory-controller cards, but at least some of them don't work.
VT05 terminal. DEC's first general-purpose video terminal. Quite rare, I think. It works, last time I tried.
VT100 terminal. Works.
PDP-11/03-L system box. It's a rack-mountable BA11 chassis with CPU, memory, BDV11, and serial card.
PDT-150. Works. Have a spare CPU board also.
VAXstation 3100-M38.
AlphaStation 200 -4/166.
"Pizza box" storage box. Accepts 3 SCSI SBB disk drives.
About 2 linear feet of microfiche, tech and maint. info. These alone are worths 100's of $$ on eBay. This is mostly "good stuff".
Option Module List books, 4 volumes.
VMS CDs.
Digital Technical Journals - I think it's a complete set.
DEC handbooks - about 4-5 linear feet.
A variety of modules, including Unibus, Q-bus, u-VAX, and some straight-8 flip-chip cards.
Also available, but for an additional cost:
Original Commodore PET, 8K RAM, chiclet keyboard. It was my very first computer in 1979.
Atari 800 system.
HP-85.
A home-brew S-100 system that I built, based on a PDP-8i switch panel and vintage LEDs.
Pete
Contact me at:
saipan59
at
Q
dot
com.
Or call:
719 282 1033 (weekends, or evenings before 10PM Mountain)
I have quite a pile of TSX-plus docs that need to find a good home -
so far three or four binders. TSX is an extension of RT-11. Please
contact me off list. Bitsavers has dibs. Free for postage (media rate
should not be too bad).
--
Will