At 07:07 PM 23/07/2019 -0700, you wrote:
>Nonetheless, comparing some small amount of lost information
It's not a 'small amount of lost information', because destroying rare technical works in order
to scan them, or afterwards because "now they are scanned there's no need to keep the paper copy"
is a widespread practice. Very many works in original form are being lost because of this.
>to genocide, which is a real thing that has happened and is still happening in the world today,
> and which has affected people on the list and those they are close to, is more than a bit offensive.
Let me tell you about my wife. She's Cambodian, and very barely lived through the Pol Pot genocide
in Cambodia. Many of her family and relatives didn't make it.
The Khmer Rouge were mostly insane, as a result of the secret US bombing campaign, in which they
napalmed every Cambodian country village they could spot. So virtually all country folk in Cambodia
had lost people close to them to poisonous fire from the sky. (Napalm contains phosphorus, can't be
extinguished, and even if you only get a few spots on you and survive the burning, you die slowly
of phosphorus poisoning.) The countryside people were virtually all uneducated and knew nothing of
the outside world, and had no idea why this was happening. In this context the Khmer Rouge arose,
with the central creed being that Cambodia had to be purged, since all 'foreign influences' equated
to the burning from the sky.
By 'purged' they meant _everything_ and _everyone_ with any trace of foreign influence. That included
all the people in the major cities, since they spoke with foreign (French, Chinese) accents among
other things. It also meant all machines and books. Did you know sewing machines are evil? No?
Well they were to the Khmer Rouge, so they destroyed them all.
As a result my future wife (from Phnom Phen) spent several years on sub-starvation diet, only kept alive
in a camp because she could hand-sew uniforms for the Khmer Rouge. As in needle and thread only. I guess
needles and scissors were not considered 'machines'. Ditto rifles. They weren't big on logical consistency.
The camps were intended as temporary people storage, while they sorted out who to kill. Almost everyone,
though there was a lot of mission drift. They didn't have enough bullets, so the daily killings were
done via simpler, zero cost means. A common method was for three people to kill one. Two held the
victim's arms back, pulling them against a tree trunk. The third sawed through the victim's throat with
the edge of a palm frond. This happened very often, daily.
We met and married here in Australia, had a family etc. Wonderful person. But her past haunted her and
she slowly developed PTSD. Is far from who she once was.
This is why I dislike the practice of destroying things (information and still useful tech-tools) for
reasons that seem sensible to some, but are fundamentally superficial consequences of social fads and groupthink.
It's a mindset - destroying old things, and destroying people, go hand in hand. If you can justify one,
the other maybe too.
>Please be more considerate of this and, as was suggested by the person whose correspondence you posted,
>examine your sense of scale.
My sense of scale is OK I think. There was a major global human genetic bottleneck around 12,000 years ago,
probably caused by the metorite impact that left the Hiawatha crater in Greenland. That one nearly wiped us
out. About 30,000 years ago 'something' caused a mega-tsunami that washed right across the north end of the
southern island of New Zealand, creating the 'buried kauri forests' effect. There was a relatively high-tech
civilization in the Mediteranean area sometime around 300BC, that made the Antikythera Mechanism - that one
required mathematics, accurate astronomy, metalurgy and precision machine tools, plus all the necessary cultural
support. Completely lost. The Umm al Binni lake (in Al Amarah marshes of southern Iraq, approximately 45 km
northwest of the Tigris-Euphrates confluence) is believed to be a Holocene (8,000 BC to present) impact crater.
There are traces in ancient texts of a prior civilization in that area that was apparently completely wiped out.
Just a few of a long list of dramatic natural events in quite recent times, very little known by the public.
Currently humans have achieved a pretty nice level of technological capability. But few understand how fragile
that is, and what kinds of events could crash it back to primitive levels. Very very few are aware of factors
like tech being not easily restartable, since we've used up all the easily mined resources, now running on ores
and energy sources that require existing high tech.
Almost no one is aware of the long-life isotope stocks issue, that could make a technological collapse permanent
for many millions of years, by raising background environmental radiation worldwide to levels untenable for
higher life forms, if our radioactives containment facilities were degraded during even a hundred years of no-tech.
And ALL our existing digital storage media are very ephemeral.
Factors like these, make detailed, robust and widely distributed _paper_ documentation of technological
artifacts *much* more important than most realise.
They are 'safety margin.' Always maintain a good safety margin, in anything life-critical.
Guy
Hello, Havent posted here for a while. I usually post about pdp11 and vax
stuff.
I am big into sgi equipment, I have many deskside coputers and a full onyx
1000 rack. I have just about every machine in the sgi linup and I need to
clear out most of my big sgi stuff. I was big into the nekochan forums, but
sadly since that shut down, supoprt has been limited, and i want to get
this stuff to someone that can use it.
I have a sgi crimson for sale. Possible intermittent power supply issue.
Problem with the IO3 board prevents it from booting
I have an onyx2 for sale in full working order. Its my main machine, im
migrating work to a Octane2.
I also have a loaded origin / onyx2 loaded with hardware, but i havent been
able to get it to post or get to the serial console. Good machine for parts
or to try and fix.
Many octane 2 machines, a couple are fully loaded with 8gb of memory, dual
processors, pci expansion box, etc.
Enough indys to make a jenga tower.
Indigo with keyboard
indigo 2 with matching keyboard.
Might be persuaded to sell the onyx 1000 rack, im not going to part it out,
and needs a forklift to be moved.
2 Sgi tezro's in working order. I picked them both up a year or two ago, i
used them in a headless serial console fassion, i was not able to get my
monitor to sysc with either of them. They both work aside from Battery/RTC
warnings.
I am open to offers, Im not looking to just give them away. Im hoping to
recoup some of my money to move and pay for college.
Open to answer any questions about them
--Devin D.
Charlie at Qei Inc in MA is an old-time DEC dealer from back in the day.
I asked him if he has any PDP stuff left, and he said yes.
He much prefers emails.
He works from pictures and lists of PN or model numbers.
Send your requests to qeiinc at verizon.net.
Large items will need to be picked up.
Items under 25 pounds that are not too fragile can usually be sent UPS.
Be patient; he has a huge warehouse and finding things can be a challenge.
It may take more than a week to get an answer, but he will look into all
requests.
Cindy Croxton
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
I'm looking for a scan (or hard copy) of the later revision of the Rockwell
R6500 Programmming Manual which includes coverage of the additional R65C02
instructions. I believe this is Rev 2 dated January 1983.
There are several different scans of the original revision that did not
cover the R65C02, so I don't need those.
I'm not sure whether they also issued a new revision of the Hardware
Manual, but if so, I'd like to get a copy of that as well. As with the
Programming Manual, I already have scans of the original revision.
Best regards,
Eric
Guy Dunphy <guykd at optusnet.com.au> wrote:
> Ditto for a service/schematics manual for the Documation
> TM200 punch card reader. No copy can be found.
I don't know about the TM200, but I have the technical manual
for the Documation M-200 card reader. If that will help you,
I would be happy to scan it for you. It is already on my list
of manuals to scan for Bitsavers. This is the August 1974
update containing the recommended spares list for DEC.
Amazingly, I knew exactly which moving box it was in, and it
took less than five minutes to find that box!
Alan "Pack Rat" Frisbie
At 07:16 PM 22/07/2019 +0200, Mattis Lind wrote:
>> BTW. I have three IBM 026 card punch machines as a future restoration project. But can I find
>> a service manual? No. None online, only one for the later 028. And even if there was a PDF
>Have you seen these:
>http://www.bitsavers.org/pdf/ibm/punchedCard/Keypunch/A24-0520-2_24-26_Keyp…
>http://www.bitsavers.org/pdf/ibm/punchedCard/Keypunch/225-6535-5_24-Base_Ma…
>http://ibm-1401.info/IBM-026-Wiring-228005P.html
Last time I looked, in Sept 2018 I had previously found:
http://www.righto.com/2017/12/repairing-1960s-era-ibm-keypunch.htmlhttps://www.flickr.com/photos/pfsullivan_1056/16296856470http://bitsavers.org/pdf/ibm/punchedCard/Keypunch/029/225-3357-3_29_FE_Main…
Bitsavers has a user manual:
http://www.bitsavers.org/pdf/ibm/punchedCard/Keypunch/A24-0520-2_24-26_Keyp…
And a field manual:
http://www.bitsavers.org/pdf/ibm/punchedCard/Keypunch/225-6535-5_24-Base_Ma…
But no schematics still.
Your first URL is 404'd, though I already had that doc. Seems there's been a tree structure re-org.
Now there's these:
http://www.bitsavers.org/pdf/ibm/punchedCard/Keypunch/024-026/
123-7091-3_24_25_Parts_Catalog_Apr1963.pdf
225-6535-5_24-Base_Machines_FEMM_Dec65.pdf
22-8319-0_24_26_Customer_Engineering_Preliminary_Manual_of_Instruction_1950.pdf
229-3125_24-26_Operators_Guide.pdf
A24-0520-3_24_26_Card_Punch_Reference_Manual_Oct1965.pdf
Downloaded.
Looks like a good complete set, for mechanicals. Still no overall schematic. Maybe it didn't exist?
Gosh it's a scary-complicated machine. I'm not looking forward to finding the gotchas, like obscure
parts buried deep in the guts that have perished rubber bits, complex precision surface-hardened things
that are just plain worn out and unobtainium, etc.
>> I expect it would be the usual terrible quality.
Pleasant surprise! The image quality of all those PDFs is pretty good. But all still a mix of 2-tone
and JPG encoding, with all their various artifacts.
Fortunately at high enough res to preserve all information. High enough even to (mostly) preserve
the ink screening dots in images.
I'd still like to find original paper copies, both as a historical set with the machines, and to
scan-encode-wrap 'my way' for better looking digital versions.
>> Ditto for a service/schematics manual for the Documation TM200 punch card reader. No copy can be found.
>Do you expect the TM200 to be substantially different from the M200? My guess is that they are quite similar.
> Gone down the route of reverese engineering the differences?
The TM200 has extra circuitry (more cards, wiring) than the M200, since it also reads optical mark-sense cards.
Which means if ultimately I'm forced to reverse engineer the diferences, it's going to be a lot of work.
There's no rush and plenty of other projects. I'd rather just wait more to see if a correct manual turns up.
Not to mention that I'd like to find that manual in order to scan it.
Guy
At 11:41 PM 19/07/2019 -0600, you wrote:
>OK. I've done the first of the manuals I have. Thanks for all the helpful
>hints.
>
>I took apart the Rainbow User's Manual's metal spiral spine. I scanned it
>with scansnap and ran it through the indexing function. I think I tweaked
>the settings in a reasonable way.
>
>The results look good to my eye, but I'm not 100% sure, so I thought I'd
>post it here for feedback:
>
>https://people.freebsd.org/~imp/EK-P100E-OM-001_Rainbow_100_Owner's_Manual-Nov-1982.pdf
Congratulations, that is nicely done.
I like the way you took the trouble to keep the purple ink on some page's LED diagrams,
and the cover images.
I'm not fond of that two-tone encoding of B&W text, but that is an artifact of PDF.
(Unless you go to ridiculous bits/pixel formats, ie large file sizes.)
Since PDF does not allow inclusion of images encoded as PNG. And PNG does the best
B&W text image compression, in run-length encoded 4 bits/pixel grayscale. Which preserves
character and line edges very nicely, while still achieving better file compression.
I wish I knew why ISO and Adobe never updated PDF to include PNG images. It's one of the
worst failings in PDF. Just that one alone makes PDF unacceptable.
:) Maybe because trying to type the right one (PDF vs PNG) is really error prone?
When you scanned the pages, what was the raw save format? (If any.)
If it was any format like RGB/24, or indexed 256 color, did you keep the raw files?
>Second, how do I submit this to bitkeepers? I've looked around and don't
>see how. maybe I'm just being blind...
http://www.bitsavers.org/ bitkeepers is something else.
The site's contact email is right down the bottom of the front page. Visual, to stop spambots.
Also Al posts here in cctalk.
Guy
At 10:41 AM 21/07/2019 -0600, you wrote:
On Sun, Jul 21, 2019, 4:16 AM Joseph S. Barrera III via cctalk <cctalk at classiccmp.org> wrote:
>I'd suggest that in 2019 when bits are cheap and high-quality scanners
>nearly as cheap, "crappy quality digital image" is a bit of a straw man.
>Yes, I've seen plenty of barely-readable or practically unreadable scans,
>but they were made years or decades ago.
There are still plenty of bad scans being done today, for various reasons.
The technology of producing a final digital copy continues to improve and has a way to go yet.
*This* is why I strongly oppose destroying rare docs to scan them, now. Better to wait
till non-destructive scanning methods become available.
>What dpi qualifies as not "crappy"? 300dpi? 400? 600?
Points:
1. Both the DPI and bits/pixel affect the visual result. Having shaded pixels on curved edges
makes the eye see a smooth curve, where the same resolution in two-tone (B&W) would look jagged.
Achieving an optimal balance of resolution and shading levels for various types of content and
fineness of detail, vs file size, is a bit of an art.
But ultimately it's a simple test: look at the paper original, and your final result on screen
(at 1:1 final scale.) Does the quality look the same?
Is your copy how the original publisher would have wanted the doc to appear?
People only auto-producing PDFs rarely catch on to this, because PDF ONLY encodes as one of:
two-tone B&W (fax mode), or JPG (or JPEG2000 rarely) or the excreable JBIG2 (Never use this!)
Experiment with PNG encoding, via a tool like Irfanview, which allows flexibly setting PNG
bits/pixel, raw, indexed color or gray scale. PNG is a lossless encoding, and so the only
resolution loss is by your choice while rescaling in post-processing.
2. The resolution you scan at, and the final presentation resolution, won't be the same.
Especially when the pages include elements like screened color or B&W images. To deal with
these properly you MUST scan at a resolution several times higher than the screen dot pitch.
Otherwise there will be moire patterns (beats) between the scan sampling and the screening dots.
Then you post-process to eliminate the screening, and end up with a truly tonal image at the
resolution the eye would perceive when viewing the original screened image.
This avoids any moire patterning, realizes the original publisher's visual intent, and enables
minimizing the final file data size.
B&W text should be encoded with at least 16 gray levels available to edge shading. ie 4 bits/pixel.
B&W tonal images need at least 256 level gray scale, or the eye sees quantization of shades (aka
posterization.)
Colour images need either 24 bit/px, ie 8 bits each for RGB, or if there are a limited number
of flat colours an indexed color scheme may work. 256 colors or less, ie an 8 bit index per pixel.
Typical utilities will generate the color table automatically (which can sometimes ba a pain.)
PDF does not allow any of these kind of user choices.
3. The final page images, don't have a 'dots per inch' dimension. They have only total number of
pixels in H & V. When doing final page image down-scaling and choice of encoding, you have to
make an aesthetic decision on final pixel dimensions.
If your original page was A4 (8.5" wide) and you scanned at 600 DPI, that's 5100 pixels wide.
But you'll likely find that the final copy can be scaled to around 1000 to 1200 pixels wide,
with 4 bits/px (if B&W text), for an on-screen page image indistinguishable from the original.
4. All post processing should be done in 24 bit RGB, at the full scan resolution. Keep staged backups.
NEVER use any indexed color scheme when scaling, rotating, etc. The result is unavoidably bad.
The final two steps should be: rescale to desided X-Y pixel size, THEN down-code to final
color system and file encoding. There's a discussion of this in http://everist.org/temp/On_scanning.htm
In general, 'acceptable' resolution VERY MUCH depends on the content.
>I just scanned my Rainbow 100 User's Manual at 300, 600 and 1200dpi using the scansnap default settings. You see a jump between 300 and 600, but little difference going on up to 1200 for this material. I posted the 300dpi results and even they are acceptable. Some of the diagrams look heavier than the 600dpi version and at high zoom you see pixelated letters, where the 600 doesn't. The 1200 is hard to see any big difference and takes 4x as long to scan. I think I'll be scanning the remaining rainbow docs at 600dpi. The file is 22MB vs 12MB, so that's worth it. The 1200dpi version was almost 70MB which is starting to get a bit large for a 60 sheet document. The sweet spot seems to be 600dpu, at least for this material.
Just wondering if you're aware of the freeware util Irfanview? https://www.irfanview.com/
It's very capable for batch processing large sets of images. Rescaling, changing coding, cropping, etc.
Guy
So, I have a bunch of old DEC Rainbow docs that aren't online. I also have
a snapscan scanner that I use for bills and such.
There's four kinds of docs, and I'm looking for advice:
(1) wire-ring bounded. What's the best way to scan these? The easiest is to
just clip the wire binding and drop it in the scanner. But then what?
(2) Folded with staples. These are booklet format, with stables in the
middle. I could easily remove the staple and scan. but how do I replace the
staple?
(3) Gum bound. These books are bound with some kind of gum / goo on the
spine. Some of these are so old I could just remove it and have no real
degradation of the state. Others have spines that are still in good shape.
(4) Three ring binder. This is easy: remove, scan, replace. Right?
Finally, how do I get the resulting scans into bigkeeper? Any fancy options
I should enable to make the pdfs maximally useful?
Warner