Re: [Freedos-user] Some USB-Stick problems
Hi again, see the new, separate thread for more USB-printer solutions :-) A new thought: I got a VERY good suggestion for the problem of FAT filesystems and file contents getting corrupted by those power outages when the drivers restart the engines of the trucks. You remember, I wondered whether running DOS in some emulator in Windows or Linux would be better or worse, given that those use other filesystems like NTFS or EXT3, not FAT. The suggestion is A LOT easier: Buffer those 12 Volts before you send them to the inverter! No more crashes, thus no more worries which filesystem or operating system suffers most or least from those crashes. I should have come up with THAT. Given that the outages are very short, various solutions are possible. Maybe even something trivial like charging a cap from the 12V through a diode and connecting the inverter to the cap instead of directly to the car battery. Or, for more stability for longer interruptions, charging a small 12 Volts battery, of course. I assume the printers also need 230 Volts? If not, a solution without the inverter might be possible. The Thin Client may even work directly from 12 Volts, but this is out of specs. Regards, Eric ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Some USB-Stick problems
> Next problem: I tried to get printer support via USB (currently they > use classic LPT, but those printers get very rare). Indeed they are. And many modern printers use protocols that aren't compatible with old DOS programs. > But as soon as I load the basic USBUHCI driver, the USB-stick is no > more available, due to reinitialization of the hardware, it seems. > Is there a way to keep the USBdrive as C: available and get printer > support? Just loading USBPRINT (from Bret Johnson) doesn't get a > connection to the printer. According to the specs, you have six USB ports (using a VIA chipset) which means you have 3 UHCI host controllers (each one controls 2 ports). If you load USBUHCI (or preferably USBUHCIL) with no options, it will install itself to control the first one it finds (called Index 0). That must be the one you have your disk plugged into since your disk stops working. What you need to do is install USBUHCIL for /Index:1 or /Index:2. You'll need to experiment to figure out which physical ports are associated with which host controller index. Since you're booting from USB, you're going to need to make sure the printer is plugged into a port from a different host controller than the boot disk is. USBPRINT is only compatible with USBUHCIL, not with the BIOS. You must install USBUHCIL for the host controller index that controls the port you want to plug the printer into, and then install USBPRINT. That should let you use a USB printer (or an old LPT printer and a USB-to-LPT adapter cable) as if it were an LPT printer. You may also need to provide some command-line options to USBPRINT to make sure it virtualizes the correct printer port (I assume you'll want it to be LPT1). ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Some USB-Stick problems
Hi Woody, Unfortunately, using the internal IDE is out of question, since the whole process in that company is used to take that stick after the salestour, go into the office and plug it into a transfer PC, where some other software reads in all sales data, then updates the stick with new tour-data and maybe App- and Freedos updates. Well, you probably have a lot of control over the software, so you could modify it to just use the USB stick as vessel to transport sales data, tour data and updates while the software installation resides on the internal disk. Those sticks could boot into a tool which updates app and tours, checks the filesystem and creates a flag/lock file when done. Booting from the stick again would instead update sales data on the stick. In the office, people could have a tool (maybe a simple batch script) which gathers sales data from the stick, puts new updates and tour data on it and clears the flag/lock file again for the next tour etc. Still pondering non-USB and non-stick solutions: You may also install "extension cords" so people can plug CF cards as IDE storage. My PC has a Wechselrahmen which does let me connect a CF card with a mechanical adapter. I have stopped using it years ago, but you get the idea. There also are adapters with controller, for CF on SATA. Think about Delock 91687 or 91624 which only need a free slot bracket. Unfortunately, the T510 does not have any space for it, even a SATA cable would need a custom hole. Neither CF as IDE nor USB sticks are hot-pluggable in the DOS and BIOS scenario you are using, so there is not hot plug ability to lose, but getting rid of USB complexity still feels like a good thing to try out. Another possibility would be to replace the USB sticks by something which is less sensitive to power outages. Server SSD with supercaps come to mind, connected by SATA or via a simple USB enclosure if you must stick to using USB. Or you could improve the power supply hardware infrastructure. That 4Mb XMS limit was just because FoxPro doesn't need more. There are few apps which get confused when they get too much XMS (for example more than 32 MB of XMS 2.0, or more than 2 GB of XMS 3.0) but I would not manually set any limit unless you really have to to "protect" old apps. Windows 3 also does not like too much RAM, by the way. As said, I suggest that you do not use EMM386 style drivers unless you actually want EMS or UMB. If not, it reduces complexity to only use HIMEM style drivers. mediumtypes for the USB: Floppy, Zip and Harddisk. Those are basically predefined sets of CHS geometry. Floppy goes up to 2.88MB, ZIP is more like harddisk. You usually stick to harddisk and hope that BIOS and OS will use LBA instead of CHS anyway, to avoid any confusion about which geometry would be the best. You can also boot read-only CD/DVD or their images. Most FreeDOS bootsectors (SYS) and kernel autodetect LBA support of the BIOS, but for the FAT32 bootsector, some fixed choice is made when you run SYS, no boot autodetect. The issue of caches, crashes and power outages: You do not have to worry about the read-caches available in DOS, so you should be safe if you close files AND call those disk reset and cache flush calls after that as long as you only get crashes between flushing and the beginning of the next write. You can try to postpone writes during periods when crashes (engine restarts) are likely. This will protect you from getting half-written broken data. As said, DOS itself is barely able to cache anything in the sense of delayed or pooled WRITES. You can actually improve performance using READ caches like LBACACHE. It should not impact your data corruption problem. Only a WRITE cache would make your problem larger. Unfortunately, basically ALL storage media apart from floppy disks have intrinsic write "caching" in the sense that your data will get converted and sent to the actual disk or flash chip AFTER it got sent by the computer. So if your computer crashes while working on your files, unsaved or partially saved data gets lost or, worse, corrupted for obvious reasons. But if POWER to your drive is lost, MORE data can get lost. Some drives use backup energy (supercap or, for harddisk, using their mechanical energy) to mitigate that extra loss. USB sticks, however, are not in that category. Neither are CF cards. Their advantage is just having fewer interface and data conversion layers in the pipeline. Drives also tend to be configurable concerning whether they are allowed to pool or cache written data. Other people here may be able to recommend tools for this, but I would say it is hard to control those settings from DOS for USB drives and more feasible for SATA or IDE drives. In Linux, you would use HDPARM for this. Some drives (in particular some flash models, both SSD and USB sticks can suffer from this) also corrupt more data than necessary or even get completely bricked if a sudden power loss interrupts internal
Re: [Freedos-user] Some USB-Stick problems
Hi Eric, Thanks for your reply! Yes, I meant that T510 boxes. Bad eyesight ;) Unfortunately, using the internal IDE is out of question, since the whole process in that company is used to take that stick after the salestour, go into the office and plug it into a transfer PC, where some other software reads in all sales data, then updates the stick with new tour-data and maybe App- and Freedos updates. Changing that process would mean, that someone (me?) has to get to all those Truck PCs in 5 subsidaries and reconfigure them to use the internal storage for booting and then switch to the external stick for the current app and data. Not that easy to accomplish, unfortunately. Don't ask me, why the original developer did that workflow about 25 years ago, it was running since then with "take the chip (now stick) to the office and get your updates". They added that USB cardreaders because the T510 series don't provide a builtin cardslot anymore. Maybe earlier boxes had them and when they upgraded the PCs they kept the cards and just added those USB attached readers, which itself were another source for errors due to wacky cable and MicroUSB-plugs... Remember: thats all in a vibrating truck. That's why I got rid of them and replaced them with the direct attached sticks. In longterm we are developing a completely webbased solution with handhelds, thus I'm currently just enhancing the 'end-of-life' of that crazy solution and stabilize the data. Ok, that much for the background story. That 4Mb XMS limit was just because FoxPro doesn't need more. Thanks for the NoEms hint! Also that SET FoxProSWX is configuring Foxpros startmode, not related to my problems. Keybord and country settings are also ok and working. As I experimented with different USB formatting tools, I noticed in DiskGenius that this can set different mediumtypes for the USB: Floppy, Zip and Harddisk. Could those have some influence in caching? Rufus does only the 'harddisk' type. I will try a Buffers=1 for testing. Also thanks for the USB insights! Much appreciated! tried to understand the docs from the various USB drivers but got lost in between Jürgen Wondzinski Von meinem/meiner Galaxy gesendet Ursprüngliche Nachricht Von: Eric Auer via Freedos-user Datum: 26.10.23 23:26 (GMT+01:00) An: freedos-user@lists.sourceforge.net Cc: Eric Auer Betreff: Re: [Freedos-user] Some USB-Stick problems Hi Woody! You probably mean a HP t510 thin client, with VIA Eden X2 U4200 CPU, VIA VX900 Chipset, 2 GB RAM, some flash storage, VIA ChromotionHD graphics (DVI/VGA), audio, GB-LAN, Atheros WiFi, 6x USB2, 1x RS232, 1x LPT, 2x PS/2, 65W 19V power brick: https://support.hp.com/us-en/document/c03260067 According to this site, you can connect IDE storage, so a compact flash card with a suitable adapter indeed sounds like a great idea. CF usually support IDE I/O, which means that a simple mechanical adapter with a power regulator is sufficient, no extra controller or card reader necessary: https://www.parkytowers.me.uk/thin/hp/t510/ Depending on the model, the flash may also be SATA instead of IDE DOM (Disk On Module), which is even easier, but the mechanics can be problematic given the small housing of the whole computer. Also, the website says that using SATA SSD may somehow interfere with and damage the network interface (LAN, Broadcom NIC). There also is a tiny Mini-PCIe 1x slot, for WiFi extensions etc. > The app itself was first on a 256Mb CompactFlash Card, which > was attached with a USB cardreader to that PC. Why the extra step with the USB cardreader? > The software booted from that Flashcards with a regular MSDOS6, > no USB drivers etc necessary, seems all is handled by BIOS. When a BIOS can boot from USB, it will often be able to present USB storage as harddisk (or sometimes floppy or CD-ROM), yes. But it will usually not support changing "disks" on the fly. > I then changed those Flashcards to real USBSticks and formatted > them with RUFUS and FreeDOS (Kernel 2043), recompiled their App > and now some "funny" things happen Using USB adds an extra layer of complexity and a BIOS with USB boot support at that time may have been very minimalistic, so for example you may only get USB 1 speed or writes would not be supported or only in slow and convoluted ways. I remember I once managed to boot DOS with Windows 3 from an USB stick on an old PC , but it was no fun to use and not really stable. Also note that certain brands of USB sticks seem allergic to power glitches or getting unplugged at the wrong moment, which can lead to data loss or even bricked USB sticks. Likely a problem with the extra complexity of the firmware running on the stick itself which prefers a clean shutdown. > ... when they restart the engine, the 12V will get powered off > for a short time, thus the PC just crashes and reboots. Nobody likes that, not even DOS. And
Re: [Freedos-user] Some USB-Stick problems
On Thu, 26 Oct 2023 at 22:27, Eric Auer via Freedos-user wrote: > > According to this site, you can connect IDE storage, so a compact > flash card with a suitable adapter indeed sounds like a great idea. > CF usually support IDE I/O, which means that a simple mechanical > adapter with a power regulator is sufficient, no extra controller > or card reader necessary Strongly concur with Eric here. If you can eliminate USB storage, I think that will work better with DOS. -- Liam Proven ~ Profile: https://about.me/liamproven Email: lpro...@cix.co.uk ~ gMail/gTalk/FB: lpro...@gmail.com Twitter/LinkedIn: lproven ~ Skype: liamproven IoM: (+44) 7624 277612: UK: (+44) 7939-087884 Czech [+ WhatsApp/Telegram/Signal]: (+420) 702-829-053 ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Some USB-Stick problems
On Thu, 26 Oct 2023 at 21:13, Jürgen Wondzinski via Freedos-user wrote: > *** > Next problem: I tried to get printer support via USB (currently they use > classic LPT, but those printers get very rare). This could help there: https://www.retroprinter.com/ I interviewed the creator; I can put you in touch, if you wish. -- Liam Proven ~ Profile: https://about.me/liamproven Email: lpro...@cix.co.uk ~ gMail/gTalk/FB: lpro...@gmail.com Twitter/LinkedIn: lproven ~ Skype: liamproven IoM: (+44) 7624 277612: UK: (+44) 7939-087884 Czech [+ WhatsApp/Telegram/Signal]: (+420) 702-829-053 ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Some USB-Stick problems
Hi Woody! You probably mean a HP t510 thin client, with VIA Eden X2 U4200 CPU, VIA VX900 Chipset, 2 GB RAM, some flash storage, VIA ChromotionHD graphics (DVI/VGA), audio, GB-LAN, Atheros WiFi, 6x USB2, 1x RS232, 1x LPT, 2x PS/2, 65W 19V power brick: https://support.hp.com/us-en/document/c03260067 According to this site, you can connect IDE storage, so a compact flash card with a suitable adapter indeed sounds like a great idea. CF usually support IDE I/O, which means that a simple mechanical adapter with a power regulator is sufficient, no extra controller or card reader necessary: https://www.parkytowers.me.uk/thin/hp/t510/ Depending on the model, the flash may also be SATA instead of IDE DOM (Disk On Module), which is even easier, but the mechanics can be problematic given the small housing of the whole computer. Also, the website says that using SATA SSD may somehow interfere with and damage the network interface (LAN, Broadcom NIC). There also is a tiny Mini-PCIe 1x slot, for WiFi extensions etc. The app itself was first on a 256Mb CompactFlash Card, which was attached with a USB cardreader to that PC. Why the extra step with the USB cardreader? The software booted from that Flashcards with a regular MSDOS6, no USB drivers etc necessary, seems all is handled by BIOS. When a BIOS can boot from USB, it will often be able to present USB storage as harddisk (or sometimes floppy or CD-ROM), yes. But it will usually not support changing "disks" on the fly. I then changed those Flashcards to real USBSticks and formatted them with RUFUS and FreeDOS (Kernel 2043), recompiled their App and now some "funny" things happen Using USB adds an extra layer of complexity and a BIOS with USB boot support at that time may have been very minimalistic, so for example you may only get USB 1 speed or writes would not be supported or only in slow and convoluted ways. I remember I once managed to boot DOS with Windows 3 from an USB stick on an old PC , but it was no fun to use and not really stable. Also note that certain brands of USB sticks seem allergic to power glitches or getting unplugged at the wrong moment, which can lead to data loss or even bricked USB sticks. Likely a problem with the extra complexity of the firmware running on the stick itself which prefers a clean shutdown. ... when they restart the engine, the 12V will get powered off for a short time, thus the PC just crashes and reboots. Nobody likes that, not even DOS. And USB sticks like it less than compact flash cards. Would it be possible to use a compact flash card connected directly to the IDE port of the thin client? Or some SATA device, assuming that LAN damage would not be a problem? there seems to be some caching involved. I am not aware of any free open source delayed write cache for FreeDOS, but I am not sure whether BUFFERS can pool writes to some small extent? You already call FDAPM FLUSH when the app ends, but you probably want to modify your app itself, so it can call the flush things itself (no need to use FDAPM then) each time when you close your files after using them. Would it be an option to improve power supply stability? If you boot DOS from USB, you are stuck with the BIOS USB drivers, so you cannot update DOS drivers to solve things. You should probably avoid USB storage completely, given that the thin client supports internal IDE or SATA disks. Even if you need some adapters and even if the - probably not used in the trucks - LAN or WiFi interface breaks, internal disks (CF, SSD, DOM etc.) are protected from the rough street life and are probably more rugged in terms of unplanned power loss or reboot than USB sticks. You could for example use USB just to install one of the computers (I also assume our USB images are meant more as installers than as live images for everyday use) and then clone the internal disk of that PC to create more internal disks for more thin clients :-) That also gives you full flexibility regarding whether to use FAT16 or FAT32 and whether to use only a part of the available disk space etc. With boot images, you could always get unwanted complexity such as embedded boot floppy or CD-ROM images, which you will not suffer from when installing to an internal medium. That said, you can probably just "dd" one of our USB images to a stick in Linux, keeping extra space empty. There must be Windows tools which allow you to just do a dumb 1:1 transfer of our boot stick image to USB. Other people on this list will know other boot stick creator tools for the Windows version you are bound to. Using DOSBOX as a tool for installation feels like at least three extra layers of unwanted complexity. Another recommendation: If you only need XMS and UMB space is no problem, avoid JEMMEX, JEMM386 etc. and consider using only one simple HIMEM or XMGR style driver. Yet another way to reduce complexities. As you have already found out, when you load DOS USB drivers (for USB printers) you
[Freedos-user] Some USB-Stick problems
Hi all, (this will get a longer story, sorry) I inherited a FoxPro/DOS application, which is in use in about 120 delivery trucks. They have a HP 1510 Thinclient with monitor, USB-keyboard and LPT-printer strapped on the passenger seat, powered by a 12V to 230V inverter. The app itself was first on a 256Mb CompactFlash Card, which was attached with a USB cardreader to that PC. The software booted from that Flashcards with a regular MSDOS6, no USB drivers etc necessary, seems all is handled by BIOS. I then changed those Flashcards to real USBSticks and formatted them with RUFUS and FreeDOS (Kernel 2043), recompiled their App and now some "funny" things happen (which they say never happened with the old system) a) They now have often lost clusters, which a chkdsk can repair, but it also can damage the DBFs with their data. b) Some USBSticks get completely wiped out, i.e. they loose their whole filesystem. I tracked those effects down to misbehaviour: they don't shut down the app, and when they restart the engine, the 12V will get powered off for a short time, thus the PC just crashes and reboots. But it's difficult to change that habits. I already rewrote the app so that it opens any data as short as possible and closes all files immediately, but stil there seems to be some caching involved. The config/autoexec currently have no USB-related drivers loaded. Is there anything to tweak in this situation? I already added FDAPM FLUSH at the end of the app bat, but that didn't made any difference. I have attached both files to the end of this mail. *** Regarding the USB-Sticks: I first used 2Gb sticks (to be in FAT16 mode) but those were easily bent and cracked, now I'm using very stable full metal ones, but those are 16Gb minimum, thus FAT32. I tried to put the 2Gb ISO on those 16gb sticks with Rufus, but that thingy just expands the partition to full size. Unfortunately that DOSFSCK takes forever on a 16Gb partition, thus I would like to have only a maybe 256 or 512MB partition (I really need only 30MB for the app and data). Does anyone know a tool to format and partition an USBStick bootable and transfer the files onto it without changing the partitionsize? (Windows tool preferred, because I must remote connect with Teamviewer into those subsidiaries). RUFUS is singled out because it doesn't respect the partition size. Maybe I should setup a DOSBOXX and partition, format and make bootable with separate Freedos steps? (Some command help for that would be appreciated, since those DOS days are prone to some Alzheimer attacks :=) But a Windows One-step tool to partition and transfer the iso would be way more convenient. *** Please take a look at the attached config.sys: that FoxPro app would need 4Mb XMS memory, is that jemmex call correct for that? Or should I use a different syntax? *** Next problem: I tried to get printer support via USB (currently they use classic LPT, but those printers get very rare). But as soon as I load the basic USBUHCI driver, the USB-stick is no more available, due to reinitialization of the hardware, it seems. Is there a way to keep the USBdrive as C: available and get printer support? Just loading USBPRINT (from Bret Johnson) doesn't get a connection to the printer. *** A more cosmetic problem: Is there any way to suppress that whole bunch of startup output, especially that "Press F8 to trace " etc ? Thanks for any pointers! wOOdy from Bavaria, Germany *** Config.sys: set lang=DE set dosdir=\Freedos device = \freedos\jemmEx.exe PGE maxext=4096 noems country = 049,850 \freedos\country.sys files = 100 buffers = 20 *** Autoexec.bat: @echo off set Drive=%DosDir%\.. set Path=%dosdir%;%Drive%\Fox; set Temp=%Drive%\temp set FoxProCFG=%Drive%\fox\config.fp set FoxProSWX=+x -t set DirCMD=/P /ONG /4 fdapm apmdos display con=(ega,437,1) mode con codepage prepare=((437) %DosDir%\ega.cpx) mode con codepage select=437 keyb gr,437,%DosDir%\keyboard.sys cls rem start the app hbw.bat ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
