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 will compete with the BIOS USB drivers and lose connection to the USB stick. One workaround is to tell the DOS driver to only take over ANOTHER controller than the one where your USB stick is plugged in. Which ports are connected to which controllers (I assume you do have more than one, as you have 6 ports) is something for trial and error. Also check the documentation of the DOS driver. But again, I recommend to not use USB sticks at all.
Is there any way to suppress that whole bunch of startup output, especially that "Press F8 to trace"
You can disable that by using SYS CONFIG to patch some boot flags in the kernel, as far as I remember.
device = \freedos\jemmEx.exe PGE maxext=4096 noems
Why does the XMS get artificially limited to 4 MB? Do you use NOEMS to get more UMB space? Note that it does not actually disable EMS, it just disables EMS 3.2 compatibility. EMS 4.0 stays available. What are the pros and cons of PGE or NOPGE for you?
country = 049,850 \freedos\country.sys
The syntax seems a bit off?
files = 100
That seems to be a relatively high number.
buffers = 20
You may want to consider fewer buffers, not sure? http://home.mnet-online.de/willybilly/fdhelp-dos/de/hhstndrd/cnfigsys/buffers.htm
set FoxProSWX=+x -t
What do those switches mean? Any other switches that might be interesting to use?
fdapm apmdos
I hope that reduces energy consumption and heat :-)
display con=(ega,437,1) mode con codepage prepare=((437) %DosDir%\ega.cpx) mode con codepage select=437 keyb gr,437,%DosDir%\keyboard.sys
If you need more free RAM, you may want to give MKEYB a try instead of KEYB. I guess you do want to load those CP437 fonts, though? Regards, Eric _______________________________________________ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
