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...
>
>
