12 Jul
2012
12 Jul
'12
3:51 a.m.
On 2012-07-12 12:11, Rick Murphy <rick at rickmurphy.net> wrote:
At 12:12 PM 7/11/2012, Richard 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.
>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 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
12 Jul
12 Jul
4:53 p.m.
At 06:51 AM 7/12/2012, Johnny Billquist wrote:
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).
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.)
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?
.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.
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.
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.
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...
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
-Rick
5:51 p.m.
Rick Murphy wrote:
At 06:51 AM
7/12/2012, Johnny Billquist wrote:
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. 
14 Jul
14 Jul
3:21 p.m.
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...
--
"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>
6:21 p.m.
At 06:21 PM 7/14/2012, Richard wrote:
In article <4FFEAC19.2080507 at update.uu.se>,
Johnny Billquist <bqt at update.uu.se> writes:
I'm not sure why you don't think it does. The fact is that TECO-8 does
13-bit math.
It's a PDP-8, after all - combining the AC with the link bit gives you
13 bits. TECO-8 retains the full AC and Link for Q-register numeric
values and numeric operations. That's why you can get a return value
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... from ^B that's basically 4096 added to the 12-bit
date word. How are
you going to add 4096 to a 12-bit value and make a difference?
Or, I can quote from the DEC documentation [1]:
H.16 Arithmetic Precision
TECO-8 performs 13-bit arithmetic except that multiplication
and division by
negative numbers gives unpredictable results. All numbers
stored in Q-registers
are 13 bits long. Numbers stored in flags (such as ET, EU,
etc.) are only 12-bits
long. When storing a number into a flag, the high order (sign
bit) is lost. When
using the value of a flag in an arithmetic expression, the
12-bit value is sign
extended first.
[1]
<http://h71000.www7.hp.com/doc/73final/documentation/pdf/teco.pdf>http://h71000.www7.hp.com/doc/73final/documentation/pdf/teco.pdf
(It's good to see credit for the TECO-32 creator in this document.)
-Rick
11:53 p.m.
In article <201207150121.q6F1LRQD031755 at rickmurphy.net>,
Rick Murphy <rick at rickmurphy.net> writes:
It's a PDP-8, after all - combining the AC with
the link bit gives you
13 bits.
Ah, OK. I didn't know this about the PDP-8; all I knew was that it's
word length was 12 bits.
--
"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>
4542
days inactive
4545
days old
5 comments
4 participants
participants (4)
-
bqt＠update.uu.se -
jhfinedp3k＠compsys.to -
legalize＠xmission.com -
rick＠rickmurphy.net