The Museum of HP Calculators

HP Forum Archive 20

[ Return to Index | Top of Index ]

Update of ILPer, the HP-IL peripheral simulator
Message #1 Posted by Christoph Giesselink on 28 June 2011, 3:51 p.m.

I just updated ILPer, the HP-IL peripheral simulator program created by Jean-Francois Garnier. ILPer was developed as printer and mass storage simulation in connection with the PIL-Box hardware and real calculators like the HP-41 and the HP-71B with the HP-IL interface module. The disadvantage of this solution was, that you only could connect one ILPer instance on the PC side of the PIL-Box. The new version of ILPer now has also an interface to link more than one peripheral simulation together. I called the new connection method "Virtual HP-IL". The programs and a description of the used technique for the transport layer can be found on my HP page at http://hp.giesselink.com under "Virtual HP-IL".

Of course the new version 1.4 of ILPer is fully backwards compatible to his latest version 1.35.3. So it still could be connected with the PIL-Box as standalone system. In this case you only have the advantage of the minor improvements like the new *.lif file filter, remembering the display position, the possibility of the automatic activation of the "Start" button after program start, new settings saving method, ...

I especially want to thank Mike for his suggestions and his assistance by reading the additional manuals of the published material.

Regards

Christoph

      
Re: Update of ILPer, the HP-IL peripheral simulator
Message #2 Posted by John Robinson on 28 June 2011, 9:32 p.m.,
in response to message #1 by Christoph Giesselink

Thanks Christoph, that's great !!. Is the source still Visual Basic, or has it migrated now ?

Also, where will future updates come from ? Jean-Francois Garnier or yourself ??

Thanks John

            
Re: Update of ILPer, the HP-IL peripheral simulator
Message #3 Posted by Christoph Giesselink on 29 June 2011, 2:58 p.m.,
in response to message #2 by John Robinson

All programs are written in Visual C++ (sources included). The latest Visual Basic version of ILPer was v1.35. I migrated the ILPer sources in fall/winter 2009-2010 to Visual C++ to fix some issues I recognized during my work with the PIL-Box. The versions 1.35.1 to 1.35.3 published over JFG web page were already versions which base on the migrated Visual C++ sources. Because I done the migration before, it was no problem for me to add the new TCP/IP (IPv4) interface.

For those who already had a closer look to the sources, you will recognized that they are already prepared for the IPv4/IPv6 (dual stack) protocol. To activate the IPv6 stack I need to use a newer compiler version, which has the disadvantage of installing an additional runtime package by the user and the build EXE file will not run on older Win OS revisions like Win98 or Win2K depending on the used compiler.

I'm in contact with Jean-Francois and he told me that he's very busy a the moment. So I decided to publish the update and the additions by my own for some reasons. But be sure that further updates of ILPer will base on now published v1.4 version, either published by JFG or by me.

Regards

Christoph

                  
Re: Update of ILPer, the HP-IL peripheral simulator
Message #4 Posted by Mike (Stgt) on 30 June 2011, 7:07 a.m.,
in response to message #3 by Christoph Giesselink

Well, I am a 'big iron' dinosaur (VM/CMS) and as such a big devotee of everything virtual. So my daydream would be an emulated HP-41 as controller. By virtual HP-IL I could use the Hercules System/370, ESA/390, and z/Architecture Emulator with extend NutEm to do so (yes, I have an simulation of the Nut CPU (HP41 and Voyagers) written in FORTRAN). Alas there are several hurdles to overcome - it will stay a daydream.

Using Open Object Rexx (an extension of REXX I know from the host - and preventing to use C) I wrote a sniffer for the virtual HP-IL. From this starting point I try to do a simulation of a device. Hopefully ready some day.

A big thank you to Christoph for bringing virutal HP-IL to life.

Ciao.....Mike

                        
Re: Update of ILPer, the HP-IL peripheral simulator
Message #5 Posted by Egan Ford on 30 June 2011, 10:52 p.m.,
in response to message #4 by Mike (Stgt)

Quote:
So my daydream would be an emulated HP-41 as controller.
Doesn't EMU41 already do this?
                              
Re: Update of ILPer, the HP-IL peripheral simulator
Message #6 Posted by Mike (Stgt) on 4 July 2011, 8:35 a.m.,
in response to message #5 by Egan Ford

Yes, JFG's EMU41 does it, of cause. Alas, only in conjunction with the PIL-Box - if I got it right. I'd like a 'virtual only' set up.

Ciao.....Mike

                                    
Re: Update of ILPer, the HP-IL peripheral simulator
Message #7 Posted by Marcus von Cube, Germany on 4 July 2011, 10:13 a.m.,
in response to message #6 by Mike (Stgt)

The problem with DOS and networking is that:

1/ DOS has a severe memory limit
, 2/ There is no standard TCP/IP stack available
, 3/ Finding a DOS network driver might be tricky.

Each stack (FTP software, IBM, Microsoft) comes with its own set of libraries which must be linked into the program. I don't know the memory requirements of EMU41 or EMU71 but TCP/IP is taking its share, too, so that 1/ might be a real constraint.

Marcus

                                          
Re: Update of ILPer, the HP-IL peripheral simulator
Message #8 Posted by Mike (Stgt) on 4 July 2011, 10:33 a.m.,
in response to message #7 by Marcus von Cube, Germany

Well, ooRexx gives me access to TCP/IP and looks for me as a TCP/IP-novice good enough. And it runs in a DOS window - yes - _window_, so besides the HP200LX I have no pure DOS machine any more. If you run EMU41 on a Windooze-PC, are all of the constrains you mention still true?

Ciao.....Mike

                                                
Re: Update of ILPer, the HP-IL peripheral simulator
Message #9 Posted by Marcus von Cube, Germany on 4 July 2011, 10:51 a.m.,
in response to message #8 by Mike (Stgt)

I'm not a DOS on Windows specialist but it's not unlikely that the emulated DOS environment also emulates the MS TCP/IP stack for 16 bit programs.

Are you sure that ooRexx is a DOS program and not a Windows command line (CLI) application? There is a huge difference between the two environments! Coming from OS/2, I know (and like) Rexx pretty well. I cannot imagine that it can be run on top of plain DOS. Long filename support and the presence of DLLs in the installation directory of ooRexx would speak for a native Windows CLI application.

                                                      
Re: Update of ILPer, the HP-IL peripheral simulator
Message #10 Posted by Massimo Gnerucci (Italy) on 4 July 2011, 3:49 p.m.,
in response to message #9 by Marcus von Cube, Germany

Quote:
Coming from OS/2, I know (and like) Rexx pretty well. I cannot imagine that it can be run on top of plain DOS.

I used Rexx on MS and PC-DOS well before OS/2: it could be done.
I should still have the floppies somewhere...

Greetings,
Massimo

                                                      
Re: Update of ILPer, the HP-IL peripheral simulator
Message #11 Posted by Mike (Stgt) on 5 July 2011, 5:30 a.m.,
in response to message #9 by Marcus von Cube, Germany

You are right, ooREXX is not a DOS program, there are AIX, Linux, and Windows installations. I once had two REXX for DOS, one came with PC-DOS V7 (IIRC), the other was BRexx from Vasilis Vlachoudis of the Cern Laboratory.

And TCP/IP on DOS? Well, I mentioned before that I am _not_ the connoisseur of TCP/IP, but I used an eMail system on a HP200LX connected to a modem or via IRda to a mobile phone. It based on WWW/LX what is freeware today. I assume that this program installed some TCP/IP capability to this 2nd to none DOS machine. So for sure you do not need Windows or similar to access the Internet.

Ciao.....Mike

                                                            
Re: Update of ILPer, the HP-IL peripheral simulator
Message #12 Posted by Marcus von Cube, Germany on 5 July 2011, 9:50 a.m.,
in response to message #11 by Mike (Stgt)

My first TCP/IP experiences were on DOS, too: "FTP Software" with a NE2000 network card (with packet driver) and coax cabling. We were juggling with all the possible high memory tricks available at the time to cram everything we needed into the machines.

With virtual DOS environments (e. g. on Windows or OS/2) things become easier because the network software interface can be reduced to a thin compatibility layer which maps the calls to the host operating system. You still need the proper libraries because there is no standard API. DOS lacks dynamic libraries to hide the implementation and DOS itself has no network API either.

                                          
Re: Update of ILPer, the HP-IL peripheral simulator
Message #13 Posted by Christoph Giesselink on 4 July 2011, 4:05 p.m.,
in response to message #7 by Marcus von Cube, Germany

Hello,

the DOS operating system has no TCP/IP support. There have been (quite expensive) 3rd party products implementing a TCP/IP stack for pure DOS programs years ago.

AFAIK Windows 3.x was the first MS OS containing an API for the Win integrated TCP/IP stack. So you have to write a "Windows" program to use the TCP/IP stack.

Furthermore on modern servers the NetBIOS and WINS services are more and more disabled, without them you loose the connection to other PC's over the network.

I fully agree with Marcus that the available DOS memory is also an important aspect. On a real DOS machine the network card drivers need alone ~100KB-150KB, not counted the additional memory inside the application (emu41).

IMHO one possible solution for Windows would be using a Null-Modem emulator (like com0com) and a special bridge software (similar to ILPilbox) translating the serial data from the emu41 COM port to the virtual HP-IL loop.

Of course it also should be possible to use two PIL-Boxes. With Emu41 and one PIL-Box you have the emulated 41 in real HP-IL world and then connected with a 2nd PIL-Box and the program ILPilbox you have connection to the virtual HP-IL interface. ;-)

Christoph

                                                
Re: Update of ILPer, the HP-IL peripheral simulator
Message #14 Posted by Mike (Stgt) on 5 July 2011, 6:40 a.m.,
in response to message #13 by Christoph Giesselink

Your last suggestion does not comply with my 'all virtual' stipulation. <G>

Ciao.....Mike

BTW, recently I had some achievements by recoding a 'state machine' according 'HP82166A HP-IL Interface Spec.', now I need to link the device with 'internal messages'. Work in progress.

                                    
Re: Update of ILPer, the HP-IL peripheral simulator
Message #15 Posted by Egan Ford on 4 July 2011, 3:55 p.m.,
in response to message #6 by Mike (Stgt)

Quote:
I'd like a 'virtual only' set up.
There are patches for nonpareil for exactly that. E.g., I have virtual mass storage, 80 and 40 column video, and printer.

It's been two years since I played with this, but it should still work.

Patch: http://kdntl.pagesperso-orange.fr/hp41/nonpareil-patch-doc.html

My 2009 PPT with a few screen shots: http://sense.net/~egan/HHC%202009%20HPIL.pdf

I tested this primarily with OS/X and Linux, however I was able to get it to build and work with Windows/Cygwin.

I should have added that EMU41 already emulates HP-IL with devices without a PIL-Box. I guess I may not really understand exactly what you want to accomplish.

Edited: 4 July 2011, 4:00 p.m.

                                          
Re: Update of ILPer, the HP-IL peripheral simulator
Message #16 Posted by Christoph Giesselink on 4 July 2011, 4:34 p.m.,
in response to message #15 by Egan Ford

Quote:

There are patches for nonpareil for exactly that. E.g., I have virtual mass storage, 80 and 40 column video, and printer.

Sorry I don't understand the "tcp" option in the modified Nonpareil version. From my reading understanding you can't create a loop?

It seem for me that one Nonpareil instance can work as server, another instance as client and so they can exchange data.

The "Virtual HP-IL" is a real loop, so the server port must always be different to the client port.

Christoph

                                                
Re: Update of ILPer, the HP-IL peripheral simulator
Message #17 Posted by Egan Ford on 4 July 2011, 6:57 p.m.,
in response to message #16 by Christoph Giesselink

Quote:
From my reading understanding you can't create a loop?
Sure you can. You can start nonpareil with a virtual printer, serial port and storage all on a virtual loop. You can print, save/restore, etc... All communication is HP-IL.

The tcp option allows you to create other virtual devices without having to patch them into nonpareil. HP-IL frames are wrapped with TCP frames. At this time no virtual HP-IL devices have been created.

Khanh-Dang had planned on creating a dedicated virtual loop for use with standalone virtual devices, but he never got around to it.

All the code is there, someone just needs to run with it.

                                                      
Re: Update of ILPer, the HP-IL peripheral simulator
Message #18 Posted by Mike (Stgt) on 5 July 2011, 7:35 a.m.,
in response to message #17 by Egan Ford

Sorry for interfering your communication, but if you read your append once more it is so obvious:

Quote:
At this time no virtual HP-IL devices have been created
Quote:
...but he never got around to it
Quote:
...someone just needs to run with it

Christoph's 'virtual HP-IL' is available. And works so far.

Ciao.....Mike

                                                            
Re: Update of ILPer, the HP-IL peripheral simulator
Message #19 Posted by Egan Ford on 5 July 2011, 11:12 a.m.,
in response to message #18 by Mike (Stgt)

I think there is a bit of confusion here. The nonpareil patch creates a virtual HP-IL loop in RAM and has built into it various virtual HP-IL devices, e.g. printer, disk, tape, serial, etc...

All communication between the various devices is via HP-IL. This is no different than EMU41 emulating HP-IL. Both nonpareil and EMU41 support the PIL-Box as a bridge from the virtual to the physical.

The nonpareil patch has another virtual device, 'tcp'. I.e. a way to tunnel HP-IL through TCP/IP. The intended purpose of this was to support other virtual devices without having to link them into the nonpareil executable. At this time none have been created, or released I should say. I have a version with just the virtual loop and the devices but without the controller. The intended purpose was to provide virtual devices to the PIL-Box, however the tcp interface should usable as well.

                                                                  
Re: Update of ILPer, the HP-IL peripheral simulator
Message #20 Posted by Mike (Stgt) on 5 July 2011, 11:58 a.m.,
in response to message #19 by Egan Ford

Thank you for clarification. I will have a look to the patched Nonpareille.

Ciao.....Mike

                                                                  
Re: Update of ILPer, the HP-IL peripheral simulator
Message #21 Posted by Christoph Giesselink on 5 July 2011, 1:10 p.m.,
in response to message #19 by Egan Ford

I just checked the sources in the diff file especially the file hpil_io_tcp.c which seem to be the implementation for the tcp option in the expanded Nonpareil version.

In function hpil_io_peripheral_tcp_main() is the implementation for the server, line 255 is reading a frame and in line 287 the modified frame is writing back. Both functions read() and write() use the same socket so both communications use the same port (in this case by default 4141).

IMHO that's a big and important difference to the design of "Virtual HP-IL". A "Virtual HP-IL" device has different ports for receiving and transmitting frames (like you have two cables in reality).

Example for "Virtual HP-IL" with three devices

HP41/71 ---port60001--> Device1 ---port60002--> Device2
   ^                                               |
   +--- <--port60000--- Device3 <--port60003--- <--+

Example for "Nonpareil with tcp extension"

HP41 ---port4141--> Device
 ^                     |
 +-- <--port4141--- <--+

So you see, the tcp implementation in the modified Nonpareil version don't create a loop because send and receive share the same port and so you can create only a connection between the emulated HP41 and one device.

Christoph

                                                                        
Re: Update of ILPer, the HP-IL peripheral simulator
Message #22 Posted by Egan Ford on 5 July 2011, 1:45 p.m.,
in response to message #21 by Christoph Giesselink

Quote:
So you see, the tcp implementation in the modified Nonpareil version don't create a loop because send and receive share the same port and so you can create only a connection between the emulated HP41 and one device.
You can create multiple connections by defining multiple ports.

E.g. in hpil.conf: 

#HP82182A
#set printer_switch 1
#printer mode=manual

#HP82163
#video 32 zoomx=2 zoomy=2

#HP92198 (two displays)
video 80 zoomx=1 zoomy=1
video 80 zoomx=1 zoomy=1

#HP9114B
#disc file=/Users/egan/.nonpareil/foo.lif

#HP82161A
tape file=/Users/egan/.nonpareil/foo.lif

#PIL-Box
pilbox tty=/dev/cu.usbserial-FTE03NXR debug init=con speed=115200

#New HP-IL devices
tcp listen port=1111
tcp host=127.0.0.1 port=1112
tcp listen port=1113

E.g.:                                               emulated device
                                                          ^
                                                          |
                                                          V  
np/hp41 -> np/hp-il-display -> np/hp-il-storage -> np/tcp-port-1111
   ^                                                      |
   '------ np/tcp-port-1112 <- np/tcp-port 1113 <---------'
                  ^                   ^
                  |                   |
                  v                   v
            emulated device     emulated device
It is not exactly the way you do it, but it is still a virtual loop with multiple devices.
                                                                              
Re: Update of ILPer, the HP-IL peripheral simulator
Message #23 Posted by Marcus von Cube, Germany on 5 July 2011, 2:21 p.m.,
in response to message #22 by Egan Ford

Can the two methods be mixed and matched?

1/ Is the protocol the same (TCP vs. UDP)?
2/ Are the frames formatted the same?
3/ If (1) or (2) are not both true, can an intermediate server be created to translate between the two?

Since there doesn't seem to exist a device implementation for NP, it might be a good idea to replace the NP protocol by the ILPer one to solve the compatibility issue. Both IP address(es) and ports need to be configurable because the device(s) might reside on different (virtual) machines.

                                                                                    
Re: Update of ILPer, the HP-IL peripheral simulator
Message #24 Posted by Christoph Giesselink on 5 July 2011, 3:08 p.m.,
in response to message #23 by Marcus von Cube, Germany

Quote:
Can the two methods be mixed and matched?

Not directly.

Quote:
1/ Is the protocol the same (TCP vs. UDP)?

Yes, it is, TCP.

Quote:
2/ Are the frames formatted the same?

Yes, they are. Each frame has 16 bit in network byte order.

Quote:
3/ If (1) or (2) are not both true, can an intermediate server be created to translate between the two?

To use ILPer in combination with Nonpareil Emu41 you need a bridge software (ILTCP?) like the ILPilbox software.


+-------+              +--------+
| Emu41 |---port4141-->| Bridge |---port60001-->Device1---port60002-->Device2
|       |<--port4141---| ILTCP? |                                        |
+-------+              +--------+                                        |
                           ^                                             |
                           +---- <--port60000---Device3<--port60003-- <--+

Quote:
Since there doesn't seem to exist a device implementation for NP, it might be a good idea to replace the NP protocol by the ILPer one to solve the compatibility issue. Both IP address(es) and ports need to be configurable because the device(s) might reside on different (virtual) machines.

The TCP/IP server inside ILPer, ILScope and ILPilbox accept frames from any IP address, so the configuration dialogs want to have the IP address of the next device only, but of course the two port numbers.

I will publish a software which will use the "Virtual HP-IL" in the next weeks.

Christoph

                                                                                          
Re: Update of ILPer, the HP-IL peripheral simulator
Message #25 Posted by Marcus von Cube, Germany on 5 July 2011, 4:02 p.m.,
in response to message #24 by Christoph Giesselink

Quote:
Quote:
1/ Is the protocol the same (TCP vs. UDP)?

Yes, it is, TCP.

How do you handle the loop setup? Is it temporary in the sense that each connection is established just for a single packet and then closed, or is permanent? Then how do you setup the complete loop? You can't start all servers at the same time?

I think its much easier to use UDP instead because its connectionless. A server just listens for packets, checks if it is meant, acts upon the data if necessary and sends a response or the unmodified packet to its next partner. There is no error if the partner cannot be reached but the controller will monitor the arrival of the packet it had sent and will either raise an error or try again, just as it would if the physical loop were broken. I have the feeling that the handling will be much easier for a device and the logic in the controller is already there. With this scheme, its no problem to stop a device and replace it with some other, just acting on the same ports or interfaces. If you want to add or remove a device, you need to stop and reconfigure its neighbors but the rest of the loop is not affected.

                                                                                                
Re: Update of ILPer, the HP-IL peripheral simulator
Message #26 Posted by Christoph Giesselink on 5 July 2011, 5:01 p.m.,
in response to message #25 by Marcus von Cube, Germany

Quote:
How do you handle the loop setup? Is it temporary in the sense that each connection is established just for a single packet and then closed, or is permanent?

When the client get his first frame to send, the client setup the connection and stay permanent. If sending failed to an established connection, the client automatically reopens the connection and then send the frame again.

Quote:
Then how do you setup the complete loop? You can't start all servers at the same time?

Yes, I can start all servers at the same time, because the clients establish their connection at the first frame and not at program startup.

Quote:
I think its much easier to use UDP instead because its connectionless. A server just listens for packets, checks if it is meant, acts upon the data if necessary and sends a response or the unmodified packet to its next partner. There is no error if the partner cannot be reached but the controller will monitor the arrival of the packet it had sent and will either raise an error or try again, just as it would if the physical loop were broken. I have the feeling that the handling will be much easier for a device and the logic in the controller is already there. With this scheme, its no problem to stop a device and replace it with some other, just acting on the same ports or interfaces. If you want to add or remove a device, you need to stop and reconfigure its neighbors but the rest of the loop is not affected.

I made a proof of concept program with configurable settings of using IPv4, IPv6, TCP/IP and UDP in September/October last year. The main reason for choosing TCP/IP was, when I tried to establish a IPv6 connection, but the gateway was only IPv4, the UDP package get lost. With TCP/IP I get an error when I try to "connect" a IPv6 connection over a IPv4 only gateway. Because I implemented a dual stack (after recompiling the sources with a IPv6 capable C++ compiler) I switch back to IPv4 and establish the connection over IPv4. Furthermore TCP/IP helps to find a broken link. The program which find no server under the given IP address can pop up an error message box. Before, I preferred UDP like you, because the behavior is closer to the original hardware.

With the retry of an established connection I described above it's no problem to stop a device, replace it and start again. The problem is on the HP-IL loop controller side, because the new device has only his default HP-IL address, you have to readdress the loop, on the HP71B with "RESTORE IO".

Hope this make the interface more clear. The programs are licensed under the GPL, so you may have a look at the sources.

Christoph

                                                                                    
Re: Update of ILPer, the HP-IL peripheral simulator
Message #27 Posted by Egan Ford on 5 July 2011, 5:14 p.m.,
in response to message #23 by Marcus von Cube, Germany

Quote:
Since there doesn't seem to exist a device implementation for NP, it might be a good idea to replace the NP protocol by the ILPer one to solve the compatibility issue. Both IP address(es) and ports need to be configurable because the device(s) might reside on different (virtual) machines.
Yes, an RFC for HP-IL over IP is in order. :-)

Nobody is developing nonpareil's HP-IL support. Khanh-Dang halted development nearly two years ago. I thought that I would have had time to contribute to it myself, but I have been swamped with work and other personal projects. It's open source; any can take over.

                                                                              
Re: Update of ILPer, the HP-IL peripheral simulator
Message #28 Posted by Christoph Giesselink on 5 July 2011, 2:36 p.m.,
in response to message #22 by Egan Ford

Many TNX, now I understand the principles of the loop.

Christoph

                                                                              
Re: Update of ILPer, the HP-IL peripheral simulator
Message #29 Posted by Mike -Stgt- on 6 July 2011, 7:00 a.m.,
in response to message #22 by Egan Ford

Thank you for clarification. But I still have 2 questions:

i) The sequence of TCP ports in your diagram is 1111-1113-1112 but in the conf file they are sorted acending. How do you fix the position of a device within the loop?

ii) the loop is built within Nonpareil's add-on, so the TCP devices get only frames that are addressed to them? Or do they get all traffic and must filter out what is realy of interest?

Ciao.....Mike

                                                                                    
Re: Update of ILPer, the HP-IL peripheral simulator
Message #30 Posted by Egan Ford on 6 July 2011, 11:51 a.m.,
in response to message #29 by Mike -Stgt-

Quote:
i) The sequence of TCP ports in your diagram is 1111-1113-1112 but in the conf file they are sorted ascending. How do you fix the position of a device within the loop?
The order of the HP-IL devices is based on the order listed in hpil.conf. My diagram didn't match my hpil.conf file. Error on my part.
Quote:
ii) the loop is built within Nonpareil's add-on, so the TCP devices get only frames that are addressed to them? Or do they get all traffic and must filter out what is realy of interest?
The TCP devices only get what is destined for each of them since they each connect or listen to distinct ports.
                                          
Re: Update of ILPer, the HP-IL peripheral simulator
Message #31 Posted by Mike (Stgt) on 5 July 2011, 7:11 a.m.,
in response to message #15 by Egan Ford

Quote:
EMU41 already emulates HP-IL with devices without a PIL-Box. I guess I may not really understand exactly what you want to accomplish.
Yes, JFG's EMU41 is a gem, and it covers most of the needs. What I'd like to try is programming 'my own' HPIL device and set it into the virtual HP-IL. With Christoph's innovation it is now feasible for me - but I miss badly a virtual HP41 as controller.

Ciao.....Mike

                                                
Re: Update of ILPer, the HP-IL peripheral simulator
Message #32 Posted by Egan Ford on 5 July 2011, 10:49 a.m.,
in response to message #31 by Mike (Stgt)

If you want to use Christoph's, then you should be able to hack up the nonpareil patch so that it's tcp support complies with Christoph's interface. This way you get a controller.

BTW, now that EMU41 is open source, it should be possible to port it to win32 or Unix and add IP support. Or keep it DOS and use a packet driver.

Edited: 5 July 2011, 11:13 a.m.

                                                      
Re: Update of ILPer, the HP-IL peripheral simulator
Message #33 Posted by Mike (Stgt) on 6 July 2011, 7:18 a.m.,
in response to message #32 by Egan Ford

I may code FORTRAN, REXX, alas still no C yet. :(

Ciao.....Mike

      
Re: Update of ILPer, the HP-IL peripheral simulator
Message #34 Posted by Frido Bohn on 29 June 2011, 6:21 a.m.,
in response to message #1 by Christoph Giesselink

Great job Christoph!

Thank you for the update. It works perfect with Windows 7, 64 bit, as stand alone without the .net package (if somebody wants to know ;-)
I like the icon. Although it was already with the prior version I wanted to appreciate your sense for details at least on this occasion.

[ Return to Index | Top of Index ]

Go back to the main exhibit hall