Hide the keyboard – it's the only way to keep this software running By the time Friday rolls around, The Register understands readers might just want to toss the rest of the working week away without a care for the consequences. That sense of ennui is why we ease you into the last day of the working week with a new installment of On Call, the reader-contributed column that celebrates the …
This is even worse , which I didnt think possible.
I'd have sacked that guy / idiot / gorilla on the spot, not that I've ever been in a position to sack anyone and I dont think the protagonist was either.
Does he run round the rest of the room pushing random buttons for shits and giggles? what a tool . This has really pissed off more than a "on call" should or has before for some reason .
I've seen this countless times. A new technical system is going in place and it is impacting someone's job. You can bet damn well that maintenance worker knew exactly what was going on and got a good laugh out of the new system crashing.
And the "solution" was a piece of plexiglass over the keyboard?? Talk about not solving the problem! The problem is employees blatantly thrashing on company equipment. And it was going unchecked by other employees coming in for the same shift?
That is a huge behavioral and cultural problem. This was in the gas industry (not clear if that means petrol or air gas). Either way, this type of systematic employee misconduct often leads to what is commonly called an "industrial accident".
"I've seen this countless times. A new technical system is going in place and it is impacting someone's job. You can bet damn well that maintenance worker knew exactly what was going on and got a good laugh out of the new system crashing.
And the "solution" was a piece of plexiglass over the keyboard?? Talk about not solving the problem! The problem is employees blatantly thrashing on company equipment. And it was going unchecked by other employees coming in for the same shift?"
Did you read the article? I dont think you did. It never stated that the employees were blatantly thrashing on company equipment. It stated that ONE employee threw his lunchbox on the table, where it hit the keyboard.
No mention that this was impacting someones job. No mentikon that it was a maintenace worker. No mention that the worker knew the effect it would have. Not even "Henry" and his colleague had any idea that simulatenously pressing X number of keys would crash the system.
"Did you read the article? I dont think you did. It never stated that the employees were blatantly thrashing on company equipment. It stated that ONE employee threw his lunchbox on the table, where it hit the keyboard."
It was part of a new piece of expensive control equipment. Generally, random employees don't use the room that is in as a crew room. If he was there, he was supposed to be there. So by definition he knew what it was and had probably had training on its use. Throwing his heavy (metal?) lunch-box on the desk right next to the new expensive equipment should be an obvious no-no even to the most uneducated gorilla. And in that time period, it was commonly a disciplinary offence to even drink a mug of tea next to the computer and/or keyboard, never mind eat your lunch over it, or worse drop your lunch box on it.
Not least of which, it happened on multiple days. The system crashed each time he threw is lunch box on the table. Even he ought to have correlated the effect with the cause after a few days.
"It was part of a new piece of expensive control equipment. Generally, random employees don't use the room that is in as a crew room. If he was there, he was supposed to be there. So by definition he knew what it was and had probably had training on its use. Throwing his heavy (metal?) lunch-box on the desk right next to the new expensive equipment should be an obvious no-no even to the most uneducated gorilla. And in that time period, it was commonly a disciplinary offence to even drink a mug of tea next to the computer and/or keyboard, never mind eat your lunch over it, or worse drop your lunch box on it.
Not least of which, it happened on multiple days. The system crashed each time he threw is lunch box on the table. Even he ought to have correlated the effect with the cause after a few days."
Again you are adding suppostion.
Its a new system, who said anyone had been trained in its use? Heck, Ive worked in places were "training" is a deliverable, but never is.
Heavy and metal. Its weight and composition are not mentioned, and are irrelevant. A tupperware box with sandwiches in can press multiple keys.
Ive been in the game for years but never been in a company that made it a disciplinary to have a drink or food at desk, including the Forces where back in the day Junior ranks were barely trusted with the things, often being cautioned to hell and back wrt the cost of it, and how they couldnt be trusted with one (which made me laugh, as many soldiers were entrusted with equipment worth far more than the paltry £1200 386sx from the DGITS catalogue.. try £5m worth of CET!).
Uneducated gorilla... hmm.. how many blue collar workers would you use that expression to their face... I'll hazard a guess that will be 'none' then.
Even he ought to have correlated the effect with the cause after a few days.
Are you kidding? I had a user who would report, every single day, that going to a certain website caused the computer audio to stop working, necessitating a system reboot. This user dutifully reported the issue to their supervisor and manager, day after day, for a full 2 months and change, before I finally chimed in and asked the manager why they didn't just tell the user to stop going to said website, which none of the other users ever go to.
I'm from the UK. I've worked in oil and gas in Scotland and Europe. We called it "oil and gas" when referring to the industry. If we were getting technical we might talk about "condensate" when referring to the mix of stuff that comes up the pipes depending on the type of operation. I've never heard anyone refer to anything as "air gas".
"And the "solution" was a piece of plexiglass over the keyboard?? "
It seems odd that a critical piece of gear is left somewhere that a "worker" might plop down their lunch box or get close enough to touch. It's like the oil pipelines that can be accessed from the internet. Why? Yes, it would be more expensive to do it differently, but when millions of dollars/pounds/euros are hanging in the balance every minute of every day, a bit of expense to protect that is worth it.
Risk management is a huge PIA to executives that demand their bonuses, but only for those that are nearsighted. It's not that hard to plot the costs to minimize a risk verses the likelihood it might happen vs how much it would cost if it did. It's the same as when I figured out how much home owner's insurance to carry. I could buy enough for 100% replacement should anything happen, but that's not cheap. I am zero percent covered in the case of a forest fire burning down my house. For it to become an issue would first mean growing a load of trees nearby and I don't see that happening without much more climate change in a wetter direction. Flooding isn't an issue, etc. Some things I've needed to guess at some numbers for, but the base tier covers everything I need it to cover.
"Does he run round the rest of the room pushing random buttons for shits and giggles? what a tool . This has really pissed off more than a "on call" should or has before for some reason ."
Same response as to Marty McFly. Re-read the arrticle. The guy wasnt running around pressing random buttons. He threw his lunch box on the table. Guess what, its not uncommon for people who work in non-IT functions to do that sort of thing.
Thank god you are not in a postion to sack anybody - you'd be pretty lonely having sacked everyone for something trivial that pissed you off.
He through his lunchbox on the desk and hit the keyboard, it's not like the table just got bumped. For it to happen multiple days in a row the guy must have done it multiple times, hence just throwing things around and hitting random buttons.
Taking things to the max and seeing harm in innocent encounters.
Also did you dictate that comment?
"For it to happen multiple days in a row the guy must have done it multiple times, hence just throwing things around and hitting random buttons."
The question would be if it was the same cause each time. Other days it could have been somebody at the start of shift that thought to see "what happens if I push this button". After that it's, "what if I type in something naughty".
A former colleague of mine tested my monkey-proof (I hoped) user-I/O I had designed for an image processing tool (way back in the late 80s, early 90s) by leaning with both his underarms on the keyboard for a few seconds, resulting in an interesting mix of weird characters. He then pressed enter and got two error messages:
"Input answer too long, remainder clipped"
and
"Error in integer input format"
and a new prompt to enter the right answer. I was quite chuffed. I had actually written my own interrupt handler for just such a case. I do not doubt there more inventive monkeys could throw a spanner (or wrench) in the works, but at least it survived this pretty extreme test.
If you're trying to develop an interface that can survive anything, your error messages are concerning me.
"Input answer too long, remainder clipped": This one concerns me anyway. If my answer is too long, truncating it to size and using that doesn't sound like the right approach under any circumstances. If those limits are firm, reject it and tell me acceptable sizes. If I could do something to extend the length of acceptable input, keep my input and give me the option. Otherwise, you're virtually guaranteed to have the wrong thing when truncated; if I intended the long value, you have something wrong, and if I intended a short value and somehow put on extra data, you have something wrong and probably much larger than what I intended. Either way, that could cause problems.
"Error in integer input format": This one isn't as big a problem. However, the message could be better. If you want nontechnical users to understand it, you are going to need more words, and that applies to a lesser extent even for the technical user. I assume this means "input must be but is not an integer", but that's not exactly what you said.
When rewriting a very buggy bit of real time code produced by a co-worker I discovered he had a habit of sprinkling the error message "hideous error" into his code. It transpired that he used it exclusively when encountering an error situation he didn't know how to handle. Previously he been berated for not testing for error conditions.
There was - and probably still is - a last-resort unhandled exception trap on the AS/400 which resulted in the error message "Here be dragons. Call (developer's name)" - not cleaned up when it all rolled to production. Had it demonstrated to me by a colleague who once worked alongside said developer at Big Blue.
> Control access for systems of any significance should be completely isolated from access by non-specialist workers
Good point in general, but in this case the keyboard was clearly expected to be required (hence the shield instead if, say, locking it in a cupboard) and it was inside the existing control room, full of tasty knobs and buttons, so one would presume that everyone on the shift was already relevantly qualified and specialised personnel.
Although perhaps, for the sake of the new system, still a bit too much in the hefty gas rigger mindset and not willing to give up dropping me sarnie box on the table like I done for the last five years before this interloper arrived. A bit more "sensitivity towards the fragile new equipment" training was also in order.
Depends on the computer it's attached to. Plugging a keyboard into a live running system may or may not end well. It was quite probably a PC of some sort and probably ok to plug in, but there were still oddball PC "compatibles" around with different, unique or propriety connectors and, if late in the 80's, might have been a PS/2, notorious for not recognising a keyboard plugged in after boot time and even blowing the keyboard fuse on the motherboard.
Not always a good idea. I was dressed in smart suit with tie done up waiting for members of the press to arrive for live demos of a new range of computers (rebadged Sun-2s) and new software when, being bored, looked at the keyboard cable and thought "is that an RJ45 plug?". Unplugged it to get a better look and the computer halts. Frantic rebooting happened with about a minute to spare before the actual arrival of the fourth estate. My excuse was that I'd been so busy typing at our development machines that I had never had any idle time actually to look at the keyboard nor to learn that typing "C" would continue from halted state....
I was told this...
They wanted to physically move some mainframe disks to make some space for new kit - but without shutting it down. It needed to be moved just a couple of inches.
Two of them put their backs to it and gently pushed. It moved - success.
What they had not realised was someone's belt was caught under the Emergency Power Off button. So when they stood up, it pulled the EPO and shut down the disks.
It took two hours to recover!
This was the same company who connected two main frames together. The cable was only 4 meters long. Instead of routing it down to the floor, under the floor, and up, they had to connect it at neck height with a couple of stands to support it. This worked, until someone walked into it, and pulled it out of the machines.
Colin
Working in a hot, humid climate and sporting minimum attire, an older colleague was lifting and moving a large, very heavy, metal-clad instrument. He eased it down on a metal bench but unfortunately trapped his clothing and a rather delicate piece of skin. An emergency hospital visit, a swift cut and soft bandages..... And antibiotics...... no alcohol.....
At the time he did shout out to <deity>. I don't know if he changed religion but he now had the opportunity.
Something similar...
"The line should be terminated within 2m of the router" (2m=1 Osman for the metric martyers)
The guy terminated the line on the wall opposite the rack, so you could stretch out your arms and reach both with finger tips
(obviously too difficult to lift the floor tiles)
Forty years ago or more my father would sometimes bring home prototype printers that his company was developing, to see if me and my brother could crash them just through the buttons on the front panel. We sometimes could. Many years later I used my own son the same way while building an electric organ. Give a small boy access to a device with over 200 organ keys, buttons and LEDs which makes lots of noise, and the hard part is keeping track of what he is doing. The even harder part is prying him loose again.
Absolutely anonymous, but back in the day, I was tasked (by the financial institution) with trying to crack their financial system, to syphon money off into a particular account of theirs.
I had one video camera pointing at the screen and one at the keyboard through each test session. An independent person had to sit with me during each session monitoring the cameras.
Both video tapes were couriered to the financial institution after each test session, so that they could see exactly what I was doing.
I remember an old Sun bug report for Solaris where some stress testing caused a crash in CDE. It helpfully listed a workaround: "don't pound on the mouse like a wild monkey"
This was when Sunsolve listed a lot of useful information about bug reports and before Oracle hid it all away...
As a first timer in a VLSI lab I got to try out some Sun SPARCstations, of which there were 10 in a row and all networked. The lab tech was very proud of his domain and showed off their ability to act as terminals to one that was powerful enough to run CAD for all of them. That just means they were each 10 times too powerful but I digress.
The mouse on mine could move but nothing could click. The tech guy leaped into helpful mode and pointed out that the buttons don't work when the keyboard's numlock is on. "But that's crap!" I said without thinking. Something that I regret because he was almost brought to tears. I had insulted his babies for having a pointless and crap design and who wouldn't be hurt by that? Of course I still think I'm right. It's a ridiculous oversight.
It sounds like the mouse buttons are somehow mapped into the keyboard. Possibly the mouse movement also is but it somehow isn't interfered with.
But disabling mouse clicks while someone is moving the mouse with num lock turned on seems very unhelpful. If they are moving the mouse, then they want to use the mouse.
"It helpfully listed a workaround: "don't pound on the mouse like a wild monkey""
I think it was Oberheim that had a warning on one of their PCB's counseling against dropping a penguin from an airplane onto the keyboard (piano). If you wind up with some space on a PCB........
Given Turbopascal was mentioned I am wondering whether CP/M (80, 86) was involved. The 1980s also covers MSDOS 1.1 - 4.0 but I would have thought MSDOS' keyboard interrupt handling wasn't that fragile.
I suppose Turbopascal could have been used for embedded development which might make sense if you were dealing with a lot of sensors that used interrupts to get the processor's attention rather than polling.
I could imagine if the system had a fairly large interrupt load that a race condition in the keyboard interrupt handler might be exposed by mashing the keyboard eg if the ISR didn't immediately mask further interrupts before processing.
I vaguely recall MSDOS device drivers had interrupt and strategy parts but were basically a charade as the two parts weren't asynchronous.
Back then I thought minicomputer hardware like DEC's PDP8 and PDP11 rule that space (industrial control and monitoring.)
Going back to the late 1980's I produced lap timing systems for the F1 teams (later sold to other motorsports). I repurposed the barcode reader input on an Epson PX4 to read from timing beams. This was all in Z80 assembler including the fixed point maths library to do all the calculations. The special keyboard would also time key presses to 1/100th second accuracy for manual timing. I did the first F1 in-car telemetry also, although I used an early Epson laptop to display at the receiver end.
Epson EHT-10's (the first(?) touch screen handheld) were used to allocate baggage in the hold of Concord.
More Epson PX4's were used for the Gallop Pop chart data gathering, for EPOS at Tie Rack, and for order-entry at Pharmacies, with an Intel 486 interfacing with 50 ordering lines at a time and a recalcitrant mainframe (often buffering the orders when the mainframe went offline).
Millennials are surprised what can be achieved with relatively simple technology, when they need multi-MB programs to print "Hello world!"
"Millennials are surprised what can be achieved with relatively simple technology, when they need multi-MB programs to print "Hello world!""
Just the other day I was installing a driver for Windows and it crossed my mind that the size of the download was bigger than an entire Win98 base install :-)
> I would have thought MSDOS' keyboard interrupt handling wasn't that fragile.
I know the story is true because I seen it, only in an office with a budget binder. On IBM 5150 PCs there was a small CPU in the keyboard interface, to buffer keystrokes. BIOS serviced. If you let it fill up, it would throw an error, the PC lock-up. This misfeature faded in late XT or early AT machines.
Ah, found my 2016 explanation:
"Buffer Overflow" used to mean something different.
This was the late 1980s. Our low-funded department was using hand-me-down IBM PCs. THE "PC", 5150.
I get a call "the PC crashed and it is beeping!"
It isn't beeping. It does say "Buffer Overflow". What buffer? Try Crtl-Alt-Del... nothing. Big red switch. Re-starts fine, does what a PC is supposed to do. Glitch? Gamma rays? I ask them to call if it happens again.
Couple days later, same again.
This went on for a week. One day I came over to get my paycheck, and it did it while I was standing there. Beep-beep-beep-beep.... "Buffer Overflow".
I look at the binder with 10 pounds of fan-fold financial printouts sitting on the keyboard. I tell the user to keep stuff OFF! the keyboard.
FWIW, IIRC: IBM had a lovely auto-repeat type-ahead keyboard, but the 5150 only had like 16 characters of key-code buffer. Once that overflowed, even Ctrl-Alt-Del would not get through. It would keep beeping, but the user had noticed that taking the binder off the keyboard (before I got there, and not telling me) silenced the beeps.
Presumably it wasn't continually buffering new things, or there would be odd keystrokes showing up on the terminal. In that case, why didn't they do something along the lines of waiting until no keys were pressed (they already knew the buffer was overflowing in order to beep), then clearing the buffer and starting again? It would make sense if they hadn't bothered with a buffer, but to have one and have no ability to clear it seems like a weird oversight.
> why didn't they do something along the lines of waiting until no keys were pressed (they already knew the buffer was overflowing in order to beep),
See https://www.minuszerodegrees.net/bios/bios.htm
The BIOS (self-test, boot, floppy, console, TTY and more) fit in 8Kbytes. (Not 8Meg!) While clever minds can do a lot in 8K, the PC project was a rush-job and you are not supposed to leave lunch or budget on the keyboard. (I assume cats were banned in Boca Raton lab.)
Way back when Cray computers were the ultimate in super computing processing, the company I worked for had one that was doing oil seismic processing. The CRAY-1 was a beautifil machine. Shaped like a torus, it stood aprox 2m tall, with a circular bench seat around the base which held all the power and cooling components. And it is extremely tactile. People would walk past and just run their hands over the cabinet.
But we kept getting crashes. When this happens 20 hours into a 23 hour job, it gets a toiuch annoying. The onsite Cray engineer had no clue. It happened at different times of day, different days of the week. No pattern at all. So he did the only thing possible and watch the computer like a hawk. All was fine until one female operator from the tape handling room walked past, touched the CRAY and crash. It only happened to her. Turns out that her nylon work coat (think lab coats, but cheaper), rubbing against her nylon tights was causing a static buildup that she discharged through the sensitive electronics.
The solution was to erect a small fence around the CRAY beyond which only male operators could venture. The unions went mad. Discrimination they yelled. Right up until the the situation was explained the the shop steward and he was told that women could of course tend the Cray, but only after the shift leader had checked they were wearing silk underware.
Yes the 70s had some, interesting, clothing choices. Here is a glorious example of the man himself.
https://www.computerhistory.org/revolution/supercomputers/10/7/3
And here's another favourite photo. It's the Enterprise in a time travelling mixup and Dr McCoy is a total pimp.
https://en.wikipedia.org/wiki/File:The_Shuttle_Enterprise_-_GPN-2000-001363.jpg
> the man himself.
But you have to admit, Cray's outfit does match the computer... which is rather dubiously colored, but the peripherals for our university IBM 4381 had really strange primary-colors claddings. Printers and tape drives in bright red and blue was weird looking.
> Dr McCoy is a total pimp.
Roddenberry is wearing an strange dark brown outfit himself, in the middle, and what is up with Nimoy and the red/white stripes above the pockets? And I feel deprived of not fully seeing whatever Doohan is wearing.
It's interesting the gay man (Takei) is the one wearing the most conservative outfit, other than the NASA folks required to be in grey suits.
And of course Shatner is not there at all, which is probably why they're all smiling and happy looking.
And all of the male Enterprise crew members are wearing some pretty pimptastic shoes, to be honest…
The other strange things about that photo are that James Doohan rather looks like he could be auditioning for a role as another Scot, namely Billy Connolly, and Gene Roddenberry likewise as Terry Wogan!
> rubbing against her nylon tights was causing a static buildup that she discharged
This story (probably true) runs back before transistor computers. To knock you out before an operation they use anesthetics, and for the longest time it was gasses related/similar to ether. Ether is also known as starter fluid because it is so VERY flammable it will start a cold engine full of bad fuel. Of course there was a mystery explosion or two blamed on Nylon underthings. (Before 1940, silk.) A memo supposedly went out to surgeons to "keep a close eye on their assistants' garments". (Cotton should be far better for static than the suggested silk, but I wasn't there and don't date surgical staff.)
> Dr McCoy is a total pimp.
You should see his powder blue 1968 Thunderbird. OK, even my grandfather had a T-bird, but DeForest Kelley got one of the very first Ford 428 engines, improved heads on the venerable truck/Tbird boatanchor. It is said that he loved that car.
But I was in highschool when that photo was made and I do not think DeForest's get-up is extreme. Not my style but common for dress-up, dances or Shuttle launch.
> The perspex sheet was the best solution after all.
I can't have cats so I would never know: there is a whole cat-egory of keyboard protectors:
https://www.amazon.com/Anti-Cat-keyboard-protector-Keyboard-Storage/dp/B0B618LNL6
Well, a smack on the pain-interrupted employee could've fixed that, but an USB-polled keyboard would have worked too.
However, old kit may not have USB, and human employees tend to have Geneva Conventions and Human Rights protecting them or something.
The perspex sheet was the best solution after all.
At first I thought someone was unplugging or turning off some piece of gear that caused the system to bork itself. The famous vacuum cleaner or kettle-in-the-UPS conundrum comes to mind.
PS
Can we get a BOFH icon?
If this is the '80s, it's LONG before anything like USB was even a twinkle.
Do you remember a lot of motherboards with the old large AT DIN keyboard connector, where if you disconnected the keyboard, it required a reboot to see it again?
Well, it might not have been "a lot" but it was enough to really piss me off and remember it 35 years later.
"If this is the '80s, it's LONG before anything like USB was even a twinkle."
FWIW, it was a twinkle at that stage. Ataris SIO interface for daisy chaining multiple tape/disk drives, printers etc was around and the designer of the SIO interface went on to be one of the devs for USB :-)
. . . is what in the trade is known as a "molly-guard1," I believe.
EtymologyFrom Molly (female given name) + guard.
Originally a Plexiglas cover improvised for the Big Red Switch on an IBM 4341 mainframe after a programmer's toddler daughter (named Molly) tripped it twice in one day. Later generalised to covers over stop/reset switches on disk drives and networking equipment.
_______________
Both my parents spent time working at a large (originally government-owned) manufacturing site. Loads of people had nicknames. Some had real names known only to the payroll department.
One middle-management chap was known as "The Sherriff" because he regularly announced "I'm just shooting off to...". One chap was known as "Black Pudding" because he had once warmed up his lunch in the urn of hot water intended for brewing tea. The origins of "Spongecake" were anything but politically correct. My mum, it turned out, was known as "The Duchess of <building name>".
I was given my nickname by my primary school teacher, Mr. Isbester, when I was 11 years old. I was the only member of my class that knew about Pi, and could recite it to ten decimal places. He asked who had told me, and when I explained that my father worked at University College, London, he dubbed me "Professor Purvis", a nickname that I have carried through school, university, and most of my working life.
the problem of operators with extra fingers pressing things they should not.
The solution was simple and is done during their first day.
"This button stops the machinery, this button starts the machinery, if the other buttons are pressed, your finger goes whee whee whee all the way home" while showing them my cigar cutter....
Human rights violation? since when have operators been classed as human?
I'm sure I've done this one before but...
Working on controllers for electric fork-lift trucks, we had a controller mounted high on the back of a vehicle so that it was easy to get at. It never had a cover on either so that the EPROM could be swapped out to update the software.
Worked like a charm until one afternoon when the controller started to reset now and then when the vehicle was moving towards the outside of the building. Many an hour was spent reviewing the code but no faults could be found. I then noticed a shaft of sunlight that moved up the back of the truck as it moved towards the widows - with the controller resetting when the sunlight hit the EPROM.
Whilst they can be a pain to get off at times, those light-proof stickers that are supposed to be put over the UV erase window can be useful - the EPROMs weren't getting erased, but there was enough charge getting moved about to cause the occasional read error...
No one:
1) Testing took place within a test cell.
2) It was enclosed by a barrier*.
3) The only person allowed in the cell whilst the vehicle was operating was the driver.
4) All testing took place at low speed.
5) The hardware automatically put the controller into a safe state if the micro failed.
Up until that point, everyone believed the stickers were there to prevent long term erasure - no one was aware that a burst of weak UV could lead to corrupted reads.
An easy to remove cover was put in place after this incident, followed shortly after by a move to the use of FLASH.
* I had this put in place when I saw how things were done at the time I joined the company, as safety was not great.
Decades ago, a customer with a PDP 11 had erratic system crashes. No remote debugging success, change of tape drive by field service after a supposed relationship to the backup yielded no resolution. With the customer becoming annoyed, we dispatched an engineer to the site. A day of connecting flights and the next day he arrived. We provided a three ring binder with documentation, "how you boot the system", "Making a daily backup, "Making a weekly backup" . . .Customer was resting the binder cover on the number pad of the system console. Multiple keys supported the cover without being depressed. A single key or two triggered a crash. The customer would then move the binder and read the system startup page.
Backup tapes on a DAT (remember those?) were getting corrupted so the unit was sent to Sony to fix it. No problem found. They were still getting corrupted so the unit, cable and controller card went to Sony. They still couldn't find out what was wrong.
They asked me to have a look at it and I spotted the problem right away. They had laid the cable across the back of a 21" CRT monitor. Cable moved, problem solved.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
