How can I let an AVR simulate a (LPTx) printer and receive the (ASCII) data (the OS needs ready acknowledge?)
Surely it latches on _STROBE and then just assert ACK ? The PC parallel is VERY simple! (until you get into ECP/EPP anyway)
I have to turn it around. The LPT give ack signal (?) and then the printer (AVR) a busy signal when reading the data, the LPT give a strobepulse every bit?
Sounds like an LCD protocol.
Can only find this info, yes indeed looks simple.
Get information from the web on the operation of the PC parallel port and printer interfacing.
In its most elementary form, the LPTx port uses 7 output lines (bits) for data and four or so lines for status. The original parallel port received one bit logic signals for transmitting information to the PC. One bit active for 'out of paper', one bit active for 'ready to receive next character', etc... Check web documentation for more precise details.
The AVR needs to reproduce these signals to make the PC believe that there is an old-style 'line printer' (LPT) attached to it.
I assume that you are running an older PC program that has a printing function in its program flow and the newer PC that it is being run on doesn't have a parallel port; or there isn't an older printer available that has a parallel or Centronix interface.
This is why I demand programmers supply me with source code when I buy software. Not so that I can 'steal' their code by copying their algorithms, but so that I can still use the program in the next generation of peripheral interfaces. Of course, the programmers never honor my request for source. So I'm always left four or five years later with perfectly good function code that is useless because it has no ability to connect to new peripherals with different interfaces. GPIB, MPU-401, VESA, ISA, ... the endless parade of useless expensive turkeys led by a cadre of arrogant myopic programmers...
If the AVR is pretending to be the printer then it should latch the 8 data lines when it sees _STROBE go low then it should assert _ACK back to the PC (that's an input to the PC). Notice the directions of the arrows in your graphic. That shows which are PC outputs/printer inputs (D0..7, _STROBE) and which are printer outpus/PC inputs (_ACK, _PAPER etc.)
What I'm trying to accomplish is either controlling the pins of a USB to parallel cable or using the print commando and simulate a printer and then do something like: C:\print project.hex (or project.eep, or via a batch file.)
The AVR must generate the ISP signals after (via databuffer in SRAM of direct feed through)
I want to try to use my old LPT programmer and DOS programming software (SP12) on a netbook (has only USB).
I can print (sharing printer first) via the cable with: net use lpt1: \\servername\printername /persistent:yes
And there seems no software around which can control the cable LPT pins. (have no idea what the command print is using (inpout32.dll?), because it looks like it must be possible because the print commando can control the pins.) I cannot find any driver also.
And giveio.sys does not work either, needs a real LPT port.
Sounds like the hard way to solve the problem. Is there not a way to use a usb->serial cable and toggle the control lines? Less hoops to jump through or simply implement a STK500 style serial to isp using an AVR.
$20 to Smiley will get you a USB Thingie with something like 12 or 14 I/O pins and power.
"I wish I were dumber so I could be more certain about my opinions. It looks fun." -- Scott Adams
Why not just make:
It's a USB-ISP programmer about as cheap as you can make it. You can use the par-port programmer on the original PC to program the code into mega48 to get you going.
© 2022 Microchip Technology Inc.