On 12/9/2010 2:46 PM, Richard wrote: I was considering it, but it's about 950 pages which makes it a rather daunting task. Is there any OCR software that can deal with this sort of thing? This is potentially made more complicated by the fact that there are horizontal lines across most of the pages, which in many cases intersect with the text (which also isn't the clearest text I've ever seen). But I haven't done anything with OCR software in over a decade, so maybe the technology is up to the challenge? Josh

Even with adobe acrobat pro X? It made things incredible here with my docs and the clearscan option...

On 12/9/2010 9:12 PM, Eric Smith wrote: That's dedication :). Yeah, that's pretty much what I expected. I guess even if the OCR software was robust enough to deal with the lines in the images, the occasional bits of noise in the resulting text would be very annoying to track down and correct. I'd love to do something like that with these Tek sources, and then tie it in with the emulator I've been toying with, but I just don't think I have the time. It'd be really nice to have the emulator's debugger be able to match up the current instruction with line(s) from the source files, etc... Josh

At 11:02 AM 12/10/2010, Richard wrote: What do you estimate that would cost? - John

Richard wrote: Same problem as OCR. You'd spend more time cleaning up the results than it would take to type it in yourself. Eric

On 12/11/2010 05:43 PM, Richard wrote: And how are you going to tell whether there are errors, without spending a bunch of time proofreading it?

Richard wrote: I can get on average significantly less than one character in error per page, *including* the line number, address, object code, source statement, and comments. I'd be willing to wager that using "unskilled" labor (people not familiar with the assembly language in question) will not be able to do it with fewer than five errors per page no matter how much you offer, since they won't even be able to tell what constitutes an error when the source material is a poor-quality reproduction from microfilm or a bad photocopy. Sometimes it is difficult even with a good copy! I never claimed otherwise. It is *more* drudgery to correct someone else's errors doing this than to type it myself. Speaking from experience, dealing with data entered *and* proofread by supposedly skilled data entry operators. I would be absolutely delighted if someone could prove me wrong. Eric

Richard wrote: You're completely missing my point. But by all means, feel free to offer the work units on Amazon's Mechanical Turk service, and find out at what price I'm willing to do it. Eric

Well, I am awesome (start blowing the horns!) at doing this sort of thing (but, no, I am not volunteering). Kicking around the backwaters of the Internet is a circa 1950 document called (I think) "Cross Index of Electronic Tube Types". It is a raw text file, about 120 pages of very tight text, so really about 200 pages of normal spaced text. Tube types, descriptions, stock numbers, equivalents, all sorts of esoteric knowledge. Fair Radio sells reprints of it. Anyway, about 20 years ago I scanned the third generation photocopy of the document, OCRed it (on a 486), then proofread it in my spare time. Some comments: 1) It went faster than I thought it would. The first pages were slow, but later pages went fast. I noticed that I started to recognize common OCR errors, and had a heightened sense finding them. This became very handy when I started sections where all the data was very similar, like all the 2J** magnetron tubes. Towards the end I was doing a page in less than two minutes. If you do a sample using a "human-OCR" service, you may not see this effect, as the few samples submitted might not get the guys and girls "in tune". Once "in tune", I am sure the service will start to fly, and be done much quicker than expected. 2) Being a tube geek anyway, many of the OCR errors, or even errors in the source data, stuck out like a sore thumb. These were easy to correct (and in some cases, correct me). Knowing what you are looking at is a huge help. Think of it like how your 8th grade math teachers taught you about story type problems - if the answer you get looks wrong, it probably is. As it turns out, the final OCR'd data is remarkable error free - except for original source errors. 3) It was extremely easy to break into chunks. Some days I could do a bunch, others, none. Putting it aside for even a week did not get me "out of tune". 4) It was not as much of a drag as I thought it would be. Every so often I would discover some interesting tidbit in the listing, and have to research it more. I bet if I was doing the same thing with a source listing, perhaps with juicy comments from the programmers, I would probably get distracted just as much, and thus learn a bunch of things that I probably would never learn any other way. Anyway, the point of this is that while the firmware listing in question is quite big, it is certainly very doable. One person could probably do it very on-and-off in a few months, or it could be broken into chunks and done in a fraction of the time by a team of people. It is not an insurmountable obstacle. -- Will

At 02:30 PM 12/12/2010, Richard wrote: You must be new here. :-) - John

In article <4D05B76B.3080100 at brouhaha.com>, Eric Smith <eric at brouhaha.com> writes: If you approach it as "dump a bunch of listings in their face and lock them in a room with noone to talk to", then yeah. (Reminds me of an old Dick Van Dyke episode where he's laid off for the summer and has to write marketing fluff for radio rectifier tubes.) However, if you write an instruction guide and give a brief tutorial on how to do this successfully, then it doesn't take knowledge of assembly language, the 6800 mnemonics, or even Tektronix's crazy mixing of assembly and BASIC. This *isn't* rocket science and it *doesn't* require special knowledge of computers to do properly. It does, however, produce much better results with a little instruction and guidance. -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://legalizeadulthood.wordpress.com/the-direct3d-graphics-pipeline/> Legalize Adulthood! <http://legalizeadulthood.wordpress.com>

Oops, proofreaders, not transcribers. -- Will

I am not (even though I really don't have a dog in this fight). Familiarity with the material does not buy a proofreader all that much. -- Will

William Donzelli wrote: Hmmm... Apparently I misunderstood your post about entering the tube substitution index.

I had a friend transcribe the listing for the Microdata 1600's diagnostic, RD00. He managed to get it transcribed in about 2 weeks of casual work, and had 2 errors in 1k of firmware, or 1024 locations and statements, including typing in not only the source, but the object to go with it. Since it was a diagnostic, and I was writing an emulator I caught them relatively easily. He was not a computer illiterate person, however, but a programmer of many years experience (Thanks, John) Jim

Back in the "good old days", IBM made the "Verifier" punch. It was part of the 029 punch series, but did NOT punch data onto cards. Instead, it compared what was being keyed in to what was on the card currently going through. If it came up with a discrepancy, it punched a notch on the 12-edge. If the whole card matched, then it put a notch in the column 80 END of the card. A deck of cards consistently notched on the end was a reassurance that the original punching and the verification matched, and therefore was probably pretty accurate. Of course, that doubled the price and the amount of work for having a service bureau punch your data. If done right, the punching and verifying would be done by two different keypunch operators, to reduce the possibility of the same mistake repeated being verified, particularly with 0 and O, etc. Eventually, some of the service bureaus realized that instead of punching, and then verifying, that it was a lot less work to verify and then punch! So, they would verify entire boxes of blank cards, and then use those for the raw supplies for punching. Hmmmm. Here's a card where somebody made a mistake, realized it, cancelled that card, and punched it over again. But the bad card has a verify notch! Thirty years ago, an old friend who was a good solid 100WPM typist wanted out of her job at UC. So, I helped her set up "The Microcomputer Service Center" to do contract Apple and TRS80 data input. The name choice was flawed, as people would call thinking that it was a repair business. She made a decent living at it, but when I left City College of San Francisco, she took over teaching the classes that I had had, and made a career of teaching. Don't get me started about how I made the wrong decision about which school district to work at when I went to Peralta! -- Grumpy Ol' Fred cisin at xenosoft.com

On 12 Dec 2010 at 16:04, William Donzelli wrote: Wasn't there also a version of the 029 with the verifier as an option (i.e. a switch on the keyboard panel that said "Verify")? --Chuck

On Sun, 12 Dec 2010, Chuck Guzis wrote: The 129 models 1 and 3 could both punch and verify: http://sturgeon.css.psu.edu/~mloewen/Oldtech/Keypunch/Keyboard-L.jpg The Punch/Verify switch is on the left. I don't know of any 029s with the verify option, only the 059 verifier. Mike Loewen mloewen at cpumagic.scol.pa.us Old Technology http://sturgeon.css.psu.edu/~mloewen/Oldtech/

On 12/12/2010 6:02 PM, Chuck Guzis wrote: Legend has it that someone once got fired from IBM for turning in a suggestion form recommending that the CardAType plant be bombed with 557's. ;-) I'd imagine it is just a legend, but I think they were both pretty much beasts to maintain. Later, Charlie C.

On 12 Dec 2010 at 12:54, Fred Cisin wrote: It happened a long time ago, but it taught me that there's a very large human element to computers. I submitted a pile of coding sheets to keypunch and got the deck back with the note: "I didn't know if you meant zero or "oh" when you write (O with a stroke through it), so I punched some cards both ways." One worthless box (2000) of cards. After that, I learned to drop by keypunch to occasionally chat with the ladies (it was comprised entirely of women), and occasionally drop off some munchies and other things. They knew me and I knew them. And I never had an issue with keypunch after that. --Chuck

Are your (presumably plain text) versions of these listings avaialble anywhere? -tony