Yeah after scratching my head on this one I think I will try a different approach to the system. The screen is USB which isn't ideal in DOS unless you do Windows/DOS (9x etc) but that's not FreeDOS.
I will look at another way to get the plan working. -Ed On Mon, Oct 7, 2024, 10:57 Frantisek Rysanek via Freedos-user < freedos-user@lists.sourceforge.net> wrote: > > Date sent: Sat, 5 Oct 2024 14:18:30 +0100 > > > > It's a Elcon generic touch screen. > > > > I've read what the others have posted. > Is it that same Elcon we're talking about? > > If yes, the same Elcon: > Is this a current product, or something historical that's not on that > website anymore? > > If the Elcon screen is indeed some ARM-based "HMI", in what relation > is the DOS instance that you're asking about? Running on that box? In > an emulation? Or is the panel computer in fact x86-based, i.e. none > of the ARM-based models currently at the Elcon.gr website? > > If it is ARM-based, I should tell you that it won't run DOS, and > cannot work as an external monitor to an x86 DOS PC.The HMI panel has > got no VGA/DVI/HDMI/DP/TTL/LVDS external input, so there probably > isn't much need in trying to get your hands on its touchscreen > sensor, is that correct? > > Note that this category of "ARM-based HMI" allows two approaches: > > A) use the firmware that the HMI vendor has included in the package, > which has some visual programming language or a SCADA-style > development kit or whatnot. The visual front end is a part of that. > To the "process technology", it can speak Modbus, or a number of > other "industrial" fieldbus protocols. > > B) with some ARM-based HMI vendors, you can buy the bare hardware, > and you are free to install and develop your own firmware, typically > starting from some proprietary Linux distro provided by the vendor, > or feel free to start from scratch on bare metal, if you are so > inclined and capable :-) > > From a broader perspective, i.e. in case you actually have a choice > of what monitor or panel PC to pick (with a TS sensor+controller > integrated), or you have an x86 panel PC running DOS just fine, let > me tell you what the market of TouchScreens for x86 PC's looks like: > > There are a number of TouchScreen vendors, some of them possibly > historical. > What you see from the PC side is a TS *controller* = the chip talking > to you over some machine-readable bus. The controller chip and board > then connect to the analog sensor, doing some magic that's not all > that interesting to you, the application engineer. > > The typical outside interface of a TS controller runs on top of RS232 > serial, or USB, or historically PS/2. Or, relatively recently, I2C. > > On RS232, the TS controller speaks a proprietary protocol, which is > often documented, and typically comes with a driver for various > operating systems - traditionally including DOS, hooking the Int 0x33 > software interrupt that's traditionally served by mouse drivers. > > On PS/2, the TS controller likely appears as a mouse, and probably > needs a proprietary driver too. > > Forget I ever mentioned I2C HCI. No go in DOS. > > USB is probably the least favourable option for you in DOS. If you > are lucky, the controller presents (or can be configured to present) > an opaque HID mouse interface - in which case, you might get it to > work, if you tackle the DOS support for USB mouse. Never tried > myselfs. You will find some rare old drivers that likely don't > support current HCI hardware. This might actually work: > https://github.com/crazii/USBDDOS/releases/tag/1.0fix2 > ...except that if the mouse is emulated by a TS controller, in DOS > you may face the problem that the coordinates will not be calibrated. > Meaning: at the output of INT 0x33 in text mode, the scale may be off > by several decimal orders. > > The modern Projected Capacitive touchscreens (with a USB HID > interface) typically come factory-calibrated for the native > resolution of the display they come integrated with. No need for > manual calibration, an no public way of doing it. > So if you ran DOS in an SVGA graphical mode matching the display's > native resolution, you would actually have an emulated mouse with > calibrated pixel coordinates - if you can achieve the opaque mouse > emulation, and work with a USB mouse in DOS on your x86 platform. > > Note that the preferred mode of USB TS controllers is not opaque > mouse emulation (the USB HID mouse class as defined in the USB > standard), but their own "USB HID touch panel" device. Apparently not > a USB standard, although it does have a generic driver in MS Windows. > I recall a trouble case involving Windows, where the customer needed > a modern USB touchscreen to deliver classic mouse clicks - whereas > the TS support in Windows ends up delivering "touch events" that are > different from a classic mouse click. > At that time, the TS vendor was polite enough to provide alternative > firmware for the TS controller, which resulted in the TS appearing as > a mouse, and Windows then delivered mouse clicks as desired by the > application integrator. > The TS vendor in this trouble case was SiS/USBest. Not providing a > driver for DOS. > > The morale is: if you have a choice, for DOS on bare metal, prefer > touchscreen products with RS232 output interface (and don't confuse > them with HMI panels). > > As for TS controller brands that I recall having a DOS driver for > their RS232/PS2 models, in descending order by quality of support: > - ELO (perhaps my all time favourite) > - PenMount/Salt > - EETI/eGalaxTouch/Hantouch/TouchKit/D-WAV etc. > - GroovyTouch > - 3M Microtouch > > If you have no clue what touch screen controller is inside, in a PC > at hand, you still have the option of trying different drivers one by > one :-) i.e. throw stuff at the wall and see what sticks. Curiously, > this has often been the case, in the age of RS232 TS controllers, > even if you purchased the PC from a particular vendor. > I still have an archive of unpacked TS drivers for DOS. > Ask me if you need this. > > Note: if you need to run DOS on modern-day x86 hardware, you may face > systems that are UEFI-only anyway. So you won't be able to run on > bare metal. Consider running your DOS app in an emulator / virtual > machine. In that case, you will have an emulated mouse, possibly > aligned just fine to your screen. The HW-specific drivers will remain > to be "someone else's problem" (the hypervisor's). > > If you need to run DOS on bare metal, in a panel PC, try asking ICOP > what they have in that vein. Historically, they've been the last > bastion of various retro x86 operating systems support - though > nowadays they also sell modern ATOM/UEFI-based machines with > Projected Capacitive touch screens and no DOS support. > Some of their older models might serve your needs. > Note that ICOP work with "industrial" product lifecycles, long > availability. > > Frank > > > > _______________________________________________ > Freedos-user mailing list > Freedos-user@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freedos-user >
_______________________________________________ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
