ancestry
> I think the IWII has the engine for another printer in it but I can't
> remember whose. I keep dredging up Okidata and Canon, but I think those
> are wrong. Citizen?
I think the Imagewriter 1 was just a rebadged C. Itoh 8510. One of the
C.Itoh models supported a 4 color ribbon. and this carried over to the
IW2.
The ancestry of the IBM Color printer goes back to the IDS 480 which
was such a nice printer that Dataproducts bought the company in the
very early 80s.
I believe its design became the basis for the long running
Dataproducts 8050/8070 series of dot matrix printers offering color
ribbons.
I think the IBM Color Printer was made by Dataproducts with different
plastic and branding.
Paxton Hoag
Astoria, OR
USA
> Date: Mon, 22 Oct 2007 23:26:06 +0100 (BST)
> From: ard at p850ug1.demon.co.uk (Tony Duell)
>> The 5182 is a dot matrix printer with a four color ribbon. Kludge on a
>> stick.
>
> Thet idea was not uncommn at the time. DEC made one called the 'LA324'
> which could take a colour ribbon and mechanically shifted it up and down
> to change colour. I also rememebr using an Epson printer in the mid 1980s
> that could take a 'colour kit' which was a motor + mechanical bits to
> tilt the ribbon.
>
> How well it worked I don't know. I've never been able to find a colour
> ribbon for my LA324.
The Apple Imagewriter II can use a color ribbon and the color ribbons are
still fairly available. I have a few boxes sealed up in plastic bags...
However, Apple never wrote a viable color driver for the Mac OS. One
could print the 8 basic Quickdraw (not Color Quickdraw) colors, for
example, by coloring cells in Excel and printing the spreadsheet, but
anything complex was out.
A company called Microspot wrote MacPalette II for the Mac which dithered
the colors on the ribbon to provide 24 bit color printing.
Keep in mind that the IWII is a 72 or 144 dpi dot matrix printer. The
images produced by MacPalette are pretty amazing given the underlying
printer. It really does get the colors nicely mixed. The image quality
is poor because of the poor resolution, but it's a bit like the dancing
bear. The wonder isn't that she dances so well, it's that she dances at
all.
I always get really poor text quality with MacPalette II though, so if
anyone else is using it and knows what I'm doing wrong, let me know.
IIRC, MacPalette II only prints in Tall Adjusted, so many the poor text is
just an artifact of that, or maybe one is meant to use different fonts.
I think the IWII has the engine for another printer in it but I can't
remember whose. I keep dredging up Okidata and Canon, but I think those
are wrong. Citizen?
Jeff Walther
> Date: Tue, 23 Oct 2007 11:20:22 +1300
> From: "Ethan Dicks" <ethan.dicks at gmail.com>
> On 10/23/07, Jules Richardson <julesrichardsonuk at yahoo.co.uk> wrote:
>> Hmm, I thought all modern machines emulate a parallel port connected via
>> an ISA bus
>
> Macs have never had parallel printer ports, not even the new Intel Mac
> Pros.
Au contraire. Okay, actually, it's a nitpick. During the cloning
heyday, there was a family of clones which had a parallel port. I think
it was the model from Motorola (Starmax?), but my memory is hazy. Of
course, that was back in the 90s.
Jeff Walther
Richard wrote:
> Sridhar Ayengar writes:
>
>> My compile on the VAXstation 2000 was at least a few days. Maybe a week.
>
> Are we talking *just* the kernel here, or are we talking compiling a
> full distribution (all the utility programs, shell programs, X server,
> X clients, etc.).
>
> I have a really hard time believing it takes a few days *just* to
> compile the kernel. Toss in the huge pile of additional programs
> accessible from the shell or the X Window System and now we're talking
> believable.
Well, in the (my) case of the SE/30 taking two days to compile a NetBSD 1.5
kernel, it definitely was just the kernel. Other stuff would have come later.
Granted, it may have been less than 48 hours, like starting early one evening
and ending late the next morning, but in my memory it was two days until it
upped and died when nearly done. I also suspect it might have been (a lot)
faster had the machine been equipped with the full 128 MB RAM at the time,
instead of just a paltry 20 MB. Might have saved the (500 MB) drive, too. :-)
In any case, it was done just for shits and giggles, and if anything it did
inspire a whole new level of appreciation for the art of cross-compilation.
,xtG
tsooJ
On 10/24/07, Zane H. Healy <healyzh at aracnet.com> wrote:
> I know there was some interest in 1541-III PCB's recently. Vincent
> Slyngstad and I have been discussing this since that time, and he has
> done up schematic in Eagle CAD and has the initial board layout done
> (actually three different versions using different SD Sockets).
Nice.
> The big difference between this and the original design is that it uses
> through the hole parts wherever possible rather than surface mount
> parts.
I would build one or two, regardless.
> I'm trying to find out if anyone here will be interested in boards.
Yes. One or two bare boards, depending on price (or if they are
really cheap, perhaps 3).
> I have a design question or two for anyone that is interested.
> Additionally, I'm looking for anyone familiar with SD Sockets, as
> neither Vince nor I are, and a couple questions have come up on the
> socket placement.
Sorry... I have minimal experience with SD sockets.
-ethan
Joost writes
> Unlike Indigo2, however, a different class CPU on an O2 means a
> different motherboard.
Other way around - Indigo2 had different mainboards for the different
processors (IP22 for R4k, IP26 for R8k, IP28 for R10k), whereas O2 had
a single mainboard (IP32) for all processors. The R10k/12k processors
did have different mounting hardware, though (the R10k/12k module takes
up one of the drive bays).
The Indy's main limitation today is memory. It does not support SIMMS
over 32MB, so it can have only 256MB RAM installed. A smaller
limitation is the internal FAST-10/narrow SCSI interface (O2/Octane
have Ultra/Wide). Still useable, though, and has the most gonzo startup
tune I've heard anywhere (I have never heard of degrees of gonzo before
this, though...) Definitely get 256MB RAM, 24-bit graphics, and IRIX
6.5.22 with the unused bits (especially ESP) chkconfig'd off (or 6.2
works well, too, but fewer software packages available). I wouldn't
advise Indigo for a first system, they're a bit more tempermental and
require the proprietary keyboard (try a few different PS/2 kbds in your
Indy or above, though, as some don't work quite right).
Octane came slightly after O200/O2000/Onyx2, the first release of IRIX
6.4 doesn't support Octane. The difference was only a couple of months,
though. If anyone offers you an Octane, take it. O2s have the
advantage of being small and quiet, but they don't seem to be as
durable or as fast. It's getting to the point where Octanes with Vpro
graphics are hitting the freebie bins (I'd like to find one...), and
Octane supports faster CPUs, more memory, and faster graphics. The
downside is (most likely) no PCI (the add-in PCI boxes are about $300
even now), but there are few drivers for O2 PCI (O2 doesn't support GbE
cards, and I think there might be an issue with FC/SAS but I'm not sure
there). That said I have a PI 4D/25, Indigo R3k/R4k Indy R5k, Indigo2
R4k, Indigo2 IMPACT R10k and an Octane 2x250/SSE (mostly running
different versions of IRIX, the only double I have is 6.5 with the
I2/R10k running 6.5.22 and the Octane running 6.5.30- the other beasts
run 3.3.2, 4.0.5F, 5.3 and 6.2 (with one unused, I'm considering 5.1.1
there). They're all useable, but do bog down a bit with things like
Firefox and OpenOffice. I do work on most of them, though (although the
4D/25 with 3.3.2 is mostly a "novelty" system - I haven't been able to
find much of anything that runs under NeWS/4Sight).
> Yep, went through that at the museum because some people were advocating
> putting media on the archive shelves - but it's not an idea I'm a fan off; the
> stuff's just too prone to damage and decay.
Unless you recover the data, what you have is a physical artifact of a magnetic
storage medium. There is absolutely no way to say what, in fact, is even on it
until you read it. Bits aren't preserved if they exist on only one physical medium,
which you may not be able to recover in the future.
>
>Subject: Re: kernel compile times
> From: "Ethan Dicks" <ethan.dicks at gmail.com>
> Date: Wed, 24 Oct 2007 15:19:15 +1300
> To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at classiccmp.org>
>
>On 10/24/07, Sridhar Ayengar <ploopster at gmail.com> wrote:
>> >> My compile on the VAXstation 2000 was at least a few days. Maybe a week.
>>
>> ...it was swapping like crazy during the compile, and
>> swapping to the same disk where the sources were stored. That machine
>> is S*L*O*W. It would have probably gone a whole lot faster if it had
>> enough RAM.
>
>Oh, yeah. The CPU is nominally as fast as a MicroVAX II (and over 50%
>faster than an 11/750), but if you were swapping, that'd be a *huge*
>difference in compile times. I was doing this on an 8MB 11/750 with
>nothing else going on (or on a 5MB 11/730 in a similar state), which
>is, BTW, fully loaded, thus the difference.
Actually since there is no Qbus the basic VS2000 CPU is generally faster.
However.. It lacks the external hardware support for fast IO for mass
storage and any bulk transfers. It also has a few implmentation items
that actually slow it for IO.
>
>I haven't had the pleasure to use a fully-loaded VS2000 - mine are
>around 6MB - enough to boot and run, but not a lot of empty RAM
>sitting around.
I have three one each 6, 8mb and 12mb. I use the 6mb as hot spare
and for formatting disks as the differnce from 6 to 8mb is fairly
noticeable even with V5.44.
>I think a VS2000 disk vastly underperforms compared to an RA81 on a
>UDA50, so the swapping makes it much, much worse.
No question. MFM disks have less than half the serial data rate and
the RA/UDA has a lot more smarts to make it happen (Buffers, LRU cache,
silos). The 9224 HDC is fairly dumb it's basicically a 765 +similar
HDC with DMA chip built in. On the VS2000 the DMA only goes to a
16k segment (hardware implementation limitation) so to get data
elsewhere the CPU or another DMA chip moves data again from the
buffer area to wherever. So in the end The VS2000 disk system
is slower than most PCs running the WD1003 with the same RD54.
A small insight as to why a MVII with the same chip is generally
faster.
Allison
Got a good price tonight for the Days Inn / Stanford U., just a couple
of miles up the road from Mountain View and the CHM. $81 per night,
in-room Ethernet and snacks, all included with the price. Can't beat
that.
