>I suspect that the check should actually be made for the day field of
>the date word being zero as being invalid... the year can be 00, the
>month can be, too, but the day field should always be non-zero for
>a valid date. (though I've always had a problem with why the months
>field was 0-11 instead of 1-12 when the day field was 1-31).
You might want to check your manuals again, Megan - for the past two
decades that I've been doing RT-11 programming, the month field in the
date word *does* run 1-12, not 0-11. (Actually, 0-11 would make
more sense since you're almost always using it as an index into a
table of month names...)
And, of course, the CSI command lines generally expect RAD50 constants for
months, not numbers, so you can generally type
037266 instead of JAN
023112 instead of FEB
050572 instead of MAR
004322 instead of APR
050601 instead of MAY
040726 instead of JUN
040724 instead of JUL
004617 instead of AUG
073630 instead of SEP
057114 instead of OCT
054756 instead of NOV
014713 instead of DEC
Note that octal 004322 = decimal 2258. So some fixes are going
to happen in the future with date parsing if one wants to be sure not
to confuse 'APR' with the year '2258' :-).
There are some other funny things with year parsing in CSI command lines
that have been around since the mid 70's. In particular, most of the
RT-11 utilities used to (that is, prior to 5.7) take as legal years
59 through 63 decimal. Convert these to octal, and you see they
are represented as 73 through 77. This way, if you forgot the decimal
point on a CSI command line in specifying a year in the range 73-77,
the utility "fixed it up" for you with the "do what I mean" operator :-).
It's a cute trick, but it doesn't work from 1980 through 1999 because
8 and 9 aren't legal octal digits... and it wasn't reimplemented for
4 digit years in the range of 2000-2007.
--
Tim Shoppa Email: shoppa(a)trailing-edge.com
Trailing Edge Technology WWW: http://www.trailing-edge.com/
7328 Bradley Blvd Voice: 301-767-5917
Bethesda, MD, USA 20817 Fax: 301-767-5927
>> >In addition, some of the code in RT-11 in the monitor and elsewhere
>> >rejects a date value with a year value of zero - meaning that 1972 is
>> >considered invalid by that code.
>> This was fixed in RT-11 5.7, it now consistently handles 1972 through
>> 2099, inclusive.
>I am confused here just a little bit. And I am not taking exception to
>what was done in V5.7 - in fact, I believe that the decisions which were
>made were correct. However, if "this was fixed in RT-11 V5.7" is
>what I think the word "fixed" means, then not allowing the command:
>"DATE 01-Jan-72"
>in all versions of RT-11 which did allow the command "DATE 01-Jan-73"
>means that these previous versions had a "bug". If a "bug" is the correct
>interpretation for not allowing a year of 1972, I wonder why the developers
>of RT-11 never corrected that aspect in all the years of RT-11 development?
It wasn't a very serious bug, unless you had files with datestamps
>from 1972 on them. In my experience, you're only likely to see pre-1974
datestamps in RT-11 if the files were imported from, say, an old DOS-11
tape.
>> >the DATE/TIME hardware clock on the third party board. Any idea
>> >how the 11/93 does the 1999 transition with the now Y2K compliant
>> >firmware update?
>> Look in the NL.MAC source code - the SETUP.SAV window range was
>> chosen identically:
>I stated my question incorrectly. I know how the DATE value is divided
>in the different 4 fields. What I was specifically wondering about was how
>DATE/TIME values in the 11/93 were handled before the firmware on the
>11/93 was made Y2K compliant as what happens now - if indeed anything
>is different? I have seen references to the upgrade needed by the 11/93
>firmware to make it Y2K compliant. What I am curious about is how the
>Y2K compliant firmware for the 11/93 handles the year and if that was
>any different before the 11/93 firmware was made Y2K compliant.
Technically, the "11/93 TOY clock firmware fix" wasn't to fix a Y2K
problem, it was there to fix a Y2000.164 problem. The actual problem
occured after 29-Feb-2000, which the TOY clock firmware regarded (at
boot time) as an illegal date and it set the TOY clock back to the
factory default date (1-Jan-1980, if I'm not mistaken.)
This was more of a boneheaded "2000 is not a leap year" mistake than
anything else.
Most (all?) other PDP-11 TOY clock modules don't attempt to do anything
particularly "smart" (here, simple is good, because the "smart" code
may do something "stupid" someday) with the date.
--
Tim Shoppa Email: shoppa(a)trailing-edge.com
Trailing Edge Technology WWW: http://www.trailing-edge.com/
7328 Bradley Blvd Voice: 301-767-5917
Bethesda, MD, USA 20817 Fax: 301-767-5927
IIRC, it was the TCP/IP that didn't work well in the presence of DEC
hardware back then. If we put a bridge between the DEC stuff and the
SUN/APOLLO/HP... it seemed to work OK. There wasn't any NETWARE stuff there
either, since that was still early in NOVELL's lifespan. I use it here
because it lets me view the server as another drive or two and because I
can't find a smaller shell/driver set for DOS.
Dick
-----Original Message-----
From: Allison J Parent <allisonp(a)world.std.com>
To: Discussion re-collecting of classic computers
<classiccmp(a)u.washington.edu>
Date: Sunday, November 14, 1999 9:24 PM
Subject: Re: Effective Speed of 10BaseT
><Not just humor, Allison. Substantial accomodation for DEC network hardwar
><had to be made back then ('86..'87) because DEC had features which would
><foul other hardware up if accomodation wasn't made. In order to keep from
>
>Sounds like the features were those needed to do WAN and you wanted
>something lighter. Generally at that time I was viewing most LANs as
>broken or nearly so. The only protocals I remember that worked were
>DECnet, TCP/IP and BANYAN vines for routable and Netware for local
>PC stuff.
>
><bringing down the LAN, all software/configuration changes had to be made i
><advance of connecting the first DEC hardware. It didn't always bring down
><the LAN, but if that was your only worry, it certainly would.
>
>my experience was non DEC hardware didn't work or was questionable. Though
>the common Qbus NI (DEQNA) was known to be a poor performer in more ways
>than one. Side effect of an old design even by late '87 standards.
>
>Allison
>
Greetings all;
A new arrival joined us tonight, but it looks like he is suffering from a
very rough life.
A HERO-1, who was fished out of the dumpster (EEK!) a couple of years ago,
and rattled around someone's desk ever since as a curiosity. Fortunately,
I have a friend who was able to rescue him from this rather unpleasant fate.
At first glance, he is in rather sad shape. One of the metal side panels
and both of the plastic panels are missing, there are some cracks in the
head plastics, the blue foam bar for the sonars is gone, a couple of
keycaps from his keypad are missing, and the arm plastics are badly damaged.
Mechanically though he seems fairly complete. Some bent metal here and
there but nothing too serious, and the wrist is going to need some help.
Batterys are completely shot, no charger or teaching pendant, tho I have
all that with my other HERO-1. And besides, I've been looking for an
excuse to build a 'control console' for Science Fair demos. (big buttons
and icons)
Electronics look to be in fair condition, I've noted a couple of (common)
ICs are missing, and in my first quick look I noted a small junction board
mounted on the bottom plate just inside of the back door marked 'Interface
board' that puzzled me... Until I pulled the head plastic and found that
what I had first thought to be a 'bike flag' (really, a red triangular flag
that says "HERO" on a stiff wire), was actually the antenna for the RF
remote receiver unit!
No apparent options other than the arm (and speech board). Have not
checked ROM versions yet... He will need a thorough check out before I
consider powering him up.
But... all in all, I think he might even make it back to life in time for
our next scheduled Science Fair appearance in February. (one can always hope)
...And then there were three! Mayhaps he will join us at VCF IV. B^}
-jim
---
jimw(a)computergarage.org
The Computer Garage - http://www.computergarage.org
Computer Garage Fax - (503) 646-0174
Tim Shoppa Replies:
>Jerome Fine replies:
>>In addition, some of the code in RT-11 in the monitor and elsewhere
>>rejects a date value with a year value of zero - meaning that 1972 is
>>considered invalid by that code.
>
>This was fixed in RT-11 5.7, it now consistently handles 1972 through
>2099, inclusive.
Thank you... I was about to respond to Jerome that if it did do
that (and I didn't know it did), I would have considered that to be
a bug which would require fixing, not programming around...
I suspect that the check should actually be made for the day field of
the date word being zero as being invalid... the year can be 00, the
month can be, too, but the day field should always be non-zero for
a valid date. (though I've always had a problem with why the months
field was 0-11 instead of 1-12 when the day field was 1-31).
Megan Gentry
Former RT-11 Developer
+--------------------------------+-------------------------------------+
| Megan Gentry, EMT/B, PP-ASEL | Internet (work): gentry!zk3.dec.com |
| Unix Support Engineering Group | (home): mbg!world.std.com |
| Compaq Computer Corporation | addresses need '@' in place of '!' |
| 110 Spitbrook Rd. ZK03-2/T43 | URL: http://world.std.com/~mbg/ |
| Nashua, NH 03062 | "pdp-11 programmer - some assembler |
| (603) 884 1055 | required." - mbg |
+--------------------------------+-------------------------------------+
<Not just humor, Allison. Substantial accomodation for DEC network hardwar
<had to be made back then ('86..'87) because DEC had features which would
<foul other hardware up if accomodation wasn't made. In order to keep from
Sounds like the features were those needed to do WAN and you wanted
something lighter. Generally at that time I was viewing most LANs as
broken or nearly so. The only protocals I remember that worked were
DECnet, TCP/IP and BANYAN vines for routable and Netware for local
PC stuff.
<bringing down the LAN, all software/configuration changes had to be made i
<advance of connecting the first DEC hardware. It didn't always bring down
<the LAN, but if that was your only worry, it certainly would.
my experience was non DEC hardware didn't work or was questionable. Though
the common Qbus NI (DEQNA) was known to be a poor performer in more ways
than one. Side effect of an old design even by late '87 standards.
Allison
<Hey! What's wrong with DEQNAs and MV2000s?
Actually nothing. I run a bunch of both. They are 1988 technology and
expectations should be accordingly.
<A serious question, actually: What *is* wrong with MV2000s? I have a few
<-- not currently in use, but intended for a play-with-VMS-cluster after I
<move -- and one of them constantly gets ethernet errors. On the machines
<that work, the lance chip is moved up onto a little daughtercard with a
<few other components; on the one that doesn't, it's directly in its
<socket. (Sorry about the lack of detail -- the machines are in storage --
<but anyone who knows about this presumably doesn't need my description.)
Don't know, though I've never seen one without the lance board. Maybe
someone was trying to make a system with the wrong parts.
Allison
Not just humor, Allison. Substantial accomodation for DEC network hardware
had to be made back then ('86..'87) because DEC had features which would
foul other hardware up if accomodation wasn't made. In order to keep from
bringing down the LAN, all software/configuration changes had to be made in
advance of connecting the first DEC hardware. It didn't always bring down
the LAN, but if that was your only worry, it certainly would.
Dick
-----Original Message-----
From: Allison J Parent <allisonp(a)world.std.com>
To: Discussion re-collecting of classic computers
<classiccmp(a)u.washington.edu>
Date: Sunday, November 14, 1999 7:46 PM
Subject: Re: Effective Speed of 10BaseT
><Part of my team at the lab where I worked at the rocket ranch was once
><tasked to quantify this and the first question you must ask is "Is there
an
><DEC hardware in the building, connected or otherwise?" What was determine
>
>This is humor, right?
>
>Allison
>
>
Items Added on 11/14/99:
#40) IBM PS/2 Model 30 - no hard drive or floppy drive
#42) Compaq SLT-286 Laptop Docking Station
#43) Original Radio Shack Color Computer - worked when last used.. Includes
5 1/4" floppy drive and some program carts. Some hand wear on paint below
keyboard.
#44) Frank Hogg Labs - Radio Shack Color Computer Cartridge Port Expander
(prototype?)
#45) IBM PC Junior - unknown condition
#46) IBM PC Junior - unknown condition
#47) Apple Macintosh Model M0001, Serial # F4110WXM0001 - unknown condition;
plastic shell is cracked. Includes keyboard.
#48) Apple Macintosh 512K - Model M0001W512K Serial # F439338M0001W - worked
when last used. Includes keyboard & mouse.
#49) Apple Macintosh external high-density 3 1/2" floppy drive
#50) North Star Horizon S-100 computer. Clean; missing a bit of wood veneer
on left front of cover. Unknown condition - I have never plugged it in.
Will add pictures as time allows.
http://incolor.inetnebr.com/bill_r/computer-sale.htm
-Bill Richman (bill_r(a)inetnebr.com)
http://incolor.inetnebr.com/bill_r - Home of the COSMAC Elf Microcomputer
Simulator, Fun with Molten Metal, Orphaned Robots, and Technological Oddities.
So I've got this PDP-8/e OMNIBUS box, a pile of cards and want to see what's
working. Here's my parts list:
2 x KK8A CPU cards
1 x KK8E board set
1 x MS8-C Hex MOS memory card
2 x KM8 "option 2" cards
2 x DKC8AA "option 1" cards
1 x PDP-8/e OMNIBUS box w/front panel
When I load the KK8E into the box, I can set addresses, examine data in
the MS8, toggle in small programs (NOP, NOP, JMP 0) that appear to work.
One odd thing - when I load an address then deposit data, if I'm reading
this thing correctly, it seems that the data is going one location higher
in memory than I think I'm at. I'm not certain if this is operator error
or something wrong with a card.
When I load a KK8A board into the box instead of the KK8E, it runs blank
memory OK, but when I attempt to set the load address, pressing the key
increments the MA register from what ever it is. I can single step, but
not easily set or inspect memory if I can't reset the address.
Now the questions:
I know you can stick a KK8E in a hex ONMIBUS box (-8/a-620, etc.). What
happens if you try to put hex cards in a quad box? (I have the PSU set off
to the side for clearance, in case anyone is wondering how I did it.) Does
the hex MOS memory _need_ to be in a hex slot to have power/grounds/term
on the fifth slot?
Is the front panel from a PDP-8/e *compatible* with the KK8A? I do not own
a programmer's panel for the DKC8AA, nor do I currently have a hex chassis
where the cards are, limiting my options.
Eventually, I can get a hex box and all these cards together, but for now I'm
trying to work with what I've got.
One last side question: has anyone ever used the parallel port on the DKC8-AA?
Drivers aside, it seems like you could do quite a lot with it. The handbook
suggests that it's possible to use it to run a LA-180, but with the data
inverted and with different IOTs.
Thanks,
-ethan
=====
Infinet has been sold. The domain is going away in February.
Please send all replies to
erd(a)iname.com
__________________________________________________
Do You Yahoo!?
Bid and sell for free at http://auctions.yahoo.com