Actually, it depends. One some classics, the handshaking was essentially hadnled in hardware. Write a data value to the port, and it generates a corerectly tiped sstrope. It also maes a busy signal somehow available to the host processor whcih is cleared when the hardware gets the approrate acknowledge signal from the printer. I doubt that could easily be used as a data input. The otehr odd one is the original Apple ][ parallel card. The status line Basically, it runs differnt code depending on whether the printer is ready. I supect you could do data inptu with that one byu watching one of the locations in ROM which cotnains a differnt value depending o nthe state of that address input. Sure. But a lot of classic printer prots, even if the handshake is doen in software have jsut the 7 or 8 data lines, a strobe output and a busy input. Snly one input. You could bit-back serial data over that line, I guess. I got the impression the OP didn't want to write mcuh software like that. Perhaps that's incorrect. Anyway, having a clearer idea of what the OP wants to do and what he is prepared to do (making cables, making more complex hardware, writing software, etc) would be useful. -tony

----- Original Message ----- <snip> I just want to run virgin (unhacked) software I am looking at buying a group of parallel to ethernet adapters and a group of serial to ethernet adapters like the UDS10

On Sat, Oct 27, 2012 at 5:20 PM, Tom Sparks <tom_a_sparks at yahoo.com.au> wrote: Many years ago, I tried to hack a driver for the Xircom (parallel port) pocket ethernet adapters for AmigaDOS. I got as far as negotiations with folks within Xircom about getting information on how the devices talked to the PC parallel ports when they decided that they didn't want to "be in the market of supporting other platforms". I do know that they are not trivial to talk to, but perhaps there's now a Linux or BSD driver that could be inspected to divine out enough secrets to make an Amiga driver. I will say that it will never be fast. An 8MHz 68000 would have a hard time moving more than 200kb/sec peak without a DMA engine. There is native Amiga-to-Amiga parallel port networking available, but it's point-to-point (there never were cards for the Amiga for more parallel ports*, so it's one per machine) and AFAIK, nobody ever ported that code to a non-Amiga OS, so it doesn't help you connect up to a larger network. There were SCSI-to-Ethernet adapters that were somewhat popular in the older Mac era, but I don't remember anyone even attempting to use them on another platform. They would be difficult to find now, I'd expect. I would be "easy" to start with something like the same kinds of chips used by a couple different Commodore64 Ethernet adapters - the TCP/IP end of things is all handled by the chip (CS8900?) and the host just moves assembled packets to/from the chip via a simple interface. You'd still have to come up with driver support for each classic platform you wanted to support, but that's the same no matter where you go. -ethan * you could add a *printer* port, not a generic Amiga-compatible parallel port, to an Amiga by using a standard PC ISA card and a GG2 Bus+, but in practice, what folks did was to use those to talk to their printer and the Amiga native port to talk to digitizing devices (sound, Digiview, etc) because those expected to communicate with the 8520 CIA register set not an ISA card. OTOH, if you already have a GG2 Bus+, you can use a simple 10MBps ISA networking card and write no software whatsoever. A solution for an A2000, but not an A500 (you need a box with ISA and Zorro slots to mount the GG2 Bus+. There was never enough of a market to adapt the design to a slap-on-the-side version for the A500/A600. Technology wasn't the issue - it would work. It was just never financially feasible to design and build the product). -ethan

The wizchip toys are better...all the TCP/IP stack is inside the chip, so you can offload the main processor. --- Enviado do meu Motorola PT550 Meu site: http://www.tabalabs.com.br ----- Original Message ----- From: "Dave McGuire" <mcguire at neurotica.com> To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at classiccmp.org> Sent: Monday, October 29, 2012 4:40 PM Subject: Re: networking classic hardware

On Mon, 29 Oct 2012 15:07:49 -0400 Dave McGuire <mcguire at neurotica.com> wrote: [WIZnet Ethernet chip, that does TCP/IP in "hardware"] They have a "raw" packet mode where you can send raw packets at the IP or MAC level at your choice. There are several break out / eval boards out there with a WIZnet chip, magnetics, ... You can interface them via ISP or a 8 bit MCU bus interface. Should be trivial to add them e.g. to a C64 expansion port with minimal glue logic. -- \end{Jochen} \ref{http://www.unixag-kl.fh-kl.de/~jkunz/}

Get the newer, red ones. Now you can use SPI! --- Enviado do meu Motorola PT550 Meu site: http://www.tabalabs.com.br ----- Original Message ----- From: "Dave McGuire" <mcguire at neurotica.com> To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at classiccmp.org> Sent: Monday, October 29, 2012 7:18 PM Subject: Re: networking classic hardware

What is CUPS? As I undertand it, then, you want ot have paralle input ports on the linux box. I can think of several ways to do this, one of which probably only really applies ot my linux machine.. That one invloves making special hardware to plug into an expansion slot in said linux box, it's only going ot be easy o na machine with ISA slots, and I suspect mine is one of the last such machines running. Getting over that, I wonder if you could use bidirectional printer ports on the linux box as simple input ports, given the right programming. I would have to check the specifications. Anotehr approach would be to use serial (RS232) ports on the linux box (or USB-serial converters if you ony have Useless Serial Botch ports). I don;t know how easy it is to configure the classics you mention to use serial printers, if so, then the hardware is easy. If not, then paralell to serial converters exist, or can easily be made So each classic machine is only outputting data, right? -tony

On Sat, 27 Oct 2012, Tom Sparks wrote: Ok, having re-read the entire thread, I have a better idea of what you are after. For printing, I used a multi-port parallel autoswitch with its inputs connected to the different computers I wanted to print from. It's output was connected to a parallel to serial adapter that I had connected to a Linux machine which ran lpd. The Linux machine could queue anything I wanted to print and send it out to the printers I had on my network. This worked pretty well, but it took awhile to get all the settings correct. The only downside was that I had to manually change which printer I wanted to print to via the Linux system. In thinking about it now, I guess I could have used a manual switchbox connected between the parallel to serial adapter and multiple serial ports on the Linux system to select different printers, but I didn't think of that at the time. As for serial connections, if you just wanted to use the machines as terminals, a basic terminal server would do the job, but since you also want to be able to transfer files, you'd need something more flexible. I'd probably recommend using a multi-port serial adapter (Boca, Stallion, Cyclades, Digi, etc) with the Linux machine. Standalone serial device servers such as the Lantronix UDS10 probably aren't going to do what you want (or at least not easily) if you want to transfer files and data between the classic system and the Linux computer. For inbound telnet connections /to/ a system, devices such as the UDS10 can work pretty well though.

On Sat, 27 Oct 2012, Tom Sparks wrote: IMO, you are getting way ahead of yourself. AFAIK, the Lantronix UDS10 doesn't support PoE anyway. In fact, I don't think /any/ of their older (read: halfway affordable) devices support PoE. As far as KVM over IP goes, that's a whole 'nother ball of wax... Software for many classic machines may not have support for Zmodem since it was one of the later protocols. Some may support protocols such as Xmodem or Kermit, but may or may not support proper CRC checking. On the Linux machine, lrzsz and ckermit will support these. Good luck. Unless you have a support contract, Lantronix is highly unlikely to add a feature to unsupported / "legacy" devices. They are trying to target wireless stuff these days. Keep in mind that Lantronix also only provides Windows drivers for port redirection with their serial devices. Again, for inbound connections, something like the UDS10 can work well, but for outbound, you'll probably be rather disappointed. Based on my own experience I'd recommend using parallel where you can for sending print jobs out to the Linux machine and save serial for outgoing connections from and data transfers to/from the classic hardware. If you need to remotely locate your printers, have the Linux machine talk to print server devices near your printers. If the Linux machine is close to the printers and you don't have very many printers, skip the ethernet print servers entirely and save yourself the trouble and headaches they absolutely /will/ cause.

On Sun, 28 Oct 2012, Tom Sparks wrote: With most classic hardware, you are probably going to have to handle printing and transferring files separately, at least to keep things simple and halfway manageable (and affordable on a hobbyist's budget). The UDS1100 isn't really the same animal as the UDS10. You'll also find the newer models tend to go for a whole lot more on the surplus market because people in the controls and automation industry currently use them and they need to be able to obtain support from the manufacturer. There are some serious drawbacks to PoE that a lot of people don't realize until they've deployed it at least once or twice. In general, PoE switches are much more expensive (even used/surplus). They have to be physically larger for the extra real estate required for the extra electronics and power supply circuitry. With all the extra electronics, those switches run a lot hotter and they tend to have lots of small, noisy (high rpm) cooling fans. You will also likely find that a PoE switch will actually use /more/ electricity than a small number of switch mode power supplies because those PoE capable switches are generally designed to supply up to about 12-15 watts per port on 12 ports (and generally about 6-7 watts per port if you are using 24 ports). For a small number of centrally located devices, PoE has some serious disadvantages over a small number of switch-mode wall-wart type power supplies. On the other hand, if you have a lot of devices such as WiFi access points, VoIP network connected phones, or network connected security cameras that are spread out over a large area where there may not always be an easy way to power them directly, PoE can have some real advantages. For this particular application though, PoE isn't something I would personally recommend. I'm not aware of a KVM solution for classic hardware, but with more modern hardware, IP solutions tend to be expensive and complex. I have several that I'm currently using, and even though I can find a lot of the individual devices/components on the surplus market, they have not been cheap or easy to get working. A major drawback to these systems is that virtually all actually encode the VGA signal in real time and stream it as a video to the client software. Because of this, you can't cut and paste text between the remote and local host when you are using one of these systems. The video encoding also introduces noise and artifacts into the video, which makes these systems incredibly annoying to use if you have to use one for long periods of time. The video streaming also means that pretty much all of these devices are limited to more modern web browsers. The less expensive devices ($500-$1000) tend use ActiveX so they only work with Microsoft's Internet Explorer. Some are even so poorly designed that they only work with IE6. Since last year, a few have begun to support Java 6, but those don't yet support Java 7, which is what Oracle is pushing now that they've bought Sun and have depreciated Java 6 (and plan to discontinue it next year). Mozilla is even currently trying to scare people away from Java 6 and towards Java 7 with via the Firefox plugin status/update stuff. Put simply, KVM over IP is a pain in the butt to support, and unless you need it for remote servers where you only need it for occasional maintenance, you are better off avoiding it. I'm not so sure about that. Even cable TV boxes and smart phones are running Linux these days. Fun fact: Many of Lantronix's own serial devices have used Linux under the hood (and they haven't always been particularly good about releasing the source code per the terms of the GPL license). Did any have source code available or support their older devices? Maybe even tackle each of these one at a time? Are your printers located near each other? Even if you go with network connected print server devices, multi-port parallel port print servers tend to resell for considerably less on the surplus market than those designed for single printers. There are even some that have both parallel and serial outputs (I use a few of these myself). If the printers are located near the Linux machine that you are going to use as a print server, it is still far easier to just install one or more parallel and/or serial I/O cards and connect the printers to that though. PS, your email client seems to seriously mangle quoting and manually fixing it is quite tedious.

Can;'t you just tell me what it is? I do not understnad what you are trying to do. What do you mean by a 'print request'? Can you explain jsut what is connected to what, using what interfaces. You start out by saying you want to only transfer data from the classic to the linux box, which to me implies output only on the classic, input only on the linux bos. Then you want to run web browsers, termianl emulators ,etc. That implies bidirectional data transfer. Now what _exactly_ are you tryign to do? -tony

----- Original Message ----- CUPS is unix/linux printer server with spooling and rule based translation of print jobs I using print request as the first step before it becomes a print job print request -> print job -> spool/queue -> output parallel port -> ethernet -> linux box -> ethernet -> printer server -> printer serial port -> ethernet -> linux box on one side I want to make all my printer available to all my computers on the other side I want to be able to let my computers access a hand full of dial-up online services recreate on the linux box