Date   : Sat, 03 Oct 2009 21:12:39 +0200
From   : rick@... (Rick Murray)
Subject: Centronics to Serial

Steven John BASS wrote:

 > He's suggested that perhaps the ACK signal needs to be handled,
 > which his setup doesn't do.

Eh!?!?

      Computer output                   Printer

1.   Set data onto D0-D7               --
2.   Asserts !STROBE for a bit         Sees !STROBE
3.   --                                Reads data from D0-D7
4.                                     Flashes !ACK in response
5.   Sees !ACK to mean data taken      --
6.   ======================= goto step 1 ======================

In other words, ACK is used to ACKnowledge data has been taken in 
response to the STROBE. It's a dead simple handshaking protocol, but 
arguably the most popular for several decades. Dead easy to implement.


> I'm wanting to capture the printer output from an old Z80 computer, that
> only has a Cenronics (parallel) port, to the serial port on my BEEB.

Would it not be better to feed into D0-D7 of the User Port, hook up 
!STROBE and !ACK to the control lines, and write a few lines of code to 
read in data on the STROBEs, write a byte to disc, pulse the ACK and 
carry on going until you press SPACE, or something?

It seems like parallel-to-serial is an unnecessary complication.


> It is so I can capture of data from an obsolete word processor, which uses
> an incompatible format.

:-) I did the exact same thing with an ancient DOS stock control system 
where the data was scrambled in the files and the author wanted some 
stupid amount of cash to unscramble the files - this being when Win95 
was starting to make inroads, DOS was dying, and nobody had a 
satisfactory answer as to whether or not the software was Y2K capable.

So I simply set it to stock management mode, and told it to print 
EVERYTHING. The A5000 the back-to-back cable was wired to stripped out 
all the EPSON control codes, extracted the data into a page-by-page 
buffer (a big string array), then spat out FoxPro-like DBF data for 
importing into the NEW stock control system, which was based around 
Visual FoxPro (when Microsoft had just acquired and Winified it, but 
before they completely buggered it up). I couldn't get TCP/IP to work 
between Win95 and the A5000, so I ran a long serial lead (based upon a 
length of twisted pair!), with some C code running on the PC to read in 
sort-of-Xmodem to save to file (I messed with the header to permit 
arbitrary sized blocks up to 16K apiece, just for this application).

So:
   Crusty old PC - printing, it thinks, to an Epson LQ of some sort.

   A5000 - accepting print data
           stripping EPSON codes
           making an 'image' of the printed form in memory
           translating that to blocks of DBF file data
           sending via Rick-X-modem
           [all done on-the-fly]

   Win95 PC - accepting Rick-X-modem data, checksumming it,
           writing it to disc


The most complex thing was getting the A5000's printer port to work 
backwards. RISC OS didn't seem to like the idea, I eventually "opened" 
the parallel device and then bit-bashed the hardware... like I should 
have done in the first place.
The second hardest thing was getting the DBFs working. Visual FoxPro 
didn't quite like the older FoxPro 2.5 format files. Took a bit of 
examination of generated files to alter ONE "unknown purpose" byte in 
the initial file header. :-)


> Does anyone fancy having a crack at this project?

I'm not volunteering, but I think directly stuffing bytes into the user 
port will be simpler than serial translations.


Best wishes,

Rick.

-- 
Rick Murray, eeePC901 & ADSL WiFI'd into it, all ETLAs!
BBC B: DNFS, 2 x 5.25" floppies, EPROM prog, Acorn TTX
E01S FileStore, A3000/A5000/RiscPC/various PCs/blahblah...