Cauzin

At 10:39 AM 11/7/98 -0500, cswiger wrote: It's spelled "Cauzin". Back in 1996 I e-bumped into Dick Balaska &lt;dick(a)buckosoft.com&gt; <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 Below is a description of the "paper floppy disk" as given by an old friend of mine, Dennis Adams &lt;DAdams(a)etcconnect.com&gt;om>, 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.