[HP41/71B/75D HP-IL ILPER ILVIDEO] PIL-Storage multiple connection

[floppy]

Hello,
I want to see what are the possible mix therefore setup of different HW HP41/HP71B/HP75D connected to a single PIL-Storage described there https://www.hpmuseum.org/forum/thread-19053.html (which optionally can be contacted to a screen; therefore ILPER printing area and ILVIDEO could be seen).
Perhaps with one PIL-Box or several PIL-Box for each HP41/71B/75D in different USB ports therefore I need to understand the hardware interactions
- depending of I/O Module present
- depending of machine type
- depending of machine on/off
- depending of how many virtual loop in the PC
- depending of the number of virtual drives

Comments/remarks from people here are welcome.

Questions:
- HP71B is the only one computer which can control its status with the standard (HP71B) HP-IL. Correct?
- HP41 and HP75D can only control its status if it has an I/O Module? (I think so; else these computers are as "controller" by default when in an HP-IL)
- HP71B can have a double HP-IL in order to control 2 different HP-IL-Loops with loops cab be with or without HP41 / HP75 in it (condition is the HP41 and HP75D changed their own status to receiver by an I/O module)
- HP41 and HP75D in the same loop dont work if they dont have their own I/O module and one has the status controller and the other status receiver (the HP41 or HP75D without an I/O Module will be a controller by default): one must control its status by its own I/O module (the status of an HP75D cannot be defined by an HP41-controller; but for example the HP75D must define its own status as receiver before the HP41 as controller will work correctly)
- A virtual drive in ILPER can only be reached in a PC inside the same virtual loop? (= 1 HP41 and 1 HP71B cannot be connected to the same virtual drive if both are not in the same HP-IL loop). probably the loop lock the virtual drive and nothing can happens with that file from another loop. But perhaps not and the system is dynamic with reading the HP-IL commands.
- Any HP41 or HP75D in a loop (with or without I/O module) must be switched on? (else it will break the loop)
- It is preferred to have a virtual drive different for each hardware ? (one for HP41, another one for HP71B, another one for HP75D). If a common virtual drive is ok, is it ok for all 3 HP41 and HP71B and HP75D files? or only HP71B/HP75D?
- ILVIDEO80 can be contacted from 2 different virtual loops?
- HP75D can have an output to ILVIDEO but it must be selected like in HP41 with the HP-IL command (HP71B make output automatically in ILVEDEO80 because it detects it).

I suppose the setup for following hardware
- HP41 w/ HP-IL, w/ PIL-Box, without I/O Module
- HP71B w/ HP-IL (single; not double)
- HP75D w/ I/O Module
with PIL-Storage will be
a) HP41 in its own HP-IL loop and one PIL-Box connected to USB Port 1 of the PIL-Storage and ILPER (HDRIVE1 in ILPER)
b) HP71B and HP75D in the same HP-IL loop and one another PIL-Box connected to USB Port 2 of the PIL-Storage in HP-IL virtual loop ILPILBOX with HRDIVE2 for HP71B and HDRIVE3 for HP75D and VIDEO80 in the virtual loop

Then I will test
a) if the PIL-Storage is sensitive to PIL-Box connected or not to it via the 3 free USB ports of 4 available ports on the tested board (one is busy with the USB storage memory)
b) multi connection/access of the virtual drives in the same/different virtual loops

And post the result how must be a setup for succesfull works with several HW connected.

[artag]

I'm in the process of putting together a PIL-Box and I think I have all the other parts, except for a 75C instead of a 75D. It may take me a while. The PIL-Box will initially use the public PIC code (1.5 I think) but I will get the later version in the new year.

The one thing that pains me about this is the use of windows emulation. I think the linux ILPer doesn't have necessary functionality but Cristophe was working on an upgrade. Perhaps that could be revived ?
https://www.hpmuseum.org/forum/thread-10099.html

[MeindertKuipers]

I would recommend to go with the Python version of ILPer, this is supposed to work on Linux as well (I only use Windows, so I do not have personal experience).You can find it here: https://github.com/bug400/pyilper

[artag]

My experience of Python is that it isn't portable. It depends heavily on its environment and the author's skill in isolating it from the system is critical. It has started to appear in things like the arduino toolchains for esp32 and nrf52840 . One of those I could only get to work by running the entire arduino IDE inside a Pthyon venv. This is not a good approach.

But I will try pyilper, especially if I can find help when I get stuck. I would think that it would be fixable in the system floppy is talking about, since that's an 'appliance' application where the raspberry pi is dedicated to the job and its common to provide an entire readybuilt filesystem image.

I think this approach is used for Octoprint, a pi-based 3d print spooler, and it's one of the few Python applications I've found to work out of the box. I will be delighted if I find pyilper to be as well built.

[floppy]

My focus is connecting several systems to one virtual drive system (on ARM board; why ARM? can be small and create a kind of "WoW" effect).

Pyilper is not a focus for me for ARM. Christoph ILPER windows binaries works so far on ARM using
raspbian: debian based OS (for ARM)
+ Adaptor (ARM - 32bits): Box86
+ Wine Debian based 32bits
+ ILPER 32bits Windows
(the 3 different levels are ok; we are having a "good enough" data exchange speed)

[PeterP]

(12-20-2022 12:55 PM)artag Wrote:  My experience of Python is that it isn't portable. It depends heavily on its environment and the author's skill in isolating it from the system is critical. It has started to appear in things like the arduino toolchains for esp32 and nrf52840 . One of those I could only get to work by running the entire arduino IDE inside a Pthyon venv. This is not a good approach.

I think this depends a bit on the environment. Python is the native language for the RPi, natively installed on macOs, and is of course super at home in Linux environments, coming pre-installed for a number of distro's. So in this particular use case I think you should have fewer issues imho.

[artag]

That could be the case, but my experiences seem to been the opposite. I use Linux for almost everything and as you say, it does use Python for many built-in system operations.

But this means that when I encounter a python application that has been built for a later version than the one that drives the system, and attempt to update to match, I break things. There is an attempt to keep system resources separate from those used for transient things but I still show astounding ability to break them .

The general advice is to do such things in a virtual environment. This is probably easier for the experienced python user than for the newb just trying to run something he found on the net. In particular, it's a non-obvious step (and I seem to fall for it even now, burnt fingers and all).

In contrast, running a windows python application means installing everything needed from scratch, and not affecting anything in the system (though there is potential damage if other python applications are in use). So I think it ends up being more completely documented and less invasive. But my experience of running those is even more limited and there may be other common difficulties.

The Pi is perhaps in a middle ground. It does rely on the local system, but it's so small and cheap that it is common to dedicate an entire machine to the job. This means that the developer gets it working using whatever processes work, and then often encapsulates the entire file system for the end user. So the developer's environment is replicated and all is well. So it could work for floppy, but they will experience all the integration pain. At least though, his users wouldn't !

In recent years Python has become beloved by many developers, and quite strongly defended when criticised. I am, though, finding more and more often when I feel like voicing my criticisms that there are others who agree with this.

I sincerely hope that some of the effort being put into the problem pays off and it becomes the reliable environment that many think it is. At the moment, that seems to be by proliferating dependency management systems. Incompatibly, of course .

[floppy]

Perhaps this work (no adaptation of python or pyqt for ARM; just re-use of the windows binaries):
raspbian: debian based OS (for ARM)
+ Adaptor (ARM - 32bits): Box86
+ Wine Debian based 32bits
+ Pyilper 32bits Windows (with pyqt etc.)
NOT TESTED/CONFIRMED SO FAR.

[artag]

I'm going to back off a little bit and admit to being needlessly pessimistic. I haven't got a system up and running yet but I have tried :

ilper for windows

I ran this under Wine. Always a recipe for unknown yak-shaving ! In fact, after a brief stop to go looking for mfc80.dll it startup fine. I don't have a PIL-Box yet so I couldn't test it in operation but at least it displayed an interface. I'm more comfortable about running on an x86 machine under Wine than emulating the x86 on an Arm so that's encouraging. And the sources are available so adapting it to run natively under Linux (or maybe using winelib) is a possibilty.

pyilper

I got the impression from the above conversation that pyilper had been developed for python on windows and 'should' run on linux. I did use to find that python was OK with reasonable portability via pyserial : it's only more recently that my every attempt to run python applications ended in frustration. And pyilper required me to install yet another python installer, anaconda. I could see this going down a deep hole.

But firstly, more investigation of anaconda seemed to show an open source base, and pyliper only required a minimal version, miniconda. Better still, there is a debian installation package which I tried and didn't seem to require anaconda either - a .dpkg is usually much easier to use than a 3rd-part installer. Again, I got as far as the application giving me a gui and wanting to find a PIL-Box.

So overall, an encouraging start. Good to find some options that are reasonably mature and written without too may assumptions. Now, I need to get the PIL-Box built so i can go further.

This was on my desktop x86 Linux machine. Maybe trying to do it on Arm, while a really nice 'boxed' solution is more hassle especially if I try to use native code rather than emulation. Floppy's approach has the advantage that a disk appliance could be built using off-the-shelf parts and perhaps will inspire a native re-implementation - but in the meantime offers a way to do that . Credit to him for getting it so far.