> Dude, I'm very interested in that stuph
Anyone who uses "dude" and "stuph" in a sentence doesn't need to have
anything other than a Linux box, preferably "modded".
Hello Everyone,
I ran across a Summagraphics MM1103 tablet. I see that there was a thread
on this list in 2004 regarding this device. Do we know the communication
protocol/format? Do we know what the 3 8-bit DIP switches inside do? Any
documentation or pointers to documentation would be appreciated.
thanks, -kurt
Hi,
These need to find new homes :-( (I have too many of them)
The 14c -- the lightest of them -- is probably shippable
(though I suspect it would cost more than *most* folks would
be willing to pay!). I suspect the 19r is too heavy for
anything but local pickup (85751). The 19c *definitely*
pushes the limit on weight (unless you just want the *base*
and not the 75# of monitor! :> ).
If no interest, I'll disembowel them so I can reverse
engineer the electronics and then pitch the resulting
"scrap" into the hazardous waste recycling service.
(I *probably* will want to tear the 19c's monitor apart
regardless as I've not been able to find any published
information on it and have a couple of others like it that
I will need to support :< )
You'll have to find your own keyboard/mouse (PS/2 keyboard
and 9 pin mouse) as I'll hold onto these for my other NCD's.
Thanks!
--don
Re:
Hmmm... I don't know how to "create a PDF from a scanner". <:-)
I typically scan documents to TIFF files. Then, open Acrobat
(not Acrobat Reader) and paste the document in along with any
added text, etc.
So, it was my understanding that Acrobat did NOT further process
the TIFF -- nor a JPEG, etc. Rather, just "held it in place
on the page"
*********
That's the hard way of doing it.
The somewhat easier and generally preferred way:
- Open Acrobat
- File / Create PDF / From Scanner
[This is from Acrobat version 6; may be different in other versions].
RE: " Why won't we just all switch to PNG"
First, it's not nearly as well supported as either TIFF or JPEG.
In my case, when I'm scanning documents, I am almost always going to save
them as PDF files rather than as [explicitly] either TIFF or JPEG [although,
internally, my PDFs created from a scanner are JPEGs]. I'm not even sure
that using an internal PNG format is easily possible.
>
>Subject: Re: PDP-8 /e/f/m memory
> From: Don <THX1138 at dakotacom.net>
> Date: Wed, 16 Aug 2006 11:41:47 -0700
> To: General Discussion: On-Topic and Off-Topic Posts <cctalk at classiccmp.org>
>
>> I thought I'd said that. Bit of work history, engineer and product
>> engineer for a semi company that sold micros and ram.
>
>Work history doesn't help list readers since they can only read
>what you've *written* (except for those few clairvoyants sitting
>in the back row...) :>
Most will not build unless supplied as a kit for $49.95.
>You neglected to note that Icc grading *between* CMOS static
>RAMs AT DC varies SUBSTANTIALLY. Power consumption at operating
>frequency isn't an issue (here). Rather, the difference between
>Icc(standby) on a "regular" 62256 (e.g.) and a "low power"
>62256.
Yes, I know. Does anyone care?
>You can buy even LARGER devices (e.g. > 1MB -- B not b)
>that will idle at *2* uA.
>
>I.e. the data retention time of a well designed BBSRAM
>circuit *is* limited to the shelf life of the battery
>powering it (during standby). *But*, only if you select
>the right grade SRAM.
At 2ua a 3V 30mAH Li cell has a life of how many years?
At 20ua a 3V 30 mAH Li cell has a life of how many months?
At 2ma using two AA alkaline cells (Duracell) in hundreds of hours?
>In my reread of your comments, I don't see *that* mentioned. :>
>(much of the 32KB devices you'll find in PC's and their ilk
>are not chosen for this very low Icc(standby) -- *especially*
>cache RAM!)
Doesnt matter! if battery life were an issue I'd have brought
it up. However I specifically metnioned in another post that
battery life or even battery backup was not an issue.
FYI: nearly all the previous commercial designs the ram array
was usually 2102s and even the LP version at DC was both heat
and power intensive. Their power drain was measured in amps
for the array (96 2102s for one board). B elieve it or not
they did provide for backup (using large SLAs).
I'd point out that I have a bag full and some are very low power
I measured several for this and got less than 1ua at 3v and room
temp, outputs floating inputs grounded CS/ and OE/ negated. You
forget guarenteed specs vs whats likely supplied as yeild is often
to the better part. That was only the CMOS cache rams pulled
>from old 486 boards of late generation (green). I have a very deep
new parts stock with a tubes of graded 62256 and other
low power rams as well as CMOS logic.
>To put things in perspective, a 1F supercap charged *nominally*
>to 5V (use care here since supercaps typically don't have much
>margin for overcharge :>) would discharge to 2V (the typical
>data retention voltage of a CMOS SRAM) in just 3000 *seconds*
>(less than an hour) with a 1mA retention current. This could
>be extended to ~30hours using 25uA devices. Using a *2*uA
>device can extend this to 2.5 weeks...
Read that as a battery would do far better.
Back in 1981 when I first got my hands on a supercap
I evaluated them against Li primary cells. I wasn't
impressed then or now. Super caps are just big (is capacity)
caps and don't really hold a lot of energy. They don't
leak or do bad things as a rechargeable storage but a 1F
super cap doesn't match a cr2016 or 2032 for total
watthours of available energy. As a result a 2032 coin
cell would perform much better than a super cap and I've
never seen one leak. They are cheap and play with the
dallas memory power management chips quite nicely.
>[have I done my math right? Sorry, I'm just doing it in
>my head so I may slip a decimal or three... :> ]
Doesn't matter. The board I'm doing is not backed up. Even if
it were it would be only short term backup as in minutes to
hours so I could ride through a power "burp". A few AA alkalines
in an external box would do that very well.
This is a PDP-8f and it weighs in at a mere 60 pounds for the CPU
box and there is a open 13"x4"x5" (60 cubic inches) cavity where
a suitable enclosed and even properly vented (external to the
CPU case) box could be placed containing a large battery and
charge circuit. Right above the PS (in it's own box) and far
enough away from the bus.
If I need power fail backup I have 20k of core! What I want is 32k
of semi to play with for large OS stuff and still leave room on the
board for an IDE interface and maybe even a 2.5" drive or CF.
Allison
>
>Subject: Re: USR quad modems... (ontopic - really!)
> From: Roger Merchberger <zmerch-cctalk at 30below.com>
> Date: Thu, 17 Aug 2006 09:15:15 -0400
> To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at classiccmp.org>
>
>OK, just kidding, but - to venture into where my brain & dynamic memory
>part understanding, the 41256 uses a particular refresh[1]
>which newer memory doesn't deal with well[2], so going *beyond* 512K is
>problematic.[3] *If* I can figure out how to get 512K of SRAM to work in a
>CoCo3, going *beyond* 512K might become a bit easier.
>
>Not to mention - going from SRAM to FRAM would be a pretty easy jump. A
>CoCo3 with a "Suspend" switch could be *neat*. ;-)
>
>Or, I might be full of condensed milk, as my father-in-law used to say.
>
>Just my random thoughts for the day...
>
>Laterz,
>Roger "Merch" Merchberger
>
>[1] 256 cycle / 8-bit counter / something like that. Did I mention that my
>brain doesn't grok DRAM well??? ;-)
>
>[2] 512/1024 cycle / 9-10 bit counter / something like that. Just in case
>you didn't catch it, I have DRAMophobia. ;-)
Dram is "refreshed" or rewritten to keep the little capacitors from discharging.
They are organized as rows and columns. The refresh process only needs a pass
through every row within so many milliseconds (varies with part)to do the trick.
Now as rams get bigger you natually have more rows and columns. But, while
they were getting bigger they were also getting more complex. Sounds bad, huh?
Well no! The complexity is in the logic to do the refresh. Parts in the late
4164 (64k) design life and later started turning up with their own internal
refresh counter and by wiggling the RAS/ or CAS/ the right way and often
enough they refresh themselves. Most of the big (41256 and larger) parts
have this as well as most of the 30pin SIMM (256k, 1m and 4m, 16m) parts.
Now for a lot more detail and great explantion see Tim Olmstead's DRAM paper
available from Gaby's site http://www.cpm.z80.de/ "The Unofficial CP/M Web
Site". Worthwhile reading for anyone mystified by Drams or phobic about them.
FYI: the paper is Z80 centric but those that know it also know it only does
128 refresh. Yet, big (megabyte) rams can be hung off it due to the newer
parts doing their own refresh thing. It all translates to other CPUs as well
including those that don't do refresh for you at all (non z80 family).
Allison
RE:
>>I scan at 300 DPI MINIMUM for everything, but I sometimes scan at 600
>>dpi if there is extremely fine detail present.
>Agreed on the DPI front. What I tend to find unacceptable though,
>even on pure textual material, are bi-level scans - too much
>information from the original is lost"
********
Agreed. I NEVER scan anything as "black and white" (each pixel is black or
white). It just does not work well, ever, even for pure text that you would
think really is "black and white". I always scan monochrome material, even
text, as "grayscale". However, 8 bit depth (256 shades of gray) is all that
you need for such monochrome material (in fact it's even more than you
need), even if the scanner supports a greater depth.
>
>Subject: Re: PDP-8 /e/f/m memory
> From: Douglas Taylor <dj.taylor at starpower.net>
> Date: Wed, 16 Aug 2006 20:24:43 -0400
> To: "General Discussion: On-Topic Posts Only" <cctech at classiccmp.org>
>
>
>Is it a bad idea to try and salvage/reuse the DC021 bus transceivers off
>the CXY08 boards that seem to be so common and useless?
>Doug
No! though testing them afterwards is advised.
Allison
>
>Subject: Re: PDP-8 /e/f/m memory
> From: Al Kossow <aek at bitsavers.org>
> Date: Wed, 16 Aug 2006 15:51:19 -0700
> To: "classiccmp at classiccmp.org" <classiccmp at classiccmp.org>
>
>
>> Firstly, this is, as I am sure you agree, not a list to provide answers
>> to members questions.
>
>Thank you for the clarification. This will save me a great deal of time in
>the future not researching answers to questions.
>
>If this list is meant to be just another wank like alt.folklore.computers,
>enjoy the noise.
;) thats funny!
What isn't funny is I'd almost missed your post. I had the memory info
I was looking for wrapped in 75 other posts from this list that morning.
That would have been terrible loss as it was the definitive answer.
Allison
