18 May
2006
18 May
'06
2:10 p.m.
The archive search on classiccmp.org does not appear to be working. I
thought it was me at first but I guess the words vax and unix have
been mentioned here before ;)
Dan
18 May
18 May
2:17 p.m.
Dan Williams wrote:
The archive search on classiccmp.org does not appear
to be working. I
thought it was me at first but I guess the words vax and unix have
been mentioned here before ;)
Hmm, I tried searching for something about a week ago that I knew had been
posted recently and had the same trouble - I think Jay's said in the past
though that the archives screw up whilst they're being re-indexed or
something, so I just put it down to that and thought nothing more of it (the
reason for needing to search went away).
Perhaps there's a more serious problem at work though...
cheers
Jules
6:50 p.m.
Jay mentioned to me off-list that the archive search basically
doesn't work until about 10 PM - 3 AM. At 3 AM the indexer starts
again and doesn't finish until about 10 PM(!). He would like some
volunteers to hack the python code to be more efficient or something,
but I don't know python. Please contact Jay to help out and get the
specifics!
--
"The Direct3D Graphics Pipeline"-- code samples, sample chapter, FAQ:
<http://www.xmission.com/~legalize/book/>
Pilgrimage: Utah's annual demoparty
<http://pilgrimage.scene.org>
7:15 p.m.
Jay mentioned to me off-list that the archive search
basically
doesn't work until about 10 PM - 3 AM. At 3 AM the indexer starts
again and doesn't finish until about 10 PM(!). He would like some
volunteers to hack the python code to be more efficient or something,
but I don't know python. Please contact Jay to help out and get the
specifics!
Ouch, I don't do python (something about it taking 10 seconds for
"Hello, World" to run on my VMS server). It sounds to me like this
is a good candidate for running either once a week, or once a month.
Zane
19 May
19 May
9:55 a.m.
Zane H. Healy wrote:
> He would like some
> volunteers to hack the python code to be more efficient or something,
> but I don't know python.
Sounds more like it needs rewriting in a more efficient language to me (isn't
Python interpreted? Probably not a good choice for search indexing!)
I can't imagine the indexing code's *that* complicated - I expect it's the
search side and how to quickly find results in the masses of data that tends
to be the tricky part.
"Hello, World" to run on my VMS server). It
sounds to me like this
is a good candidate for running either once a week, or once a month.
Hmm, isn't the dictionary (mapping words to codes) static and built up from
existing archives? 'new' words found subsequently will get longer codes
assigned to them and be less efficient, but if the initial sample data is
large it won't necessarily matter. Beats rebuilding the dictionary and
re-assigning codes all the time, assuming that's what's done at the moment.
If the dictionary is static then files can be indexed as they arrive rather
than the whole archive needing scanning every x hours to keep indexes in sync.
(This was the assumption I was basing some desktop search code on which I was
writing - but that's another one of those half-done projects that's sitting a
way down on the priority list to complete right now. I found myself not being
able to find anything in my local archives and couldn't find anything
available on the 'net to do the job)
cheers
Jules
1:04 p.m.
Jules Richardson wrote:
Sounds more like it needs rewriting in a more
efficient language to me
Python compiles to p-code, it's fine. I'm sure the code is inefficient,
or he has REALLY slow disk.
Either way, the indexing doesn't need to be run every single night; once
a week is fine.
--
Jim Leonard (trixter at oldskool.org) http://www.oldskool.org/
Help our electronic games project: http://www.mobygames.com/
Or check out some trippy MindCandy at http://www.mindcandydvd.com/
A child borne of the home computer wars: http://trixter.wordpress.com/
1:09 p.m.
Jim Leonard wrote:
Jules Richardson wrote:
A disk sort once or twice a year would be handy too!
Sounds more like it needs rewriting in a more
efficient language to me
Python compiles to p-code, it's fine. I'm sure the code is inefficient,
or he has REALLY slow disk.
Either way, the indexing doesn't need to be run every single night; once
a week is fine.
1:11 p.m.
Jim Leonard wrote:
Jules Richardson wrote:
I don't like Python, but I don't think it's to blame here. I've got a
website setup on my VMS server where I have a lot of information that I want
to be able to search. IIRC, the search software I'm running is written in
C, and it is less than 18GB of data (18GB 10K LVD drive on a UW-SCSI
controller). I think it tooks something like three hours last time I
indexed the data (the data is basically static, so I run the update manually
when I add more).
Zane
Sounds more like it needs rewriting in a more
efficient language to me
Python compiles to p-code, it's fine. I'm sure the code is inefficient,
or he has REALLY slow disk.
Either way, the indexing doesn't need to be run every single night; once
a week is fine.
2:24 p.m.
In article <200605191711.k4JHBIjB027267 at onyx.spiritone.com>,
"Zane H. Healy" <healyzh at aracnet.com> writes:
I don't like Python, but I don't think
it's to blame here.
From what I recall of the discussion with Jay, the
issue is a naive
implementation combined with a huge data set.
--
"The Direct3D Graphics Pipeline"-- code samples, sample chapter, FAQ:
<http://www.xmission.com/~legalize/book/>
Pilgrimage: Utah's annual demoparty
<http://pilgrimage.scene.org>
20 May
20 May
2:15 p.m.
New subject: Free for the taking HP/Apollo, vt100, wyse, Sun Ultra 5
With the size of my NeXT collection growing, I'm running out of
space, and these things need to go.
I rescued 4 HP/Apollo machines from the dumpster, 2 are PA-RISC and 2
are 68040 machines.... I can dig up the exact information if anyone
is interested. The vt100 was used by Brown University, and I believe
it is in working condition, as is the wyse. The Ultra 5's (3 of them)
have 15" monitors, and lot's of spare bits like drive cages etc.
I'm in Rhode Island, though I'm often in the Burlington/Bedford area
of MA. If nobody is interested in these things I'm going to either
put them on ebay, or dump them.
2:28 p.m.
New subject: Free for the taking HP/Apollo, vt100, wyse, Sun Ultra 5
What are the 68040s?
Paxton
--
Paxton Hoag
Astoria, OR
USA
21 May
21 May
1:19 p.m.
New subject: Free for the taking HP/Apollo, vt100, wyse, Sun Ultra 5
On 5/20/2006 at 2:15 PM Gavin Thomas Nicol wrote:
I rescued 4 HP/Apollo machines from the dumpster, 2 are
PA-RISC and 2
are 68040 machines....
I'm a big fan of the PA-RISC architecture, but without software and system
experience, I think I'll have to reluctantly pass on them.
Cheers,
Chuck
22 May
22 May
12:21 p.m.
New subject: Free for the taking HP/Apollo, vt100, wyse, Sun Ultra 5
Chuck Guzis wrote:
On 5/20/2006 at 2:15 PM Gavin Thomas Nicol wrote:
The PA-RISC ones won't run Domain/OS anyway, so are possibly less interesting.
I imagine far more capable PA-RISC machines can be had easily (I expect these
are Apollo 7xx systems - nothing wrong with them, and the construction's
nicely done - just slow compared to other PA-RISC systems)
I think the DN4000 / DN4500 machines are the '040 boxes (and last in the
"real" Apollo line)
Would love them for Bletchley but I'm not about to ship something that heavy
across the pond!
cheers
J.
I rescued 4 HP/Apollo machines from the dumpster,
2 are PA-RISC and 2
are 68040 machines....
I'm a big fan of the PA-RISC architecture, but without software and system
experience, I think I'll have to reluctantly pass on them.
24 May
24 May
1:53 p.m.
New subject: Free for the taking HP/Apollo, vt100, wyse, Sun Ultra 5
In article <22239BB9-A379-490B-83D2-53E45FDF3450 at mind-to-mind.com>,
Gavin Thomas Nicol <gtn at mind-to-mind.com> writes:
I rescued 4 HP/Apollo machines from the dumpster, 2
are PA-RISC and 2
are 68040 machines.... I can dig up the exact information if anyone
is interested. [...]
I've been looking for an Apollo DN10000, it was one of their last
machines and supported a 3D accelerated PHIGS implementation
(graphics ISO/ANSI API). Can you post back model numbers for the
Apollo machines? Pictures would be great too.
--
"The Direct3D Graphics Pipeline"-- code samples, sample chapter, FAQ:
<http://www.xmission.com/~legalize/book/>
Pilgrimage: Utah's annual demoparty
<http://pilgrimage.scene.org>
2:35 p.m.
New subject: Free for the taking HP/Apollo, vt100, wyse, Sun Ultra 5
Richard wrote:
I've been looking for an Apollo DN10000, it was
one of their last
machines and supported a 3D accelerated PHIGS implementation
(graphics ISO/ANSI API).
You and me both! I've never got wind of there being one in the UK at all - and
as for finding one with OS media... (I seem to remember the DN10k's used
proprietary CPUs*, so stock 68k OS tapes don't work)
*were these developed in-house, or sourced from elsewhere? Google doesn't seem
to confirm either way, and there seems to be a lot of confusion regarding the
machines in general.
From memory they'd support up to 8 processors.
As a big fan of Apollos I'd love to find one too, but don't hold out much hope!
No idea why they're so rare and forgotten about; far as I'm aware the
architecture and performance were sound enough - possibly just too expensive?
cheers
Jules
20 May
20 May
8:16 p.m.
It had been written....
>> He would like some
>> volunteers to hack the python code to be more efficient or something,
>> but I don't know python.
All true.
Sounds more like it needs rewriting in a more
efficient language to me
(isn't Python interpreted? Probably not a good choice for search
indexing!)
No, not a different language.. the entire mailman software is python
based.
Unfortunatley I'm not a python programmer. But I'm not about to switch
packages.
I can't imagine the indexing code's *that*
complicated - I expect it's the
search side and how to quickly find results in the masses of data that
tends to be the tricky part.
The indexing and searching code isn't mailman
anyway, so the problem has
nothing to do with mailman. The indexing and searching is done by htdig.
If the dictionary is static then files can be indexed
as they arrive
rather than the whole archive needing scanning every x hours to keep
indexes in sync.
Some one tell the guy who wrote the mailman/htdig integration
piece.
A big chunk of the problem is that the complete text of all archives for
both cctalk AND cctech is done every night. A rather huge task. CCtalk and
CCtech will be combined at some point in the near future anyways (I know, I
keep saying that, but it'll happen).
Jay West
10:11 p.m.
Jay West wrote:
...
A big chunk of the problem is that the complete text
of all archives for
both cctalk AND cctech is done every night. A rather huge task. CCtalk
and CCtech will be combined at some point in the near future anyways (I
know, I keep saying that, but it'll happen).
The thing I don't get about this is: I would imagine any rational
implementation would keep the old set of indexes alone and in a usable
state for searching while the new set was being generated, even if it
takes 20 hours. Then, once the new indexes were finished, the new ones
would be switched into play and the old ones deleted.
So I don't understand why search only works between 8pm and midnight (or
whatever the small window is that someone stated at the beginning of
this thread).
10:30 p.m.
Jim wrote....
The thing I don't get about this is: I would
imagine any rational
implementation would keep the old set of indexes alone and in a usable
state for searching while the new set was being generated, even if it
takes 20 hours. Then, once the new indexes were finished, the new ones
would be switched into play and the old ones deleted.
You would think that's
the way it was done. I have not done any detailed
troubleshooting on it. What I can say for sure is this... the indexing
starts off somewhere around 2am ISTR. It is obvious that it is indexing both
cctalk and cctech in separate runs. It runs until around 10:30pm or 11pm at
night. During that time, searches for anything return a null result. If I
kill off the index processes, a search for the same word does yield results.
Draw your own conclusions.
So I don't understand why search only works
between 8pm and midnight (or
whatever the small window is that someone stated at the beginning of this
thread).
Because that's how long it takes the reindex process to run... from
around
2am to around 10:30pm (CST {GMT-6}). It's a horrible design, but... soone or
later I'll have to dig in to it further.
Jay
21 May
21 May
5:15 p.m.
Jay,
htDig can be setup to run that way. I'd be happy to fix it up for ya.
preferred username: timr
ssh2 dsa key: http://rikers.org/id_dsa.pub
--
Tim Riker - http://Rikers.org/ - TimR at Debian.org
Embedded Linux Technologist - http://eLinux.org/
BZFlag maintainer - http://BZFlag.org/ - for fun!
22 May
22 May
12:22 p.m.
Jay West wrote:
We need a batch interface so we can submit search requests into the queue and
get the results back the following day. (actually, that would be kinda cool
and in keeping with the list charter ;-)
cheers
Jules
So I don't
understand why search only works between 8pm and midnight
(or whatever the small window is that someone stated at the beginning
of this thread).
Because that's how long it takes the reindex process to
run... from
around 2am to around 10:30pm (CST {GMT-6}). It's a horrible design,
but... soone or later I'll have to dig in to it further.
6:11 p.m.
Jules Richardson wrote:
We need a batch interface so we can submit search
requests into the
queue and get the results back the following day. (actually, that would
be kinda cool and in keeping with the list charter ;-)
Make sure you number the punch cards in case they get dropped.
--
Tim Riker - http://Rikers.org/ - TimR at Debian.org
Embedded Linux Technologist - http://eLinux.org/
BZFlag maintainer - http://BZFlag.org/ - for fun!
6:24 p.m.
On Mon, 22 May 2006, Tim Riker wrote:
and make a diagonal mark on the deck, so that there can be a visual alert
to a scrambled deck
We need a
batch interface so we can submit search requests into the
queue and get the results back the following day. (actually, that would
be kinda cool and in keeping with the list charter ;-)
Make sure you number the punch cards in case they get dropped. 
19 May
19 May
1:40 p.m.
In message <200605182315.k4INFf5J010032 at onyx.spiritone.com>
"Zane H. Healy" <healyzh at aracnet.com> wrote:
Ouch, I don't do python (something about it taking
10 seconds for
"Hello, World" to run on my VMS server). It sounds to me like this
is a good candidate for running either once a week, or once a month.
Sounds like Perl on my NSLU2. Two seconds to do a hello world, nearly ten to
run SpamAssassin over a single message. The same hello world app in C ran
instantly (or quick enough that I couldn't time it), and my homebrew spam
filter isn't much slower despite all the PCRE calls.
--
Phil. | Kitsune: Acorn RiscPC SA202 64M+6G VF+UniPod
philpem at dsl.pipex.com | Cheetah: Athlon64 3200+ A8VDeluxeV2 1G+180G
http://www.philpem.me.uk/ | Tiger: Toshiba SatPro4600 Celeron700 256M+40G
1:55 p.m.
Phil wrote:
"Zane H. Healy" <healyzh at
aracnet.com> wrote:
NSLU2? What on earth is that?
BTW, I don't have any issues with the speed of Perl or Ruby on my VMS
server, just Python. The actual execution of Python on VMS seems to be
fairly fast, at least on my box, the problem is the overhead with starting
it.
Zane
Ouch, I don't do python (something about it
taking 10 seconds for
"Hello, World" to run on my VMS server). It sounds to me like this
is a good candidate for running either once a week, or once a month.
Sounds like Perl on my NSLU2. Two seconds to do a hello world, nearly ten to
run SpamAssassin over a single message. The same hello world app in C ran
instantly (or quick enough that I couldn't time it), and my homebrew spam
filter isn't much slower despite all the PCRE calls.
2:45 p.m.
In message <200605191755.k4JHtLYJ028662 at onyx.spiritone.com>
"Zane H. Healy" <healyzh at aracnet.com> wrote:
NSLU2? What on earth is that?
www.linksys.com -> search for NSLU2.
Basically it's an ARM-powered mini server that runs Linux. They're designed
to connect a USB hard drive or pendrive to a LAN (kind of a poor man's NAS),
but there's been a lot of hacking done on them. I've got mine running Debian,
with a custom kernel and the kernel-mode Speedtouch ADSL driver. At the
moment it's doing the DSL routing, email downloading, spam filtering, print
serving, some basic network monitoring (MRTG) and hosting my SVN repository.
I've also been using it to tunnel through annoying firewalls... It's kinda
nice to have files downloading when the connection is usually idle and have
everything ready to go by the time I get home.
CPU is an Intel IXP440 Xscale running at 133MHz, but it can be overclocked
(well, actually de-underclocked) to run at 266MHz. It's only got 32MB of RAM,
but that's plenty for what I use it for. Main reason I bought it was because
it's totally fanless - the only noise is from the HDD. Certainly beats having
a noisy PC running 24/7. I was kinda getting sick of swapping out case fans
and power supplies...
BTW, I don't have any issues with the speed of
Perl or Ruby on my VMS
server, just Python. The actual execution of Python on VMS seems to be
fairly fast, at least on my box, the problem is the overhead with starting
it.
That seems to be the problem on the NSLU as well. Once Perl is up and
running, it's not too bad. It's the startup time (and RAM usage) that causes
the problems (and SpamAssassin's sheer complexity).
--
Phil. | Kitsune: Acorn RiscPC SA202 64M+6G VF+UniPod
philpem at dsl.pipex.com | Cheetah: Athlon64 3200+ A8VDeluxeV2 1G+180G
http://www.philpem.me.uk/ | Tiger: Toshiba SatPro4600 Celeron700 256M+40G
3:46 p.m.
www.linksys.com -> search for NSLU2.
Basically it's an ARM-powered mini server that runs Linux. They're designed
to connect a USB hard drive or pendrive to a LAN (kind of a poor man's NAS),
but there's been a lot of hacking done on them. I've got mine running Debian,
Oh, now that is just plain cool! I don't think I've ever looked at any of
this type device.
I can't find any hard data, I assume it just talks Samba out of the box?
Putting Debian on there offers up some real posibilites (NFS, Samba,
Appletalk, and DECnet). Though that limited memory is a real bummer.
Zane
4:53 p.m.
New subject: Linksys NSLU2 (was Archive search)
In message <200605191946.k4JJkHhC031503 at onyx.spiritone.com>
"Zane H. Healy" <healyzh at aracnet.com> wrote:
Oh, now that is just plain cool! I don't think
I've ever looked at any of
this type device.
<http://www.nslu2-linux.org> has a load of info on what you can do with it.
Even some hardware hacks (see below).
I'm running OpenDebianSlug on mine, with a patched 2.6.16 kernel (2.6.12.2 is
horrendously unstable). If you want the kernel modules and the flashbios
image, I'll see about putting them online somewhere.
I can't find any hard data, I assume it just talks
Samba out of the box?
Yep. The web-admin interface is a bit quirky though; I prefer setting stuff
up by editing the config files manually :)
Putting Debian on there offers up some real
posibilites (NFS, Samba,
Appletalk, and DECnet). Though that limited memory is a real bummer.
It's not a real big deal if you hook up a USB hard drive. Mine had about 10MB
free until I installed the mailserver software (I'm using UW-IMAPD, IPOP3D
and Postfix). It's also running the Cherokee webserver software, NFS,
Subversion, MySQL, Samba's Winbind, SMBd and NMBd servers, some stuff to
catch SNMP traps from the WiFi AP, fetchmail, CUPS and OpenSSH. Currently
showing 8MB free RAM, and about 30MB swap in use. I've got 128MB swap
allocated on the HDD, and you get about 30MB out of the 32MB RAM after the
initrd's taken its cut.
DebianSlug is supposedly the best version of Debian to use on an NSLU2,
primarily because it uses packages from the official Debian ARMLE
(little-endian ARM) port. OpenDebianSlug uses the OpenSlug big-endian kernel
and the unofficial big-endian ARM port of Debian. I'm running OpenDebianSlug,
no problems since the kernel swap, but the package updates sometimes lag a
bit.
They're also pretty hackable - you can replace the RAMs with larger chips and
(in theory at least) go as far as 128 or 256MB. Not sure why you'd want to,
but I'd like to give it a try at some point. Power consumption is only 5W or
so - they're bundled with a 2A PSU, but 1A of that is 'reserved' for the USB
ports. My USB hard drive (a firmware-patched IBM 75GXP in a Vantec Nexstar2
casing) wolfs about 30W...
--
Phil. | Kitsune: Acorn RiscPC SA202 64M+6G VF+UniPod
philpem at dsl.pipex.com | Cheetah: Athlon64 3200+ A8VDeluxeV2 1G+180G
http://www.philpem.me.uk/ | Tiger: Toshiba SatPro4600 Celeron700 256M+40G
5:11 p.m.
Philip Pemberton wrote:
In message <200605182315.k4INFf5J010032 at
onyx.spiritone.com>
"Zane H. Healy" <healyzh at aracnet.com> wrote:
That sounds like startup cost talking. It takes 10 seconds to run
SpamAssassin over a single message, but it probably takes 10 seconds to
run it over 100 messages. Start Perl, Load code, Compile code...
startup cost.
--
Jim Leonard (trixter at oldskool.org) http://www.oldskool.org/
Help our electronic games project: http://www.mobygames.com/
Or check out some trippy MindCandy at http://www.mindcandydvd.com/
A child borne of the home computer wars: http://trixter.wordpress.com/
Ouch, I don't do python (something about it
taking 10 seconds for
"Hello, World" to run on my VMS server). It sounds to me like this
is a good candidate for running either once a week, or once a month.
Sounds like Perl on my NSLU2. Two seconds to do a hello world, nearly ten to
run SpamAssassin over a single message. 
23 May
23 May
11:17 p.m.
New subject: Kaypro docs...
I just posted both PDF and TIF scans (600dpi) of my Kaypro Technical
Manual to the retroarchive site (http://www.retroarchive.org). I've
never seen this available before so I figured there would be some need
for it.
I've now got access to a duplexing sheet fed scanner that can only be
described as the Cat's Ass. :) In the coming days I'll be scanning some
CP/M 68k docs as well as all my Ampro Littleboard docs. From there
I'll progress into my complete (I think) set of the Staunch 8/89'er and
the Heatkit ROM listings. From there I'll scan anything I can fit into
the hopper. *grin*
The TIF images are clean enough for OCR work if anyone is interested in
doing that.
The CP/M 68k docs should have been done (literally) years ago, but for
one lame ass excuse or another, it never got done. Those should be
posted by tomorrow.
g.
24 May
24 May
1:28 a.m.
New subject: Kaypro docs...
On Tuesday 23 May 2006 20:17, Gene Buckle wrote:
I just posted both PDF and TIF scans (600dpi) of my
Kaypro Technical
Manual to the retroarchive site (http://www.retroarchive.org). I've
never seen this available before so I figured there would be some need
for it.
Thanks!
Cheers,
Lyle
--
Lyle Bickley
Bickley Consulting West Inc.
Mountain View, CA
http://bickleywest.com
"Black holes are where God is dividing by zero"
2:36 a.m.
New subject: Kaypro docs...
Gene Buckle wrote:
I just posted both PDF and TIF scans (600dpi) of my
Kaypro Technical
Manual to the retroarchive site (http://www.retroarchive.org). I've
never seen this available before so I figured there would be some need
for it.
Not to discourage you, the world could use more people willing to scan
and archive what they have, but
http://www.classiccmp.org/bitsavers/pdf/kaypro/
has a timestamp of "09-Dec-1999 15:10".
I've now got access to a duplexing sheet fed
scanner that can only be
described as the Cat's Ass. :) In the coming days I'll be scanning some
CP/M 68k docs as well as all my Ampro Littleboard docs.
I scanned my ampro littleboard docs, but then I removed them when I
found they were already online. Howard Harte has some stuff here:
http://www.hartetechnologies.com/manuals/Ampro/
Check and scan what he doesn't already have. Of course, if you are so
inclined, scan everything you have. But if you are going to triage,
scan things that aren't online.
From there
I'll progress into my complete (I think) set of the Staunch 8/89'er and
the Heatkit ROM listings. From there I'll scan anything I can fit into
the hopper. *grin*
H89 ROM listings are already online, but they are behind a password at
http://www.sebhc.org/. Having copies freely available would benefit
more people.
I have used a nice high speed copier/scanner at work that can spit out
tif files or ready-to-go pdf files. There is a word of caution though.
The machine is set up to have a very high quality dithering algorithm
in order to get the visually most appealing results. This is different
than the simple threshold quantifier that you get from most scanners
when you ask for B&W scans. When you zoom in close to the text, the
edges will have a feathered appearance as the copier is trying to
approximate partial pixel coverage. It looks good, but hurts
compression and doesn't do anything helpful for OCR.
8:50 p.m.
New subject: Kaypro docs...
Not to discourage you, the world could use more people
willing to scan
and archive what they have, but
http://www.classiccmp.org/bitsavers/pdf/kaypro/
Ahh. Didn't realize that. However, mind has a publish date of June
1985, which may indicate that it has more or corrected info.
I scanned my ampro littleboard docs, but then I
removed them when I
found they were already online. Howard Harte has some stuff here:
http://www.hartetechnologies.com/manuals/Ampro/
Ahh, that matches the one I have. Thanks for the heads up.
Check and scan what he doesn't already have. Of
course, if you are so
inclined, scan everything you have. But if you are going to triage,
scan things that aren't online.
The attitude I'm taking is that if it'll stay still long enough to scan,
it's fair game. I just wish I had unbound copies of the Bug Books.
(BTW, I've only got Bug Book III. If anyone out there has I and II or
any of the follow-ons (if there were any), please let me know if you're
willing to part with them.)
H89 ROM listings are already online, but they are
behind a password at
http://www.sebhc.org/. Having copies freely available would benefit
more people.
Ok. It looks like the one MTR-90 listing book I've got is not loose, so
I won't be scanning that until I find one that's bound in the blue
covers that can be separated without band-sawing spine off of it.
(which I would do if I had another clean and intact copy)
I have used a nice high speed copier/scanner at work
that can spit out
tif files or ready-to-go pdf files. There is a word of caution though.
The machine is set up to have a very high quality dithering algorithm
in order to get the visually most appealing results. This is different
than the simple threshold quantifier that you get from most scanners
when you ask for B&W scans. When you zoom in close to the text, the
edges will have a feathered appearance as the copier is trying to
approximate partial pixel coverage. It looks good, but hurts
compression and doesn't do anything helpful for OCR.
You might want to grab one of the smaller TIF files and see if it'll
cause any problems. I didn't notice any dithering on the one I spot
checked yesterday, but I may have missed something.
g.
1:20 p.m.
New subject: Kaypro docs...
On Tuesday 23 May 2006 11:17 pm, Gene Buckle wrote:
I just posted both PDF and TIF scans (600dpi) of my
Kaypro Technical
Manual to the retroarchive site (http://www.retroarchive.org). I've
never seen this available before so I figured there would be some need
for it.
Do you have the schematics for the power supplies used in their machines? I
have some, three or four versions by different mfrs. if I'm remembering
right, if needed.
--
Member of the toughest, meanest, deadliest, most unrelenting -- and
ablest -- form of life in this section of space, a critter that can
be killed but can't be tamed. --Robert A. Heinlein, "The Puppet Masters"
-
Information is more dangerous than cannon to a society ruled by lies. --James
M Dakin
8:54 p.m.
New subject: Kaypro docs...
Do you have the schematics for the power supplies used in their machines? I
have some, three or four versions by different mfrs. if I'm remembering
right, if needed.
Roy, I didn't even check. I know there is a number of schematics listed
and some black & white photos of power supplies, but I haven't checked
closely.
g.
18 May
18 May
2:18 p.m.
The archive search on classiccmp.org does not appear
to be working. I
thought it was me at first but I guess the words vax and unix have
been mentioned here before ;)
Dan
I'm not so sure they'd have been mentioned here before, this list doesn't
really deal with Vacuum cleaners, or Harems.
Zane
6634
days inactive
6641
days old
34 comments
17 participants
participants (17)
-
bfranchuk＠jetnet.ab.ca -
cclist＠sydex.com -
cisin＠xenosoft.com -
frustum＠pacbell.net -
geneb＠simpits.com -
gtn＠mind-to-mind.com -
healyzh＠aracnet.com -
innfoclassics＠gmail.com -
julesrichardsonuk＠yahoo.co.uk -
jwest＠classiccmp.org -
lbickley＠bickleywest.com -
legalize＠xmission.com -
philpem＠dsl.pipex.com -
rtellason＠blazenet.net -
Tim＠Rikers.org -
trixter＠oldskool.org -
williams.dan＠gmail.com