Tandon Track 0 adjustment
What's the recommended method for adjusting the track 0 switch and track 0 stop on a Tandon TM100-2, if you don't have an alignment disk? I do have a scope. Mike Loewen mloe...@cpumagic.scol.pa.us Old Technology http://q7.neurotica.com/Oldtech/
OMNIBUS board handle spacers
I just printed some board handles for a 32k OMNIBUS board (thanks Vince Slyngstad, et al.) I now notice that all the OMNIBUS boards have an extra 0.1in spacer between the board and the handle. UNIBUS and QBus boards and logic flip chips don't have the spacer. Anyone else notice this and understand why? The only thing I can see is that it might adjust for the over the top connectors used on a lot of OMNIBUS boards. -chuck
Re: Scanning Suggestions (Bookmarks & Colour)
On 8/27/21 6:01 PM, Paul Koning wrote: > I once looked for open source OCR, and found one (an obscure GNU project I > think) but it didn't do much. |Most of the world uses tesseract, including ocrmypdf I didn't see an obvious example of ocrmypdf doing OCR in parallel on a single document |
Re: Scanning Suggestions (Bookmarks & Colour)
On Fri, Aug 27, 2021 at 05:55:44PM -0700, Al Kossow via cctalk wrote: > I was also just thinking you would probably have to have a layer (black) with > all of the > stuff to OCR including the stuff in red and blue, then overlay the color on > that > after the pass through whatever you're using to do the OCR. > > The one bottleneck I would really like to fix is getting the 24 cores on my > machine doing > OCR on 24 different pages at the same time. > > The documentation for ocrmypdf describes how to do that. https://ocrmypdf.readthedocs.io/en/latest/ and https://ocrmypdf.readthedocs.io/en/latest/batch.html Don
Re: Scanning Suggestions (Bookmarks & Colour)
> On Aug 27, 2021, at 8:55 PM, Al Kossow via cctalk > wrote: > > I was also just thinking you would probably have to have a layer (black) with > all of the > stuff to OCR including the stuff in red and blue, then overlay the color on > that > after the pass through whatever you're using to do the OCR. > > The one bottleneck I would really like to fix is getting the 24 cores on my > machine doing > OCR on 24 different pages at the same time. What OCR do you use? It's been a while, but I've been using ABBYY FineReader. I once looked for open source OCR, and found one (an obscure GNU project I think) but it didn't do much. paul
Re: Scanning Suggestions (Bookmarks & Colour)
I was also just thinking you would probably have to have a layer (black) with all of the stuff to OCR including the stuff in red and blue, then overlay the color on that after the pass through whatever you're using to do the OCR. The one bottleneck I would really like to fix is getting the 24 cores on my machine doing OCR on 24 different pages at the same time.
Re: Scanning Suggestions (Bookmarks & Colour)
> On Aug 27, 2021, at 8:32 PM, Paul Koning via cctalk > wrote: > > ... > >> It turns out though that if you drive it with a computer then you also get >> the choice of TIFF or PNG as additional choices. TIFF is likely to be quite >> a bit too big. I'll try PNG and see how big the files it generates are. I've >> no idea what the default compression is straight out of the software but as >> long as it's lossless I can hopefully post-process to squeeze things down if >> possible. > > TIFF is (normally) lossless. I think PNG also, or at least can be, but I > don't understand it as well. I should have checked first, but at least now I know: yes, PNG is lossless, it uses Deflate compression. And TIFF is also lossless, with a variety of compression schemes. In particular, it is the way to go for bitonal images with the CCITT compression scheme, which is specifically optimized for that case. paul
Re: Scanning Suggestions (Bookmarks & Colour)
> On Aug 27, 2021, at 5:36 PM, Antonio Carlini wrote: > > On 27/08/2021 22:05, Paul Koning wrote: >> JPG is the wrong tool for pages with color text or color line art. As I've >> mentioned before, JPG is fit ONLY for photos, not for any image with hard >> edges. Text compressed with JPG will suffer badly. > > > Yes, true. I thought that for colour, all I could get was JPEG. It certainly > seems to be the case that the HP PhotoSmart I have scans everything as JPEG > 300 dpi when you use the front panel to scan to a memory stick. Post > processing wouldn't make that any better, which is why I thought I was stuck > with JPEG. Wow, that's crazy. Perhaps they thought the product was only going to be used by consumers who have no clue. > It turns out though that if you drive it with a computer then you also get > the choice of TIFF or PNG as additional choices. TIFF is likely to be quite a > bit too big. I'll try PNG and see how big the files it generates are. I've no > idea what the default compression is straight out of the software but as long > as it's lossless I can hopefully post-process to squeeze things down if > possible. TIFF is (normally) lossless. I think PNG also, or at least can be, but I don't understand it as well. TIFF is actually a container and inside it can be any number of encodings. Compression schemes can be simple ones like run length coding, or more complex ones like LZ. Either way, if there are patterns, especially significant areas of the same color, the compression works very well indeeed. A raw scan probably won't compress well. But something as simple as a white point adjustment to make the bulk of the background be full white will make the file very much smaller. If you tweak the black point some as well, so areas meant to be black are in fact full black rather than slightly-varying grays, you will gain still more. As a bonus, the resulting image will also be much crisper and easier to read. The other day there was a mention of open souce tools at leptonica.org: from the examples given in the intro, for example here: http://www.leptonica.org/binarization.html it looks like a very nice tool kit to clean up images very well and easily. While I don't see it mentioned, the cleaned up images will certainly compress very effectively in TIFF. paul
Re: Scanning Suggestions (Bookmarks & Colour)
> On Aug 27, 2021, at 5:19 PM, Al Kossow via cctalk > wrote: > > > Probably the way to deal with DEC tri-color would be to define rectangular > regions and have > three separate bitonal layers colored black red and blue, and a third JPEG-2 > for grayscale > or color images. Doing the layer separations would be the non-fun part. I haven't looked at tools in, say, GIMP to create spot-color layers from RGB images. If it can do that, a good way to do what you describe is to give it a spot color definition that matches what the color print looks like. Then the black layer and the red (or whatever) layer are the two you want, and you could run each through a threshold operation to make them bitonal. Then the image converted back to RGB would compress really well with TIFF. paul
Re: Scanning Suggestions (Bookmarks & Colour)
On Sat, 2021-08-28 at 01:40 +0200, Torfinn Ingolfsen via cctalk wrote: > On Sat, Aug 28, 2021 at 12:43 AM Van Snyder via cctalk > wrote: > > > > > > This isn't a default part of Debian distributions, and apt-get > > can't > > find it. > > > > I found it on github > > > > https://github.com/brouhaha/tumble > > > > I had to install several packages that are not default parts of > > Debian > > "Buster" 10, such as bison, flex, libtiff-dev libjpeg-dev > > libnetpbm11- > > dev > > > > I wasn't able to compile it on Debian "Buster" 10. Ultimately, > > "make" > > gave up: > > FWIW, I got it to compile on Debian 11 by applying the fixes in pull > request 7 > https://github.com/brouhaha/tumble/pull/7 > Unfortunately, I no longer have any Debian 10 machines to test on. Thanks for the tip. That did the trick. Compile worked. Haven't tested the executable yet. Van > > HTH
Re: RQDX3 firmware sources
On Thu, Aug 26, 2021 at 10:49 PM Doc Shipley via cctalk < cctalk@classiccmp.org> wrote: > On 8/26/21 19:22, Charles Dickman via cctalk wrote: > > > I'm not even going to try, but I think the actual low-level formatter > code > > is missing. Was curious if anyone else noticed that too. > >I always thought that the service diagnostics were the only > formatting code available for the RQDX3? > > The diagnostic ZRQC actually invokes a program internal to the RQDX3 to do the formatting. That internal program is missing. > > Doc >
Re: Scanning Suggestions (Bookmarks & Colour)
On Sat, Aug 28, 2021 at 12:43 AM Van Snyder via cctalk wrote: > > > This isn't a default part of Debian distributions, and apt-get can't > find it. > > I found it on github > > https://github.com/brouhaha/tumble > > I had to install several packages that are not default parts of Debian > "Buster" 10, such as bison, flex, libtiff-dev libjpeg-dev libnetpbm11- > dev > > I wasn't able to compile it on Debian "Buster" 10. Ultimately, "make" > gave up: FWIW, I got it to compile on Debian 11 by applying the fixes in pull request 7 https://github.com/brouhaha/tumble/pull/7 Unfortunately, I no longer have any Debian 10 machines to test on. HTH -- Regards, Torfinn Ingolfsen
Re: Scanning Suggestions (Bookmarks & Colour)
On Fri, 2021-08-27 at 14:10 -0700, Al Kossow via cctalk wrote: > It is trivial to add page bookmarks with Eric Smith's tumble with the > -b %F option This isn't a default part of Debian distributions, and apt-get can't find it. I found it on github https://github.com/brouhaha/tumble I had to install several packages that are not default parts of Debian "Buster" 10, such as bison, flex, libtiff-dev libjpeg-dev libnetpbm11- dev I wasn't able to compile it on Debian "Buster" 10. Ultimately, "make" gave up: # make clean; make ... bison and flex... ... a bunch of successful cc compiles to get .o files cc tumble.o semantics.o tumble_input.o tumble_tiff.o tumble_jpeg.o tumble_pbm.o tumble_png.o tumble_blank.o bitblt.o bitblt_g4.o bitblt_tables.o g4_tables.o pdf.o pdf_util.o pdf_prim.o pdf_name_tree.o pdf_bookmark.o pdf_page_label.o pdf_text.o pdf_g4.o pdf_jpeg.o pdf_png.o scanner.o parser.tab.o -ltiff -ljpeg -lnetpbm -lz -lm -o tumble /usr/bin/ld: tumble_input.o:(.bss+0x0): multiple definition of `blank_handler'; tumble.o:(.bss+0x20): first defined here /usr/bin/ld: tumble_tiff.o:(.bss+0x20): multiple definition of `blank_handler'; tumble.o:(.bss+0x20): first defined here /usr/bin/ld: tumble_jpeg.o:(.bss+0x0): multiple definition of `blank_handler'; tumble.o:(.bss+0x20): first defined here /usr/bin/ld: tumble_pbm.o:(.bss+0x0): multiple definition of `blank_handler'; tumble.o:(.bss+0x20): first defined here /usr/bin/ld: tumble_png.o:(.bss+0x0): multiple definition of `blank_handler'; tumble.o:(.bss+0x20): first defined here /usr/bin/ld: tumble_blank.o:(.data.rel.local+0x0): multiple definition of `blank_handler'; tumble.o:(.bss+0x20): first defined here /usr/bin/ld: scanner.o:(.bss+0x18): multiple definition of `yyin'; semantics.o:(.bss+0x50): first defined here collect2: error: ld returned 1 exit status make: *** [Makefile:127: tumble] Error 1 Is it available as a statically-linked executable, or only as source from github?
Re: Call for manuals and maybe floppies: IBM 8100
Re: "My next project once I finish my IBM 1410 FPGA implementation (so, a couple of years out, probably) would be to write an emulator for the boat anchor known as the IBM 8100. I had exposure to these things back in the 1980s." I encountered one, once. Probably 1979, in a small conference room in building 47U of Hewlett-Packard's Cupertino site. Sitting all alone in the room. I was looking at it, and an HP engineer came in and explained that they were waiting for IBM service to fix the memory board ... the board HP had removed to look at closely :)
Re: Scanning Suggestions (Bookmarks & Colour)
On 27/08/2021 22:10, Al Kossow via cctalk wrote: On 8/27/21 2:05 PM, Paul Koning via cctalk wrote: For material such as the RSX manuals you mentioned, the tool needed is a compression algorithm that handles color with hard edges faithfully. Basically that means a lossless compression scheme. That should be fine, since pages like that should compress very well, at least if the scan has been touched up just a bit to make the page background reasonably pure white. Ethan worked on a filter a long time ago for DEC manuals. J David Bryan's work was mentioned recently. I did see it, but it didn't look like a cookie-cutter recipe. I'd be happy to be proved wrong though. What I don't want to have to do is manually process each page (beyond having to decide which to scan in colour). I would be looking for an algorithm or process that I can just point at scanner data for a page and have it spit out the optimised PDF page. I'm sure that will appear at some stage, but I don't think it exists yet. The RSX-11M/M-PLUS Error Logging Manual, for example, has somewhere between 20 and 50 pages with colour present. I can pick those out and re-scan them and I can relatively easily merge those pages with the original B scan, but if I have to manually examine each page, I'll never make it to whatever manual is in my list after that one :-) It is trivial to add page bookmarks with Eric Smith's tumble with the -b %F option Thanks, I'll look into tumble. Antonio -- Antonio Carlini anto...@acarlini.com
Re: Scanning Suggestions (Bookmarks & Colour)
On 27/08/2021 22:05, Paul Koning wrote: JPG is the wrong tool for pages with color text or color line art. As I've mentioned before, JPG is fit ONLY for photos, not for any image with hard edges. Text compressed with JPG will suffer badly. Yes, true. I thought that for colour, all I could get was JPEG. It certainly seems to be the case that the HP PhotoSmart I have scans everything as JPEG 300 dpi when you use the front panel to scan to a memory stick. Post processing wouldn't make that any better, which is why I thought I was stuck with JPEG. It turns out though that if you drive it with a computer then you also get the choice of TIFF or PNG as additional choices. TIFF is likely to be quite a bit too big. I'll try PNG and see how big the files it generates are. I've no idea what the default compression is straight out of the software but as long as it's lossless I can hopefully post-process to squeeze things down if possible. If this turns out to work without ballooning file sizes, then I can just not bother preserving the B pages, as lossless colour PNG should OCR as well as B (I would think). I have a few pages in the scanner now at 600dpi PNG so I'll soon know how that compares to JPG or B Thanks Antonio -- Antonio Carlini anto...@acarlini.com
Re: Scanning Suggestions (Bookmarks & Colour)
Probably the way to deal with DEC tri-color would be to define rectangular regions and have three separate bitonal layers colored black red and blue, and a third JPEG-2 for grayscale or color images. Doing the layer separations would be the non-fun part.
Re: Scanning Suggestions (Bookmarks & Colour)
On 8/27/21 2:05 PM, Paul Koning via cctalk wrote: For material such as the RSX manuals you mentioned, the tool needed is a compression algorithm that handles color with hard edges faithfully. Basically that means a lossless compression scheme. That should be fine, since pages like that should compress very well, at least if the scan has been touched up just a bit to make the page background reasonably pure white. Ethan worked on a filter a long time ago for DEC manuals. J David Bryan's work was mentioned recently. It is trivial to add page bookmarks with Eric Smith's tumble with the -b %F option
Re: Scanning Suggestions (Bookmarks & Colour)
> On Aug 27, 2021, at 4:50 PM, Antonio Carlini via cctalk > wrote: > > I have a few manuals to scan and I'm looking for suggestions, about how to > add bookmarks and how to handle colour. > ... > For photographs or shaded areas that don't necessarily come out well under > those settings, I plan to use 8-bit greyscale. I'd prefer to use 600dpi but I > may have to fall back to 300dpi if the per-page fiile size shoots up too much. Depending on the resolution used, given that the photos are printed as halftone (black dots of various sizes), you may get weird scan artifacts. Some scan programs may have tools to convert a halftone image to the equivalent grayscale image, such a thing is likely to be helpful. > The real issue is colour. I know that various people have looked at the issue > of how to efficiently scan pages that are mostly black and white but have > some coloured text (RSX-11 manuals and early VMS manuals did this to > highlight terminal input, for example). I don't think this is a solved > problem and I'm not expecting a solution, what I'm really looking for is to > check that what I'm about to produce will have all the information that a > future efficient algorithm is likely to need. > > I'm going to start by scanning the whole manual as though it had no colour > (so 600 dpi bilevel G4 encoded, except for pages with photos and shading and > so on). Then I'm going to go back and rescan the pages that have colour and > scan those at 600 dpi and save as a JPG. JPG is the wrong tool for pages with color text or color line art. As I've mentioned before, JPG is fit ONLY for photos, not for any image with hard edges. Text compressed with JPG will suffer badly. For material such as the RSX manuals you mentioned, the tool needed is a compression algorithm that handles color with hard edges faithfully. Basically that means a lossless compression scheme. That should be fine, since pages like that should compress very well, at least if the scan has been touched up just a bit to make the page background reasonably pure white. With more effort it would be possible to reconstruct the original three-color material (white, black, red or whatever), but that's a fair amound harder and probably not necessary for adequate compression. But please, make it a practice to avoid JPG except in those cases (rare or non-existent in document scanning work) where you're actually dealing with a continuous tone photograph). paul
Scanning Suggestions (Bookmarks & Colour)
I have a few manuals to scan and I'm looking for suggestions, about how to add bookmarks and how to handle colour. Bookmarks should be easier, so lets start with that. I want to add bookmarks (or whatever they are called) so that it is easy to navigate to page "2-48" or "C-17" in a document. Many of the PDFs on bitsavers have that and I've found it very useful so I'd like to do that for my future scans. I've tried with pdftk (the Java port as the original is no longer available on my distro) but that failed. So I tried GhostScript and that also failed, while also rewriting the PDF to be considerably larger. Is there simple way to achieve this (ideally from the CLI)? Now for the scanning itself. For manuals that are simple monochrome, I plan to scan at 600dpi bilevel G4 encoded, wrapped in PDF. For photographs or shaded areas that don't necessarily come out well under those settings, I plan to use 8-bit greyscale. I'd prefer to use 600dpi but I may have to fall back to 300dpi if the per-page fiile size shoots up too much. The real issue is colour. I know that various people have looked at the issue of how to efficiently scan pages that are mostly black and white but have some coloured text (RSX-11 manuals and early VMS manuals did this to highlight terminal input, for example). I don't think this is a solved problem and I'm not expecting a solution, what I'm really looking for is to check that what I'm about to produce will have all the information that a future efficient algorithm is likely to need. I'm going to start by scanning the whole manual as though it had no colour (so 600 dpi bilevel G4 encoded, except for pages with photos and shading and so on). Then I'm going to go back and rescan the pages that have colour and scan those at 600 dpi and save as a JPG. Then I'll produce a final PDF with the colour pages inserted. I'll also produce a PDF with the B pages that were replaced by colour pages (I assume OCR will be better served by non-jaggy scans). So the final outputs will be: manual.pdf - the whole manual, including whole pages scanned as colour if any colour is present on them manual_BW.pdf - the G4-encoded bilevel pages that were replaced by colour pages Thanks Antonio -- Antonio Carlini anto...@acarlini.com
Re: IBM 1620 Simulation
On 8/27/21 11:23 AM, Lee Courtney via cctalk wrote: > Video interview I made with John (Maniotes) in preparation for donation of > the 1620 program library to CHM - https://youtu.be/N12pQBiRd7A I remember that name--he was at Purdue Calumet Campus. I probably even met and talked to him 50+ years ago. --Chuck
Re: IBM 1620 Simulation
Video interview I made with John (Maniotes) in preparation for donation of the 1620 program library to CHM - https://youtu.be/N12pQBiRd7A Lee Courtney On Fri, Aug 27, 2021 at 9:50 AM Van Snyder via cctalk wrote: > On Thu, 2021-08-26 at 20:17 -0700, Al Kossow via cctalk wrote: > > > > > > On 8/26/21 7:43 PM, Van Snyder via cctalk wrote: > > > There was a professor at Purdue who had two 20-drawer card cabinets > > > full of 1620 software. I think his name was Maniotis. I think the > > > Computer History Museum in Mountain View has it now. Maybe it's > > > online. > > > > https://www.computerhistory.org/collections/catalog/102710141 > > > > The 1620 restoration crew read them it > > they are in > > http://bitsavers.org/bits/1620/1620.zip > > Should be http://bitsavers.org/bits/IBM/1620/1620.zip > > > > > -- Lee Courtney +1-650-704-3934 cell
Re: IBM 1620 Simulation
On Thu, 2021-08-26 at 20:17 -0700, Al Kossow via cctalk wrote: > > > On 8/26/21 7:43 PM, Van Snyder via cctalk wrote: > > There was a professor at Purdue who had two 20-drawer card cabinets > > full of 1620 software. I think his name was Maniotis. I think the > > Computer History Museum in Mountain View has it now. Maybe it's > > online. > > https://www.computerhistory.org/collections/catalog/102710141 > > The 1620 restoration crew read them it > they are in > http://bitsavers.org/bits/1620/1620.zip Should be http://bitsavers.org/bits/IBM/1620/1620.zip >
Re: Wilson Laboratories SX-530 disk exerciser
Hello Alan, I am not at home right now, but when I will be back next week, I will see if I have the manual for that exerciser. If so, then I will scan it to upload it on bitsavers. Best regards, Pierre - http://www.digitalheritage.de Am Donnerstag, 26. August 2021, 01:51:48 MESZ hat Alan Frisbie via cctalk Folgendes geschrieben: I recently acquired a Wilson Laboratories SX-530 disk exerciser for SMD interface disk drives. Unfortunately, it did not come with a manual. Does anyone out there have a copy they could make available? Yes, Bitsavers was the first place I checked. :-) Yes, I still have some SMD drives in working condition -- at least they were before I moved. One is a Century Data Systems T-302, and another is a Fujitsu Eagle. The T-302 is wonderful for impressing younger people who aren't familiar with older technology like 12-platter removable disk packs. :-) 220 volt, 30 amps starting, 6 amps running, all for a whole 256 megabytes (formatted). Thanks, Alan
