At 10:39 AM 11/7/98 -0500, cswiger wrote:
>
>'Byte's early years were fun for hardware hackers - I wonder if
>anybody actually got their 'barcode' software publishing scheme
>to work. They had a few issues with pages of barcodes you were
>supposedly able to read in with a wand.
It's spelled "Cauzin". Back in 1996 I e-bumped into Dick Balaska
<dick_at_buckosoft.com> <
http://www.buckosoft.com/~dick/resume.html>,
one of the engineers who worked at Cauzin. Below are several
messages from earlier in 1998 about this topic, and a related
technology.
Anyone want to make a jillion dollars? Re-typing URLs is a pain.
OCR is a pain and impractical for small bits of text. Reciting
addresses is a pain. I think we need a pen- or credit-card-sized
device that can read barcodes. While I'm reading a magazine, I see
a URL I want to visit later. I scan the barcode. Later, I transmit
my pen's contents to my PC, maybe via IrDA.
It's scalable from give-away keychains to smarter devices, it's
embeddable. Make a PostScript font with the barcode. Allow one-to-
one ASCII-to-barcode, upsell software to checksum it or auto-inject
barcode text in any app's documents.
Make a modem-like variation that can emit a few hundred bytes of
info while held to the mouthpiece of a phone, as well as receive
a few hundred bytes when held to the earpiece. Presto, a way to
transmit your name and address to someone else. Sell the $100
thermal-label-printer version to corporate America.
- John
>To: classiccmp_at_u.washington.edu
>From: John Foust <jfoust_at_threedee.com>
>Subject: Re: [getting old punched cards read]
>
>Here's another twist in the archive problem, related to our previous
>discussion: <http://www.paperdisk.com/> makes software that prints
>data in a highly compressed form on paper. It looks like they're
>getting 2 to 4 megs of data per 8.5x11 page, printed with a laser
>printer, and retrievable with a scanner.
>
>If tapes and CDs aren't reliable, perhaps paper is better. (Search
>www.dejanews.com for "Dead Media Working Note paperdisk" to see a
>longer article about this.) However, I'd say that laser-printed
>output has its own archival problems related to the properties of
>toner plastic, in that it can re-melt or stick to adjacent pages,
>and that it's sensitive to vapors from out-gassing plastics
>such as those in binders.
>
>Cauzin SoftStrips for the 90s and beyond! I have some friends who once
>worked for a Wisconsin company that had a similar gizmo that worked with
>a record-player-like device.
>
>- John
>Jefferson Computer Museum <http://www.threedee.com/jcm>
>
Below is a description of the "paper floppy disk" as given by
an old friend of mine, Dennis Adams <DAdams_at_etcconnect.com>,
who once worked on this technology.
- John
The "Paper Floppy Disk"
Newslog International (aka Lab1) developed technology for recording up
to 30-50K of data on a printed piece of cardstock approximately 6" x 4".
The data was recorded with error detection and correction information
(Reed-Soloman, I believe), as well as redundant groups, so it could
withstand misprints, marks, holes, and other flaws. This was all pre-CD,
and the cost was very cheap. One of the names for them was TDB's for
Transportable Databases. They were intended for software distribution,
database updates, games on the back of cereal boxes, etc.
Each track was a
portion of a circle (about 1/10 of the circumference). The reader had a
large (approx. 14") spinning wheel, and supported variable track pitch and
data bits per inch (so different quality paper and printing processes could
be supported), and could track media that was not cut square by skewing the
tray that held the media (since there was no physical or optical "center" on
the media -- it had a virtual movable "hole" to spin on). It used a Z80
microprocessor (running extremely tweaked assembly language by Al Jewer) and
interfaced to a computer via "high-speed" RS-232 (9600 bps).
I did demo
software on a variety of hosts, including the Storm operating system
(multi-user CP/M OS by Ron Fowler, also the author of the popular MEX
communications software), Commodore 64, and IBM-PC XT. We had a Coleco Adam
computer that we briefly considered writing something for, but it never
stayed running long enough to evaluate.
We did a multi-month trial of a
large database update for a large company based in Moline. We sent out
three months of updates to a 13M database. Each update was a half-dozen or
so cards that could be scanned in any order and then the update was applied
to the database. This was run at three dealerships that could retrieve
up-to-date database information much faster than their microfiche system
which was always out-of-date. It also displayed additional textual
information that was on other microfiche or books and not usually
referenced. This was circa 1985, and was quite impressive to the people who
used it. So much so that the actual media technology took a back seat to
the database system itself (an interesting lesson to be learned there).
Newslog / Lab1 ran out of money before the technology could be completely
finished and sold or marketed. Not that they didn't try. I learned a lot
about "demos" and "demospeak" while I worked there. I still have some media
around, but alas no reader. I'm willing to bet it could be read by a modern
high-res scanner. An energetic soul could probably even write a reader
emulator that fed the bits that it peeled radially from the high-res scan
into the actual Z80 reader code to decode it.
The best anecdote I recall regarding the technology was in the "camera"
software that generated the film original used for duplication: the base
unit of measurement was derived from the bits-per-track and camera wheel
speed and other factors I've forgotten. All of the internal calculations
were based on this "tick", which varied in actual length, but was
approximately 1mS. The camera system's author was Bill Whitford, and the
unit of measurement henceforth became known as a "willisecond." Bill's code
ran on a much larger processor with a lot of memory (I think it might have
been a 4Mhz Z80 with 64K of memory), so he development in C.
Received on Mon Nov 09 1998 - 11:04:43 GMT