Latest Version of EMU41



#35

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


#36

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.

#37

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


#38

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

#39

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


#40

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


#41

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.

#42

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...

#43

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


#44

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


#45

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


#46

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!

#47

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.


#48

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


#49

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.

#50

Thanks, Egan. I'll check it out.

#51

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 :)


#52

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!

:-)


#53

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

#54

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


#55

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.


#56

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

#57

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?


#58

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.

#59

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


#60

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
#61

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.

#62

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


#63

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.

#64

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


#65

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


#66

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


#67

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.


#68

Thank you!


Possibly Related Threads...
Thread Author Replies Views Last Post
  EMU41; Dosbox on Linux; Excruciatingly sloooow Geir Isene 9 512 12-01-2013, 05:10 PM
Last Post: Geir Isene
  latest prime software release? Geoff Quickfall 3 278 10-12-2013, 03:53 PM
Last Post: Tim Wessman
  So, latest 41CL / Library 4 config is... Gene Wright 4 333 09-22-2013, 02:59 AM
Last Post: Ángel Martin
  Latest 50G Update...? Matt Agajanian 1 164 09-03-2013, 05:00 AM
Last Post: Pier Aiello
  Latest HP Prime "emulator" software available :) Adrien Bertrand 46 1,619 08-21-2013, 10:48 PM
Last Post: Joe Horn
  SVN command to get latest realbuild Barry Mead 3 253 07-19-2013, 12:59 PM
Last Post: Didier Lachieze
  Latest & Last SandMath is released Ángel Martin 0 174 07-02-2013, 12:44 AM
Last Post: Ángel Martin
  [WP 34s] How to get the latest version of file xyz Walter B 3 236 03-17-2013, 05:52 AM
Last Post: Alexander Oestert
  Latest Clonix/NoV's SW update. Diego Diaz 5 302 02-15-2013, 12:12 PM
Last Post: Ángel Martin
  The latest version of Free42 is now a OS X Universal application..... zeno333 1 184 10-21-2012, 11:12 PM
Last Post: Matt Agajanian

Forum Jump: