Recall that the other day, I was seeing this on running AJRLHA.DG:
STATE NOT 5 AFTER SEEK WITH 0 DIFFERENCE (this error and register dump
prints twice in succession. State 5 = Lock-on, keeping on track).
WD1 0317 (lower head, heads not out, spin-down)
WD2 0204 (write data error, write gate error). This one worries me. WDE is
"write gate on but no transitions on write data line". The drive should
never be trying to write when there is no data being sent, and this
diagnostic program does not do any writes to disk! So a fault, head
retraction and shutdown is the proper response to this fatal error. I'll
have to put a logic analyzer on the appropriate bits and see why it thinks
it's supposed to be writing... or where the command came from.
ERROR FLAG SET
ER 2000 (Operation incomplete within 200 ms). Probably because the drive
shut down when the WDE error occurred.
CB 0003 (Seek)
Today the fault immediately on starting the test is still present (and yes,
Henk, it did occur to me that there might be something wrong with the
diagnostic because all the others work! Has anyone got the source code for
AJRLHA?)
However, there are different initial errors today!
Diagnostic starts
(Fault light comes on immediately):
Prints this block twice:
Error flag set
ER 2002 (Operation incomplete, Drive error)
CB 0103 (12-bit data mode, Seek state). <--- This seems to be OK, 8-bit mode
is required for Maintenance, Get Status or Read Header, but not Seek
command)
then Error flag set
ER 2000, CB 0103; (same as above but no Drive error)
Fault light goes off;
then ER not as expected but error flag not set:
WD1 0235 (Heads out, upper head locked on track)
WD2 0002 (volume check bit)
ER 0003 (Drive error; Drive ready);
WD1 0335 (same except lower head)
WD2 0002 (volume check bit)
ER 0003 (Drive error; Drive ready);
Per the user's manual, the Fault light only comes on with the following
errors:
1 Drive-select error,
2 Seek time-out error,
3 Write current in heads (during sector time) error,
4 Loss of system clock (this condition is not latched and not represented in
status word),
5 Write-protect error,
6 Write data error,
7 Spin error.
I am confident that the reported fault is not 1, 4, 5 or 7. The drive is
being selected properly, works except on initial test, the write protect
switch is not set, and the drive stays spinning with Ready light on when not
being accessed.
However, that still leaves a seek time-out (reported today) or a write error
(seen two days ago) when there shouldn't *be* any writes.
I really want to find out why the drive previously thought it was being told
to write, at the wrong time.
I just had a new idea:
What if a command register is being corrupted between the setting by the
program, and the drive electronics?
Say a Write Data command (CB xxx5) is erroneously received by the drive but
the proper registers for a write have not been set up. That would Fault the
drive and the diagnostic would report an error.
Another example: The diagnostic is issuing the proper Seek command (CB
xxx3), but the drive is actually receiving something else, so the expected
seek would time-out in the diagnostic, and depending on the command the
drive actually is reading, could light the Fault too .
When attempting to run Dumprest for RL during the previous session, I had to
add retries for seeking because the program would halt with a seek error
there too.
So I'm now suspicious of an intermittent or partial short (another whisker?)
between the command registers and the drive. Maybe it's not "hearing" the
controller properly! It's even got the correct expensive DEC cables between
the card and the drives, and a terminator on the farthest drive.
Jon wrote:
>I'm pretty far away from competence on PDP-8s anymore, but the symptoms
>sound like maybe the drive faults on LONG seeks, but as long as the seeks
>are short, it works OK. There might be a one-shot in the controller that
>allows so many ms for a seek to complete, and due to aging capacitors, the
>delay is now too short. But, that's a totally wild guess, there could be
>troubles in the drive seek electronics that only occur on longer seeks.
That's an interesting SWAG, thanks :)
I checked the 22 uf capacitor (and 39K resistor) that provide the timeout
delay. They are OK. If anything the 22 uf is well on the high side, thus
giving a longer delay.
Time to toggle in some more programs I guess.
What really bugs me is that this whole system was completely working for
years... up until it didn't :P
Chuck Guzis <cclist at sydex.com> wrote:
Subject: Re: Control Data 160 Ebay
I believe the eBay lister stated that it was a 160, not the -A. So no
return jump for you...
--Chuck
Which would make it even more scarce. There were only a little over a 100 of the 160 models made. And 40+ of them were rebranded as NCR machines.
There were 495 160-As made officially. (There were also a small number shipped without serial numbers to the good people at Langley.)
I know of at least 5x 160-As still in existence, besides my own. Which should be going to a museum this week if they can sort out shipping glitches. My system includes a 161-A Typewriter in lousy shape and a 167-2 Card Reader in perfect shape. Plus all manuals, software (with listings) and spare parts. Even the paper tape rewinder!
I did not know any 160 machines survived, so who ever bought it has a unique item.
I have looked for 15 years for an 8092 = the first true 8 bit computer. Haven't found even a hint or rumor of one.
I am working with Al Kossow, to see that this material is eventually in his archives.
Billy Pettit
> From: Holm Tiffe
> "Ensure that halt trap option is disabled (jumper W9 installed)."
Well, either that was transcribed incorrectly, or the person who wrote it
confused. On the M8192, per EK-KDJ1A-UG-002, pg. 2-1, W_5_ is the halt trap
option, and W9 is... BEVENT recognition. One removes W9 to enable the LTC
(using the QBUS BEVNT line).
Which kind of explains your results... :-)
Noel
PS: BTW, the M8190 (KDJ11-B) in similar - the onboard ROM diagostics barf if
the LTC isn't on (i.e. the switch on the chassis to enable BEVNT has to be
on).
That triggers again a question I had for a while ...
HOW OFTEN theses old PROM fail ??
Who had been through this problem and does it "really" worth to have some blanks
"just in case" ??
---
L'absence de virus dans ce courrier ?lectronique a ?t? v?rifi?e par le logiciel antivirus Avast.
https://www.avast.com/antivirus
As previously posted, reseating the boot ROMs in their sockets cured the
corrupted boot loader issue. Got lucky there :)
In my system there are two RL02 drives. I will call them "Top" and "Bottom"
here, after their physical locations.
I put the OS/8 pack that had been acting strangely in the bottom drive
(faulting the disk and halting the 8/A when OS/8 was interrupted with
Ctrl-C) in the top drive, and switched unit plugs.
It works perfectly there! Ctrl-C returns to the "." prompt as expected.
The pack I formatted also still reads four 4000+ blocks partitions when
switched to the bottom drive.
As before, the AJRLHA diagnostic (Seek/Fctn) still faults and prints errors,
but only at the start of testing the drive. Thereafter that drive shows no
errors. Then the program will switch to the other drive and the same problem
occurs. Specifically (edited and reformatted for clarity, with results
interpreted from the RL02 user manual):
(Ready light goes out, Fault light on)
STATE NOT 5 AFTER SEEK WITH 0 DIFFERENCE (this error and register dump
prints twice in succession. State 5 = Lock-on, keeping on track).
WD1 0317 (lower head, heads not out, spin-down)
WD2 0204 (write data error, write gate error). This one worries me. WDE is
"write gate on but no transitions on write data line". The drive should
never be trying to write when there is no data being sent, and this
diagnostic program does not do any writes to disk! So a fault, head
retraction and shutdown is the proper response to this fatal error. I'll
have to put a logic analyzer on the appropriate bits and see why it thinks
it's supposed to be writing... or where the command came from.
ERROR FLAG SET
ER 2000 (Operation incomplete within 200 ms). Probably because the drive
shut down when the WDE error occurred.
CB 0003 (Seek)
(Fault light goes out)
ER NOT AS EXPECTED BUT ERROR FLAG NOT SET (prints this block twice)
WD1 0235 (heads out, lock-on, keeping on track)
WD2 0002 (Volume check bit, no errors)
ER 0003 (Drive Error and Drive Ready)
CB 1004 (8-bit mode, Read Header)
BAD STATUS RECEIVED FROM DRIVE (also prints this block twice)
WD1 ACTUAL 0235 (heads out, lock-on, keeping on track)
WD2 ACTUAL 0002 (volume check bit)
WD1 EXPECTED 0234 (heads out, seek - track counting)
WD2 EXPECTED 0000 (no errors)
Some of these errors look like a "cascade"... because the first false-write
error occurred, the others are flagged before the drive can become ready
again.
Then it goes on to run for about 10 mins, flickering the Ready light
constantly so it's very dim, obviously accessing as fast as it can.
No further errors.
Next the program switches to drive 1 and the results are identical, except
the "STATE NOT 5" message has WD1 0217 (upper head, heads not out,
spin-down).
So only the Seek diagnostic is giving errors... the AJRLIA diagnostic
(Read/Write) and 'KA (Performance Exerciser) do not show errors. Writes the
entire pack and reads it with no errors. I suspect it has automatic error
retry but without the source code, that is speculation.
Anyhow it may be time to break out the scope and RL02 service manual and
check some settings and waveforms...
But I still think this is actually a problem with the RL8A controller and
not *both* RL02's, since both drives return the same errors, and never had
problems like this before...
Any help making sense of this mishmash of errors would be greatly
appreciated :)
-Charles
@ simski, who wrote :
>Hi,
> Hmm. russian carsds. sounds interesting. I'm certainly interested in
> their looks. could you post a scan of one of them?
Well, they very much look ( and feel ) like original IBM ones, with :
- Right angles : NO rounded corners
- Characters printed : standard 0 to 9 row numbers with 1 to 80 column numbers over "0" ligne and "9" ligne
- only two cyrilic "labels" (??) printed sideway at the leading and trailing edge of the card.
Color is what ** I ** call light brown, but there is certainly a more accurate word for it, something like "bistre" ??
All the prints are printed quite "light" and I am not sure it will go through scan correctly (!!) .
I will try next week ( scanner un-connected right now ;-) )
If interested ( as collector's item ?? ) , I may send a couple. PM me.
---
L'absence de virus dans ce courrier ?lectronique a ?t? v?rifi?e par le logiciel antivirus Avast.
https://www.avast.com/antivirus
"wmachacek" <wmachacek at q.com>wrote:
Subject: Control Data 160
I have a CDC "160 Computer Programming Manual" that I obtained many years
ago when I was working with CDC equipment. This manual caught my eye and I
squirreled it away since we were using the 160-A computers not the 160s.
This manual has a publication number of 023a and a date of 1960. The
picture shown inside the manual is pretty much like the one described
herein. It shows the dropped side panels. The manual shows the Ferranti
paper tape reader and the BRPE paper tape punch as standard equipment. As
optional equipment it shows Ampex magnetic tape handlers (FR300 or FR400),
an 80 column punched card reader (no maker listed), an 80 column card punch
(no maker listed), a line printer (no maker listed), a Soroban-modified IBM
electric typewriter, and a digital communications line buffer. This manual
has 45 pages and shows a full view of the computer and a close-up of the
front panel. I always kept this as a kind of a CDC oddity as I had heard
that the 160s were a proto type and never actually went into production. At
least that is what I heard back then. I hope this information kind of helps
to better identify these computers. Bill
...............................................
Bill,
I have a copy of that manual here and was just looking at it. I believe I have all of the 160 and 160-A documentation and software. I have been giving it all to Al Kossaw to add to bitsavers. He is overloaded with so much that needs scanning, that it may be a while before getting posted.
The early 160's used IBM punched card equipment. The 088 was the usual card reader of choice. Punching was via an IBM 523 or 521.. Printing was on a 1402 or 407. All these devices used an adaptor called the 1610.
Later, printing shifted to the Analex 1000 lpn drum printer. Horrible machine to work on. A cheaper printer also became available: the 501 drum printer. It was made by Holley Carburator! I think it was their only venture into computerdom. Very unreliable machine, used Teflon hammer assemblies. I never saw a straight line of printing on any of those machines.
Much of my early career at CDC was swapping out the foreign peripherals and replacing them with CDC ones. Including the Ferranti Paper Tape Reader.
I'm a little hurt that the 160 is thought to never have gone into production. I was a customer engineer in the Twin Cities area and worked on lots of them, including some that went to NCR. Even Honeywell used them to test production .transducers. This was the first 12 bit machine, and went into production in 1958. It was extremely reliable. Other than paper tape gear and typewriter repairs, the only failures I can remember are burned out light bulbs and push button switches.
Its main signifigance was the development of processing the peripheral operations so the large mainframes were freed up for the big jobs. That lead to the 6600, 7600 and the Cyber Series of computers. Even today, I/O is staged so the big processors are freed up.
The 160 was a Seymor Cray design. The 160-A was designed by James Pederson in the early 1960's. It was at the request of several customers who needed more peripheral processing power in the fledling space industry. Most of the early 160-A sales were to the aerospace industry. I first worked on them while in the Army. They were used on missile engine test fixtures in Humtsville, Alabama.
Incredibly reliable machines. My personal machine (s/n 190) is still working, complete with all origianl parts. Made in 1963. 52 yers old and still chugging along. Sadly, I had to give it up for health reasons. It's now on its way to a Museum.
Billy Pettit
Greetings cctalk list ..
I'm about to do a one time run of some CoCo 3 Joystick adapter PCB's. Using this simple PCB, along with one IC, 8 resistors, some wire and the two connectors, an adapter can be built to adapt an Atari style 9 pin Joystick to a CoCo 6 pin DIN, allowing one to use a digital joystick with their Tandy Color Computer. More info at ..
http://www.lemon64.com/forum/viewtopic.php?t=57859
Anyone here using (or have used) a C-64 with the venerable Epyx FastLoad
cartridge? I'm running into a VERY annoying bug, and would like to know
what if anything is known about it.
Bug works like this..
Use the FL "$" command to display the disk directory. Immediately after,
try to save a program to disk that has a certain number of chars in the
filename in common with another filename on the disk. For instance [SAVE
"PROGRAM03",8] when a file (or files) named "PROGRAM01", 'PROGRAM02", etc.
already exist.
The bug results in a 74 "drive not ready" error, and the save fails.
Sometimes picking a more unique filename will allow a save. Other times, it
seems no filename will allow a save.
Only way I've found to get around the error is to load a different file..
which is no good, as it will overwrite the one in memory. So far, I've only
noted the bug when working with BASIC files.
What's up with this? Is there a workaround?