test-drb

test-drb@ccmp.vtda.org

101090 discussions

Even more PDP-8/A weirdness (was: Re: PDP-8 diagnostics SR settings?)

by charlesmorris800＠centurytel.net

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

10 years, 7 months

Control Data 160

by bpettitx＠comcast.net

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

10 years, 7 months

M8192 KDJ11-A ZKDJB2 XXDP Test Failure

by jnc＠mercury.lcs.mit.edu

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

10 years, 7 months

21MX proms (per request

by gerardcjat＠free.fr

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

10 years, 7 months

Control Data 160

by jnc＠mercury.lcs.mit.edu

> From: Mark Linimon > excellent post. Ditto. Thanks for sharing those memories, and history, with us, Mr. Pettit! Noel

10 years, 7 months

Even more PDP-8/A weirdness (was: Re: PDP-8 diagnostics SR settings?)

by charlesmorris800＠centurytel.net

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

10 years, 7 months

punchcard svg file available

by gerardcjat＠free.fr

@ 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

10 years, 7 months

Control Data 160

by bpettitx＠comcast.net

"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

10 years, 7 months

Tandy CoCo Joystick Adapter

by iridius＠yahoo.com

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

10 years, 7 months

C-64 / Epyx FastLoad bug(s)? Workaround?

by drlegendre＠gmail.com

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?

10 years, 7 months

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

test-drb