The Museum of HP Calculators

HP Forum Archive 19

[ Return to Index | Top of Index ]

Latest Version of EMU41
Message #1 Posted by Gerry Schultz on 13 Mar 2009, 7:18 p.m.

To All:

I'm looking for the latest version of EMU41. I have resurrected my old Win98 PC with ISA slots and installed an HP82973A HP-IL to PC I/F card. I have an older version of EMU41.exe dated 10/18/97 which appears to run properly (I do have the 41CV and CX binary image files). I also have a copy of EMU41.exe dated 2/22/04 which appears to support HP-IL but it crashes when I run it on my work PC. I also have Christoph Klug's latest book, "HP-41 Input/Output Board" which I am using to help set up the HP-IL to PC I/F card.

When I search using Google, I find lots of links to EMU41 but the ones that work are to the 1997 version of EMU41. The links on the version 6.2 of the HP Museum disks to EMU41 are dead so if anyone knows where to look, I would appreciate it.

As I remember, The full version of EMU41 has been released to the public. If that is true, then that's the version I'm looking for as I want to take files from my HP82161A cassette drive and HP9114B floppy drive and store them on my PC. I also want to use the LIF utilities to try formatting some double-density floppies that the 9114 reported as having bad media on my PC's 3 1/2" drive.

Thank you for the help.

Gerry

      
Re: Latest Version of EMU41
Message #2 Posted by ZOleg on 13 Mar 2009, 8:30 p.m.,
in response to message #1 by Gerry Schultz

Whats happen with JFC page at http://www.jeffcalc.hp41.eu?
Its possible use virtual Tape in Emu41/Emu71 for HP-41CX and HP-71B connected to PC via RS232/HP-IL 82164A adapter?

Edited: 13 Mar 2009, 8:46 p.m.

      
Re: Latest Version of EMU41
Message #3 Posted by Egan Ford on 13 Mar 2009, 11:34 p.m.,
in response to message #1 by Gerry Schultz

The latest version (2.45) of EMU41 works with the HP-IL ISA card. However, I cannot get to JFG's site (http://www.jeffcalc.hp41.eu/). I can send it to you if you cannot find it elsewhere.

The latest LIFUTIL for DOS can be had here:

http://www.home.agilent.com/agilent/faqDetail.jspx?cc=FR&lc=fre&ckey=1000002597:epsg:faq&nid=-536902437.536881997.02&id=1000002597:epsg:faq

            
Re: Latest Version of EMU41
Message #4 Posted by Gerry Schultz on 14 Mar 2009, 8:30 p.m.,
in response to message #3 by Egan Ford

Thank you all for all the responses.

Egan, yes, please email me version 2.45 of EMU41. You can send it to my work email address and if you could add my home email address g_schultz AT ca DOT rr DOT com I would appreciate it. Thank you for offering it. Also, thanks for the link to the LIF utilities. I'll follow up with that this weekend on my Win98 PC.

Gerry

      
Re: Latest Version of EMU41
Message #5 Posted by Howard Owen on 14 Mar 2009, 11:41 p.m.,
in response to message #1 by Gerry Schultz

JF's site at http://www.jeffcalc.hp41.eu was back online when I checked just now

            
Re: Latest Version of EMU41
Message #6 Posted by Gerry Schultz on 16 Mar 2009, 3:21 p.m.,
in response to message #5 by Howard Owen

Egan, Howard, everyone, thanks for all the information. JF's website is indeed up and I have downloaded the latest versions of EMU. Please note that EMU41 2.47 beta is now available. I also got Warren Furlow's latest HP-41Archive DVD just this morning. I only ordered it Friday so thanks to Warren for the fast shipping.

Egan, I got your emails and links. Thank you for all your help. Yesterday, after I got all the "honey-dos" done, I put in the HP-IL card in my Win98 machine and cranked up the latest version of EMU41 (2004) and it didn't crash. I was able to get the internal HP-IL loop to work with FDRIVE1. I put a floppy in my PC drive formatted and storing a 41 program from my 9114b and the EMU41 successfully did a DIR. With the fully implemented EMU41 I can try my HP-IL devices on my PC and see if they work. Then I can start playing with the LIF utilities. I have some floppies to test.

Finally, I just won an auction for a HP-71 on that unmentionable website. It includes the HP-IL loop so I can use my external devices with it. I guess I'll have to get the full version of EMU71 to link it to my PC.

Oh, where does it end???

Gerry

                  
Re: Latest Version of EMU41
Message #7 Posted by Marcus von Cube, Germany on 16 Mar 2009, 4:38 p.m.,
in response to message #6 by Gerry Schultz

EMU41 should be fine for supporting the HP-71. AFAIK the real HP-41 is unable to give up control of the loop but the emulator does so if no I/O is under way or while it is idle.

                  
Re: Latest Version of EMU41
Message #8 Posted by Egan Ford on 16 Mar 2009, 5:59 p.m.,
in response to message #6 by Gerry Schultz

Quote:
Oh, where does it end???
It doesn't. There are 32/80 column video adapters to be had, HP-IL to serial projects (e.g. see my X10 home automation hack: http://www.hpmuseum.org/cgi-sys/cgiwrap/hpmuseum/articles.cgi?read=763, and how to set your 71B clock with a GPS: http://www.hpmuseum.org/cgi-sys/cgiwrap/hpmuseum/articles.cgi?read=746), Plotters, etc...
                        
Re: Latest Version of EMU41
Message #9 Posted by Howard Owen on 16 Mar 2009, 7:03 p.m.,
in response to message #8 by Egan Ford

And nobody has done HPIL/IP or a PCI version of the HP-IL PC card. A Linux driver for the HPIL card would be nice too.

I'm long on ideas and short on action, unfortunately. :)

Regards,
Howard

                              
Re: Latest Version of EMU41
Message #10 Posted by Khanh-Dang Nguyen Thu-Lam on 16 Mar 2009, 7:36 p.m.,
in response to message #9 by Howard Owen

If someone gives me a HP-IL PC card, the first thing I would do is to write a Linux driver :-)

                                    
Re: Latest Version of EMU41
Message #11 Posted by Egan Ford on 17 Mar 2009, 7:04 a.m.,
in response to message #10 by Khanh-Dang Nguyen Thu-Lam

When this releases (http://www.jeffcalc.hp41.eu/hpil/index.html ) I'll send you one in exchange for a Linux USB driver.

                                          
Re: Latest Version of EMU41
Message #12 Posted by Khanh-Dang Nguyen Thu-Lam on 18 Mar 2009, 5:57 a.m.,
in response to message #11 by Egan Ford

I guess there will be nothing to do if the PILBox uses protocols such as RS232 or serial USB. Under Linux, things would work just fine if you open the right device file (say /dev/ttyS0 for a RS232 serial port or /dev/ttyUSB0 for a USB port), then write data to or read data from this file. Actually, for the USB "driver", there would be just one single program line to add to the Linux sources saying "Hi serial USB driver, would you mind to bind to any device which USB ID is the one of PILBox?".

What would be more interesting is to write a HPIL library so that users wouldn't have to remember the codes for PIL commands. Who really cares about the Ready Send Data PIL frame being 0x560?

Anyhow, thank you for your offer, that's nice!

                              
Re: Latest Version of EMU41
Message #13 Posted by Egan Ford on 17 Mar 2009, 7:02 a.m.,
in response to message #9 by Howard Owen

PCI? Or PCI-E? Gen1 or Gen2? I think the safer bet would be JFG's PIL-Box: http://www.jeffcalc.hp41.eu/hpil/index.html.

I am holding out for that.

P.S. Welcome back.

Edited: 17 Mar 2009, 7:05 a.m.

                                    
Re: Latest Version of EMU41
Message #14 Posted by Gerry Schultz on 17 Mar 2009, 1:53 p.m.,
in response to message #13 by Egan Ford

Hi All. Just wanted to follow up with this thread. I put EMU41 version 2.45 on my Win98 machine last night and successfully loaded and ran a program from the 9114 on the external loop into the EMU41. So I now know that the HP-IL I/F card is functioning properly in my Win98 machine.

As I have been using EMU41, a couple of questions came up. First, is there any way to save the 41 machine state? I do some key assignments for HP-IL functions and when I quit to edit the EMU41.ini file, I have to re-do the assignments manually again. I need the "C" in 41C. In the ini file, I saw some bin files listed I didn't know what they are; like ccd_osx.bin and xiola.bin. What do these bin files represent? Is osx Apple's OS X? Is there any further documentation on EMU that goes into more detail about the bin files and the devices section of the ini file.

Thank you for your patience and help,

Gerry

                                          
Re: Latest Version of EMU41
Message #15 Posted by Egan Ford on 17 Mar 2009, 2:43 p.m.,
in response to message #14 by Gerry Schultz

Quote:
First, is there any way to save the 41 machine state?
IIRC, machine state is save in MEM41.DAT and XMEM41.DAT. Just back them up.
Quote:
In the ini file, I saw some bin files listed I didn't know what they are; like ccd_osx.bin and xiola.bin. What do these bin files represent? Is osx Apple's OS X?
CCD_OSX is another community created module. You have the docs on your HP-41 Archive DVD.

XIO, is the HP-IL Extended I/O module. Very nice to have. Documented in Klug's book as well as the MoHPC DVD.

Quote:
Is there any further documentation on EMU that goes into more detail about the bin files and the devices section of the ini file.
Google, e.g.: ccd osx site:hpmuseum.org, e.g.: emu41.ini site:hpmuseum.org.
                                                
Re: Latest Version of EMU41
Message #16 Posted by Gerry Schultz on 17 Mar 2009, 8:24 p.m.,
in response to message #15 by Egan Ford

Thanks, Egan. I'll check it out.

                                    
Re: Latest Version of EMU41
Message #17 Posted by Howard Owen on 17 Mar 2009, 2:10 p.m.,
in response to message #13 by Egan Ford

Oh, man, I just saw that JF will release the source to ILPer. That means that a Linux/Mac USB driver is the priority, so we can port the virtual loop too.

NutML -> DOS/C -> Windows/VB -> (Linux|OSX)(C|Python|??)
Quite a journey that knowledge will have taken.

If the implementation language is C, it would facilitate the writing of an HPIL/IP router. :)

Regards,
Howard

P.S Thanks :)

                                          
Re: Latest Version of EMU41
Message #18 Posted by Marcus von Cube, Germany on 17 Mar 2009, 6:20 p.m.,
in response to message #17 by Howard Owen

Why not create something in Java. As long as the USB is recognized as a serial port, the Java Comm API should be able to handle it.

What you get: portability, GUI, object oriented design, ... The compiled code should run an any platform with javax.comm installed. Makes it interesting!

:-)

                                                
Re: Latest Version of EMU41
Message #19 Posted by Howard Owen on 17 Mar 2009, 7:19 p.m.,
in response to message #18 by Marcus von Cube, Germany

Java ought to be fine for the simulator. But I'm thinking about routing IP frames to IL and back - that's probably a little too close to the real machine for Java.

Regards,
Howard

                                                
Re: Latest Version of EMU41
Message #20 Posted by Howard Owen on 17 Mar 2009, 8:31 p.m.,
in response to message #18 by Marcus von Cube, Germany

Having thought a little bit more about this, I can see that the implementation language of the loop is not so important. What is needed for an HPIL/IP router, or for any software using HP-IL is loop access to both the physical and the virtual loops. The driver interface should give access to the physical loop, but the virtual loop emulation could make this easier by providing loop architecture administration as well as emulation So Java, C, FORTRAN, whatever, the virtual loop implementation should define an interface to the emulated loop. Further, the emulation interface should allow selecting shared or standalone mode. That is, in shared mode, the loop emulation would put the frames it receives from external software onto the physical loop after running them through the emulated devices. In standalone mode, it would instead return the frames to the external software. There could also be an "invisible" mode where the emulation would simply transfer frames between the loop and external software, without performing any emulation beyond that. Switching modes on the fly would be cool, too, rewiring the virtual loop on an ad hoc basis.

What I'm obsessed with is the idea of using your 9114 drive from my HP41C, us being at arbitrary distance over the Internet. :) Also, and I think I mentioned this here several years ago, you could have a cluster of 41s working in parallel on a problem. What is the processing power of all our 41s put together? How far up the mips (never mind gips) scale could we go?

Regards,
Howard

                                                      
Re: Latest Version of EMU41
Message #21 Posted by Egan Ford on 17 Mar 2009, 9:02 p.m.,
in response to message #20 by Howard Owen

Howard, check this out: http://pagesperso-orange.fr/kdntl/hp41/nonpareil-patch-doc.html.

It's a patch to nonpareil and it provides some very nice HP-IL capabilities, including a TCP interface. As soon as the PIL-Box releases and a driver created I image that this could also be linked in to act as your proxy. And it is in C.

                                                            
Re: Latest Version of EMU41
Message #22 Posted by Howard Owen on 17 Mar 2009, 11:59 p.m.,
in response to message #21 by Egan Ford

That does indeed seem to be a big chunk of the solution. The patch must be GPL, since it doesn't change the license text in README. So now I wonder what license JF will use for his release. For the sake of arbitrary combination, derivation and downright happy hacking, it would be best if he used the GPL too.

Regards,
Howard

                                                      
Re: Latest Version of EMU41
Message #23 Posted by Khanh-Dang Nguyen Thu-Lam on 18 Mar 2009, 6:14 a.m.,
in response to message #20 by Howard Owen

There is no need for a HPIL/IP router, just let your HP41 talk TCP/IP, directly :)

I am writing a ROM (written in MCODE) called NutIP which encodes/decodes TCP/IP frames. A web server is provided as a proof of concept. The work is nearly done, I just need to do a lot more testing and to implement the TCP retransmission part (not the hard part of NutIP, though).

I haven't released NutIP yet, but the documentation (kind of teaser) is available at: http://pagesperso-orange.fr/kdntl/hp41/nutip/.

BTW, I would like to see NutIP running on real hardware before releasing it. I still don't have a HP-41 + PIL ROM + (MLDL or Clonix or NoVRAM) + (the HP82164 HPIL/RS232 interface or PILBox or HPIL PC card). Is there anyone living near Paris who would like to do some tests and who is lucky enough to have all the hardware mentioned above?

                                                            
Re: Latest Version of EMU41
Message #24 Posted by Howard Owen on 19 Mar 2009, 6:08 p.m.,
in response to message #23 by Khanh-Dang Nguyen Thu-Lam

Wow, SLIP! Why not PPP? Smaller I'll bet.

This is also way cool! Native TCP/IP would be great to have. Of course you'd need applications layered on top of the native IP. For example, wouldn't Something like SMB or NFS be required in order to share mass storage? Both the client and the server parts of the protocol would have to implement IP <-> HP/IL translation, and at multiple layers. You'd have to do that over for each service/application too. I can see this would be a great challenge for an ace mcode programmer. Fitting the application(s) into 8K or even 4K would be quite an acheivment. Of course, a more clever architecture than the simple-minded one I have in mind could make the whole thing more feasible

I'm more interested in doing a router because all those translations can be done in a high level language and with better resources. I would also like to accomodate/incorporate virtual HP-IL devices.

But the prospect of a native web server running on an HP-41C is just too tasty to pass up. I think both approaches have merit. :)

Regards,
Howard

Edited to correct typo resulting from posting from my iPod :)

Edited: 20 Mar 2009, 2:05 a.m.

                                                      
The IP Loop
Message #25 Posted by Marcus von Cube, Germany on 18 Mar 2009, 9:00 a.m.,
in response to message #20 by Howard Owen

I've a possible scenario in mind which is independent of the implementation language. Not knowing very much detail about the HP loop, others might need to jump in if necessary.

Each device is an independent piece of software. These pieces may be implemented in any language and need not necessarily be independent processes, tasks will do, as long as they all talk the same language: UDP. This is the connectionless and thus simpler form of IP connectivity. Each device listens on a specific port and talks to its neighbor on the neighbor's port. For simplicity, lets assign port 50001 to device 1, 50002 to device 2, and so on. Configuration is per device: The port to listen to and the port to talk to. The IP address can be the broadcast address or a specific host. Devices can be spread across the network at will. Since the same UDP port can be listened to from several processes, even a kind of automatic loop arbitration and address assignment may be possible. (A device stopping service can brodcast a quit message that is honored by its left neighbor and causes its reconfiguration.)

How to connect the real HP-IL world to this? With the HP-IL card, you only need a small driver in your DOS PC under the table which talks to the card and translates the data to UDP for its neighbor in the virtual loop, or from UDP to HP-IL in the other direction. The USB-HP-IL bridge just needs the same functionality implemented for different hardware. An implementation may even be based on the Xport connected to some small micro controller. This can either act as an IP-HP-IL bridge or be a device by itself. Others may even consider a wireless implementation of the same idea.

Marcus

                                                            
Re: The IP Loop
Message #26 Posted by Howard Owen on 18 Mar 2009, 12:54 p.m.,
in response to message #25 by Marcus von Cube, Germany

I think that a single device per software module ought to be possible, or multiple devices. Either way, the modules would take in HPIL frames and emit them. What happens to the frames in between should only concern the particular module. Other modules - or real IL devices - would learn about those internal events via loop messages.

It's very important to define a set of interfaces that everyone can code to. There seem to be several of us interested in this idea. I'd also like to get JF involved in the conversation around the design of a distributed, IP based HPIL extension. I suggest we call it VL, for Virtual Loop. (It could be HP-VL, but HP might get annoyed.) I'm not able to put a great deal of time and/or effort into this, but for now, here's my first shot at a high level requirements list. These are completely ad-hoc and subject to revision. They also incorporate many ideas from many folks. I'm just aggregating them into a requirements list

  • VL will be a generalized, software based extension of HP-IL accommodating both real and virtual HP-IL devices.
  • VL will be an object oriented system, with virtual devices implementing VL standard messaging interfaces. Otherwise the internal state of such objects will be opaque.
  • Communication transports should be completely transparent to virtual devices. (i.e. the network should be invisible)
  • Virtual devices will communicate both in-band and out-of-band
    • In-band communication with loop messages should adhere to the HP-IL spec, modified by the requirements of real HP-IL devices.
    • Out-of-band mechanisms will allow extended communication between software modules for such things as loop reconfiguration.
  • Source and target of in-band communication should be dynamically configurable via out-of-band mechanisms. (This will allow, for example, "captive" virtual loops under the control of a master virtual device. This could be one way to do extended loop addressing.)
  • VL reconfiguration should be possible using in-band communication (via HP-IL frames) and out-of-band (so that one software module could replace another transparently.)
That's all I have time for at the moment. Comments?

Regards,
Howard
                                                            
Re: The IP Loop
Message #27 Posted by Eric Smith on 20 Mar 2009, 12:32 a.m.,
in response to message #25 by Marcus von Cube, Germany

I was working on HP-IL support for Nonpareil back in October-November, though I haven't had time to finish it up, and since then Khanh-Dang Nguyen Thu Lam has published patches for Nonpareil to support HP-IL, along with emulation of some HP-IL peripherals. I have not had time to try his code.

My own plan was roughly what you describe, with datagrams over UDP (or Unix-domain sockets) to pass the frames between devices and a "loop manager" process. However, I didn't plan to assign port numbers to positions in the loop. I just planned that each device would send a "connect to loop" message to the single UDP port of the loop manager, and the loop manager would assign and track the device position within the loop and route the HP-IL messages appropriately.

The loop manager could provide some means for a user to order the devices within the loop, possibly by a GUI interface. The devices would have no knowledge of where they are within the loop (just as in a real loop).

My plan for supporting physical HP-IL was to allow for a "device" on the virtual loop to be a physical loop. In other words, there would be some process acting as a proxy, participating in the virtual loop by UDP, and in the physical loop. In principle there could be more than one physical loop particpating in a virtual loop, or even more than one virtual loop participating in a physical loop. There could be proxies for the 82973A card, JFG's PIL-Box, or other hardware.

I got as far as defining a basic datagram format for HP-IL messages and loop management messages, and writing code for two different HP-IL interfaces, one directly from the state machines defined in the HP-IL spec, and the other based on the 1LB3 chip spec. When I left off, these were feature-complete but only slightly tested.

Edited: 20 Mar 2009, 12:36 a.m.

                                                
Re: Latest Version of EMU41
Message #28 Posted by Eric Smith on 20 Mar 2009, 12:41 a.m.,
in response to message #18 by Marcus von Cube, Germany

Sun's JRE (and JDK) do not supply an implementation of the Java Comm API for Windows. So much for "write once, run everywhere". :-(

                                                      
Re: Latest Version of EMU41
Message #29 Posted by Marcus von Cube, Germany on 20 Mar 2009, 5:14 a.m.,
in response to message #28 by Eric Smith

But the specification exists and code written against it should run on any implementation. It looks like RXTX is the way to go: RXTX Wiki. It replaces javax.comm with gnu.io but is otherwise identical.

      
Latest Version of EMU71
Message #30 Posted by ZOleg on 15 Mar 2009, 8:34 p.m.,
in response to message #1 by Gerry Schultz

Emu71 on JF site - its full version or need to be registered for full power?

            
Re: Latest Version of EMU71
Message #31 Posted by Egan Ford on 15 Mar 2009, 9:32 p.m.,
in response to message #30 by ZOleg

You'll need to register to get support for the HP-IL ISA adapter.

                  
Re: Latest Version of EMU71
Message #32 Posted by ZOleg on 16 Mar 2009, 8:10 a.m.,
in response to message #31 by Egan Ford

To work through the HP-80164A RS232/HPIL require registration?

                        
Re: Latest Version of EMU71
Message #33 Posted by Egan Ford on 16 Mar 2009, 10:56 a.m.,
in response to message #32 by ZOleg

If you want to connect the serial end of your 80164A to the serial port of a PC, then no registration is required. However, I am unsure what functionality you will get.

                              
Re: Latest Version of EMU71
Message #34 Posted by ZOleg on 16 Mar 2009, 7:53 p.m.,
in response to message #33 by Egan Ford

Thank you!


[ Return to Index | Top of Index ]

Go back to the main exhibit hall