Re: [Freedos-user] cannot boot installation media
Dear Mr. Ramos, > - Balena Etcher > - Rufus > - Untebootin > - Win32DiskImager. interestingly to me, you don't mention the trusty old `dd` ... :-) Have you tried looking for a BIOS update? I have, but the HP support website does not respond to the "Presario 427" search query. Maybe it would respond to a "product code", if that label on the underside of the machine is still readable. In the video linked below, there's a motherboard partnumber N14JP6-V2, apparently shared with "HP Compaq 420", for which there is still some historical support (a BIOS available for download) - hard to say if this would fit your laptop or brick it. The Presario 427 seems relatively modern, but could be an oddball, especially if it shipped with Linux. By the time this product was released, Presario was a budget line under HP, a decade and a half after the merger of Compaq with HP. The 427 might be specific to a particular "sales region" on the globe. And, name-brand machines are not unknown to have peculiarities in the BIOS, especially if they are local oddballs, of which the brand disclaims responsibility on a global scale... Hmm. Looking at this screen: https://youtu.be/Ymro4opGIKI?t=119 So... you're saying that the USB stick does not appear on offer? Mind the line "USB Key Drive BBS Priorities" at the very bottom. Only in this video, the boot mode is configured to "UEFI only", so it's not a good example. Do you have more than one USB mass storage device plugged in, by any chance? :-) As for booting from USB mass storage: by the time your Presario launched, booting from a USB stick had been available in the BIOS for well over a decade - now with all the bells and whistles, I'd say. Apart from USB CD/DVD and Floppy, i.e. speaking only of physical "USB hard drives" (USB mass storage in HDD mode), I know of two styles of how the medium can be laid out: A) as a hard drive, i.e. having a legacy BIOS MBR + partition table B) having just a single filesystem all across the surface, i.e. the FS boot sector is in LBA sector 0 (= where the MBR is in var.A). Also known as "floppy layout" (not to be confused with a native USB mass storage floppy). Veteran FreeBSD folks would call this the "dangerously dedicated" layout. Perhaps your BIOS makes a difference between these two variants? :-) Most modern BIOSes don't. I recall in Award 6 series BIOS, on some desktop motherboards, there was a SETUP option for you to pick what to expect on the hard drives: MBR, "floppy" (dangerously dedicated) and "auto" - where Auto was the default and would never give me a problem. Also, in the "partitioned" variant (= A), the partition start/end offsets are aligned with some ultra-legacy structure of Cylinders/Heads/Sectors. There actually used to be at least three schemes in the ancient days (nineties), often called "CHS, LBA and Large". (The modern fdisk variants trying to align to 2048 sectors per track, rather than 63, is a mere benign deja vu.) However bogus these alignment schemes are, on non-fossil ATA/LBA disk drives and USB Mass Storage, I still remember an era when BIOSes made a fuss about this alignment making sense, i.e. you had to pick and match the right one for your BIOS - but that era ended maybe a decade prior to the birth of your Presario machine... I've also seen my "mouseclick-happy" colleagues "write an ISO image onto a USB thumb drive", often using Rufus - not sure if Rufus does just a verbatim block copy of ISO image onto the USB Mass Storage LBA address space, or it dissects the ISO and copies individual components onto the USB thumb drive which it duly formats (i.e. if Rufus knows enough about the layout of modern Linux distro installers to rehash them in this way). My guys next door actually do this with Windows installer ISO images too, I believe... might also work owing to the UEFI boot sequence, not sure. One last question/topic maybe: The BIOS in the video (linked above) appears to have a small USB options menu, where you can enable/disable two ports individually. The machine originally came with Linux. Do you still have Linux in the box? Or, can you boot some Linux installer? Basically some kind of Linux instance that would tell you, if it can see your USB thumb drive or not. The one you're trying to boot FreeDOS from. Should be visible in dmesg and /proc/partitions. What does Linux fdisk or sfdisk tell you about the thumb drive? Can you boot other operating system installers from the thumb drive? No ready-made recipe, just my two cents worth... Frank > > Thank you Bob and @Norby Droid. > > I am aware of that, I didn't just copy the files to the USB stick. As > I was trying multiple methods, I used a variety of programs to > generate the half-a-dozen bootable drives that I tried. I used: > > - Balena Etcher > - Rufus > - Untebootin > - Win32DiskImager. > > I'm starting to think there's something wrong with my USB drives. I > have a bunch but they're not
Re: [Freedos-user] How can I make FreeDOS display correctly the â
> I also had this problem, For some reason, the ã > is missing from codepage 850. If that's true, I would call this a bug in the FreeDOS EGA.CPX ...? Just fabulating, I haven't analyzed this deeper. Frank ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] How can I make FreeDOS correctly display the "ã" character?
Let me suggest the following hypothesis: Your FreeDOS and graphical hardware is running with the HW-default code page, known as Code Page 437. https://en.wikipedia.org/wiki/Code_page_437 Whereas, you're trying to display text encoded in CP850. https://en.wikipedia.org/wiki/Code_page_850 CP850, aka PC Latin 1, which is not the same as ISO Latin 1. Perhaps your keyboard is already switched to produce CP850. You probably need to run some program(s) to load the right codepage into the graphics card. I don't have a ready-made and tested recipe for you... could be something like: In config.sys: COUNTRY=055,850,C:\FDOS\BIN\COUNTRY.SYS In autoexec.bat: DISPLAY CON=(EGA,850,2) MODE CON CP PREP=(437,850) C:\FDOS\BIN\EGA.CPX) MODE CON CP SEL=850 maybe also: CHCP 850 Further reading: https://gitlab.com/FreeDOS/base/cpidos/-/tree/master/DOC/CPIDOS http://home.mnet-online.de/willybilly/fdhelp-internet/en/hhstndrd/base /display.htm http://home.mnet-online.de/willybilly/fdhelp-internet/en/hhstndrd/comm and/chcp.htm http://home.mnet-online.de/willybilly/fdhelp-internet/en/hhstndrd/base /cpidos.htm http://home.mnet-online.de/willybilly/fdhelp-internet/en/hhstndrd/cnfi gsys/country.htm https://marc.info/?l=freedos-dev=99788711909602 (examples look more like MS-DOS than FreeDOS) Frank > > The "ã" is a very common character in Portuguese. It shows up in > words such as "não", "alçapão", and "órgão". > > The system's keyboard and layout are already configured to "br" (for > Brazilian Portuguese) and working perfectly. Other accentuated > characters display just fine. That is the case of "á", "à", "ô". > However, "ã" shows as something else entirely. Image below: > oIh6TW8.png > > How can I get FreeDOS to correctly display those characters? > > Thanks! ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Dial-up emulation?
Here is a neat summary of the DOS PPP drivers: http://www.oldskool.org/guides/tvdog/internet.html#I ...but, someone has already raised this question: Do you have a "counterpart"? I mean - a dial-in service answering with a modem and a PPP stack. Or at least a null-modem connection to a PPP "server", such as pppd running on Linux. Or possibly Windows running the "server side of RAS" would work too. You have mentioned that one of the PC emulators contains a "Hayes modem emulation". What is the use for that, exactly? What does it do? Suggestion: it answers to a few AT commands, including ATD, to which it responds with CONNECT, and puts you through onto a serial line - either a physical outside COM port, or e.g. an emulated virtual COM port in your host OS (where the emulator / VM is running). This might be useful to bamboozle some old DOS software, that insists on dialing out a modem (when accessing a serial line for whatever final purpose) - while in reality all you have is a null-modem cable, or a virtual equivalent thereof. The other option would be, that the "modem emulator" also provides the "server side PPP stack", effectively to set up a network connection, probably TCP/IP (although in principle, PPP can encapsulate other L3 protocols, such as Novell IPX/SPX or MS NetBEUI if I have all the ancient buzzwords right). Note that theoretically, at some sub-layers, PPP is really symmetrical, a conversation between equal parties. The client/server distinction stems from one party asking the other to authenticate, again using a modular mechanism supporting several protocols. For your practical purposes, these details are somewhat esoteric... Should you be interested, try reading RFC1661. If you don't insist on PPP / dial-up, and you really mean "I want to open Google in Arachne", just go down the "packet driver" route. You will save yourself quite a bit of hassle (configuring PPP). If OTOH it is the pain that you are after, go ahead with PPP client side and server side :-) and the follow-up networking stuff on the server part. Frank > > I'm not looking for anything out of Qmodem specifically. I'm > searching for a TSR that handles dial-up networking in the background > while I use TCP/IP utilities like PING, TRACERT and FTP; and/or a web > browser like Arachne. > > Brandon Taylor > > > From: Frantisek Rysanek > Sent: Wednesday, April 24, 2024 4:52 PM > To: Brandon Taylor via Freedos-user > > Cc: Brandon Taylor > Subject: Re: [Freedos-user] Dial-up emulation? > > Hello there Brandon, > > to me the key question is - what do you expect of Qmodem? > What would you like to achieve in / by using that program? > I've never used it, but I figure it would be a "terminal emulator" > with some added candy. An analog (predecessor, really) of Putty or > Hyperterminal in Windows. > > A terminal was originally a hardware device, having a screen and a > keyboard. I believe the rows of text on the screen were an evolution > / innovation after line printers. The text no longer rolled on paper, > now it rolled on a screen. The terminal needed to connect to > something, typically a relatively large computer (like an early UNIX > or mainframe machine), and the computer presented a command-line > interface to the user using that terminal. A single server could > cater for several terminals simultaneously, already back then. > > Later, when PC's and other computers became common-place, the > so-called "terminal emulator" programs allowed you to use your PC > (which is a pretty versatile computer) as a dumb terminal = to > display what arrived by an RS232 serial line, and to send your > keystrokes to the opposite party. You can actually connect two > terminals (or emulators) together over a cross-over RS232 line (also > called a Null Modem) and chat with each other... > > A modem is a device that originally allowed two parties to connect > over a phonecall, via the POTS/PSTN (telephone network). You first > needed to talk to your modem a little, to have it dial out the call. > If the call got picked up by an opposite modem, the two modems would > establish a "virtual serial line" spanning potentially hundreds of > kilometers. You could then chat or transfer files with a friend > (terminal emulators supported file transfer protocols such as X-modem > and Z-modem), or there were machines called "bulettin board systems", > nowadays I'd call them early servers, that you could dial into to > download or upload files, maybe do a bit of messaging... I don't > really have much of a clue what these could do, because this was > before I got my hands on a PC with a modem :-) Obviously you could > dial in remotely i
Re: [Freedos-user] Dial-up emulation?
Hello there Brandon, to me the key question is - what do you expect of Qmodem? What would you like to achieve in / by using that program? I've never used it, but I figure it would be a "terminal emulator" with some added candy. An analog (predecessor, really) of Putty or Hyperterminal in Windows. A terminal was originally a hardware device, having a screen and a keyboard. I believe the rows of text on the screen were an evolution / innovation after line printers. The text no longer rolled on paper, now it rolled on a screen. The terminal needed to connect to something, typically a relatively large computer (like an early UNIX or mainframe machine), and the computer presented a command-line interface to the user using that terminal. A single server could cater for several terminals simultaneously, already back then. Later, when PC's and other computers became common-place, the so-called "terminal emulator" programs allowed you to use your PC (which is a pretty versatile computer) as a dumb terminal = to display what arrived by an RS232 serial line, and to send your keystrokes to the opposite party. You can actually connect two terminals (or emulators) together over a cross-over RS232 line (also called a Null Modem) and chat with each other... A modem is a device that originally allowed two parties to connect over a phonecall, via the POTS/PSTN (telephone network). You first needed to talk to your modem a little, to have it dial out the call. If the call got picked up by an opposite modem, the two modems would establish a "virtual serial line" spanning potentially hundreds of kilometers. You could then chat or transfer files with a friend (terminal emulators supported file transfer protocols such as X-modem and Z-modem), or there were machines called "bulettin board systems", nowadays I'd call them early servers, that you could dial into to download or upload files, maybe do a bit of messaging... I don't really have much of a clue what these could do, because this was before I got my hands on a PC with a modem :-) Obviously you could dial in remotely into a UNIX machine and work in its command line "shell" = work with files, read and send e-mail, use NNTP newsgroups and whatnot. All of the above was possible using a PC with a modem and a terminal emulator - I assume your Qmodem belongs to this category. I wouldn't call this usage style "the internet", except maybe in a very broad sense :-) RS232-style async serial lines, and their modem-based long-distance extensions, were also useful for other styles of traffic. As a side note, I'd mention UUCP, as a distributed worldwide e-mail system, predating TCP/IP-based SMTP (in practical popularity, if not by actual age). There were in fact several e-mail standards before SMTP, and UUCP was one of them. UUCP was an "open standard" - unlike other e-mail protocols/systems that were proprietary. RS232-style direct lines and modem connections can also be used to transport TCP/IP - in case this is what you mean by "internet". To "encapsulate" IP packets over an async serial line, you need an intermediate layer, called a "layer 2 protocol" (IP is layer 3). See also the layered ISO/OSI networking model (of which the Internet is not a verbatim implementation). So for serial links, there were two popular L2 protocols: SLIP and PPP. During that era, PPP pretty much took over - being generally more advanced / flexible / extensible... more suitable to the age of mammoth modem pools and dial-up internet access. To start PPP, you generally need two things: 1) a piece of software that talks to the modem, to make it dial a number, and wait for the modem to establish connection (the modem reports CONNECT and maybe some further info). You can do this by hand in a terminal emulator, or by a script, or by a dedicated unattended piece of software called a "dialer". 2) an implementation of PPP. After you dial the modem connection, you need a way to hand over the established modem session to a PPP "driver" (protocol talker). On top of PPP, you can then run a TCP/IP stack, which in turn gets used by "internet" applications such as e-mail clients, web browsers, FTP clients and whatnot (you can also run a server with a PPP connection to the internet). For instance, Windows since 95 have an ex-works "connection software" called "Microsoft Dial-Up Networking" (if memory serves) or RAS in the NT-based Windows - which combines an unattended dialer + PPP stack, and can transport TCP/IP (or other protocols) over that. You can also run PPP over a direct RS232 connection (null modem) or over a pair of leased-line modems. Async serial modems in leased line mode create a permanent connection, and do not respond to Hayes AT commands. In these cases, you do not need a dialer (item 1 above). As for Internet in DOS: Both MS-DOS and FreeDOS can connect to the internet. But, the first question is, what sort of "experience" you expect
Re: [Freedos-user] COM Port in AMBIOS - specifications for TouchScreen?
Thomas in the unlikely scenario, that the driver you have gets you
nowhere, I can provide the unpacked DOS drivers I have in my archive,
for RS232-based TS controllers by 3M, ELO, GroovyTouch, PenMount, and
eGalax=TouchKit=HanTouch.
I have one more suggestion. Divide and conquer.
You may want to test if the COM port on your computer is allright.
The easiest way is to use some terminal emulator program, combined
with a physical loopback. The simplest loopback plug is a paper clip
stuck in DB9F hollow contacts 2 and 3. Which ones are those? Pin
numbers 1, 5, 6 and 9 should be faintly printed/embossed on the DB9
connector body. You need a strong light and good eyes, or a magnifier
glass.
For a terminal emulator, I used to know a free program called
Jean-Com or JCOM for short.
http://ftp.lanet.lv/ftp/mirror/x2ftp/msdos/programming/serial/jcom174d
.zip
I've just checked it out in DosBox, to refresh my memory...
After starting jcom.exe, do not initialize modem ("n").
To configure the COM port, use Alt+P.
I suggest that you change the default 7E1 to 8N1.
COM port and baud are probably clear.
You can then save the settings to a file, within this menu.
Note that flow control gets configured elsewhere: in the Alt+Z menu.
And, the setting doesn't seem to get saved in the file = it is
ephemeral.
You do need to disable both XON/XOFF and RTS/CTS, for a simple
loopback between pins 2+3 to work.
How do you know that it works?
Try typing something in the basic screen of the terminal.
If the loopback is plugged correctly, you should get an echo = you
should see whatever you're typing.
You can also try plugging in your TS controller.
I don't know the microtouch serial protocol...
But, chances are, that if you configure the right baud, and you touch
the screen sensor, you may see some data filling the terminal screen
in JCOM. Or maybe not. If the controller needs some init to start
spitting coordinates. I.e., if you see something, it means the
controller works. If you don't see anything, that's not a proof that
the controller is broken, or your cable is broken, or something.
Heheh take a look at this:
https://multimedia.3m.com/mws/media/367149O/ex-ii-serial-controllers-r
eference-guide-1710-1720-1750-7720.pdf
Page 18.
9600 8N1, and the controller should start sending data to you upon
touch.
There are also some commands - among the simple ones, you can try the
null command or the diagnostic command. That, provided that you can
send the leading byte 01 hexa. I haven't found a way of doing this in
JCom, apart from maybe
some scripting. Maybe by sending "ASCII" from a file (Alt+S). Not
much practical use anyway - just to see if the controller responds as
expected.
Frank
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] COM Port in AMBIOS - specifications for TouchScreen?
COM ports at legacy ISA (-like) addresses are still available in a plethora of "industrial"/embedded motherboards and computers in various oddball mechanical form factors. And, quite often there are four or even six of them. Sometimes not all are available at coastline DB9 connectors, some may be inside on dual-row headers... The COM ports are nowadays typically implemented using LPC SuperIO chips, and the SuperIO UART's of today are fairly decent, which historically wasn't always a rule :-) Typically only up to 115200 bps and a 16B FIFO, but no weird quirks, and apparently even IRQ sharing works, with the stock Windows driver - which is slightly surprising, on an ISA work-alike bus. The LPC chips from Nuvoton (ex Winbond), Fintek, SMSC and ITE can contain 2 or 4 or even 6 UART's, and you can have two LPC SuperIO chips in the system. The highest total number of LPC SuperIO UART's that I've seen together on a motherboard was probably 10. The BIOS typically contains a dedicated menu for the SuperIO config, where you can configure the IO addresses and IRQ's for individual ports. It's typically very smooth and trouble-free. If you have just four COM ports, you can typically use higher IRQ's such as 10 and 5 for COM3 and COM4. On a modern motherboard, in a modern OS, most peripherals are on the PCI-e and do not need the legacy ISA IRQ's - except maybe for the disk controller while still in legacy BIOS compatibility mode (no APIC IRQ's, no MSI's). There are also PCI-based and PCIe-based UART's from Exar and Fintek (historically I liked Oxford Semiconductor UART family very much). These PCI(-e) based devices have no problem with IRQ sharing, have 64 to 256 B of FIFO and speeds up to a megabit (or more). Only... not sure how much use they are in DOS ;-) In the industrial PC niche, a machine typically has a COM port or two, capable of RS422/485. The UART's are (almost) the same as for RS232, the difference is just in the level-shifters (line drivers) - though it is a sign of good taste if the motherboard maker uses an LPC SuperIO chip that can drive an RS485 level-shifter by a dedicated signal, basically the "Transmitter Shift Register Empty" made available on a GPIO pin or RTS or some such. The modern BIOS typically has all-around good support for the LPC SuperIO COM ports, announcing them properly via any relevant interfaces to the operating systems (ISAPnP, ACPI, DMI...) Thus, Windows or Linux typically just report all the onboard COM ports without any extra effort required. Apologies for getting off topic :-) Frank > Typically, that is the correct address for com1. Com 2 is IRQ 3, and > 2F8. Com 3 and 4 if they are supported by the bios are 3E8, and 2E8 > generally. > > I've unfortunately never had a dos machine with all 4 com ports active. > I've used com 3 or 4 periodically with an additional com card, but it > didn't have both com ports on it, and I never had a motherboard that > supported all 4 com ports, but the address 2E0 is not typically > associated with a com port, neither are the various IRQs listed in the > snippet below. Normally the com ports are on com 3 and 4, though I > think it was possible to switch irqs for com3 and com4 to be on > different irqs, in case you wanted to use multiple com ports at the same > time. > > (multiple being more than 2 at a time in this case). > > Part of it may depend on the software you're using to access the com > port as well. The driver should handle the translation to/from irqs and > port addresses, so you may not need to worry about that, but you do need > to know what to talk to on your end of the connection to make it all work. > > I've only used screens like you're describing on SBC (single board > computers) like the propeller board from parallax, so I can't offer > anything else to point you in a direction for troubleshooting other than > what I've offered above. Perhaps something here will make a connection > and you'll be able to solve it. > > > > On 3/17/2024 5:10 PM, Thomas Cornelius Desi via Freedos-user wrote: > > For some experimental reasons I got a 19« 3M Touchscreen for the RS-232 > > Port. > > (I attached the VGA cable and the RS-232 cable on both sides) > > (The monitor is functional as a monitor-only. Seller tells me touch > > function is working…) > > > > > > > > My question is about the RS-232 COM1 port. > > > > The AMBIOS (my BIOS on the machine) says that the COM1 port address is > > > > 3F8h/COM1 Enable onBoard Serial port 1 and address is 3F8h. > > > > > > > > > > - I am installing from a USB Stick (= c:\) (=source drive?) > > - port address I wrote: 3F8 > > - interrupt Number: 4 (??? no clue) > > > > The DOS driver directory the seller sent me contains some installation info, > > the examples given differ much from what I set and - of course it does NOT > > work. > > > > Any ideas someone around? > > > > Much appreciated, > > regards, Thomas > > > >
Re: [Freedos-user] COM Port in AMBIOS - specifications for TouchScreen?
In my archive, I have a copy of some driver package for 3M MicroTouch. Not sure if it matches the one of yours. The directory contains the following files: DOSPANEL.EXE DOSPANEL.HLP DOSPEN.EXE DOSTOUCH.EXE DOSTOUCH.INI DOSTOUCH.OVL MCAL.OVL MICROCAL.EXE MICROCAL.HLP MTCONFIG.EXE MTSFONT.BIN QCAL.OVL QUICKCAL.HLP TGCAL.EXE It is unpacked, "after installation". Thus, I can use it from PXEbooted DOS on any machine, and can change the configuration ad hoc, without reinstalling. I tend *not to* rely on DOS-based installers very much. Specifically the installers of touchscreen drivers are sometimes quirky. I prefer to browse the unpacked directory and see how it fits together and what I can tweak by hand, knowing the correct parameters. My DOSTOUCH.INI contains the following: ; DOSTOUCH Version 3.4 INI file ; The following lines are examples for solving SVGA problems. ; ; OEM VESA XOff X YOff Y ; mode mode T X Y set Size set Size ;CalibrateVideoMode= 30 1 80 250 1023 85 853 ;DefaultVirtualSize=800 600 [DOS Touch Screen] TouchMode=2 ClickSpeed=4 AudibleClick=1 CursorOffset=25 CommPort=1 CommIRQ=4 BaudRate=9600 I'm wondering if I can be of further help. Maybe check what you have after installation and let's see where we can go from there. Generally, try the EXE files one by one. They may throw errors, and the messages may or may not be useful :-) With some vendors, you need to have the INT 0x33 "mouse driver" (resident) installed first, for the other utils to work. With other vendors, the detection and calibration utils need to run on a clean system *without* the driver - and you only start the driver once the config tools produce a config file for you. Calibration is an interesting topic. It can happen in software on the host (the mouse driver needs to be configured by a calibration tool), or with some vendors the calibration parameters can actually be stored in the TS controller, so that the mouse driver then obtains calibrated coordinates from the hardware. Then there's the nuance between text mode and graphical mode, and multisync etc. You may need to calibrate for your desired video mode. I've also seen software that would not use an external mouse driver, and would talk to the TS controller on its own, using its own routines... (and own calibration tools) Some vendors of industrial computers have mess in their documentation about what model has what TS controller, and your best bet is trying to find out "the hard way" = on RS232 you have no device ID's to go by, so you really end up trying different vendors' drivers :-) but I guess we can believe your supplier for starters. Also, note that hardware and drivers in DOS can indeed be borderline tricky - although COM1 at 0x3F8 with IRQ 4 should be no problem. If you have that chance, try plugging your TS into some computer with Windows (or Linux, if that's your preference) and try the Windows driver. If it shows signs of life in Windows, at least you now know the vendor. Frank > For some experimental reasons I got a 19« 3M Touchscreen for the RS-232 Port. > (I attached the VGA cable and the RS-232 cable on both sides) > (The monitor is functional as a monitor-only. Seller tells me touch function > is working…) > > > > My question is about the RS-232 COM1 port. > > The AMBIOS (my BIOS on the machine) says that the COM1 port address is > > 3F8h/COM1 Enable onBoard Serial port 1 and address is 3F8h. > > > > > - I am installing from a USB Stick (= c:\) (=source drive?) > - port address I wrote: 3F8 > - interrupt Number:4 (??? no clue) > > The DOS driver directory the seller sent me contains some installation info, > the examples given differ much from what I set and - of course it does NOT > work. > > Any ideas someone around? > > Much appreciated, > regards, Thomas > > > driver info=== > > DOS Only Installation: > > From the installation drive type: > > INSTALL k: /Axxx /Inn > > k source drive > xxx port address: 2E0, 320 or 330 > nninterrupt number: 9, 10, 11, 12 or 15 > > The software is copied to > > c:\mts\touch > > You will see that the installation program tries to connect to the touch > controller by varying COM port speed and parity and, if found, sets the > line parameters to > > 2400baud > 8 data bits > 1 stop bit > no parity > = > > > > ___ > 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
Re: [Freedos-user] SNMP agent for DOS?
On 11 Jan 2024 at 22:06, Eric Auer via Freedos-user wrote: > > Hi Anton, > > > The machines are indeed physical with custom made ISA Bus controller > > cards, built on prototype board, and only 4 were made, 2 in production > > That sounds exciting! > > > plan is to eventually replace ... with something more ubiquitous. > > Looking at other forums, people do impressive things combining old > and new hardware. For example there are tiny modern microcontroller > based extension cards for old PC, emulating all sorts of classic > boards, people convert from TV to HDMI using DSP based boards and > DOS expert RayeR is working on a way to connect classic ISA sound > cards to modern mainboards through the LPC bus on the TPM header! > > For more general purpose things, Raspberry Pi style computers can > be a good option, natively running Linux, sometimes other operating > systems, or emulators for retro operating systems inside Linux, > while at the same time offering a variety of GPIO and bus systems > suitable for different control projects. > > Have a good evening, too! Eric > This is my long-term "food for thought". Keep the old (often DOS-based) system going, especially if you have docs and source code, vs. rebuild from scratch using %your_favourite_contemporary_technology% . On my job, selling hardware to people who have a longer planning horizon / end up being themselves long in the tooth, I've met several individuals and systems that are at the heart of some company's business "in real life", and are difficult to replace. The living of a manufacturer may depend on such one-of-a-kind system. The general idea may be: try to avoid stuff that's obscure. Whenever possible, i.e. when doing an overhaul, you need to replace an obscure solution with something more manageable in the long term = open, modular, better structured, more future-proof, with a long/infinite end of sale. Makes me wonder what that would be. DOS and ISA-based hardware have been around for what - 40 years? You can still purchase a new x86 computer to run DOS, with ISA slots, from companies like Advantech and ICOP (you will possibly have to combine parts sold by the these two, in a PICMG setup). If you have the source code, and there are people around who grok it... that's a relatively fine situation, innit? :-) Replace such an old solution with something that's based on Linux and e.g. the RPi. Note that the RPi is a proprietary platform. Yes it's been around for a decade or so. But: are there any clones / is there offspring? There are certainly work-alikes and friends, all of them with a lower market share, none of them binary compatible. This is only future-proof as long as new pieces of the hardware are available, and the "ecosystem" around = the build environment, installationg media, perhaps a card reader for the boot disk (microSD) and whatnot. Speaking of x86, for instance, by now physical 3.5" floppy drives are a problem, and parallel IDE isn't easily around either, anymore. CD's are getting out of fashion, to the point of becoming nearly extinct... So: whatever platform of SW and HW you choose for your future-proof system, you'd better purchase a crate of spare parts while they are available :-) and make a thorough data backup and precautions, that will allow you to keep the "build environment" or at least the "deployment aids" alive into the future. People building things on Windows and PCI a decade ago are facing these issues right now! Compared to the old days of ISA and DOS, moral longevity of both hardware and software has *shortened*, and there is a tendency to make all the stuff more proprietary, more turn-key, more "vertically integrated" i.e. your special PCI(-e) device is no use whatsoever without a signed driver for your particular current OS version, which won't boot on a new computer two years down the road (as there won't be drivers for the disk controller for your current OS version). There are "temporal windows of backward compatibility", but typically not very long, factual compatibility is always subject to practical testing = never certain beforehand. It's actually getting difficult to install the same binary-identical OS version from scratch again a few years down the road, etc. Emulators and hypervizors are all fine, but tend to separate your OS instance from bare metal. We don't even need to speak modern OS versioning and compatibility maintenance. In the plant process control, there are parts such as analog interface adaptation converters (AKA "barriers") = amps, isolators, level-shifters, filters. 20-30 years ago there were fine parts in this category that in the meantime have been phased out without a direct replacement - as to the function, not to mention pin-compatibility. Now... there are systems whose functionality or "control task" is relatively simple, and attainable by various means. For many purposes, any PLC on the market, from any
Re: [Freedos-user] SNMP agent for DOS?
On 8 Jan 2024 at 10:29, Michael Brutman via Freedos-user wrote: ... > > Obviously something that does real-time operations should not be > burdened with a TSR. But it should also not be burdened with running > DOS on legacy hardware either. Nobody in their right mind is running > something safety critical on old PC hardware running DOS, so assume > there is some room for slop in the workload. > I do meet people relying on a DOS app on old hardware every once in a while. They end up having an ancient DOS box controlling a key piece of machinery in the shop or something, sometimes not having a backup of the OS boot drive, afraid to open the hood on the PC etc. As for SNMP, I have once tried to write a client, from scratch, to do some simple queries. "Just a quick hack." There were comprehensive libraries at the time, that did stuff like convert ASN.1 MIB source code into C++ classes and then compile that... it dragged along a heap of dependencies, which I did not want to port from UNIX to Windows, so I started with a hardcoded minimal set of C++ objects to manipulate ASN.1 BER to implement what I needed... I got it to a stage where the queries principally worked, and then the skunkworks project got shelved, I left the job, things shifted IRL etc. Frank ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] SNMP agent for DOS?
On 7 Jan 2024 at 21:28, Anton Gustafsson via Freedos-user wrote: > > Hi Roderick! I agree, in this case it is mostly to satisfy my > supervisor's need to follow protocol. All machines in the network are > supposed monitored (load, mem, swap etc) using a software called Zabbix > which has the ability to use either their own agent, ICMP or SNMP. > > It is possible to use Zabbix without an agent, and for example only > check availability over ICMP pings. It is a slight workaround, since the > actual frontend on Zabbix shows hosts as unavailable when not using an > agent, though they it is possible to configure the system not to send > "host_down"-emails. There seem to be disagreements within the Zabbix > developer community whether this is a bug or a feature. > > Anyway it feels a bit redundant since these machines are custom hardware > controllers and are integrated in the rest of the process system, and > the control room interacts with these machines continuously. > DOS is not a multi-tasking OS, does not have a process scheduler and only uses a single CPU core. There's a single application running in the foreground, having total control over pretty much everything, and that's it. Yes you can have "resident" pieces of software (aka TSR) that remain loaded and "can do things in the background", but that "background" is just a piece of the CPU time, principally spent in an interrupt service routine. While the TSR is doing its thing, the piece of software in the foreground is asleep. Not knowing the details, I'd suspect that a feature-complete SNMP stack might easily turn out to be quite hefty. SNMP is not necessarily a CPU hog, but a decent SNMP software stack will be neither simple, nor minuscule in the RAM. Allright, desktop software (and its users) are normally tolerant to a bit of lag here and there. If you're speaking Industrial Process Control, that's a red flag. (Are you?) You have a piece of legacy control software running in DOS, assuming that it has the whole machine for itself, likely relying on deterministic timing and response to incoming events. The software is possibly running a tight loop clocked by the system timer and/or interrupts from some dedicated I/O peripherals. Losing critical CPU time to a nosey SNMP monitor is generally not an option! And there is no CPU process scheduler to sort tasks by priority. Spending too much time in an ISR is a big no-no. And, anything running in the normal foreground context (i.e. outside of an ISR) has a lower priority than any IRQ. Yes, IRQ's can be ordered by priority, but it generally requires programming of the IRQ controller. This isn't something you want to do to unsuspecting legacy control software "behind its back". So apart from that principal problem above: Roderick has already mentioned DMH software. I also recall Lantronix having an SNMP module for their Xport line of miniature "terminal servers" (serial-to-ethernet gateways) - the old Lantronix had an embedded x86 environment similar to BIOS/DOS, not sure about the current product line. Both are principally SDK's, providing SNMP in the form of a library, documentation and "interface bindings" for some programming environment, that allows you to add the missing bits specific to your project or platform. I.e., to deploy these SNMP products, you need to do some programming. The DMH SNMP API probably depends on DMH's own TCP/IP stack, which in your case would be a second TCP/IP stack besides the Microsoft stack... not sure if they can run side by side and share a NIC... The Lantronix SNMP module depends on Lantronix hardware and a particular development environment. Not really made for generic DOS. Yet again, apart from the problems mentioned above: Someone in this thread has already raised the question: *What* would you want to monitor, in a PC with DOS? DOS doesn't have a CPU scheduler. Means you cannot quite monitor CPU usage, as seen by the OS. You *could* monitor a select few CPU MSR's, related to system power management - the current state of EIST/TURBO, and the CPU core temperature. Provided that your (legacy?) CPU's support those HW features. Note that in DOS, the CPU never goes IDLE, and therefore the CPU's own internal power management will see the CPU's "control unit" as active all the time (100% CPU utilization). You could possibly hazard access to a SuperIO HW monitor, which has information about fan RPM and voltages. Are there any disk drives involved? These have SMART - but I don't think there's a BIOS service for SMART, or for crafting your own ATA command and passing that to the BIOS disk service... = you'd probably need your own disk driver, and circumvent the running system's disk driver to avoid an unhandled race condition... If the control system had some interface, such as a page of RAM at a "well known address", or a "software interrupt" for that purpose, you could theoretically take some variables from
Re: [Freedos-user] What DOS programs represent the 1980s and early 90s?
Oh guys, to me the era nowadays is not so much about particular software programs - it's about fond memories of many things blasting off all at once. You probably know what happened by the end of 1989 in DDR, CZ+SK and elsewhere in the eastern bloc. E.g. our neighbors in PL had a bit of an advance start, but to us in CZ, 1989 was the year that the wall came down, with a practical change of govt. actually taking place in early 1990. That's also when the borders to the west have opened in practical terms / the iron curtain was ripped into pieces, western consumer goods and computer hardware started flooding in via various channels (official and not so official). In the summer of 1990 I was aged 14, I just finished the elementary school (at the time it lasted 8 years) and got smoothly accepted to a highschool (called Gymnazium in this part of the world). And, the highschool had a room or two with obscure eastern 8-bit computers, which were hardly any practical use, apart from a pacman clone and Basic. I believe in about 1990-1991, the school also got a room in the attic with about 10 shiny new PC's and a small server, networked using 10Base-2 Ethernet. The PC's were diskless 386SX at about 20 MHz, about 1 MB RAM, the brand was "Data Media Corporation" if memory serves. I have no clue how the school got hold of those - in retrospect, at the time in my country each of those PC's must've been worth an annual wage of my father (if not two or three). And, while I was not in the "programming" class, I had access "outside of the curriculum" - owing that to the liberal access regime (allowed by the headmaster), and a polite network admin / IT teacher on site. I really cannot thank them enough. I certainly remember a lot of games... speaking of fading echoes of the eighties, I figure Larry Leisure Suite would be about right :-) But perhaps the one fond memory is borrowing a book from the school's computer admin: a manual to Borland Turbo Assembler, and reading that from A to Z in a few days. This was the closest to an x86 ISA reference book that I could get at the time :-) Not that I achieved much in bare TASM, beyond the Hello world. There was no internet. There was a city library with a few relevant books. There were maybe two relevant monthly mags. The BBS stuff was initially inaccessible to us mere mortals. Hell a PSTN telephone line at home has only reached us in mid nineties I guess. Modems were not much practical use and very expensive. I had my first encounter with modems and some BBS sites in mid nineties (after "graduating" from the highschool) already in parallel with my first e-mail address at the university... I believe the uni ran e-mail in the LAN over Novell file sharing, the client was Pegasus (possibly managed by Mercury at the server). Apart from Pegasus in DOS, I recall using a Gopher client, and an early Mosaic HTTP browser on a few odd PC's that were beefy enough for Windows. Not that the web was much use at the time - until search engines appeared, Netscape came about and things started rolling. To us east of the iron curtain, the PC's have gushed in rather abruptly after 1990. Kids of my generation have skipped the 80's DOS, and the first practical Windows version around was 3.11. The first PC's in my eyesight were 286, and my first PC at home was a 386DX/40 in about 1991/1992, I believe it had a Biostar mobo = a Taiwanese clone. That's where the slope has really begun for me :-) Owing that to my parents BTW. The PC (and my typing skills) also had some use in my mom's small consultancy business at the time, so it was not a pure toy and has "paid for itself" within its lifetime. The programming class at the highschool (= not me) got some serious headstart into algorithms etc. The school engaged a teacher in his fifties I guess, a slim white-haired pro, apparently with proper education and relevant practice. All the school had at the time was Pascal with objects, but looking back I have to say that he taught the stuff the right way and he knew what he was doing. I recall that two of the best students coded a software app in Borland Pascal with Turbovision for creating daily/weekly teaching schedules for the school. A pretty advanced piece of software, considering use of objects / "dynamic data", the data model, and the algorithmic manipulation / application of constraints etc. Classes getting split 50%/50% for some subjects and whatnot... I don't recall the details, but I remember output on fanfold paper via an A3 dot matrix printer, using a fixed-width font with "line" characters for the table/boxes. What a time to be alive, even as a lone computer nerd in a "humanities" class... that's where my English originally comes from BTW. The "programming" class wasn't nearly as heavy in foreign languages. Apart from the computer nerdy side of things, the grip of Commies was gone almost overnight, overlapping with my later teenage
Re: [Freedos-user] How do I change screen resolution?
Hi there, nice to see that you're trying to tweak old software to fit on modern screens... still I have a cold shower for you :-) Sorry about it. Not sure where DOS borrowed its "terminal" / console code, whether CP/M or UNIX... the fact is, that in the way of "support", the DOS console lacks quite a bit of flexibility, compared to modern terminal emulators running in the windowing GUI. Namely, DOS doesn't seem to support or understand an arbitrary number of rows or columns. As others have pointed out, the choice is quite limited: https://gitlab.com/FreeDOS/base/mode/-/blob/master/SOURCE/MODE/MODECON .C?ref_type=heads#L266 https://gitlab.com/FreeDOS/base/mode/-/blob/master/SOURCE/MODE/MODECON .C?ref_type=heads#L151 http://wiki.freedos.org/wiki/index.php/Mode So much for support on part of DOS, which practically means the command line itself, plus maybe some apps that rely on DOS for the console display (which ones are those?) A part of the problem is, that most software for DOS handles the video resolution and video output itself, directly with the hardware, typically using the VGA+VESA BIOS services to configure a resolution (if more than the classic 80x25 text mode is supported by the app). Some software understands 43 or 50 rows too - various Borland TurboVision TUI's and some file managers, if memory serves. But, that's about it. The source code to FreeDOS "mode" command speaks even about 60 rows text mode support, which is interesting. Some 2 decades ago, I sometimes used that in Linux at the text-mode console. Type vga=ask at the kernel command line, etc. The other key aspect is, that without detailed knowledge of your proprietary video hardware, you likely need to select one of the graphics modes offered by the VESA BIOS services. On graphical cards of the general "SuperVGA category", i.e. more modern derivatives of the legacy original VGA, the VESA BIOS typically offers a plethora of high-res graphical modes (addressed per pixel) and also some text modes, addressed by the character. There was also a resident extension called UNIVBE, which could add support for some modes on some popular hardware that shipped with a shoddy VESA option ROM. And this selection of VESA BIOS modes, is exactly what you get offered by the Linux "vga=ask", and what you can use in DOS, if your software supports the higher VESA VBE modes. To get a listing of available VESA modes in DOS, I recall a tool called VESATEST. Or was it VTEST ? Possibly this one: https://archive.org/details/msdos_VESA24_2_shareware Apparently that was written in 1993. Also my friend Rayer has written something: http://rayer.g6.cz/programm/programe.htm#VESATEST The current version is from 2018... If the VTEST shows you a text mode with 60 rows and about 132 characters, you can try supplying that one to "MODE CON COLS= LINES=". But it will only work in the pure DOS prompt. As already mentioned, various apps will mostly not respect this setting, and will set the video mode based on their own respective historical preference. I've just stumbled over a page that points to various VESA/VBE-related proggies for DOS: https://dosdriver.de/graph.php You may also find or write some tool to ask the BIOS for just any supported VESA mode, including graphical, and exit to DOS without switching the mode back to 80x25. Sometimes you'd end up in this state after a game has crashed gracefully enough to return. You can see the command.com working, characters do get displayed, the graphical modes often do support the BIOS text-mode output routines too - but the cursor probably won't blink, you may still be limited to 80x25 text-mode characters, and there are possibly other downsides, including the risk of a sudden freeze. Also, the DOS console code is not aware of the actual resolution of the screen, and keeps running in 80x25 characters (or whatever it was before). Times they are a changin'. While a character terminal with an 8x8 or 8x14 font size on a full HD display may look like punk to us greybeards, the same font size on a 4k display is clearly a case of "why bother". Technically no problem in Linux, and yes I have tried. Frank ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Can you recommend a good single-board-computer for legacy OSs?
On 10 Mar 2023 at 11:13, Mart Zirnask wrote: > Just for reference, I'll share some of my bookmarks. > I'm just a shy hobbyist, not an engineer whatsoever, but I've been > interested in fanless, small form factor DOS computing solutions for > quite a while. > We are a similar blood type. Only I happen to have been working in this toystore for 20 years :-) > EBOX-3100: Vortex86 400MHz, 1GB RAM, VGA, SeaBIOS, enclosure -- this > one seems like the most "complete" solution: > https://www.compactpc.com.tw/products/item/21 > FYI, compactpc.com.tw is another sibling company of the DMP holding. Therefore, similar to ICOP, "they also have their own CPU" = the Vortex86. AFAICT, CompactPC are more on the consumer/office side of the business - in terms of temperature range, form factor and the general feature set. The particular EBOX model that you've pointed to seems a bit of an oddball to me. The Vortex86EX is junior to the Vortex86DX that I've mentioned before. IIRC, the Vortex86EX is originally an "embedded" CPU = intended for vehicle onboard computing, machine control and whatnot. It shows in several respects: - a relatively lower CPU clock - some special peripherals: ADC, multichannel motor controller . - an integrated 80C51 MCU core for general use https://www.vortex86.com/datas/upload/site/2019042310373055.jpg https://www.vortex86.com/products/Vortex86EX Similarly to the DX, the EX does not have a VGA subsystem on chip either - but, in contrast to the DX, the EX does not have a parallel PCI - instead, it has a single external lane of PCI-e. Therefore, this particular computer has a dedicated VGA chip - on PCI-e, rather than the neat old Z9s on the PCI. This dedicated VGA on PCI-e is possibly something "own" by DMP, possibly related to the on-chip integrated VGA of the Vortex86DX2/DX3. In the computer that you're referring to, its nominal maximum resolution is 1024x768. Which doesn't seem like very much. The SeaBIOS looks cool! This is the first piece of hardware that I see from the DMP corp that has anything else than AMI. I can see that eBox PC's with Vortex86DX no longer exist. No more XGI Z9s for the consumer segment. Interestingly, that chip could only produce 1280x1024 maximum on the ICOP boards, despite 32 MB dedicated RAM. But, eBox PC's with the Vortex86MX are still listed. This one has on-chip integrated VGA, with a maximum resolution of 1920x1200. And, there's a DX3-based version that can do 1920x1080 (on-chip integrated VGA). Note that these VGA subsystems can only do basic 2D acceleration (blitting and such), no 3D, no video playback accel. > Various DOS SBCs by JK Microsystems: http://www.jkmicro.com/Products.html#dos > Interesting... I didn't know about this brand. They have some pretty old legacy stuff, starting from a 386... > Various Vortex86 SBCs: https://www.emacinc.com/products/pc_compatible_sbcs/486 > The SBC models mentioned at that link are made by ICOP. > Categorized as "legacy" on the home page: > SAT-DX4 - 133 MHz SBC with video and ethernet: > https://www.winsystems.com/product/sat-dx4/ > I didn't know this one either. The particular board model looks like an ultra-classic (legacy) 486DX4, but it smells to me of the pioneer days: a non-standard form factor, two sockets for the DiskOnChip... Doesn't appeal to me very much. (I still remember the relief and exhileration, when the CompactFlash arrived and the DiskOnChip landed in the scrap bin.) Frank ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Can you recommend a good single-board-computer for legacy OSs?
wow, gentlemen thanks for the feedback. Hardly ever happens to me, after such a wall of text... Seems like we have a shared interest :-) Frank ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Can you recommend a good single-board-computer for legacy OSs?
...oops, I have a small typo correction: > Note that Vortex86, especially in the DX2 generation, is pretty close > to machines of the 486 / Pentium era. > actually I meant the Vortex86DX, not the DX2. (The DX2 is actually moving away slightly from the old-skool bare metal.) Frank > It's got a proper, full-blown > ISA bus straight from the SoC, and also 32bit / 33MHz PCI. > The DX-based boards by ICOP come with an XGI Z9s graphics chip that > has something like 32 MB of dedicated Video DRAM and is accompanied > by a pretty good VESA BIOS, where good = decent compatibility with > DOS-era software. It can run Windows up to XP, although for XP the > onboard 512 MB of RAM is already hardly sufficient. Graphics drivers > are available for the Windows 9x and NT. ... ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Can you recommend a good single-board-computer for legacy OSs?
On 8 Mar 2023 at 2:15, Ben Hutchinson wrote: > > My current laptop computer is a Dell Inspiron 7559. It has this cool > feature where it lets you go into the firmware settings at bootup > with F2. Then you can disable "Secure Boot" after which you can then > enable "Legacy BIOS". This lets me boot my computer via USB stick > with a copy of DOS (whether MS-DOS or FreeDOS). This is a nice > feature, and while the computer is like almost 10 years old, I hope > most modern computers (especially the SBCs that I'm looking for) > still have a dual-firmware system like that, where you can use either > UEFI (for modern OS's) or BIOS (for legacy OS's). > Yes, 10 years ago sounds about right - at that time, UEFI was new, and the modern OS'es with UEFI support didn't have enough of a foothold to allow "wintel" to force UEFI upon you = prevent you from using older operating systems. Today, mainstream machines no longer support legacy BIOS interfaces. They haven't for a few years. You have a better chance with industrial PC's (and embedded motherboards) - the IPC vendors have kept the legacy BIOS compatibility module (the CSM) in the UEFI much longer, exactly because this market segment is conservative. But even in the "industrial" market segment, the times they are a changin'. The "firmware modules" (binary blobs) that come from Intel to BIOS/UEFI vendors (AMI/Phoenix) are apparently increasingly hostile / preventative to including a CSM in the UEFI image. So the motherboard vendors perhaps no longer have a choice. I don't have stats / keep track, but starting from say Kaby Lake and Gemini Lake, the CSM is a rare occurrence. Speaking of small-format x86 SBC's, if I should keep promoting ICOP, take a look at this proprietary form factor: https://www.icop.com.tw/product_list/44 That's 100x66 mm. This is ICOP's smallest that allows you to plug a few break-out cables / pigtails (included in the box) and start working. There are smaller SoM's that need a custom carrier board (PCB). Frank ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Can you recommend a good single-board-computer for legacy OSs?
On 7 Mar 2023 at 23:06, Ben Hutchinson wrote: > > On Tue, Mar 7, 2023, 5:14 PM Volkert via Freedos-user > wrote: > > You might look for products based on a Vortex86 SoC. Those have > > a legacy BIOS and can boot MS-DOS and older Windows versions > > and such. > > [ + a link to the Vogons forum, which has links to ICOP] > > I'm looking for one that's mass produced, just like Arduinos and > Raspberry Pis are mass produced hobbyist computer boards. The only > problem with those is they don't support intel CPU instructions. > I'd like to second the advice given by PM Volkert: you should definitely take a look at the Vortex86 family, namely on motherboards made by ICOP, or miniature PC boxes by some other sibling company in the family around DMP and ICOP. Note that Vortex86, especially in the DX2 generation, is pretty close to machines of the 486 / Pentium era. It's got a proper, full-blown ISA bus straight from the SoC, and also 32bit / 33MHz PCI. The DX-based boards by ICOP come with an XGI Z9s graphics chip that has something like 32 MB of dedicated Video DRAM and is accompanied by a pretty good VESA BIOS, where good = decent compatibility with DOS-era software. It can run Windows up to XP, although for XP the onboard 512 MB of RAM is already hardly sufficient. Graphics drivers are available for the Windows 9x and NT. With the Vortex86DX, you get an AMI BIOS with APM support (no ACPI), with AT-style power supply control. The more modern Vortex variants (up to DX3, at the time of this writing) are faster, maybe up to on par with the early 45nm ATOM's, they have more RAM onboard, their BIOS adds ACPI support, but these newer Vortex platforms start to depart slightly from the hardcore "oldtimer DOS experience". Vortex86 by DMP / ICOP is the last remaining supporter of the DOS era. You won't buy any other new hardware with a comparable set of old-skool features. Speaking of "mass-produced"... I'm not sure to what extent you are aware of the functioning of the market of PC computers. I myself work in the "industrial PC" business, so I'm aware of this niche that may slip under the radar of a typical home/office PC user. The mainstream mass-produced gaming/home/office PC's have a pretty short product life cycle and are subject to the latest marketing trends and fads. A particular motherboard model is available for maybe a year. Say 6 months to 2 years. You get a truckload (cargo ship load) of a particular motherboard model produced for stock, that stock gets depleted in a few months and will never come back. By the time that batch gets depleted, a newer model is already being mass-produced. Etc. The industrial PC HW market is different. The customers demand product lifecycles that last many years, preferably forever. The quantities sold are minuscule, compared to the mass market. Maybe 10% of the mainstream market, if you summarize across a CPU generation. The production batches are typically much smaller, compared to the mass market - but, the production runs do repeat, as long as demand lasts, and as long as chips are available. The chip-level lifecycle is longer. The stumbling block is the CPU and chipset - nowadays often merged together conveniently in an SoC. For the embedded/IPC market, the champion in product lifecycle and volume sold remains Intel (not AMD). In the product pages at ark.intel.com, mind a note here and there saying "embedded SKU options available". The word "embedded" here correlates to the specific IPC market niche, and an extended availability, often for a decade or almost. Note that this IPC/embdedded motherboard market does not run along with the evolutionary bleeding edge: instead, it seems to pick up mature CPU generations as they're phased out from mainstream availability. Courtesy of that conservative approach, in the industrial x86 market you get stable silicon (already after several iterations of early bugfixing revisions), stable motherboard PCB designs (industrial ATX motherboards can actually be fine-tuned siblings of previous generation mainstream models), stable BIOS and bugfixed drivers. If I return to the arrangements of "manufacturing and order-processing logistics" : there are differences between industrial PC vendors. Generally only the biggest vendors try to keep stocks in regional warehouses - say Advantech is a prime example here. Advantech themselves appear to work with non-trivial production batches - as a result of which, often the particular model that you're after is not in stock at the very moment when you'd need it, and you have to wait for a few weeks for the next production run + logistics. Returning customers tend to calculate with these lead times. Also, chances are that the boards are actually in stock in a warehouse near the production line, and in the EU or U.S. you can pay extra to have your motherboard delivered directly, thus saving maybe 2-3 weeks off the low-cost
Re: [Freedos-user] Can't see USB stick
I'd like to second Tom's opinion. If memory serves, MS DOS understands FAT32 since about version 7 or 8 (present in Windows 95/98) and Freedos since when I remember = could be version 1 or so... Did you perhaps confuse FAT32 for NTFS or ExFAT/FAT64? Frank On 3 Nov 2022 at 10:53, tom ehlert wrote: > Hallo Herr Travis Siegel, > > > Dos doesn't handle fat32 devices by default. You'll need to load the > > proper drivers and configure things properly for it to recognize fat32 > > partitions. > > [ disagreement ] ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] DOS ASM resources
...somehow those two URL's got fused together:
http://ref.x86asm.net/coder32.html
http://www.eji.com/a86/
Frank
On 2 Jul 2022 at 15:08, Bryan Kilgallin wrote:
> Ben:
>
> > http://ref.x86asm.net/coder32.htmlhttp://www.eji.com/a86/
>
> {Not Found
>
> The requested URL was not found on this server.}
> --
> members.iinet.net.au/~kilgallin/
>
>
> ___
> 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
Re: [Freedos-user] Difficulty with serial communications
Gentlemen thanks for sharing your thoughts, and for suggesting to "make one's own hardware" as a solution. The explanation about the nature of the RPi ecosystem (forking the hardware being encouraged by the RPi foundation) was particularly interesting to me. That said, in my everyday reality, the integrators and customers of various sorts would probably refrain from making their own motherboards. The more adventurous types make connector adaptor boards or that sort of simple stuff - but make a motherboard? Oh no... Regardless of how relatively easy it is, nowadays, to have PCB's etched and assembled, making your own motherboard is still considered "something for the other end of the supply chain". I myself have used allpcb.com on several occasions for some relatively crude gadgets - but routing a DDR3 bus or decoupling the power rails to a GHz-level CPU, no thanks :-) Have a motherboard designed by someone who's got the know-how. Mkay... :-) Make a custom carrier board for a COM-ETX or Q7, that sounds more plausible, because the high density and high speed stuff is confined to the CPU module that gets purchased whole, from a motherboard vendor. Unless you're seasoned in the business, PCB-level HW design takes several iterations before you get things right. Especially for industrial use. And it doesn't even have to be a "difficult environment" (dust, Ex, passive, difficult EMI etc). Making things all passive with a CPU that consumes 5-10W is not that difficult. Avoiding "routing typoes" in the various aspects (EMC, thermals, circuit stability) is probably the part that's difficult. Im saying this based on various design glitches that I encounter while troubleshooting the hardware that we sell... I know... a nitpicker is the one who's not willing. Who's motivated, looks for ways towards the goal... I applaud Kunbus for going all the way with their industrial Revolution PI. In the context of market segmentation, they're in the right place: they are a vendor of PLC-style hardware, supplying the broad market, and therefore they make their own motherboards. The R costs are spread over a broad customer base. Pulling off something at that level for a one-off project sounds moot on several fronts: in terms of the business model, the development process, possible lead times... BTW, regarding USB, the first difference is in the transfer rate: 100 kbps vs. 1.5/12/480 Mbps for USB 2.0. And, USB1/1.1/2.0 is using a mixed signaling style, with pull-down and pull-up resistors for early slow handshaking, and with half-duplex operation on a single signal pair for data. All in all, USB especially 2.0 is far from easy to isolate. Frank ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Difficulty with serial communications
On 8 Feb 2022 at 23:03, Eric Auer wrote: > > How about a Linux with proper RT config and drivers, > maybe even on a Raspberry-style computer to do I/O > with that ancient A/D converter hardware? ;-) > > Depending on how many channels you need, you could > also try something like Red Pitaya: > > https://redpitaya.com/ > > Some USB scopes also support 16 bit modes at low > sampling rates, with data streaming. But I guess > you need real-time reaction and USB is evil :-) > > Given that Bret has this "use RTC IRQ at 1024 Hz to > sort of poll those un-IRQ-able events by hand", you > may assume that 1 ms scheduler clock is not horribly > hard with GHz CPU clocks even on Raspberry et al. > > Depending on the hardware, FreeRTOS might help, too. > > Cheers, Eric > Hello Eric, thanks for chiming in... Yes I know all that, I've even played with RTAI a little, years ago, that's where I learned how to mask SMI sources for instance... if memory serves, I was able to service an IRQ at up to 5 or 10 kHz if there was not much to do within the handler. USB per se... I wouldn't be so concerned about the timing delays (I've learned that the system need not respond within one scheduler cycle of 1ms), but IME, USB is a pig for "industrial control" for other reasons, more mundane: the bus is not galvanically isolated and only any good for the shortest interconnects (susceptible to EMI), sensitive to cabling quality, sensitive to power inrush spikes (in DC-powered systems with a switch in the DC rail), in my practice even the "port soft-reset" is not very reliable... some of the woes boil down to the fact that the USB ports are implemented in the chipset/SoC and don't use line transceiver chips / level shifters (compared to serial lines for instance). In the wild practical environment, USB is "fragile". Troubleshooting USB-related glitches in "iindustrial" deployments is almost my daiy business :-( Speaking of RPi, the vanilla RPi is somewhat popular and there's a chance that the product would be available for some time... but its "form factor" is woefully inadequate for industrial use. There's a German company that's used the open source basis of the RPi and has built a product line of PLC-style machines on top of that https://revolutionpi.com/revolution-pi-series/ and they seem to have a nice analog input module: https://revolutionpi.com/analog-io-module/ On the scale between "obscure and vendor-locked" vs. an open solution, guess where I place this... How future-proof is this. Maybe if all the software was made to be source-level platform independent and portable e.g. between ARM/x86/RISC-V, there would be some assurance of future maintainability... Red Pitaya is a wonderful piece of hardware, but again, on the scale of vendor-lock and obscurity vs. future-proofness... ahh well. My direction of thinking is more in the way of "if this was based on the PC and Linux, and I/O interfaces in the form of PCI(-e) boards, and the project maintainers would pay attention to having at least two I/O board models of each "class" available as products, with drivers ready and working with the "control framework", with the wiring harnesses solved, that's what might be called a future-proof solution. Of all the operating systems on the market today, including various free and commercial RTOS, only Linux appears to always have drivers for recent hardware (motherboards and CPU's) and have a somewhat assured maintenance. Obviously any future prospect is just my subjective guess, based on the status quo of the past two decades. Perhaps the project wouldn't even need hard realtime (RTAI or some such), perhaps a fast-paced timer interrupt (or even just the system scheduler tick at 1 kHz) with a high-priority thread would do the job. That, while paying attention that the timing-critical box is not distracted by other loads. Regarding long-term HW availability, a different approach might be: decide on the solution, develop it, have a target "scale of deployment", have it running for a few years to get stats on HW failure rates, and before EOL, purchase enough hardware as spares - I wouldn't be afraid to suggest 2x the volume of hardware in production deployment at target scale. Based on past experience from this particular project. In terms of man-hours required to develop a software framework for process control like that, my idea is like a year of a dedicated coder's time, for basic functionality, not speaking about nice "integrator-level programming interfaces". It takes years of human developer time to build a plausible SCADA system... A single guy doing the coding, and all the hardware integration? Ahh... no way in just one year, I would say. It would take a team, working over several years. For long-term sustainability and maintenance, preferably a team of two people who would be "mutually replaceable". And the freetard in me suggests that a good way to have a chance of someone
Re: [Freedos-user] Difficulty with serial communications
On 7 Feb 2022 at 21:58, Michael Brutman wrote: > > This has all been terribly interesting, but I can't help but think: > * This product should have been ported to a more capable operating > system years ago. > * The inner workings of how the product was made to run under DOS seems > to have rotted away. > Sounds like it has been ported. I understand that the point is to avoid forklift upgrades of old PC hardware in existing deployments = avoid fixing things that work, requiring manpower that possibly isn't really there. One last (I hope) note on this = excuse another life story: Unrelated to Mr. Haywood, I have this other veteran/retired customer, supporting a [misc heavy industry] company of some sort, running a handful of DOS-based control PC's with obscure I/O hardware (fast-paced low-latency 16bit DC-referenced analog input), and an amazing but abandoned/unmaintained/closed-source modular multi-tasking real-time control system (1 ms scheduler clock) written in Borland Pascal :-O The management at the [misc heavy industry] company must've seen the writing on the wall for well over a decade. Reportedly, the tight timing and some other special sauce (fuzzy controllers, discontinuous/hysteretic controllers, non-linear noise filtering) is so exquisite in the old system that it's darn hard to find anything more modern off the shelf that would serve as a replacement. I mean - even just a RAD environment for PC-based industrial process control, or some brand of PLC's. So apparently the management just leave the old system to its moral decay, and the old bard (my integrator customer) keeps the system floating by the skin of its teeth. The other management-level option would be to hire some (non-existent?) talent to rewrite the thing from scratch in some more modern environment that would - meet the RT timing and control requirements - have the required algorithms / modules, or be extensible enough to allow the integrator to write the missing software blocks - be architecturally future-proof: the OS and the control software and the hardware IO, all layered / modular / replaceable, and long-term available. - the [misc heavy industry] company should demand source code. I know about various RTOS brands, and Linux with RT extensions, or even just vanilla Linux on appropriate hardware, with appropriate config (and application SW architecture). Apart from the programming effort required, relatively the most difficult part is getting industrial-grade analog input with open-source drivers (or register-level documentation) - yes there are analog input PCI(-e) cards, but the industry has moved away from open HW docs to closed-source drivers for the current issue of operating systems. The PCI(-e) bus interface on modern industrial IO cards is a custom FPGA-based job. I also know about PC-based and other HW available from National Instruments - some of it embedded and dedicated to RT control. NI are a powerful and lasting brand, but to me the jury is out, to what extent such a solution would be future-proof across proprietary platform EOL's and whatnot. I expect my veteran integrator customer guy to go away one day, and the frantic management of the [misc heavy industry] company to come hammering on me to revive their system - of which I barely know the PC hardware, have disgust for their dependence on every last byte of UMB+HMA, have seen a glimpse of the ancient Pascal-based software, but have no knowledge of the control-level configuration etc, and no spare parts anymore (compatible CPU boards, analog input boards, signal conditioning barriers etc). It's gonna be interesting when the * finally hits the fan. > * This really isn't relevant to FreeDOS. > you're right... apologies. Mr. Haywood I suggest that we move our debate into private e-mail. Mine should be visible in my messages. Frank ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Difficulty with serial communications
On 8 Feb 2022 at 0:17, G.W. Haywood via Freedos-user wrote: > Just a quick 'thank you'. > entirely welcome... I'm always happy if my superficial scribbling helps someone. > Yeah, sorry, I realized that after I hit 'ctrl-X' (that's what passes > for clicking 'send' on my mail client, which doesn't use a mouse... :). > mmm... Pine? Fond memories of my first jobs and perhaps some courses at school... I have recently installed (al)pine on a Linux machine where I needed local "administrator access" to some IMAP mailboxes that are read-only to their nominal IMAP users... > > ... I'm wondering if your extender uses or produces DPMI, or > > possibly predates DPMI in the flow of evolution... > ... > > ... DJGPP compiler ... > > Through all this I've been wondering about the compiler. The one I > use for DOS is still the one I bought from Zortech, before they got > taken over by Symantec. Imagine that, buying a compiler! Apparently > I ran into dozens of issues, and eventually worked through or around > them all, but if I find myself using new libraries or a different DOS > extender just to get PCI interrupts working I might not be able to > build everything with the old compiler. Scary. > You don't have to explain that to me. The very essentials of the standard C library library might be somewhat portable, but there's the old DOS environment with its specific ways, specifics of the ancient compiler+libc, specifics of the extender. No way you'd try to port that to something more modern still in DOS, just to add improvised support for PCI-based plain UART's, while they're still available... Not in the context of the production deployment that you've explained the last time around. I mentioned DJGPP+CWSDPMI merely to "decorate my code snippets with the related environment they live in". If all it would take was write a stand-alone real-mode TSR wrapping a "trampoline interrupt handler", you could probably get the job done with your favourite assembler - and it would probably not be my recentish favourite NASM. I myself am no longer a teenager. Aged 46 I have some coding past behind me. And, coding is not even the substance of my day job. And I know the feeling when I come back to a piece of code that I wrote a decade ago, and I try to re-start the simple "build environment" (say just mingw) and I realize that I've changed my Windows machine and OS twice in the meantime, that DOS binaries no longer run directly in 64bit Windows, and there are other pitfalls building 32bit programs in modern 64bit mingw... and reading my own code feels like having a deja vu reading someone else's piece :-) Once, after a long pause from coding in C++, recalling the old quirks and corner cases and workarounds felt like I was uprooting a piece of nasty weed from my grey matter... Kind of hard for me to imagine what it's like to return to your own creation from 30+ years ago. I recall my father watching me rummaging in his crate of DIY electronics creations in a dusty attic, when I was a kid. He kept going like "ohh yes, that was *this* gadget I was trying to build..." There were some tube-based radioes and cuproxide and selenium rectifiers, and some later stuff with discrete Germanium... Frank ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Difficulty with serial communications
Dear Mr. Haywood, thanks for all the praise... of the two of us, you are the veteran and the teacher. I just happen to be spending too much time trying to troubleshoot various random bugs in PC HW+SW, trying to devise a problem reproduction method, maybe point to a root cause, and ask the vendor for help. My old teenage hobby and habit to read everything about x86 register-level programming is just a bit of an aid on this job... I don't really have much time for proper programming. Every once in a while I manage to code some simple troubleshooting tool. Unfortunately, messing with the APIC's is not among my past "projects" :-( On 6 Feb 2022 at 11:25, G.W. Haywood via Freedos-user wrote: > > ... broken BIOS (DSDT) and PCI-e, where turning on "noapic" would > > result in a combination of "legacy ISA and legacy PCI" IRQ's below > > 16, combined with MSI used for PCI-e peripherals ... > > Urgh. Looks like I might be writing more pages in my notes. > That was probably too much of an "explanation shortcut" on my part. The hardware had some "APIC IRQ's" (16-23) misrouted in Linux when done via ACPI. There was a stuck peripheral and a different IRQ line screaming spurious interrupts. Falling back to the "boot IRQ's" (any IRQ's moved under 16 and shared) did work around that ACPI table bug. At the same time, Linux was able to use MSI for the several PCI-e devices in the system that were actually capable of MSI, thus alleviating the IRQ line sharing nightmare. I recall Realtec NIC's and some chipset-integrated peripherals ran with the MSI. > > I've done a bit of googling ... > > I've spent days! > Again, the amazement is mine, at your life experince - and your willingness to dabble in these tech toys apparently so late in your carreer. > > ... and found some relevant details. > > Sounds like with your experience you might be better placed to pick > search terms than I am. :/ > :-) Just a few days ago, on that "mission" troubleshooting a power management bug in modern CPU's, after writing some tools of my own, and running a diff between two MSR dumps = between a "good" and "bad" machine, I googled something like "bit 1 in MSR_CORE_PERF_LIMIT_REASONS" and I got a precise answer. A pointer to a particular Intel erratum. That, followed by me banging my head against the wall for a bit - how come that Google didn't tell me earlier :-) Before, while I kept asking about "CPU stuck at low frequency" or some such, I got heaps of forum threads where people kept asking the same question, receiving typically just superficial answers... It's just luck in phrasing your questions, and maybe having some very specific keywords available. > > ... Not sure if it's enabled by the BIOS, and thus, if you merely > > reprogram the IO-APIC to use direct delivery of a particular GSI to > > the desired IRQ 3 vector, if a corresponding config in the LAPIC is > > needed: ... > > Well I could just try it. :O > Shouldn't be too complicated to test this in a one-off / dedicated little program. Then again... I've tried googling some more, if someone has tried messing with the APIC's on his own, and the examples turn out to be pretty complex. https://stackoverflow.com/questions/57373473/ Relevance rating: 60% (there's lots of text that's uninteresting to us) The following recipe doesn't use APIC's, it's a general demo on how to enter protected mode and what to do once you're in: https://wiki.osdev.org/User:Johnburger/Demo It's pretty ancient and it doesn't rely on DPMI, but it does mention the IDT and the legacy vector table (IVT)... Relevance rating: 20%. Returning to Michael Chourdakis, try reading this from the heading "ACPI and APIC": https://www.codeproject.com/Articles/889245/Deep-inside-CPU-Raw-multicore-programming That appears to approach the IO-APIC and LAPIC access from a very no-nonsense angle - only I suspect it is not the whole story. Looking into his github repo https://github.com/WindowsNT/asm (I actually downloaded the code to a local hard drive to be able to grep) I can see the following track of crumbs to the desired IO APIC base address: in file acpi16.asm, look for function DumpMadt . That's where the IO-APIC base address gets retrieved. It gets called from a nearby file code16.asm . I haven't tried tracking the whole code flow upstream from there, but it should give you a recipe on how to get your hands on the IO APIC. Without engaging a full-blown ACPI table interpreter. Relevance rating: 80-90% ? But, I also have a tangential note to make: it turns out that the LAPIC (the one baked to the CPU core) has an EOI register = End Of Interrupt = the ISR has to ACK this. This means to me that you won't be able to simply program an IO-APIC + LAPIC to call the old vector for IRQ3 directly - *and be done with it*. You'd probably get a stuck IRQ line for your PCI card, because noone would ACK the IRQ to the LAPIC :-/ To me, this means "back to square one", as
Re: [Freedos-user] Difficulty with serial communications
On 6 Feb 2022 at 16:24, G.W. Haywood via Freedos-user wrote: > On Sun, 6 Feb 2022, Eric Auer wrote: > > > A quick thought... Given how fast modern CPU are relative to > > serial ports, could you just set a periodic timer to poll > > the status of all serial ports in case configuring their > > interrupts on PCI is too tricky? And then let the poll > > handler invoke your serial interrupt handlers when needed? > > Thanks for the thought. Frankly I don't know if the performance and > reliability of anything which tried to do it that way could ever be > acceptable but I doubt it. In any, er, event it would need a lot more > development and testing (which would be prohibitive) than a rewrite of > the interrupt handling code. > Last time I tried, a single inb() or outb() on a parallel 32bit 33 MHz PCI would cost me... not sure if 500 ns is the correct number (or was it 2 microseconds?) How often does your dogwatch() routine run? What sort of response time do your terminal users expect? Such as the echo time when typing characters. The modern multiport PCI and PCI-e UARTs tend to have large FIFO buffers, 64B per port or even more = there's hardly a chance of losing keystrokes if you poll once per second, let alone every 50 ms or so. Frank ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Difficulty with serial communications
On 5 Feb 2022 at 0:48, G.W. Haywood via Freedos-user wrote: > As I > said in my OP I had to modify some of the cards because they couldn't > share interrupts properly, by cutting traces and inserting switching > diodes to do the 'wired or' kind of thing. > Yes. I recall ISA multiport boards by Advantech that had and extra "register", implemented by a CPLD, that worked like a 3rd-level PIC. Not merely a status register with a bitwise flag per UART channel. Whenever you got an IRQ from such a card, you'd have to ACK to your AT-PIC and *then* an extra ACK to that card's own "sharing register". It was a way to implement sharing of edge-triggered IRQ's properly. And it wasn't very well documented if I recall. Advantech would provide its own library which did work, as long as you could link that to your software. If you couldn't recompile, bad luck for you. The library was pretty small, I recall trying to reverse it with a disassembler... The vendors of such hardware probably protected their "intellectual property" that way. And indeed I had an inkling to implement "simple OR logic" - which is not the correct way to share edge-triggered interrupts, but if you have have a way of polling the ports every now and then outside of the dedicated ISR, you can avoid losing keystrokes from your terminal. > Yes, I get PCI card addresses/interrupts from 'lspci' on a Linux box. > If you try booting with "noapic" and maybe "acpi=off", you should see your PCI IRQ's assigned to numbers below 16. I've even seen setups with a broken BIOS (DSDT) and PCI-e, where turning on "noapic" would result in a combination of "legacy ISA and legacy PCI" IRQ's below 16, combined with MSI used for PCI-e peripherals that supported that :-) Which obviously does not help you to re-route a particular APIC GSI to IRQ3/4, if that's your whole point... I've done a bit of googling and found some relevant details. To re-route some particular IRQ line (APIC input) e.g. to IRQ3 or rather its ISR vector, I can see two different theoretical possibilities: A) reprogram the relevant IO-APIC B) make a TSR that installs an ISR for the "boot IRQ" line (= under 16) that your PCI board gets from the BIOS, and from that ISR, call the original ISR of IRQ3 (or whatever it is that you're trying to mimick). In detail: A) reprogram the relevant IO-APIC Unless you're using server boards, we're realistically we're speaking the chipset-integrated IO-APIC. This particular APIC is an on-chip part of the south bridge, since about i815. The IO-APIC is a neighbor of the AT-PIC (two pieces of the i8259 cascaded) and they have some umbilical interconnection - although in fact, I guess any extra IO-APIC's integrated in PCI bridges ultimately produce the same overall behavior... First, mind the difference between: - an IO-APIC = the one that receives the IRQ "wires" from PCI devices and passes the IRQ events further, based on how it is programmed. This is what we'll need to mess with. - a CPU local APIC = one per core, the receiving end of various sorts of interrupts, the one actually arranging the jump to an ISR vector on that particular CPU core. Not sure if we need to touch this or not. A modern PC system has both kinds of APIC's, even if there's just a single CPU core. The APIC system architecture supports multiple cores, and you'll find references to that in all the docs, including some elements in the APIC configuration registers. In DOS, all your software likely runs on the BSP = "BootStrap Processor", i.e. the "default CPU core" that ends up running your DOS when BIOS hands over control after POST. I've found a pretty neat and compact description of what an IO-APIC is, at osdev.org - including a register map: https://wiki.osdev.org/IOAPIC At the end of that wiki article, there is a link to an Intel MPS spec in PDF (already from web-archive) - it contains a block diagram of a multi-CPU multi-APIC system, in its original form, with the APIC IRQ's being delivered over a dedicated "APIC bus". Since then, there's been a change, nowadays the APIC IRQ's are delivered inband over the system bus (DMI, which is just an obfuscated PCI-e) which doesn't have to worry you, as that particular detail is transparent to you as a programmer. Looking at the IO APIC register map, it's clear that if you know or can find out the right GSI (row in the table), you can tell the APIC what *vector* to call at which CPU, as identified by an APIC ID (which is apparently just an ordinal number - the BSP probably has an APIC ID = 0). But, this is not all. Apparently, the "just after POST" state of IRQ routing, where only IRQ's under 16 are used (and heavily shared) is not implemented by means of a corresponding configuration of the APIC mapping of the GSI's to ISR vectors in CPU cores. Rather, that "legacy mode" is a whole separate arrangement, where the IRQ's are in a so called "boot IRQ mode". Apparently, in this mode, the
Re: [Freedos-user] Difficulty with serial communications
Note that PCI boards do not use "well known" port addresses.
PCI devices get their IO/IOMEM/IRQ resources assigned / allocated on
PC startup semi-dynamically.
For instance, the IRQ routing is nowadays described in an ACPI table,
I believe it's called DSDT... Linux can alternatively be asked to
"route the IRQs", not sure how that works.
Multiport ISA boards have always been a pain exactly because of IRQ
sharing. ISA IRQ's are edge-triggered and not implemented in a way
that would allow for easy sharing. If your ISR caters for all the
devices on that line, there's a chance to pull it off (and not get a
stuck IRQ line). PCI IRQ lines are much easier to use in a shared
setup.
I've seen modern industrial PC hardware that has maybe 6 to 10 COM
ports onboard - implemented using two LPC SuperIO chips. In those
cases, all the COM ports are in the ISA address range.
Still, there's no standard for "well known addresses"
for COM5 and above. You often have a choice in the BIOS of such
machines - not sure about IO addresses, but definitely a choice of
IRQ's. Also, even if the BIOS does not allow you to configure those
IO addresses, these SuperIO COM ports typically have their bases
configurable in bare hardware - via the SuperIO configuration
registers. Each COM port is a SuperIO "logical device" and has a base
address register in the SuperIO config register bank. These are
accessible via "multiplexed gates", often at 2E+2F or 4E+4F. There's
always an "unlocking sequence" preventing inadvertent entry - and
each vendor has a slightly different sequence... it's just a few
outb's. Datasheets are available. I have some assorted code examples
if that's relevant.
Very theoretically, with multiport serial PCI cards, it might be
possible to reprogram the BAR's (by writing the card's PCI config
space) into the legacy ISA range. But, there are pitfalls.
Apart from writing the BAR in the target device, which supposedly
already makes the PCI device "decode" that address, you need to be
lucky enough to have upstream PCI bridges actually deliver the IO
transactions "your way". You may find out that the whole ISA IO space
with small exceptions is "routed" to the LPC bridge within the south
bridge chip, and ends up being decoded by the LPC SuperIO chip(s).
Actually, rather than an explicit "all ISA" window (IO ports
0-0x400), the LPC bus may be a "destination of last resort" in
"subtractive decode". PCI devices normally practice "positive decode"
and that's how PCI bridges should treat them. Only one "branch" in
the PCI tree, typically ending in a SuperIO chip, can support
subtractive decode = become a "sink of last resort" for IO port
access that's not claimed ("positively decoded") by another device.
My friend Rayer has once mentioned that he'd tried this, and was
half-way successful... I seem to recall that he managed to re-route
LPT2 to a PCI card, but not LPT1... or some such.
Regarding the modern IRQ routing style, via IO-APIC's to the per-core
LAPIC's... Not sure to what extent the legacy AT PIC = cascaded 2x
i8259 is reproduced in modern PC hardware, as opposed to just
programming the IO-APIC such that only IRQ lines 0 to 15 are used,
for their well-known purposes (where such a well-known assignment
exists). Starting from Intel 8xx series chipsets, probably the i815
for the later iterations of the Pentium III, every ICH south bridge
contains an IO-APIC with 24 GSI's (input lines) which get internally
routed to just the bottom 16 IRQ's for legacy DOS compatibility. It
takes a more modern OS to start the IO/APIC and unleash its power. Or
even to switch over to MSI... I've already mentioned the ACPI DSDT.
You probably won't want to include an ACPI table iterpreter in your
old DOS program :-) Actually, what's fixed in the hardware, is the
wiring of the IRQ lines on the motherboard - how the PCI IRQ braid is
woven among the slots and onboard devices, and how it's wired to the
IO-APIC's GSI pins. From there, internal routing inside the IO-APIC
is programmable. Given a piece of PC hardware, and if you study the
APIC programming enough, you might be able to figure out the needed
routing exercise in bare APIC metal, even without asking the ACPI
BIOS interface.
If you were interested what it takes to access the APIC, I mean get a
kick-start / bootstrap, there's e.g. some interesting work by Michael
Chourdakis:
https://www.codeproject.com/Articles/894522/The-Low-Level-M3ss-DOS-Mul
ticore-Mode-Interface
...the purpose of the project is to show how you can use more than
one CPU core in DOS, using a simple extender... and I'm pointing to
it because to start several cores, you need to work with the APIC's,
so there are some examples in the code where this is used.
Again, note that the source code is heavy in 32bit black magic.
And to close this message, I have a side note:
In case you were wondering about running DOS and DOS apps on modern
PC hardware, one of the
Re: [Freedos-user] Difficulty with serial communications
Dear gentlemen, this is my second attempt to post this. I had to remove ZIP attachments. Turned them into URL's. --- On 3 Feb 2022 at 16:38, Bret Johnson wrote: > In the traditional PC architecture, there are only 16 IRQs (0-15) > managed by two Programmable Interrupt Controllers (PICs). Intel > developed APIC (Advanced Programmable Interrupt Controller) in the > Pentium/multi-processor era (many years ago), mostly to to address the > requirements of multi-processor systems. But, APIC also allows you to > have more than 16 IRQs in single-processor systems. > > APIC requires support both in the hardware/BIOS and in the > OS/application. I've never seen any sort of DOS implementation that > supports APIC, but there may be something out there somewhere. I > think what you're trying to do might be possible (assuming you have > the correct hardware and BIOS support), but is going to be very > complicated and you're probably going to need to implement it > yourself. > I'd say that you do not need to deal with IRQ routing through the APIC's and serving IRQ's higher than #15. You do need to talk to the PCI BIOS (int 0x1A) to find your device on the bus and inquire its PCI config space about: - the port IO space occupied - the IOMEM space occupied - the IRQ allocated. Yes, if I understand things correctly, your PCI(-e) board does have a legacy IRQ# <16 allocated by the BIOS during post, and chances are, that if you hook that IRQ number learned from the PCI config space, you'll start getting IRQ events. Note that PCI IRQ's are level-triggered, for easier sharing. (Your IRQ line will likely be shared by several devices.) Which makes me believe that you do not need to ACK the interrupts to the old AT-PIC. Instead, try just satisfying all the interrupt sources in your UART or PCI board - if you succeed, the IRQ line gets de-asserted, and your ISR simply won't get re-invoked again right away. If there's another device with an IRQ source firing on that shared IRQ line, and you haven't handled that one already, your ISR will get called again. In Linux (not sure about Windows) this is used by the OS: the OS has a "super-ISR" per IRQ line, and as a driver writer, you register your HW-specific ISR with the OS, and the OS calls all the specific registered ISR's for that shared line in a sequence, maybe checking for their return values if that matters to the OS. In DOS, you're on your own. If you want to be polite, and expect other people's TSR's to share that IRQ, perhaps you can call the "downstream" ISR vector that you've backed up when hooking the IRQ yourself... You'll probably find a pretty good datasheet for the PCI UART chip on your addon board. And/or a Linux driver. If some snippets of information are missing in the puzzle (the docs are sketchy), with simple peripherals you can often get further by looking at the BAR's (in Linux using lspci -vvn without even programming) and then you can try poking some of the BAR's to see if you get the expected responses. A 16C550 backwards-compatible UART is no rocket science, and you don't need an IRQ to provoke some activity to the outside world. Port IO is easy - you get the base and range from the respective BAR, and you can start poking. Now if the chip's registers are memory-mapped, that's potentially hard cheese. To access memory-mapped registers in a PCI device, you need to perform an "ioremap" operation (maybe you can do without it in unreal mode) and the physical and remapped addresses are not likely in the DOS conventional memory under 1 MB = you need an OS service to do the 32bit memory management for you. In Linux and Windows this is a boring basic service of the kernel. In DOS, you need DPMI, and you probably need to compile your whole project as a 32bit application (not sure). In DOS, I can possibly suggest the DJGPP (GCC) + NASM, as an environment that I've met before and maybe done some stuff in... Not sure if Japheth is reading this mailing list, but there are other people who can certainly fill in my blanks on this :-) The PCI BIOS stuff still takes some coding and wrapping to be comfortable to use. In my archive, I've found some internal toy "projects" of mine, where such wrappers can be obtained. I'm including two ZIP files - refused by the list server, get them here: http://support.fccps.cz/download/adv/frr/smi.zip http://support.fccps.cz/download/adv/frr/pci-1716.zip The first one is heavily C-centric, including the BIOS calls (software interrupt 0x1A). The other one is Pascal-centric, and the PCI manipulation "unit" is a combination of nasm implementation with a Pascal source wrapper providing a Borland Pascal "interface". Namely, to get you inspired, check the PCI-related header file and look for macros PCI_CS_INTERRUPT_LINE PCI_CS_INTERRUPT_PIN They're offsets in the per-device window of PCI config space. You have mentioned Linux... in modern Linux, you'll see your IRQ mapped to some high
Re: [Freedos-user] Speaking of (tiny) DOS gaming PCs
FreeDOS embedded in the BIOS is certainly a nice touch. Then again, the one thing that speaks in favour of the weeCee is the SB-Pro-compatible audio chip. Unique to the weeCee, of all the Vortex-based machines out there. The Vortex86DX in particular is a "sweet spot" for old-school legacy DOS gaming - that Vortex generation still has native full-fledged ISA bus, can be underclocked below "an equivalent of Pentium 200 MHz" (which is more like 400 Vortex MHz), while at the same time already having an FPU. And the onboard XGI Z9s with 32 MB of dedicated VRAM is also nice (including its VESA option ROM). In other misc hardware, the Vortex86DX has one other potential advantage in the way of "legacy compatibility": the AMI BIOS from ICOP still has configurable options related to ISA IOMEM windows (no particular use for that in the weeCee). On the more modern Vortex generations, this is fading away. Frank On 28 Nov 2021 at 20:00, Ivan Ivanov wrote: > Dennis, thank you for sharing. First of all, if you'd like to get a > Vortex86 CPU-based PC, better to get those which are supported by the > opensource coreboot BIOS, instead of the proprietary closed-source > BIOS. This way, with the help of coreboot's SeaBIOS payload, you'll be > able to - using a simple "cbfstool" command - add a floppy image of > FreeDOS / whatever other floppy OS - to the coreboot.rom BIOS image, > flash it into a BIOS chip, and have a FreeDOS permanently available as > a boot entry! (being able to run it directly from a BIOS chip). If > you're interested, ask questions & I could reply with more info :-) > > , 27 . 2021 . 18:37, dmccunney : > > > > https://www.pcbway.com/project/shareproject/weeCee___Tiny_DOS_Gaming_PC.html > > > > https://www.youtube.com/watch?v=USHvvSbYmJA > > -- > > __ > > Dennis > > > > > > ___ > > 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 ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Sound in (Free)DOS
On 2 Oct 2021 at 18:30, Lukas Satin wrote: > > DDMA is one of the options and it is not working on modern systems. > This ESS Solo-1 has special WDMA mode, but it can be enabled only > using a specific pci instructions that you need to manually send when > booting DOS. > > I have added some comments at Vogons > here: https://www.vogons.org/viewtopic.php?f=46=75420=20 Lukas in that thread at Vogons you seem to mention that you have a Pentium III around 1 GHz. Which means that your machine still can handle "ISA DMA over PCI" just fine. Not sure those tricks with an (extraordinarily capable) ESS Solo would still work on a Sandy Bridge machine... BTW, WDMA? Not requiring bus mastering? I keep learning every day... Frank ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Sound in (Free)DOS
On 2 Oct 2021 at 13:21, ZB wrote: > > But I've found a manual to this mobo: > > https://www.ibase-europe.com/english/down.php?hFFile=en_downloada_caty01425982786.pdf > > It clearly shows "BIOS configuration" -- so my impression was it's able to > cooperate with DOS? Or am I missing something? > apologies, I got way off topic in my rant and managed to confuse you. Roughly Coffee Lake and newer Intel CPU's come with UEFI-only "firmware". That's 8th generation. The CPU's currently in the shops are 11th generation Rocket Lake. Your Sandy Bridge is cca "2nd generation Intel Core" and still has proper BIOS, as you correctly noticed. So yes the mobo can run dos. It only cannot transport ISA-style DMA over its PCI bus - in contrast to ICH4 and older south bridges. Frank ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Sound in (Free)DOS
Hi there Zbigniew, I've got bad news. This likely isn't gonna work for you. On the MB960, the ISA slot is implemented using the famous IT PCI/ISA bridge. https://www.ibase-europe.com/english/down.php?hFFile=en_downloada_caty 01425982786.pdf That fine ITE bridge alone is allright - but the upstream Intel south bridge isn't. Intel south bridges starting from ICH5 or ICH6 if memory serves (that's Pentium 4 era) do not support ISA DMA transport over PCI any longer. Your Sandy-Bridge generation motherboard provides hardly any chance of a nice surprise in that vein :-( You'd have a chance if your motherboard would use an LPC-to-ISA bridge. In that case, ISA DMA would likely work. (What wouldn't work is ISA MMIO - which would not be a problem for DOS+ISA era soundcards, as they're only using "port IO".) Industrial motherboard vendors typically opt for the PCI/ISA route, because ISA MMIO is more often used by legacy industrial I/O boards, compared to ISA DMA. Your best chance to get DOS working well on new bare metal, including ISA DMA, is probably some half-size PICMG ISA board from ICOP, with their Vortex86DX. VDX-6324. AFAICT that is the last CPU/SoC platform to support ISA properly. Otherwise you can start hunting after antiquities from the (pre-)P4 era. Perhaps try to look for a functional notebook from those times - they tended to have an SB-compatible soundcard onboard. Actually, as far as I can tell, SB emulation works pretty well in emulators... specifically DOSbox seems to fit my occasional needs. Works on modern PC hardware and OS. Note that the SandyBridge that you have purchased has been phased out by Intel relatively recently - and is about 9 generations old by now. The last 2-3 generations of Intel x86 CPU's come with UEFI without the BIOS-legacy-compatible CSM - even in the industrial portfolio. Technically these are not PC's anymore, in the sense that you cannot boot DOS (or Windows up to XP for that matter) on their bare metal, and Win7 only in theory. Frank On 2 Oct 2021 at 12:26, ZB wrote: > From time to time there is a question raised about "getting sound under the > DOS control". Most probably the best solution is to use old ISA soundcard. > > But not everyone is willing to search for old -- now "obsolete" -- mobos > and other peripherals; still there is other solution: to get _new_ modern > mainboard featuring ISA slot, like this one, for example: > > https://www.ebay.de/itm/303579781248?hash=item46aec3d880:g:w64AAOSwmIlg9VZD > > No, it's not my auction; I placed an order for it today, I'll let you all > know how does it work under FreeDOS' control, and what about sound > -- > regards, > Zbigniew > > > ___ > 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
Re: [Freedos-user] Upgrading the BIOS with FreeDOS
On 28 Jun 2021 at 14:09, Liam Proven wrote: > > On Mon, 28 Jun 2021 at 13:36, Paul Dufresne via Freedos-user > wrote: > > > > More than once, I saw a motherboard manufucturer (I think it is ASUS) > > claiming to have FreeDOS exe to upgrade the BIOS > > but found the programs were Windows exe and would not run on FreeDOS. > > Question: > > Is it possible the download is a Windows self-extracting archive, and > inside it, there is an upgrade image file and a DOS flash tool? Have > you checked? > > Yes, this would on the surface appear to be a foolish thing for them > to do, *but* 64-bit Windows will not run a DOS or 16-bit Windows > self-extractor, so they may not have an easy choice. > That's a good point, never thought about that :-) > Non-technical users (that is, most of them) would not know what to do > with a Zip file. > Ooompfh! :-) :-) :-) Clearly Mr. Proven you have much more experience with front-line helpdesk work. In my industrial niche, I don't recall ever meeting a customer who would not know how to extract a ZIP file. Superficially I have to laugh at the idea that someone who cannot work with a ZIP file would be interested to flash the BIOS in their motherboard... then again, I'm probably anchored in a safe bay, protected from the actual rough seas. I live and work in a retro bubble. And looking at my teenage offspring, insisting on sending photoes from their phone into their computer by e-mail instead of just using a USB cable, I have an uneasy feeling, that your touch with reality is stronger than mine :-/ > If double-clicked Windows does not extract it but > mount it as a virtual folder -- resulting in a DOS program not being > able to see the contents of that folder, and also not be able to > execute. > That's a valid point. Then again - based on the relatively infrequent occasions when I need to download drivers or BIOS updates from vendors of SoHo PC hardware (the largest asian mainstream brands) I have to say that their download packaging people / download site maintainers generally (insert your preferred invective verb) at their job. Their creations are often unbelievable. Starting from naming and descriptions on the outside not matching what's actually contained or supported by the binaries and INF files inside. Including lots of bloatware in the package... I find it perfectly possible that the fine nuances of the EXE format, such as compatibility with DOS/Win32/Win64, are under their radar. I.e. I don't suspect some cunning plan, where plain sloppiness is a good explanation. I tend to actually shiver whenever I download some such stuff and the archive format is a self-extracting EXE. Download a bare opaque EXE from a website and just run it - such a barbarian practice, from a security perspective! And by doing that, even if those EXE archives are legit, they teach the users to consider this practice safe and normal ! Whenever *I* have to download an EXE, I first try to open it with 7zip to see if I can circumvent the inlined unpacker and check the contents "at my own terms" - which often fails, if the archive is a modern InstallShield or just something that 7zip doesn't know. If I'm really doubtful, I check the MZ/PECOFF header with appropriate tools (LordPE maybe, probably not IDA Pro) and maybe search for some strings inside the binary to see if it looks half genuine... It's always a pleasure to debate with you Mr. Proven :-) Frank P.S.: as for updating BIOS from *FreeDOS* - suppose that you actually get your hands on a DOS executable. It can be a single file (all in one), or you get an EEPROM image data file and an executable flasher util from the BIOS vendor. The actual executable flasher can have whims of its own: - can dislike FreeDOS, but run just fine in MS-DOS - can dislike EMS/XMS memory managers - can require an EMS/XMS memory manager - can require a memory manager, but specifically segfault with JEMM (= makes you revert to MS-DOS and himem-sys) Combined with disk sizes and geometries, FAT32 support and possibly other quirks of the platform, it can be an interesting exercise to get a working DOS that pleases the flasher tool :-) And then there are the modern EFI "firmware" generations that come with a flasher tool in the form of an EFI executable, so you need to know your way about the EFI shell, which hopefully is included in the "firmware"... or boot an EFI shell as a "payload" from an EFI-bootable disk drive or some such. P.P.S.: my favourite download was an installer of some custom health monitoring and GPIO API (for win32) from a PC vendor whom I would prefer not to name. There was no information about compatibility, but the contents were clearly original. The package installed without errors. And after a graceful restart, the PC would end up in a BSOD at boot, as soon as the kernel driver for that API got loaded. At customer premises, without a recovery environment at hand... We did not have
Re: [Freedos-user] PCI SATA adapters with DOS
On 23 Jun 2021 at 14:59, Lukas Satin wrote: > ... Get XT IDE eeprom and put it in Ethernet NIC for example to get > boot options even for 386 and bypass size limitations Oh I see, you mean this: http://www.xtideuniversalbios.org/ ...apparently the software project is still active :-) That's one lovely practical hack :-D My remaining ISA NIC's have ended up in the trash a few years ago. I'm wondering how much work it would be to inject this into an older Award BIOS. If memory serves, ISA option ROM's somehow did not load automatically... what did work was link the ROM as a PCI PnP option ROM and insert it into the BIOS image instead of the original PCI NIC option ROM (referring to its HW PCI ID's). Requires a NIC integrated on the motherboard. No such procedure is mentioned in the XTIDE docs... Frank ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] PCI SATA adapters with DOS
Dear Mr. Brase, thanks for the detailed report... I wasn't paying attention back in March, so I don't recall what motherboard and BIOS you have there... but in general that probably doesn't make too much of a difference :-) What you're complaining about (boot sequence / ordering of disk controller channels and drives) is primarily a BIOS issue, with MS-DOS adding a handful of quirks of its own... I'd like to praise you for coping so well (scouting by way of fighting). And, "Linux" is indeed the king of the hill, when it comes to disk partitioning - or rather, the tools such as fdisk, gdisk and others, coming in modern distroes (these tools keep evolving). Thumbs up for learning about the underlying principles. Your SATA controller does have a BIOS option ROM baked in, which fortunately is somewhat compatible with the BIOS on your motherboard. There are several ways (some of them "feral", plus the BBS API) of engaging the SATA option ROM or individual drives in the BIOS boot sequence. Generally the SATA controller's OPROM can hook maybe two different "software interrupts" (if memory serves) to force itself before or after the onboard BIOS boot sequence, or it can offer the disk drives detected as individual BIOS disk drives to the host BIOS for its own boot sequence (thus leaving the ordering of individual drives at the discretion of the host BIOS and its SETUP). I recall seeing some disk controller OPROM that would give you a choice, what method of hooking the boot sequence to use (INT18h, INT19h, PnP BBS). On top of that, different brands, generations, versions, and mobo-maker-flavours of BIOSes have different user-visible approaches to boot device ordering. This alone would warrant a howto of its own. Unfortunately some BIOSes were/are just stupid and limited in what they allow you to do. If you don't like the way these issues are handled by your particular combination of motherboard BIOS and the SATA controller's option ROM, you should check for a BIOS update especially for the motherboard's BIOS - if you haven't done that yet, chances are, that a more modern BIOS, if available, has added some intelligence in that area. I recall trying some Russian hacker tools for vintage Award BIOSes, that were able to improve support for large disk drives http://www.rom.by/articles/BP/index_english.htm Beware, this could brick your motherboard. I had a HW programmer as a retreat path. And, that project is really old now. It added support for disk drives up to 137 GB - this particular boundary has long been exceeeded, we are now past another boundary at 2 TB. And, it probably does nothing about the way the BIOS Boot Sequence is approached and manipulated by the SETUP of your BIOS (and its runtime logic). Unless you install a device driver, DOS uses disk drives it learns about from the BIOS - and accesses them via the BIOS Int 13h services. Accepts them in the order as supplied by the BIOS. Windows 95 and 98 would do the same for disks from controllers where they don't have their own 32bit driver. What *drive* gets selected for loading the 1st-stage bootloader (in the drive's MBR), that's strictly a choice on part of the BIOS including any OPROMs hooking it. MS-DOS does not have a say. What *partition* on that drive (or some other drive?) gets chain-loaded next, that's the bootloader's choice. Actually it may be a second boot-loader stage in the "active" partition's boot sector (MS-DOS style), or it can be a file from a file system, or whatever... depends on what bootloader starts in the first stage and how capable it is. I recall noticing some shenanigans with primary vs. extended partitions on disk drives... MS-DOS would give the letter C: to the first primary partition it would find, following up with *primary* partitions on other drives, and then any extended partitions would follow. I seem to recall that multiple "primary" partitions per drive were not supported at all? I.e. MS-DOS would not "see" primary partitions other than the first one in the drive's partition table. FreeDOS seems more liberal in those respects. Not paying attention to the secondary IDE channel, if the primary channel is unoccupied, that sounds like a pretty dumb BIOS to me... DOS cannot see disks on the SATA controller, yet Linux is able to boot from the SATA card? How large are your SATA drives? What particular version is "MS-DOS 6" are you using - is that a "6.22", or rather "6.0" ? Isn't this merely a matter of partition size? I'm wondering if loading some driver such as UHDD / UIDE / udma2 would improve something about large disk support. Won't help you with the boot disk, but could improve accessibility of the non-boot drives: https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/udma/deve l/ https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions /1.2/repos/drivers/uide.zip
Re: [Freedos-user] Print via network - a workaround to the Samba bug
Dear gentlemen, today I've tested some ideas... one worked, one did not. 1) put a UNIX-domain named pipe in the Samba share, locally on the server: cd /mnt/samba mknod print.q p chmod 666 print.q The above needs to run as user root. The following can run as an unprivileged user: To test the idea (dry run): while true; do cat print.q; echo "\n Another one:"; done To actually run the print jobs though the printer back end: while true; do lpr -P PRNTEST < print.q; done In the DOS client, having a drive G: mapped to the network share, I can do this (either works): echo "Howdy :-)" >> G:\print.q type autoexec.bat >> G:\print.q copy /Y /B autoexec.bat G:\print.q Before trying this, I was a little worried that especially the "copy" would erase the pipe and replace it with a plain file - that did not happen, the pipe still exists and functions. The named pipe provides a clear job start and job end, inherently, by closing the pipe to the "consumer" process (lpr) when the "producer" has closed his file copy/append operation. In our case, the "producer" runs in DOS, and sends output to the pipe via the CIFS/SMB network filesystem. Note that after some time, lpr times out waiting for data (and exits, and gets respawned). This is normal and probably harmless. As far as I could observe, an lpr waiting for a print job to come does not "block the CUPS queue" in any way. I've also tried prn2file: https://board.flatassembler.net/download.php?id=1086 Unfortunately, this doesn't seem to work right over a Samba share. Nothing ever got printed. The prn2file.com gets loaded, I can configure the port to hook, but when I copy a file to LPT2, it does not fall out of the pipe in the Samba server machine. Interestingly, smbstatus indicates that the pipe is locked in RW mode by something running in the DOS client... Frank ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Print via network - a known bug in Samba
...while looking for some existing "LPT port redirection software" for DOS, I've first found this proggie: http://info.elf.stuba.sk/packages/pub/pc/utiltext/lpt2file.zip It's a little TSR in .COM format that installs in memory, captures any printing on LPT1 (done using the BIOS printing service at INT 17h) into a chunk of XMS memory and upon another invocation, can dump the captured data into a file. So it does not write the file in the background... I've taken a look at the code using IDA Pro, just for fun - to confirm my impression that hooking INT 17h is no rocket science... ...and then, I found this: https://board.flatassembler.net/topic.php?t=2319 https://board.flatassembler.net/download.php?id=1086 The download is called prn2fil3.zip . It comes with ASM source code. It does write the file in the background and opens the file in "append" mode. I'm gonna try it, hopefully later today. Frank ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Print via network - a known bug in Samba
Thanks to Eric for taking a look at my Wireshark screenshot... I was getting ready to make some PCAP files available, but ultimately it is not needed, because I already know where the problem is :-) After some further investigation, it started dawning on me, that this does look like a bug in Samba after all. That the write_print_file_request probably deserves a complementary response, which the client is possibly awaiting, but the response never comes (just an autonomous ACK from the TCP layer). Another step in the right direction was to set Samba logging to the max for the "lanman" subsystem and see what gets caught. Not much actually, but the last message mentioning reply_printwrite would suggest that smbd indeed called a function that should've transmitted a response to the "write print file request". So... why does no such response ever get tranmitted? reply_printwrite() finally rang a bell with Google :-) Curiously, three months ago some fellow archaeologist in Poland has noticed the same problem (happening to his DOS-based LanMan clients), reported that to the Samba mailing list, and got an immediate response + a fix. To a bug that's been in the Samba code since maybe 2008 :-) https://lists.samba.org/archive/samba/2021-April/235828.html https://bugzilla.samba.org/show_bug.cgi?id=14696 The fix is in 4.14.5 and probably 4.13.9. The Samba package in Ubuntu 20.04 is 4.11.6, released in January 2020. I don't think 4.11 series will get a patch, 4.11.17 is from December 2020. Rather, I'd expect the fix to eventually land in an upcoming LTS release of Ubuntu, which is probably a couple months down the road... https://launchpad.net/ubuntu/+source/samba Obviously there's always the possibility to compile from source... (or pay Samba+ for a binary package.) Side note: Today I've installed DOS 6.22 in a VirtualBox and the MS LanMan 2.2 on top of that: https://www.youtube.com/watch?v=oqMzF41dyvk=624s http://ftpmirror.your.org/pub/misc/ftp.microsoft.com/bussys/Clients/LA NMAN/ It took some manual work to get the Intel e1000 driver massaged in, but in the end it works. Combined with the host instance of Windows 7, another virtual partition with XP, and an external box running Linux, the setup behaved rather erratic - which I put down to the virtual bridge that gets set up by VirtualBox. VM's coming and going, the physical NIC port coming up and down, wireshark getting started on the Win7 host and XP guest, all of that probably takes its toll on the stability of this "virtualized" setup :-) In the end I managed to stabilize the setup enough to make the LanMan 2.2 on DOS first connect to the Ubuntu test server, and demonstrate the same results that I got with my previous MS Network Client 3.0 (probably) on FreeDOS. There are minor differences in the protocol, but the net effect is exactly the same: just the "request" packet, already carrying some payload, gets transmitted, and then the TCP session times out and gets scrapped by the client. I also managed to have the LanMan 2.2 client on DOS connect to another VM running Windows XP, and tried to print something to an XP-based shared printer (dummy, set up just to accept the print job). This worked - indeed the print request needs a response. Interestingly, against XP, the LanMan has used a slightly different protocol version. Starting again with an "Open Print File Request" (and getting a response containing an FID), the next message would be a "Write Raw Request", followed by a "Write Raw Response". Which is in contrast to the "Write Print File Request" seen from that same client against the Samba on Ubuntu. Never mind, this is probably just a cosmetic difference. Enough for today, I guess. Apart from waiting for a fix to Samba, I may try some workarounds through the disk share... something for Bryan to play with if he's interested. I'm thinking of making a named pipe in Linux, and append to it through Samba, if that turns out to work. Not sure that "copy" will be the right tool for this - it cannot be made to "append". And, I suspect that "type" won't cope with binary files (unlike UNIX "cat"). And I was wondering if ddlink might help... no, probably not. Cannot capture and redirect LPT devices, AFAICT. Frank ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Print via network
Just a short update: I've retreated in my footsteps all the way back to my lab at work, and its PXE-booted legacy NetBootDisk profile, and I have to say that the LPT2 obtained via net use lpt2: \\printserver\queue misbehaves *exactly* the same as in my minimized VirtualBox environment, and as on Bryan's bare metal at home. At my workplace, it's miscellaneous bare metal x86 hardware on the client, against a Debian 9 print server with stock Samba of that distro (and lprng printing service). Earlier this year, I just did a quick test and made a rushed conclusion that DOS printing redirection worked fine. Means to me that I should start from a clean sheet - maybe with MS-DOS first, installed from scratch, and MS Network Client installation disks, and see if that makes a difference... That's gonna take me a while. I'm also wondering about stuff such as planting a UNIX named pipe in some directory on the Linux box, that gets served by Samba as a disk share... or just run a script that would wait for a plain file with a pre-configured filename, wait for a few seconds after it stops growing and spool that via lpr or something :-) Ugly workarounds to make printing via "print to file" in the DOS box more seamless. Frank ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Print via network
This is a re-post, my first two attempts had too many attachments.
I'm re-attaching just the TXT file being printed, and here are some
relevant screenshots:
http://support.fccps.cz/download/adv/frr/dosnet/ps.png
http://support.fccps.cz/download/adv/frr/dosnet/write_print_file_reque
st.png
I'm giving up on attaching the 90kb PostScript created by CUPS,
nothing interesting in there (see the .PNG render above).
On 16 Jun 2021 at 21:41, Michael Brutman wrote:
>
> I hate to even suggest this, but are you using the /B option on the
> file copy to indicate that a binary copy is needed? Otherwise, the
> first Ctrl-Z in the file will end the file copy prematurely.
>
Dear Mr. Brutman,
first of all thanks for your personal attention and for the infomed
suggestion. I did not know about this pitfall, thanks for weeding
that one out.
This does not appear to be my problem. See the attachments.
The file that I'm sending is a clear text file - I've captured the
standard output of "net help" into a TXT file, and I'm trying to
print that. The TXT file contains no occurrence of the 0x1A character
(26 decimal) - if that's what CTRL+Z in DOS produces.
I'd swear the printing has worked for me, once, in a slightly
different environment (NetBootDisk launched via PXE in our "legacy"
boot profile). I may have been not diligent enough in my testing.
Right now Bryan works in FreeDOS booting from drive C on bare metal,
I'm trying this in a VirtualBox.
I'll have to try again in my PXE environment...
A disk share works fine, files do get copied intact.
Just the LPT redirection fails in this curious way.
BTW, on various occasions during the network startup scripts, the
ancient MS networking stack in DOS seems to wait for no apparent
reason for many seconds, before taking further action. For
comparison, I've tried loading the "packet driver" flavoured stack,
and that loads real fast, the mTCP app suite starts instantly, DHCP
takes like a second to finish etc.
Frank
The following section of this message contains a file attachment
prepared for transmission using the Internet MIME message format.
If you are using Pegasus Mail, or any other MIME-compliant system,
you should be able to save it or view it from within your mailer.
If you cannot, please ask your system administrator for assistance.
File information ---
File: NETHELP.TXT
Date: 15 Jun 2021, 23:23
Size: 1993 bytes.
Type: Text
NETHELP.TXT
Description: Binary data
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Print via network
Dear gentlemen, on and off, with Bryan we've been playing with Ubuntu, Samba, CUPS and the MS Network Client running in FreeDOS. And we're facing a dead end - same symptoms observed by me and by Bryan: We can load the MS stack, to the point that we can "net use" network disk volumes = map a local drive letter to an ARC path from the server. And the disk is perfectly accessible. But, printing is giving us an interesting misbehavior. We can ask for net use LPT2: \\server\printqueue That does succeed. But, whatever we copy to the redirected LPT2 (we've also tried LPT1 for that matter), we only get a couple lines printed. Like 4 to 6 lines, if we try to print plain text. I've observed the problem with Wireshark. The MS client connects a TCP session to Samba, they negotiate the protocol version, the client starts a print request, sends the first packet with an actual payload, gets a TCP ACK, and the very next TCP packet from the client to the server has a FIN flag - and the TCP session get gracefully ended. Interestingly, the client produces one extra packet with an ACK for the session, after the FIN / FIN+ACK coordinated handshake has closed the session. Wireshark's TCP tracing marks that extra ACK packet as a duplicate... I have no clue why this is happening. I've tried loading all the drivers "low" (instead of "high" or UMB). No joy. I'm wondering, which of the bunch of drivers and executables (about 8 of them) is specifically responsible for the printer port redirection function. And, what could make it close the TCP session prematurely. Does it perhaps expect a different "pattern of data writes" on the hooked LPT port service? Which a plain "copy" command does not satisfy? Any ideas are welcome :-) Frank ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Print via USB - licensing
On 15 May 2021 at 13:56, Eric Auer wrote: > > Hi Bryan & Frank, > > > As you had suggested, on the FreeDOS PC, in C:\MSNET\ I entered "start". > > Then I could ping from that PC to my printer, Ubuntu PC and Ubuntu laptop. > > Cool! Thanks for creating the network zip :-) What is > in that start bat file and which packages with which > licenses are required to make this become a reality? > I haven't bothered to investigate in detail. Licensing is likely a can of worms in that ZIP of mine. Hence my offer to withdraw that zip if anyone happens to object. The MS Network client (containing a flock of binaries) has some license of its own, I'm almost sure I am not allowed to re-distribute this. The config files for the MS Network client borrow heavily from the NetBootDisk.com project. Then there's the mTCP package. And the dis_pkt.com (v11). And probably some binaries coming from FreeDOS. The top-level README contains a list of URLs to where I got all the bits and pieces (at least I'm trying to give credit where credit is due). I'm not all that excited about the zip I have created. It's very bare bones, and it contains HW support for just one specific NIC (a family of Intel PRO 1000 within some timespan of their evolution). It is meant to be simple and to show the very basics. I meant this as a starting point. Frank ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Print via USB
On 15 May 2021 at 10:40, Ralf Quint wrote: > > On 5/15/2021 4:56 AM, Eric Auer wrote: > > > >> I had worried that the DOS machine on my network, would > >> give easy access from the Internet for gremlins! > > Because DOS normally does not run any servers, there is > > not much which the gremlins could access. So it depends > > on which servers you manually start on DOS: I guess the > > plans to talk to your printer will not require anything > > server-style to run on DOS, so you should be safe :-) > > If a DOS machine on a local network gets "accessed by gremlins from the > Internet", you are already in rather deep sh!t. That DOS machine would > be the last of your worries at that point... > > Ralf > I second that. In more detail: As for DOS in the hypothetical role of an "entry point" (security hole): DOS is such an ancient and nowadays exotic platform, and relatively uncomfortable to program networking pranks for, that hardly anyone would waste the programming effort required to write modern malware for it. In its heyday, there were certainly viruses for DOS, but I don't recall any notable DOS virus that would spread specifically in a network environment (which one, in DOS at that time Novell was much more popular than MS Networking etc.) I can imagine "social engineering malware" spreading by just copying its funny executable binary to any network volumes it can find, and thus infect more modern platoforms... but again, making this kind of sotware compatible with DOS would nowadays mean pretty much unnecessary baggage :-) And, yes, as the DOS machine is client only, it can hardly be attacked via the network (by feeding a crafted buffer overflow attack to some network service interface, or SQL injection, or some such). It's just much too dumb to be eligible as a victim of a sophisticated network-borne attack. As for the MS Network Client for DOS, it is true that it requires ancient authentication methods with weak ciphers and whatnot, which might make it easier for an attacker to glean passwords from the traffic or some such (and then maybe log in to the server and try pulling off further mischief). But, for that, the attacker would have to be present in your local network already = you'd have a more serious problem in the first place :-) I do believe that your DOS machine on the LAN is really a non-target nowadays. I'll try to provide you with a rudimentary Samba config in a private e-mail. Frank ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Print via USB
Oops. I've goofed up by running the last message throught the list. Already. For more than one reason, and going off topic being the least important. Apologies. Such an example of bad taste on my part. I should know better. I'll keep the possible networking follow-ups in private messages. Frankq ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Print via USB
Bryan thanks for your progress reports :-) Nice to see how you have cartographed your local network, and that you're showing quite a bit of understanding. Your existing autoexec looks pretty harmless to me. I don't have any demands on what to put in there, that's why I didn't provide an example. Feel free to tweak the PATH variable to your liking. Let me know if you don't know what the %PATH% is good for. For instance, the pktdrv/start.bat modifies the %PATH% accordingly to fit its own needs = no need to do that in the autoexec. Basically I'd say you're all set to try and load the DOS network stack, and see if that works :-) Again there are two alternative flavours of the DOS TCP/IP stack, one tastes of Microsoft, the other one of "independent open-source stuff" (the CRYNWR packet driver API). This is what you should try next - either A) or B), reboot inbetween A) and B) when you want to switch to the other: A.) the one Microsoft way: cd msnet start ping 10.1.1.1 ping 10.1.1.2 ping 10.1.1.92 B.) the CRYNWR packet driver: cd pktdrv start ping 10.1.1.1 ping 10.1.1.2 ping 10.1.1.92 I suggest that you also try mem /c /p after A) and B) in turns for comparison. Look at the "largest executable program size" at the end of the listing :-) If you get bored before I end up sending further "printing" instructions to you, try tcpdump or Wireshark on the Linux box :-) The output probably won't make much sense to you for a start, but it may open your eyes a little, to how chatty your local network is. Obviously plenty more info is available from me on that topic, and questions are welcome. Only we're getting off topic in this list. Maybe one small thing to test on your Ubuntu box: if you open a terminal window, and type which lpr what do you get? If you get something like /usr/bin/lpr, could you also try this? which lpq lpq -a Explanation: lpr is a command-line program that allows you to copy/send a file to a print queue, locally within your Linux box. The file = print job is expected at standard input. lpq is a print queue "manager" command, for your overview of the jobs being printed, and the queues present in the system. Not sure if your CUPS comes with those utilities included. Frank ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] (Fwd) Re: Print via USB
Oops, I didn't notice that this went through the list, and I replied
only directly earlier today - thereby I've wasted some of Eric's
precious time and effort. Thanks for a second opinion Eric :-)
Frank
--- Forwarded message follows ---
From: Frantisek Rysanek
To: Bryan Kilgallin
Subject:Re: [Freedos-user] Print via USB
Date sent: Wed, 12 May 2021 08:33:56 +0200
Hello Bryan,
I think you can just use your current FDCONFIG.SYS, and profile #1
matches my config.sys pretty closely.
Maybe in the line starting with
12?SHELLHIGH=C:\FDOS\BIN\COMMAND.COM C:\FDOS\BIN /E:1024
you'd better specify /E:4096 . If memory serves, this is the space
available for environment variables - not sure if you risk running
out with /E:1024, maybe even that is fine, those 4096 are taken from
the NetBootDisk.com which uses *a lot* of environment variables in
its scripts, unlike my simple batch files.
The only other differences are
buffers=30
stacks=0,0
=additions in my config.sys. Those look fairly harmless...
Frank
On 12 May 2021 at 14:20, Bryan Kilgallin wrote:
To: freedos-user@lists.sourceforge.net
From: Bryan Kilgallin
Date sent: Wed, 12 May 2021 14:20:07 +1000
Subject:Re: [Freedos-user] Print via USB
Send reply to: "Discussion and general questions about FreeDOS."
[ Double-click this line for list subscription options ]
Dear Frank:
> As I've already written, I myself have investigated the dark rabbit
> hole of MS-DOS networking for you:
> http://frantisek.rysanek.sweb.cz/FD_NET.zip
> Unzip the three directories to your DOS hard drive, take a look at
> the config.sys suggested, and see if you can get your DOS box to take
> a breath of your LAN.
I have unzipped your package and copied MSNET, MTCPAPPS, and PKTDRV
to
my FreeDOS PC's C: directory. The latter contains FDCONFIG.SYS.
Incidentally, in the page whose URL follows, I have difficulty
reading
because of the background fish logo!
http://www.bootablecd.de/fdhelp-internet/en/hhstndrd/cnfigsys/fdconfig
.htm
My FreeDOS PC's FDCONFIG.SYS file contents follow.
{SET DOSDIR=C:\FDOS
!COUNTRY=001,858,C:\FDOS\BIN\COUNTRY.SYS
!LASTDRIVE=Z
!BUFFERS=20
!FILES=40
!MENUCOLOR=7,0
MENUDEFAULT=1,5
MENU 1 - Load FreeDOS with JEMMEX, no EMS (most UMBs), max RAM free
MENU 2 - Load FreeDOS with EMM386 (Expanded Memory) and SHARE loaded
MENU 3 - Load FreeDOS without drivers (Emergency Mode)
MENU 4 - Load FreeDOS low with some drivers (Safe Mode)
124?DOS=HIGH
12?DOS=UMB
124?DOSDATA=UMB
1?DEVICE=C:\FDOS\BIN\JEMMEX.EXE NOEMS X=TEST I=TEST NOVME NOINVLPG
234?DEVICE=C:\FDOS\BIN\HIMEMX.EXE
2?DEVICE=C:\FDOS\BIN\JEMM386.EXE X=TEST I=TEST I=B000-B7FF NOVME
NOINVLPG
34?SHELL=C:\FDOS\BIN\COMMAND.COM C:\FDOS\BIN /E:1024
/P=C:\AUTOEXEC.BAT
12?SHELLHIGH=C:\FDOS\BIN\COMMAND.COM C:\FDOS\BIN /E:1024
/P=C:\AUTOEXEC.BAT}
I found `!' and `?'.
{? (DR DOS 3.41 and higher, Embedded DOS[nb 2] and FreeDOS only)
Displays a Yes/No query and (since DR DOS 5.0) optional message
to
ask the user for confirmation to execute the following CONFIG.SYS
directives.[14] (FreeDOS does not support optional messages, but
optional conditions in conjunction with boot menus defined with MENU
and
MENUDEFAULT.) (DOS 6.0 and higher supports a similar feature by
adding a
? after the corresponding CONFIG.SYS directive, f.e. DEVICE? or
DEVICE?=
instead of ?DEVICE. This variant is also supported by DR DOS.)}
{! (FreeDOS only)
Unconditionally execute the following CONFIG.SYS directive.}
https://en.wikipedia.org/wiki/CONFIG.SYS
Whereas in your FD_NET, CONFIG.SYS contains this.
{device=DOS\JEMMEX.EXE X=TEST NOEMS
files=40
break=off
buffers=30
lastdrive=z
stacks=0,0
dos=high,umb
SHELLHIGH=C:\COMMAND.COM /E:4096 /P}
But I am unfamiliar with interpreting .SYS files. And so I need to do
some reading!
I take it that I am to merge the contents of your CONFIG.SYS into my
FreeDOS PC's FDCONFIG.SYS. But I am shy of doing so, and request
hand-holding guidance!
Bryan.
--
members.iinet.net.au/~kilgallin/
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user
--- End of forwarded message ---
WPM$YI17.PM$
Description: Mail message body
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Print via USB
On 2 May 2021 at 10:24, Bryan Kilgallin wrote: > So, Frank: > > > Install Samba on your Linux PC. It may take a wee bit of learning to > > configure, but it does not bite back. I can help with snippets of > > config to make it accept ancient DOS clients. > > > > Install the Microsoft Network Client for MS-DOS. You can install > > this from scratch, or you can try using/refactoring the NetBootDisk: > > https://www.netbootdisk.com/floppy/download.htm > > > > ...and then redirect the LPT device: > > > > NET USE LPT1: \\my_samba_server\printer_queue > > I take it the DOS PC will tell the Linux PC to print! This seems a > bit complicated. > Yes, the Linux PC is an extra step - but probably the only way for you to go forward, if you still aim to print from your DOS box to your GDI printer. And it's not overly complicated, though it may require a little bit of extra learning... As I've already written, I myself have investigated the dark rabbit hole of MS-DOS networking for you: http://frantisek.rysanek.sweb.cz/FD_NET.zip Unzip the three directories to your DOS hard drive, take a look at the config.sys suggested, and see if you can get your DOS box to take a breath of your LAN. Get an IP address from DHCP and ping something on the LAN. Chances are that this part will work right off the bat. I'm fairly confident about the follow-up technologies in Linux (for your printing intermediate box). It doesn't look like a headache to set up, but it may require some tinkering and back-n-forth e-mail communication. If you have time and you're still curious about stuff, you might actually find that tech entertaining. It's not gonna clog your Linux printing setup or swamp your network or anything. Then again, if this kind of stuff just gives you a headache, never mind, go focus on something that makes your day brighter :-) Frank ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Printing over the network
FYI, and apologies for getting off topic on this FreeDOS mailing list: about CUPS, I can tell the following: 1) CUPS apparently does some auto-detection of input file type. It can auto-detect several bitmap image file types, such as PDF, Postscript, HTML, ASCII text... apparently it can detect MS Word DOC for christ sake :-) Detect, not sure if print too. 2) out of the box, it does technically detect HP PCL, but it considers it a "raw" format, and passes that through to the printer without further conversion. 3) with a bit of custom configuration, this automatic filetype detection and auto-conversion (to an internal PostScript format) can be bent to use GhostPCL, to actually prefilter the print job at hand = convert the job from PCL to internal / intermediate / common denominator PostScript. Which then gets rendered onto any back-end driver, such as your proprietary GDI. Someone has documented this back in 2007 (made a mistake at first and asked for help, the problem got solved - see the whole thread): https://lists.cups.org/pipermail/cups/2007-June/041365.html Current default contents of the upstream CUPS /etc/cups/mime.types: https://github.com/apple/cups/blob/master/conf/mime.types#L155 (line 155 is key) Means to me that you still need to get GhostPCL and configure this on your own, but it shouldn't be very difficult. And, this sorcery is not really necessary, if you can do *without* PCL when printing from DOS. Such as, you can use direct PostScript output, if your DOS apps support that. Or plain ASCII should work too. So after you get your basic TCP/IP connectivity to work in DOS, via the MS Network Client, the very next step would be to install and configure Samba. Ask me for an example minimal config file if you're interested. Frank P.S., further reading on CUPS: https://www.samba.org/samba/docs/old/Samba3-HOWTO/CUPS-printing.html#i d2635892 Nominally deprecated / no longer maintained, but in fact pretty informative. I haven't found a newer version of this overview. On 29 Apr 2021 at 22:10, Bryan Kilgallin , freedos-user@lists.sourcRe: [Freedos-user] Printing over the network wrote: > In your use case Bryan, my "package of canned DOS drivers" is just a > first half of the needed configuration. Next up, we need to configure > Samba and CUPS to transport and transform your print jobs :-) ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Printing over the network
Soo... Bryan, here's a cooked download: http://frantisek.rysanek.sweb.cz/FD_NET.zip Download the ZIP and try to read your way through the readme files included. Note that a copy of this message goes to the mailing list. I am hereby guilty of redistributing binaries from a couple different sources - if anyone feels offended, please complain to me and I will withdraw that ZIP immediately. Over the last few days, I've found a few moments to play with the MS Network Client, E1000.dos from Intel, the dis_pkt.dos v1.11 and mTCP. I ended up trying it all in a VirtualBox, where the emulated Intel Pro 1000 actually has the same PCI device ID :-) as Bryan's physical PC... I did that in a physical LAN where I have access to a Linux machine running Samba, configured to support the ancient version of the SMB protocol and a handful of DOS-related configuration features. I have "structured" the results of my effort into two directories: 1) one geared for "the way of the pure CRYNWR packet driver", prepared for mTCP. You can try sending something to your printer using "NC", but I doubt that the GDI thing would respond to e.g. plain ASCII. 2) another directory, centered around the MS Network Client (which can optionally have the packet driver shim loaded too). This should allow you to map a local LPT device in DOS to a MS Network shared printer (served by Samba on a Linux box). Which looks transparent to well-behaved DOS apps, and can be leveraged for a further on-the-fly processing of the print job in software on the Linux machine. Either variant allows you to learn the IP addresses obtained by the DHCP client and to ping other machines in the local network - which is a good starting point / introductory lesson into TCP/IP networking on your DOS machine :-) For the MS network client, I have taken "major inspiration" from the NetBootDisk 6.5. I've toyed with this before, and today I have just unpacked its ramdisk onto my virtual C drive, let it boot, and took the resulting system.ini and protocol.ini that the set of scripts produced :-) Also the sequence of loading the various binaries comes from the NBD. I just minimized the set of binaries required and de-modularized the original flexible "loading sequence" of the NBD. I have managed to get a plain ASCII text file printed on a decade old multifunction LaserJet (1522 if memory serves), through my "printing infrastructure". The hand-over point from DOS to the first downstream print queue is "LPT2:" mapped by "net use ..." to a queue advertised by Samba on Debian 9. Samba takes the queue definitions from a local /etc/printcap, and some LPR follows up from there. I believe the plain ASCII file has reached the printer without any modification. In your use case Bryan, my "package of canned DOS drivers" is just a first half of the needed configuration. Next up, we need to configure Samba and CUPS to transport and transform your print jobs :-) It would be easiest for me to just log into your Linux box, but that has some non-trivial prerequisites, such as a mapped port from your router's NAT outside (or a TeamViewer install on the Ubuntu box) and a fair bit of trust between the two of us, because letting me in your living room is a hefty security hole. Details should better be discussed in private messages, for security reasons. Alternatively, I can try sending you a minimal smb.conf and some instructions on how to install Samba on Ubuntu. That, for a start. Then we'd need to figure out the queueing magic in CUPS. I don't have much experience with advanced CUPS sorcery, but in the older days I've read about automagical "queue filters" that could auto-detect the data format of the print job being supplied by the client, and transform the job accordingly to suit the printer... I dare not hope for all that intelligence in this case, but I mean to say that various magical things are theoretically possible :-) Frank ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] DOS on (very) small form factor PCs?
On 29 Apr 2021 at 22:32, Adam Nielsen via Freedos-user wrote: > > Thanks for the NUC warning, but Win98 actually will switch from BIOS > > to built-in drivers which are likely not able to cope with new > > chips. > > That's what I thought too, but I figured it would at least run in > compatibility mode and IIRC the BIOS had options to run the SATA > interface in IDE-compatibility mode so I figured my chances were good > but alas no. > Either generic IDE mode can be enabled in the HW, or you have a chance if Win98 are willing to work via the "compatibility mode" (BIOS services) - that has theoretical chance of working even on fairly new AHCI controllers, provided that the "firmware" still has BIOS services (int 13h if memory serves). I've found this post about AHCI vs. Win98: https://msfn.org/board/topic/173885-ahci-and-windows-9x/ Not that I've ever tried this on modern hardware :-) Also, you'll have a hard time finding modern PC hardware with less than approx. 1GB of RAM, which is another principal "no go" for Windows98... Overall, to run Win98 on modern PC hardware, I'd strongly recommend to install some modern OS first (even Debian Linux) and install Win98 in a virtual PC / emulator. No problem with RAM size, HDD controller, VGA hardware compatibility, legacy BIOS support, generally drivers for hardware. The same goes for Windows XP on modern hardware, and the Windows 7 will soon follow (or have followed already, around Kaby Lake if not earlier. No driver for USB 3.1+ XHCI.) > I've only bought Intel boards for quite a few years now > As much as I am a diehard fanboy of Intel PC CPU's and chipsets in the industrial hardware that we sell, I am not a fanboy of Intel-branded *motherboards*. I've had one bad experience, about a decade ago, on an LGA775 board at the time, which had an odd glitch that the board sometimes (often) would not be able to start from ACPI S5, after it has been booted into Windows XP and shut down by software a couple times. You had to pull the cord out of the wall socket, or flip the rocker switch on the PSU. Linux did not have this problem. And it was a couple dozen boards sold, and no problem ever acknowledged from Intel... Other than that, the Intel BIOS looks like something "smug and simple" = allowing Intel to be first to the market, with their shiny new silicon on their own motherboards, like a reference implementation... but somehow as if the motherboards don't get much love from their maker after launch. So Intel CPU's and chipsets definitely yes, but on other vendors' motherboards. With respect to no-nonsense legacy BIOS compatibility and no-frills reliable hardware, I'd like to praise Advantech in the "industrial" segment and specifically Gigabyte in the office-grade PC segment. Preferably if you purchase models that are not "hot off the press", i.e. the BIOS is not an initial shipping version. > I do like the NUC though and I found that some of their older models > list Win98 as supported so I am on the lookout for those models, but > even second-hand ones go for surprisingly high prices where I am, and > people seem happy with them as they don't come up for sale very often. > Or maybe they don't last very long before they start getting flakey ;-) To me, the NUC is a problematic form factor. I've been a troubleshooter for a wide range of industrial PC's, including passive/fanless models - and I know what sized aluminium box with how many fins it takes, to decently heatsink an ATOM, or a full-fledged Core i3/5/7 CPU (even the T/U/Y models). The NUC feels just too small and flat-surfaced for the CPU that's quietly ticking away inside. The elevated inner temperature also affects an SSD that serves as a boot disk... I certainly wouldn't buy a second hand NUC. I'm a big fanboy of Intel ATOM CPU's, from Bay Trail onwards. For a variety of uses, not necessarily for DOS specifically... My favourite construction is: get a passive-cooled MiniITX board with an ATOM, and add a slow-revolving fan. Or just an airshroud to direct the faint draft of air from the PSU fan through the CPU heatsink. Frank ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] DOS on (very) small form factor PCs?
Speaking of nice vs. less complete VESA BIOS ROM's, I've known Intel for not having a full set of VESA modes since their first integrated graphics adaptors (not sure if 810/815, but 845 and afterwards certainly) - namely, 16-color indexed VESA graphics modes were missing (anything with 4 bits per pixel), which prevented some old and odd CAD apps from working... and I recall some apps resulting in a white screen even in modes that theoretically should've worked... And, Windows 98 have specific severe quirks which cause them a problem to install and run on 512+ MB of RAM. My friend Rayer has described many details on his website, only the page is in Czech: http://rayer.g6.cz/os/os.htm#WIN98-512MB Try google translator if interested :-) Frank ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] DOS on (very) small form factor PCs?
On 28 Apr 2021 at 23:24, tom ehlert wrote: > > > ...the board format does not matter much. > > It's the CPU model/generation that matters. > > NOT. AT. ALL. > > each Intel/AMD CPU produced the last 20 years is able > to execute the same way that the previous versions did. > ...okay, apologies, it is not my intention to start a flame war :-) I agree that in terms of instruction set and memory/addressing modes supported, even the most recent x86 CPU's can still run 16bit DOS-era code. What I meant by "CPU" in this case was the broader platform that goes with it. The chipset, the "evolutionary generation" of the "firmware". Speaking of the chipset, I'm referring to legacy peripheral hardware, at least the presence of a decent "legacy SuperIO" chip in moderately dusty history, vs. the gallop towards newer and speedier USB and PCI-e standards. Yes I'm aware that modern "firmware" still tends to facilitate DOS operation by providing keyboard and mouse services (or even PS/2 controller emulation through SMM) on top of physical USB hardware... Think about software that's written for slow x86 CPU's, and fails miserably on anything faster than a couple hundred MHz - and no, it's not just the Borland Pascal CRT library, there are others of this class. There are games that kind of relied on CPU speed in some ballpark, otherwise the animations are too fast to even notice etc. Older BIOSes used to allow you to mess with ISA MMIO windows available for use with your peripheral devices - with the demise of ISA, BIOS config options related to memory space between 640 kB and 1 MB have quickly vanished, and the "firmware" takes liberty at using this range for whatever option ROM's it sees fit, thus making any "conventional memory volume tuning" pretty problematic. In all those respects, the CPU generation is a pretty good predictor of what kind of a "platform" you get around it. Speaking of tiny x86 platforms, I'm wondering what happened to the Intel Quark. Initially this looked like a contender against the DMP Vortex, but only until you looked at the peripherals present on the reference motherboards with Quark. In terms of peripherals, it's like comparing a traditional large Legoes kit of late eighties (Vortex) to a slick and glittery Tamagotchi (Quark). I do feel guilty of promoting a particular vendor / product line, but let me repeat this link that I sent yesterday: https://www.icop.com.tw/product_list/44 Notice that the particular board format is a proprietary 100x66 mm, called "tiny module" by ICOP. This is not a PC104 format - which means lower price. Anything that has a PC104 connector on it is automatically +50%. The "tiny module" form factor is not significantly larger than an RPI, and while it does not have the perfomance of an RPi, in terms of tinker-friendly interfaces, it probably gives the RPi a run - especially if you're fond of the 486-era legacy x86 style. Some models have an SD slot, some have an onboard SPI flash disk to boot from. The SoC has got an on-chip USB EHCI and an on-chip 100Mb LAN. I personally prefer the Vortex86*DX* era hardware by ICOP, exactly for its 486-ish features and peripherals. The nominal clock tends to be 600 to 800 MHz, but can be underclocked down to 1/8th of that, in the BIOS (or programmatically). The VDX boards have a discrete SIS/XGI Z9s PCI graphics with a dedicated 32MB VRAM and a pretty good VESA BIOS ROM (a rich selection of classic SVGA video modes). I don't like the Vortex86*SX* as much (for obvious reasons) and I don't like the newer developments from DMP as much either, because of the "modern direction" these have taken. The VDX hardware doesn't have nearly the sort of problem with heat that an RPi tends to have, without additional heatsink upgrades. That said, even the cheapest Vortex motherboards are still more expensive than an RPi. The larger Vortex board formats, i.e. PC104 or 3.5" biscuit, have IDE (or SATA) or CompactFlash coupled to an IDE channel, and other goodies - those board models obviously cost more. But, at least you have a choice, and it's still classic 486 era busses and interfaces. I'm wondering why ICOP never produced say an ITX form-factor motherboard with an ISA slot, or a full-length ISA+PCI PICMG board. It probably wouldn't pay off (pay for the R) because retrofits/refurbs of full-scale computers in production use are really few and far between, and just nostalgia probably wouldn't generate enough sales. A side note on CPU clock rate: in the golden era of EIST, before TurboBoost, it was fairly easy to poke some EIST-related MSR to underclock the CPU core on the fly. So we're speaking say Pentium 4 or Pentium M up to Core 2 45nm. Even that way, you typically wouldn't get lower than say 600 MHz to 1 GHz on a particular CPU, where the IPC was already a multiple of what the old Pentium MMX would provide... so the EIST underclocking is not enough to dodge the "Borland
Re: [Freedos-user] hardware recommendations
On 27 Apr 2021 at 18:24, Liam Proven wrote: > A BIOS is one type of firmware. UEFI is a different type of firmware. > point cordially taken. I'll pay attention to be less casual about my vocabulary at this mailing list :-) I do have a bit of an etymological issue with the thing being called a "firmware" though. In the sense, that "firmware" originally used to be something running on an MCU in some peripheral device, that you did not run your own software on. Firmware used to be for black boxes. Calling a BIOS a "firmware" is marketing newspeak to me :-) BIOS/UEFI are mostly some services stored in an EEPROM, including a primitive loader to get your OS bootstrapped. It all runs on my x86 PC computer's main CPU, and is just about good enough to get my modern OS airborne - once the OS is airborne, the BIOS/UEFI services have a marginal role. [/subjective rant] (And then there's the AMT BMC, good for god knows what. And yes that does have a firmware worth that name, stored in the same EEPROM chip as the system BIOS/UEFI.) Frank ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] hardware recommendations
On 27 Apr 2021 at 16:01, Eric Auer wrote: > I agree that it will be tricky to ask vendors which styles > their machine supports, but actually my impression is that > support for booting DOS is not that exotic yet. In my recent experience, and I don't sell office-grade PC hardware so that experience is limited: ITX motherboards by Gigabyte, with BayTrail and Apollo Lake ATOM, do have the "legacy BIOS boot" (and CSM support) available in the BIOS. You can select whether to have it or not, there are several items in the BIOS Setup related to that. ITX motherboards by AsRock, with Gemini Lake ATOM: UEFI only. Not in the least apologetic about it :-) The motherboard user's guide, typically available in PDF for download off the vendor's website, typically has a couple screenshots of the BIOS SETUP. If there's not a word about a CSM or legacy boot, beware. There were some earlier examples of motherboards where the CSM initially wasn't available, and got added in a later version of the BIOS. But, I wouldn't rely on this anymore - for many vendors it's UEFI-only from now on. Where I work, our key supplier is Advantech = industrial-grade PC hardware. The legacy boot method is typically still supported in their hardware, ispecially in their "inhouse products", e.g. ATX / microATX / mini-ITX motherboards. But, this isn't something you'd want buy for a home PC, at the price. Otherwise it's rock solid PC hardware, and the BIOS feels very conservative / vanilla. To be honest, if I wanted to get a modern PC toy box with SoundBlaster compatibility, I'd probably use some recent ATOM, even if UEFI-only, install an appropriate version of Linux and run DOS under QEMU on top of that. And I'd be free to choose the emulated SoundBlaster if I wanted to. As for what Linux: whatever you are familiar with. And, QEMU seems to get better with every version. In the recent years, I'm with Debian, so I'd probably choose some recent fast-paced Ubuntu, to get a fresh QEMU out of the box, with frequent updates if desired. Whenever I deal with something in DOS, the native DOS-based editors and IDE's nowadays feel so tiny, in the 80x25 terminal (even 80x43). I prefer to edit text files "out of band" in some Windows or Linux environment and maybe just run the compiler for that in DOS, if cross-development on the modern machine is not practical for some reason. Frank ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Printing over the network
...for some reason, this has not been delivered on Friday... (continuing a privately started debate in the mailing list) We need to start from the fact (which you have found out, and I have cofirmed) that your printer is probaby GDI based. (To me this sad fact is still surprising, or "despite all odds".) On 23 Apr 2021 at 7:01, Bryan Kilgallin wrote: > > Hi Frank: > > > > ... so you've downloaded and installed the proprietary driver from > > Brother, for your printer? Or did Ubuntu just find and configure > > the printer automagically? > > I think that was at first Ubuntu. But I then updated from the > Brother Australia Web site. > Okay - I believe that this principally means that the CUPS printing subsystem on your Ubuntu can accept jobs formatted in PostScript and do the necessary conversion and connection to print them on your printer. The trick now is, to get PostScript jobs to the respective print queue on your Ubuntu. I'd hazard a guess that the Ubuntu PC has some listening sockets open for access via IPP, LPR and with some minimal effort we could have Samba. IPP is no use from DOS, so we have LPR or Samba left. Means to me that I have to cook a recipe for TCP/IP in MS-DOS, using the MS Network Client 3.0 for DOS, and maybe an alternative recipe using the CRYNWR packet driver API (for the mTCP tools and maybe others) - although the trick with NetCat possibly won't work, unless we can find a way for your Linux PC to accept jobs in raw format. (Hmm... maybe set up NetCat/SoCat to listen on a port and pass the job locally to LPR? Shouldn't be all that difficult.) Theoretically it should be possible to set up your own "artificial" print queue in the Linux box, employing a "filter" based on e.g. GhostScript/GhostPCL, which could accept print jobs formatted in PCL3 / PCL5. Or, raw ASCII for that matter. Convert them to PostScript and pass them to the existing CUPS queue for your physical printer. Or maybe there's a more direct way in CUPS, not sure. Again I need to sit down at my workplace with some hardware to collect the DOS drivers and "develop" a few batch files. And the Linux side of the story is yet another story :-) Frank WPM$VXKX.PM$ Description: Mail message body ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Printing over the network
On 22 Apr 2021 at 19:11, Bryan Kilgallin wrote: > Thanks, Michael: > > > I've used this trick to print graphics from a PCjr to my modern > > Brother laser printer. The graphics were formatted for an IBM > > Graphics Printer, which uses a subset of Epson ESC P2. The printer > > can handle PostScript, PCL, Epson ESC P2, and plain text. > > Whereas the documentation just says that my Brother HL-3150CDN printer > emulates GDI. > Ouch! Apparently, you're right :-/ https://download.brother.com/welcome/doc003061/cv_hl3140cw_asoce_usr.p df On page 190. Yesterday I haven't noticed that the manual was "universal"... If the printer is indeed GDI, that's bad luck in terms of direct printing from DOS. If you can print to this from Linux, there's still a chance if the Linux box functions as a proxy. Via the network. Or if "GDI" actually means PCL3, but that's a slim chance. This would be the first GDI printer with a duplexer and a built-in network port that I'm aware of :-( Frank ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Print via USB
On 21 Apr 2021 at 19:46, Bryan Kilgallin wrote: > Eek, Frank: > > > oh that's right. Suppose that you have good support in the BIOS for > > your USB keyboard, USB mouse and USB mass storage. > > Yes, I have a KVM switch driving both a keyboard and mouse from the > DOS PC! > > > Then you install > > the USB LPT driver by Bret Johnson, which takes over the whole UHCI, > > and may render your BIOS support for KB + Mouse + mass storage dead > > in the water > > I have unzipped USBDOS to a directory on a stick, that is now plugged > into my DOS PC. And I'm reading the "readme" document. -- > members.iinet.net.au/~kilgallin/ > I've forgotten to add, that there's no risk of permanent damage of any kind. If you try to load the USBDOS driver stack, and you end up with an unresponsive system (keyboard and mouse stop working), you can always just press RESET to reboot your machine, and get keyboard and mouse working again. Unless that loading of the driver is already in your autoexec.bat/config.sys :-) Frank ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Print via USB
On 20 Apr 2021 at 10:41, Ralf Quint wrote: > dreaded (from the viewpoint of operability in DOS) USB connected > printers. Finding USB drivers, given that the printer is software > compatible with DOS as mentioned above, will likely be an exercise in > futility. If someone has a surefire way of doing that (where I > personally would even except non-FOSS solutions), specially one that > wouldn't interfere with any other USB drivers, like for storage media, > I would be happy to hear about it. > oh that's right. Suppose that you have good support in the BIOS for your USB keyboard, USB mouse and USB mass storage. Then you install the USB LPT driver by Bret Johnson, which takes over the whole UHCI, and may render your BIOS support for KB + Mouse + mass storage dead in the water :-/ Frank ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Print via USB / deprecate or improve PRINT queue tools?
On 20 Apr 2021 at 10:49, Ralf Quint wrote: > If you are talking laser printers, then that might exclude printers > that are Postscript only, as they require some software on the > computer side to translate plain text into a Postscript data stream > that the printer understands. Not such a big deal for simple text > files, I have written such a tool in the past in less than an > afternoon, but it is still an additional step to be taken, unless you > are printing from a DOS application that by itself is capable of > printing in Postscript (AFAIK, both Word for DOS and WordPerfect for > DOS come with Postscript printer drivers). > Bryan says he's got a Linux computer. I've never seen a build of "mpage" for MS-DOS, but I recall old howto's for lpd / printcap and using scripts as filters. I'd just set up an extra queue for plain ASCII input and use a2ps or mpage to convert on the fly into postscript. > A printer that natively understand PCL3 ... will commonly understand plain > text. > thanks for correcting me, my memory is flakey :-) Frank ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Print via USB
On 21 Apr 2021 at 0:00, Bryan Kilgallin wrote: > I had transferred data from my DOS PC to my Linux PC via a USB-2 > stick. But I thought that I might do something as simple as printing > text, directly from the DOS machine. > So there's another solution, one I already hinted at: Install Samba on your Linux PC. It may take a wee bit of learning to configure, but it does not bite back. I can help with snippets of config to make it accept ancient DOS clients. Install the Microsoft Network Client for MS-DOS. You can install this from scratch, or you can try using/refactoring the NetBootDisk: https://www.netbootdisk.com/floppy/download.htm ...and then redirect the LPT device: NET USE LPT1: \\my_samba_server\printer_queue Actually I hope I'm not kidding here... most of the howtos mentioning this command are actually about doing this in a Windows command prompt = a more modern version of the MS Network stack... I've never tried this myselfs in pure DOS. Frank ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Print via USB
...just to follow up on what others have said, Bryan's printer is too old to support PDF, but it is a pretty decent color laser apparently, likely supports PCL5 in "HP emulation" mode, and something called "BR-script (PostScript layer 3 emulation)" which I hope gets rendered in the printer too, rather than using a translation layer in Windoze :-) The printer accepts jobs via IPP, LPR and JetDirect, therefore I don't think its a stupid super-cheap GDI printer. Some modern super-cheap printers support the PCLm first and foremost. Some older super-cheap printers would accept PCL3... Frank ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Print via USB
On 20 Apr 2021 at 16:59, Thomas Desi wrote: > Regarding printing I think there are two basic concepts: > Using fonts from the printer (I call this "generic", but maybe this > is my private lingo) or using graphics from the computer. > As I am only interested in printing out pure text (A-Z, 1-0 :) I > wonder if you attempt to print out graphics or some special fonts > or so? Might make a difference, too? Built-in fonts are obviously an option, there's always some plain ASCII built in, and I believe in the old DOS era there used to be... programs that you ran before printing your jobs, that would pre-upload font sets or national character sets into the printer, so that your print jobs could then refer to those fonts and produce the desired output on paper. Epson dot matrix printers (ESC*P language) were perfectly willing to print individual characters, a line at a time I guess. They were (are) line printers and the ESC*P "language" is little more than an "extension" of raw ASCII + control characters (CR, LF, FF etc) by "escape sequences on top" - for switching fonts and maybe more complex tasks. I mean to say that if you copy a flat ASCII File to an Epson printer, you get some noise and some output on paper. Laser printer formats are page-oriented, and are not "evolved from plain ASCII" in the way that sending a paragraph of raw ASCII text would yield visible output on paper, even if a "formfeed" provokes the printer to load paper and print a page (not sure if this even works). Even in PCL, you need to provide some commands to the printer, to place some text on the page and get it "rendered on paper". Let alone PostScript - quite a tightly specified "well formed" format. Obviously you can embed bitmaps in PCL and PostScript print jobs. Esc*P can do it too. When printing from modern software, every page can be just a huge embedded bitmap. And, there are printers that can *only* print bitmaps, albeit in a thin wrap of some standardized format: think PCLm (in spite of its name, it is a gutted / stripped down version of PDF). Umm... getting off topic, am I... Frank ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Print via USB / deprecate or improve PRINT queue tools?
On 20 Apr 2021 at 16:21, Eric Auer wrote: > > Hi Bryan, > > I believe you have to install DOS USB drivers first. And actually it > could work better to use the NETWORK for printing, because DOS (wired > LAN) network drivers are more evolved than DOS USB drivers and you can > use DOS versions of NETCAT or other tools to copy the contents you > want to print to the IP and port of your printer as hopefully listed > in your printer documentation or visible in some status information > screen when you print from Linux :-) > Eric has cracked it :-) There appears to be a version of Netcat for DOS, even including an example of how to copy a file to the printer: https://www.brutman.com/mTCP/mTCP_Netcat.html It requires just a packet driver for your NIC. So if printing into a file and copying that by an extra command is not a problem, there's your solution Bryan... Frank ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Print via USB
Dear Mr. Kilgallin, your request is less obvious than may have initially seemd to you. DOS knows an OS-level "device" called LPT1. And, most software for DOS that needs to print, can use this software-level LPT1 device (using a DOS service to print). DOS and BIOS work together to forward data from LPT1 to the physical parallel port (i8255 compatible hardware, if my memory serves). To this day, most PC's still contain SuperIO chips (on LPC bus, backward compatible with ISA) that still have the ability to implement the LPT, but few modern motherboards actually have a physical LPT... (and therefore the SuperIO chips aren't even configured to decode the addresses anymore, 0x378 and whatnot. No use.) But, yours is a different problem: your printer does not even have LPT "input". You really do need to somehow spoonfeed the data into the USB port. Technically, a USB printer shows up on the USB bus as a "USB LPT device", or "USBLP". The USB standard has a "device class" for this, and modern operating systems have a generic class-based driver for this... which is not the case of MS-DOS. Effectively, you need a stack of USB drivers for DOS, that will make use of a USB host controller (UHCI / EHCI / XHCI), enumerate the bus, and upon encountering a USBLP device, load a generic class-based driver for that device. Presenting a legacy LPT1 software device in MS-DOS, and feeding the data to the USB LPT physical port. To the best of my knowledge, there's a single driver package of this kind that I know about, working on bare metal in pure old DOS - the one by Bret Johnson: http://bretjohnson.us/ More prose about USB printing in DOS: https://www.wpuniverse.com/vb/showthread.php?38551-Print-to-USB-printe r-in-pure-MS-DOS-system/page2=8f49961ada033bce8d27f50b29967cd1 Bret Johnson's driver only supports UHCI controllers, which were only included in the PC chipsets up to and including Intel 4x series (coming with the 45nm Core2 generation of CPU's). After that, it's pure USB EHCI 2.0 only. Until about Skylake, which is USB 3.0 XHCI only... Apparently, you are lucky, because the OptiPlex GX270 appears to be a Pentium 4 generation PC. Already supporting USB 2.0 and having an EHCI, but in addition to that, all the USB ports are also available via an UHCI (USB 1.1 controller). So I suggest that you give Brett's driver a try. An alternative approach might be, to attach the USB printer to a Windows PC and share the printer on the network, and install a Microsoft Network client for MS-DOS on your DOS-only PC, and map the LPT1 over the network to your Windows PC. This LPT mapping is done using the "net use" command. But, you need to be able to configure the networking stuff, preferably over TCP/IP nowadays. Note that making the MS Network client from the DOS era talk to a modern Windows machine in the server role can be a challenge in itself. If you're lucky, you can learn about registry entries that dumb down the security mechanisms in Windows enough to accept the shitty ancient security model used by the DOS client... I don't promise that this still has a chance of success in Windows 10. I believe it does have a chance against Samba in Linux, which I'm still using to serv8e PXE-booted diskless clients (for disk mapping, not for printing, but the auth is the same I guess). Your printer apparently also supports network printing: via IPP (too modern), JetDirect style raw TCP port 9100, and UNIX standard LPR. Unfortunately, it does not contain a Microsoft Network stack (samba/CIFS) so you cannot map the printer directly by "net use ..." I've found hints that Xerox or Sun used to have an implementation of the command-line LPR client for MS-DOS: http://download.support.xerox.com/pub/docs/DC240_DC250/userdocs/any-os /en/Using_lpr_Utilities_for_DOS_and_Unix.pdf ...apparently dependent on some "very own" TCP/IP stack for DOS, and not hooking LPT1 = you could print from your software into a file and then copy that file to the network printer using the LPR utility. I haven't found any resident driver for pure MS-DOS to capture LPT1 and print to LPR or even just JetDirect (raw TCP port). How about using a Raspberry PI to build a Samba printserver for your USB/LAN-attached printer? :-D Or, if you resort to running your DOS software in Windows or even some kind of DOS PC emulator on any modern OS, your goal to forward jobs from LPT1 to any miscellaneous printer would be much easier to achieve. If all else fails, there is commercial software for Windows to help you with that. So... suppose that you've built a path for your data from the LPT1 abstraction to your actual USBLP printer. The next question is: print job format. The printer language. Looking into the docs of your printer, it's new enough to support "laserjet emulation" (read: HP PCL at some older version) and apparently PostScript as well :-) This sounds good. Don't expect the printer to print a plain ASCII file
Re: [Freedos-user] A different approach
On 3 Feb 2021 at 14:36, ZB wrote: > Build mini MSDOS gaming PC - NO EMULATION! PC104 > > https://www.youtube.com/watch?v=ZBsv-jRiIT8 > > (Using PC/104 components to build a mini 486 MSDOS gaming PC) He's built a PC-104 soundblaster card for christ sake, and he's using a 486SX CPU = no math coprocessor, even mentioning that in the vid... while the same brand (ICOP) make pretty much the same board with the lovely DMP Vortex86DX, which he fails to mention. I've just dropped a comment to that note under the vid. Such an outrage :-D And such a very nice project. Other than that, the PC-104 feature seems to be somewhat expensive on the embedded motherboards. Especially the ICOP tiny modules are significantly cheaper. No SB Audio though. If you need SB-compatible audio = ISA, perhaps PC-104 is not really so very expensive, compared to the PICMG ISA option, where you need an ISA backplane, and a big chassis etc... Frank ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Windows 95
On 28 Jan 2021 at 21:42, Šimon Dobeš wrote: > > Well it's like this. > > For me it's too hard to orientate in command line interface such as > dos. For better orientation I prefer some sort of grafical user > interface (GUI) I do not know anything other except for Windows. It > is the best environment for me since when I was a child we had an > 486 > dx2 with windows 98 se on it. In this point my gaming career > started. > I played mostly dos games and some windows games such as a pinball > and so on. After 22 years I found several abandonware websites that > offer all that great games from my childhood. But there is one > problem. I just don't know how to use dos. So I want to use GUI when > I am running any of that games. Please note that I was 7 year old > boy > when dad brought the computer home. > > I also installed Linux Mint that comes with wine. I copied games > from > CD to run it and nothing happened. Even after trying to configure > wine. > The Wine emulator caters for win32 applications. The win32 .EXE format (PE-COFF), while looking similar to a DOS .EXE on the outside, really needs a different set of OS services: the Win32 API. And this is what Wine emulates. DOS is deeper back in history. It has its own set of 16bit services and programming conventions, different from Win32 API (predating it). AFAIK Wine does not emulate a DOS environment for native 16bit DOS applications. But, not all is lost, you can get a DOS environment in Linux, even without modern heavy-weight and opaque virtualization. Which means, that you can have your apps in directories on your Linux filesystem, and run a "shim" or a DOS shell on top of those Linux native directories, and the DOS shell will feel like native DOS, and will run DOS programs, you can assign/map DOS drive letters to underlying Linux directories etc. There are two DOS emulators for Linux along those lines: DOSEMU and DosBox. You need to understand their configuration a bit, which may prove more difficult than installing DOS on bare metal and editing its autoexec.bat and config.sys :-) but these lightweight emulators then allow you to e.g. copy files or switch symlinks "underneath" the running DOS program at runtime. I've never tried this, but it might help you swap those install floppies by jumping out of the emulator for a moment, changing the contents of a floppy-emulating directory and then jumping right back into the DOS, without having to stop your DOS program. http://www.goodbyemicrosoft.net/news.php?item.828.8 http://www.dosemu.org/docs/README/1.4/ https://packages.debian.org/buster/dosbox https://www.dosbox.com/DOSBoxManual.html Or maybe something could be done about your problems installing Windows95 on bare metal. I remember trying to install Windows95 on a 486DX 120 MHz for the first time. I always gave up after maybe 20 minutes of the Windows installer doing apparently nothing. On about the 4th attempt, I got bored, got up from the computer and went to grab something to eat or what... I returned after an hour, and lo and behold, the installer was finished! I just had to be more patient, and stay away from that reset button. Obviously, as others have said, your chance of success depends on a number of things, such as exactly what your hardware is, in what condition it is (stability), if you need some drivers to get your disk controller and graphics to work and whatever. Back in the day, I got my hands dirty with Windows95 and 98 pretty often, and I've had a go with them during the noughties several times, on my job (many industrial PC's run obscure old operating systems and the one thing you do not need is an OS upgrade, even if your original hardware has died.) These were the toys of my later teenage youth. Apparently you can still buy new hardware that has full support for Windows98 and DOS: https://ipc2u.cz/catalog/ebox-3310a-h Unfortunately the audio output is not SoundBlaster-compatible, otherwise there are Windows98 drivers for almost all the components. Apparently it has a PS/2 MiniDIN for keyboard+mouse. The keyword here is "Vortex86DX" (not SX, not DX2). I also recall that there used to be notebooks with an onboard audio chip that was SB-compatible :-) but you'll have a hard time finding a 20 year old notebook nowadays. Feel free to contact me by direct e-mail if you'd appreciate help and you don't want to discuss this in public. BTW I'm Czech, you are possibly Slovak, so unless you'd like to exercise your English too (which is always a good idea!) we can take some shortcuts there as well... BTW - some further reading in Czech about DOS and Windows98 survival in modern times: http://rayer.g6.cz/os/os.htm http://windows98.xf.cz/ Frank ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] dos ethernet drivers
On 20 Jan 2021 at 0:42, andrea...@tiscali.it wrote: > Now I am trying to load a diver for a toshiba satellite with > Marvell Yukon eth.card: I found the driver (yukodi driver) > and it would seem to work, and system says it loaded > odi packet driver and so on, but neither Arachne no Link go up on > internet. I have a wattcp.cfg (My_ip = dhcp), as usual, > but they fail. ...oh wait. Let's speak ugly details. fetpkt is likely a native packet driver with CRYNWR API. That's what many DOS TCP/IP networking apps are using. (Pretty much anything outside Novell and Microsoft.) b44.odi is a Novell ODI driver = does not provide the CRYNWR API itself. But if you say that you're using b44.odi, you probably also have the odipkt.com. Now you say that the driver Yukodi does not work for you. Looks like another ODI driver. Hmm... if Arachne and others look all happy, does that mean that odipkt.com is loaded as well? Also, AFAICT the Yukon NIC is a PCI device, so you should not be required to tell the driver about any particular hardware resources such as base IO address and IRQ (and possibly get them wrong). At my workplace, I've been using the Microsoft Network client for DOS for ages, even on relatively modern hardware. And for most networking cards, the vendors have kept providing updated drivers for the Microsoft stack = those with the .DOS suffix. And, I can see traces of information that there used to be a shim driver called the dis_pkt.dos , to provide the CRYNWR packet driver interface on top of a Microsoft-style networking driver stack. Analogous to your odipkt.com which is Novell-flavoured. Unfortunately I cannot provide you with a complete boilerplate script and config file for the whole microsoft stack. I've had experience with the "Hiren's boot CD" software package where the loading of the .DOS drivers is kind of automated... Other than that, this is DOS... same old, same old. No memory protection, drivers must load resident in a couple kilobytes under 1 MB... namely the network drivers typically work but sometimes don't... You may get different results based on what DOS version you use, what EMS/XMS manager and its options, what CPU you are running on, and possibly what phase of the moon it is... I have recent unhappy experiences with DOS networking and other stuff (general application compatibility) in virtual environments (QEMU). This is computer archaeology. Trying to make your super-ancient OS run on modern PC hardware. It's a miracle that it manages to boot at all. I'm not surprised that no serious effort is wasted on trying to create modern apps for this programming environment, such as a modern web browser - from a programmer's perspective this is a ridiculous proposal. Frank ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] USB serial port
On 6 Jan 2021 at 11:23, Tomas By wrote: > Hi all, > > Is there a way to get a USB serial port adapter to work? > This cannot be made to work for legacy software that accesses the UART registers directly, hooks an IRQ etc. USB is a whole different bus architecture, compared to legacy ISA. The following driver *might* be a way for software that can work with a DOS "device" abstraction. Or, if you actually have source code of the DOS program, that needs to work with the USB COM port, you have a chance to modify your software to use the DOS device abstraction: http://www.dosusb.net/dosusb.pdf Note that USB/serial has no standard USB class (except maybe for ACM/CDC, which is not very popular among USB/serial dongles). The serdrv.sys as part of dosusb only supports USB/serial UARTs by Prolific. Open-source code examples are available in the wild interwebs, for a few popular serial/USB UART chip models for Linux (stock kernel drivers) and Android (user space libraries) - supporting brands such as Prolific, FTDI or Silicon Labs. The DOSUSB driver also provides a generic URB interface, which theoretically would allow you to write your own "USB/serial driver" = routines for your particular USB/serial chip. All in all I don't think this is what you were asking for :-) Frank ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] IDE <-> CF adapters
On 27 Dec 2020 at 6:42, Jon Brase wrote: > > Dec 27, 2020 12:05:46 AM Frantisek Rysanek > : > > > On 26 Dec 2020 at 22:40, Jon Brase wrote: > >> > > > 40 MB of RAM in Windows95 - that's something I once had in a > Pentium > > 75 MHz :-) > > Possibly the same model of machine, given that both RAM and CPU > match, and 40 MiB is a rather idiosyncratic amount of RAM (add > opposed to a power of two). Mine's an AST, forget the exact model > number and can't check right now. > No it wasn't the same model. In july 99, I got myself conscripted to have our (then) mandatory military service over with. After a short boot camp, I was assigned to a position in the office of a unit someplace in the countryside - the job involved keeping track of the headcounts, reporting the counts of the three daily meals required to the kitchen, keeping stock of clothing for them and a small ammunition stock. When I arrived, the office had a Compaq desktop with a Pentium 75 and 8 MB of RAM, grinding away at MS Office 6 under Windows 95. And I had two colleagues in the office me who were several months my seniors on the job. And from my first weekend off, I brought back 32 MB of second-hand RAM and was delighted to find out that it worked in the machine. On the next day, my comrades said something like "Frank dunno what you've done to the computer, but it it's blazing fast now." Nine months later, when my time has come to leave the army, I left the RAM in the machine. > > exceed 25 totally random IOps. Modern 7200rpm desktop SATA > drives > > during the last 15 years can typically achieve some 75 random > IOps. > > About 60 IOps for laptop drives. And those numbers do not grow > > significantly during the years, with new disk drive generations. > > OK, if modern SATA gets 75, then 25 isn't too concerning. I was > worried it might be more like an order of magnitude (or two) > difference. > Um... note that real HDDs have a memory buffer, acting as a write-back cache. Not sure how much RAM the CF cards have, possibly a couple hundred kilobytes. 10-15 years ago, not sure if 2 or 8 MB was the norm in spinning rust. Currently, the basic volume is about 32 MB maybe? , with some higher end PMR drives sporting 64 MB. And then there are SMR drives with 128 or 256 MB of RAM buffer, often called "cache" in the marketing materials, but I suspect that it's more like a working buffer for a single shingled track or segment (sequence of tracks?) that needs to be assembled before writing. Not sure if the whole "shingle buffer" can actually work as a write-back cache. If it could, that would be your perfect "RAM-based swap device, initialized from disk on startup". Just add a SATA/IDE converter. Take a look at the cheapest 2.5" Seagate Barracuda (ST1000LM048 or some such) for instance. Even if the RAM buffer is not enough to cover your whole swap, your modest swap space would likely fit inside the disk drive's "PMR zone", so you possibly wouldn't ever swap into the bulk SMR area which acts like molasses when it comes to tiny random writes. Frank ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] IDE <-> CF adapters
On 26 Dec 2020 at 17:13, Dale E Sterner wrote: > I've been using the same cf card for years. OS's > 2000 an higher can only run on KomputerBay cf chips. > These versions of windows check for fixed or removable. > XP will give you a memory error on a Sandisk card but > it still will run poorly. > Sandisk does make a fixed version but you can't buy them. > Only industrial customers can buy Sandisk fixed versions. > I tried ; they hang up on you. > > cheers > DS Innodisk are almost strictly industrial, and they assemble to order (or have stock) from single pieces up, aiming for long-term product lifecycles/availability. Consequently the lead time is a few days EXW, plus transportation to wherever in the world you are. They probably wouldn't sell to individual customers directly, but you should try talking to a local distributor advertising their stuff. Some disties may have a modest stock of some CF model that might as well suit your needs off the shelf. Frank ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] IDE <-> CF adapters
On 26 Dec 2020 at 22:40, Jon Brase wrote: > > Actually I anticipate swap usage at about double physical RAM (for a > total memory usage of 3x physical RAM). I'm using Debian to > administer the machine (with DOS/Win95 for actual retrocomputing), > and empirically that runs well (shell only) with that amount of swap > (at least with the swap partition on a magnetic disk). If I start > XFCE, then it starts thrashing, but I don't really need a graphical > environment there. > [...] > As above, I'm not going for quite 4x RAM for swap, but the exact > numbers in the current magnetic disk configuration are 40 MiB RAM, > 80 MiB swap, and I plan to overprovision swap significantly on CF to > spread out write wear. Part of what I'm trying to figure out is what > kind of overprovisioning I'll need to get a decent lifetime for the > swap device. > 40 MB of RAM in Windows95 - that's something I once had in a Pentium 75 MHz :-) and it worked pretty well for the applications of that time. So suppose that you give it 128 MB of swap, on a 1 GB drive. That will extend the lifetime 8 times compared to a Flash drive with exactly 128 MB, if using the same NAND technology. But again it's really the cumulative number of write transactions, rather than the size of the swap file, that is inversely proportional to calendar lifetime. And again I cannot quantify this any better or absolutely. Linux on 40 MB of RAM... there was a time this was perfectly okay, including a GUI. I believe something like RedHat 6.2 or Debian 3-4 would fly on that setup. Obviously it would have an ancient web browser and e.g. when editing photoes you might run into the limit of available RAM :-) 40 MB should actually be enough even for modern kernels to boot, but a modern user space probably wouldn't be happy, even with some lightweight WM / desktop. > > Don't be surprised to see 25 IOps or even > > less, pauses lasting a couple seconds etc. A pretty far cry from > > those ~4k IOps that you might come to expect, based on random > > read performance. > > 25 IOps doesn't sound good. How does that compare to a similar I/O > pattern on a late 90s/early 2000s magnetic disk? > I haven't seen a harddisk of that era for a decade or so, and I don't recall testing one with hddtest - but based on the average seek times quoted in the old days (12 to 16 ms), and based on the audio impression I recall, I'd say that the hard drives of that era would exceed 25 totally random IOps. Modern 7200rpm desktop SATA drives during the last 15 years can typically achieve some 75 random IOps. About 60 IOps for laptop drives. And those numbers do not grow significantly during the years, with new disk drive generations. These are unapologetic figures, with seeks genererated by /dev/urandom and "direct access" (no caching). The random seek positions alone pretty much prevent any cache from being effective :-) > Well, the absolute ideal for swap, if I could find it, would be an > IDE device that used a couple GiB of modern DRAM and initialized > itself at boot from some partitioning plan > exactly :-) > > > I actually wanted to say this: if you > > only have use for maybe 1 GB of swap, it's no problem that your > > partition can only be 2 GB, > > Actually only 512 MiB for anything DOS will be touching (or when > BIOS first sees the drive), but that won't be a problem for the > Linux swap partition once I've done the whole "trick the BIOS" > dance. > and I'd like to say that you consistently respond in a way that makes me believe that you know your trade, when it comes to partitioning and the various size boundaries - you have my thumbs up :-) Frank ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] IDE <-> CF adapters
On 25 Dec 2020 at 22:36, Jon Brase wrote: > Dec 25, 2020 3:26:42 PM Frantisek Rysanek > : > > > A) standard desktop Windows (XP or earlier) with swapping left > operational, 1 year of lifetime sounds about right. > > It sounds like you're using the card for the OS + swap, though, > rather than having separate cards for the OS and swap. My plan is to > separate them, and probably to overprovision the swap device > significantly. > allright - using a dedicated physical CF card for swap, and another one for the system itself, is definitely a good idea. As a way of protecting the OS boot files. If the swap drive dies, the system boot drive will likely survive, and you only need to replace and format the dedicated swap drive. It's a good start. As for the question if this is good enough, even with the dedicated swap drive, depends on your actual circumstances (swap load = volume and patterns). I suggest that you try this with a cheap MLC card for the swap drive and see how long it survives in your daily practice. And then maybe consider switching to an SLC card to get 20 times the endurance. Trying to protect your system boot partition by making a dedicated swap partition, on a shared flash drive, is moot / futile. The two layers of block mapping below LBA are oblivious of your partitioning above the LBA layer. The wear leveling mechanism inside the drive will happily shuffle blocks belonging to your "read only system boot partition" and mix them with the volatile swap partition, under the hood - for the sake of keeping the erase count per erase block level across the space of the underlying NAND chips (to utilize the available erase count evenly). When unrecoverable errors inevitably start to occur, the drive as a whole is gonna die, your system boot partition won't be accessibe either. I've noticed that you want to have about 4 times the swap space compared to physical RAM. This means to me that your historical machine is starved of RAM, and you envisage enhancing the volume of RAM by a quick swap space. Hmm. The actual success of that idea will depend on how large your typical "DRAM working set" actually is. If you have a flock of apps running at the same time, allocating lots of virtual memory, but only a fraction of that virtual memory needs to be in RAM at any one time (a timespan of say a couple dozen seconds), you're good to go. I can imagine a scenario where you have a myriad desktop apps open, but most of them are just waiting on the taskbar and are out of focus - so that Windows swap them out eventually, which causes no sorrow. But if you need to have much of that virtual space in the "working set" at the same time, your solution with a flash-based drive probably won't satisfy you, performance-wise. If I consider a single channel of 64bit PC133 SDRAM (for instance), that's 1 GBps of sequential transfer rate. UDMA100 is only 100 MBps at its very best. Also, while the latency of your RAM is about 60 ns, for the CF card it's possibly a couple hundred microseconds for reading. It gets worse. If your machine thrashes the swap space intensively, generating lots of those tiny write transactions, a typical CF card will quickly get its relatively tiny transaction buffer (and "SLC zone", if used) full of pending writes and will slow down noticeably at the outer ATA interface. Don't be surprised to see 25 IOps or even less, pauses lasting a couple seconds etc. A pretty far cry from those ~4k IOps that you might come to expect, based on random read performance. => If you're serious about upgrading your legacy machine in this way, I suggest that you purchase two CF/IDE adaptors and some cheap CF card and try for yourself. If you have a chance to test your CF cards on an IDE channel under Linux, consider trying this simple proggie of mine: http://support.fccps.cz/download/adv/frr/hddtest-1.1.tgz There are certainly other load generators / benchmarks. And there's the iostat tool, from the Sysstat package, which can show you the IOps load at the block layer, generated by any kind of software. Don't trash the CF card with random *writes* for too long, as such a test quickly eats away its available erase count. Try comparing your CF-based swap-on-flash solution with an alternative setup, using some SATA-based SSD/CFast/mSATA and a SATA/IDE converter. How about converting this all the way to a small Optane drive :-) Those have like 6k of permitted overwrites, if memory serves - and have really short latencies. Except that ehh... they seem to be NVMe = PCI-e based, rather than SATA. Ahh well. I can't seem to find any figure, how much RAM your machine actually has, just that you want 4 times that much in swap. AFAICT Windows 98 had a problem using more than 512 MB of physical RAM, not sure about how much swap they could use - but let's assume that 4 GB total would be
Re: [Freedos-user] IDE <-> CF adapters
On 24 Dec 2020 at 13:10, ZB wrote: > On Tue, Dec 22, 2020 at 02:37:44PM +0100, DosWorld via Freedos-user > wrote: > >> 1. This is bad idea - use flash cards for swap or more modern os >> (like all windows). I had experience with 16 TF cards, which die >> after 1 year (rewrite limit). All 16 cards work in non-overloaded >> machines. > > My CF card is used as "HDD" 3rd month - we'll see in 9 months will > it survive. > > I doubt it "must die" after a year of use - consider all that > photocameras that use CF cards; their owners probably had to buy new CF > cards each year. > Practical experience, using CF cards as a boot drive in "miscellaneous embedded/industrial" computers where the OS and disk don't have much to do: A) standard desktop Windows (XP or earlier) with swapping left operational, 1 year of lifetime sounds about right. B) Windows Embedded (XP or later) with swap turned off and preferably with the drive operated in read-only mode (Write Filter enabled): the CF card would live forever. Note that if you need to use the flash drive as a swap medium, with SLC you have roughly 20 times the lifetime, compared to MLC. But it's generally advisable to avoid swapping altogether. Also think about logging, Windows updates etc. We've also seen MLC CF cards die after 3 months, when used as the system drive in a SCADA machine, where the software kept making a backup of the current "state" as often as it could (writing a chunk of data to a file on the flash a couple times per second, apparently). Swapping means writing tiny transactions (4 kB) at random offsets, which practically means that the dual-stage mapping mechanism to flash rows and erase blocks will have a lot of janitoring to do. This will multiply the volume written. Compared to that, photoes are stored in pretty much sequential fashion (JPEG's, each several MB in size) and there are not nearly as many of them as the number of writes coming from Windows that keep running 24x7. How many photoes can a human shoot - a couple dozen a day? A couple hundred? When using smal flash form factors as boot drives (CF, similar IDE Flash "plugs" or SD for instance, CFast, mSATA or M.2), avoid wishful thinking. And, 2.5" Flash SSD's are not necessarily better. I'm speaking machines for business/industrial use. If this is a toy machine, you probably have your own idea :-) >> 2. Use last generation of motherboard for Pentium-1 (as minimum) >> with VIA Apollo chipset (designed for Pentium and Amd K6/K6-2) - >> only this chipset understand ATA100 native and allow connect CF >> via simple IDE-CF reductor > > I use that CF card with old 486 Soyo-SiS mobo (and the "simple > reductor"). > >> (intel VX/HX - NO). As i understand, problem is - no support >> ATA100 in older IDE-controllers. In other case, you need use >> PCI-IDE cards or special modern ISA-IDE controllers (designed >> specially for use with CF). > > I use that CF card with old VLB IDE controller. Seems to be working > just fine, the only problem is 2 GB limit; it can't "see" any larger > partition. > Anyway it's not related to CF card, but to controller rather > CF cards are generally backwards compatible with the old PIO modes (DMA-less transfers, polling for every single byte). Thus, in theory, they should work against any old IDE controller. A CF card that supports UDMA100 should run just fine in a system that can only do PIO, or run limited to UDMA33 for instance. As for size limits, I agree that some BIOSes did actually have such a limit in the past. It doesn't seem to be an inherent limit of IDE/ATA or LBA28 (those have other limits of their own). Other than that, 2 GB is a limit of FAT16, per volume = not necessarily a BIOS issue. Though I cannot rule out that a particular BIOS would in fact inspect the partition table and would not approve of partitions larger than some arbitrary size :-) Over the years, I've seen various "innovative BIOS heuristics" in the boot sequence. http://www.dewassoc.com/kbase/hard_drives/hard_drive_size_barriers.htm https://tldp.org/HOWTO/Large-Disk-HOWTO-4.html https://en.wikipedia.org/wiki/Comparison_of_file_systems And another matter is that, especially in the old days, the ATA flash target controllers (and their firmware) were not as universally compatible with various IDE hosts as were the magnetic disk drives. Over the years, Intel has crystallized as the dominant brand in terms of ATA HBA ports sold, and thus, every ATA Flash maker tested against Intel first and foremost, but hardly against any other vendor's HBA's... thus, it is not uncommon to find flash drives that work with Intel IDE HBA's but have a problem against particular lesser brands of chipsets. I have sympathy for your hardware archaeology :-) Frank ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] IDE <-> CF adapters
Hello everybody, my past experience with embedded PC computers includes a decade when CompactFlash was the bread and butter bootdisk flash format for the computers that we used to sell at the time. As for IDE/CF conversion adapters, I recall a time when the CF cards did not support DMA operation, and consequently many earlier IDE/CF adapters did not support DMA either. Which was fun when the first CF cards arrived that *did* in fact support DMA. You'd get them "detected" by the BIOS (INQUIRY worked), but then reading the MBR failed :-) So I suggest that you get some converter that does support DMA = does have the two signals required routed on the PCB. As a particular CF/IDE adaptor model still available today, I'd like to mention the Delock model 91624 . https://www.delock.com/produkt/91624/merkmale.html I cannot see DMA mentioned in its description, but I'm pretty sure it's the surviving later generation of the board that does support DMA. Pay attention to the cable that you're using. For UDMA above 33MBps, you need the dense 80wire cable. The aforementioned DeLock adaptor does have that missing pin in the 40pin header that allows you to plug in that modern IDE cable. If you use a sparse 40wire cable (or 44wire for that matter) you'd better keep it as short as possible, otherwise you get IDE transaction errors. If you stumble upon Geode-based PC hardware, be aware that especially its older generations used to have a problem with specific "ATA target controller" chip models that were popular in certain old CF card models. The symptoms span from mild rot (OS fails to boot after a successful installation) to heavy brain damage (ATA transaction failures during OS installation). I recall seeing a wave of such cards when the popular size was 16 - 64 MB, the controller chip brand was SSS (which you could only find out by cracking the card's mechanical shell open). And I seem to have recently stumbled upon an older piece of a 1GB CF card being flakey in an old Geode-based machine. As for CF card brands... SanDisk is not a bad choice, overall their flash products are top notch within the general/consumer market. For industrial-grade CF cards, I can warmly recommend Innodisk, though at the same time I should declare my vested interest (I work as a support techie with a small national distributor of this brand). https://www.innodisk.com/en/products/flash-storage/cf-card For instance their iCF4000 family are all SLC-based and the current models work fine with Geode motherboards of all vintages. The SLC silicon technology can sustain maybe 50k total rewrites. Innodisk also have something called "iSLC", which apparently means using just the most-significant bit per cell, thus using the MLC memory in SLC-like mode. This yields about 20-30k rewrites for a lower cost. But even the SLC-based iCF4000 at 1 GB can cost maybe 30-40 EURO, depending on some further "flavours" of the card (temperature range for instance) and depending on where you can buy (and you also need to consider carriage!). Be aware that swapping is generally not a very nice load on flash cards, as the write transaction may be smaller than a flash row size (page size), i.e. the written volume gets "multiplied". A nice intro into flash space allocation / wear leveling algorithms in cards with block layer abstraction: https://lwn.net/Articles/428584/ The IDE LBA sector size is 512 B. The x86 VM page size is 4 kB (unless huge pages are configured). The flash row size (page size) can be a couple dozen kB. The erase block size is megabytes, rather than hundreds of kB. Inside an ATA/SATA Flash drive or USB mass storage drive, there are two floors of space allocation (mapping) from the "virtual" LBA layer 1) to "minimum writeable size" rows (pages) and 2) to the erase blocks. And quite some janitoring is going on in shuffling these allocation units around. Innodisk have some software tools (Windows only, AFAICT) to tell you the average and maximum number of overwrites (internally kept track of per erase block, apparently). These two figures are apparently somehow encoded in a proprietary SMART variable - details available from Innodisk techsupport by email. Sorry to hear that 32bit Linux is no longer as straightforward as I used to appreciate it for the last two decades or so. It is true that I myself do not have any need for 32bit kernels anymore, as pretty much all embedded x86 PC's that we have sold over the last 5+ years (maybe more like a decade) already have 64bit cores :-) so even my PXEbooting test environment now has 64bit kernels and I don't remember the last time I got an error message trying to boot that on a 32bit CPU. I could try compiling a modern 32bit kernel with a minimal instruction set just for sport, but I don't really have the time... I hope this helps :-) Frank ___ Freedos-user mailing list
Re: [Freedos-user] New to DOS - 486
On 13 Sep 2020 at 16:26, Dan Scott wrote: > > I´ve seen video and I did play a fair number of DOS compatible > games in my earlier years especially on Windows 95 and 98. I´m > casually looking for an old 486 to tinker with too, so hopefully > I´ll stumble upon something someone is looking to get rid of or a > cheap one at Goodwill. > Back in the day, cheap 486 clone machines had weird quirks in silicon and in the BIOS, and were rather starved of RAM. Any hardware that old has to be suspected of having age-related glitches. Cold joints, dusty and oxidated contacts etc. You'll have a problem finding floppy drives and IDE HDDs. If you want 486-class hardware with enough RAM, un-486ish CPU horsepower and pretty good legacy compatibility, try looking for something with a Vortex86DX. Mind the DX, it's a particular Vortex SoC model. Anything from ICOP will do (with XGI graphics, 32MB of dedicated VRAM). Only there's no legacy audio (selected models have USB audio = no use in DOS on bare metal). If you manage to get your hands on a soundblaster card (some ISA model strongly preferred), if could work with the VDX-6324 from ICOP - but you will need a minimal PICMG 1.0 ISA backplane. The Vortex has about 800 MHz native clock rate, but can be underclocked down to 100 MHz. And, the "TurboPascal crt bug" (division by 0 exception, or error 200) doesn't occur until about 400 MHz. The Vortex86DX hardware natively still has IDE, not SATA. It is possible to buy a stand-alone IDE/SATA bridge board, allowing you to attach a SATA disk drive to an IDE HBA. And, some of the Vortex boards have a CompatFlash slot, or you can buy a CF/IDE converter board stand-alone. CF cards can still be purchased, and they have a native IDE mode, making them behave like an IDE HDD. Or you can just run your legacy DOS software in a DosBox - including VGA screen scaling and SoundBlaster emulation. Or in some hypervisor of your choice. Your only problem in that case is too much CPU horsepower, resulting in the "error 200" in some software (not necessarily Borland-based). Frank ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] [solved] Re: Debian 9 64b / QEMU 2.8.1 / FreeDOS 1.3rc2 as a guest: DHCP requests end up zero-padded
Dear everybody,
I'm itching to top-post, but as this is a no-no, scroll all the way
down if you're interested to see my outcome ;-)
On 27 Dec 2019 at 18:33, qemu-disc...@nongnu.org, free wrote:
> Dear everybody,
>
> this is a superficial early question,
> just in case this is a known problem,
> or to get your feedback ("upgrade the distro
> and stick to the distro kernel", etc).
>
> I'm playing with Debian 9 64bit (so far I haven't been motivated to
> upgrade) which happens to contain the following QEMU:
>
> QEMU emulator version 2.8.1(Debian 1:2.8+dfsg-6+deb9u8)
> Copyright (c) 2003-2016 Fabrice Bellard and the QEMU Project
> developers
>
> Actually I'm using kernel 5.2.7 on the box (boxes) = "somewhat"
> younger, compared to the original 4.9.0 from the Debian repo... ;-)
>
> As a QEMU guest, I'm trying to boot a DOS-based "Client for microsoft
> networks", actually the venerable Net Boot Disk 6.5 "distro" based on
> FreeDOS and some custom candy.
> https://www.netbootdisk.com/
> I've unpacked the NBD 6.5 onto an 8MB HDD image and deactivated
> the original on-the-fly unpacking into a RAMdisk = so it effectively
> boots off a harddisk partition. I've been using it this way for ages,
> PXE-booted using PXElinux into a MEMDISK holding the whole HDD
> image... I've just been updating the NIC drivers.
> Now I'm trying to move this into a QEMU guest, where the disk image
> is provided to the guest as an emulated IDE disk drive.
> And it basically works - the FreeDOS boots and I can
> do things inside the OS and the FS on the emulated disk.
>
> While trying to work around some other problem (some software,
> including pciscan.exe by Bart Lagerweij, and the low-level NIC
> drivers, were exciting an error in the older FreeDOS 1.0-ish kernel)
> I upgraded the guest side to the latest FreeDOS 1.3-rc2.
> Unfortunately the BAT scripts involved apparently rely on FreeDOS
> syntax, so I cannot easily port the whole thing onto MSDOS 6.22 just
> to give it a try...
> So I'm at FreeDOS 1.3-rc2, PCISCAN works and the network drivers
> appear to load - they report a MAC address etc. I've tried about two
> older Intel NIC chips and a Realtek RTL8139 (all of them as emulated
> by QEMU).
>
> Now finally for the problem:
>
> The network "client" software consists of several resident layers
> that get loaded step by step. And the progress gets stuck
> when the TCP/IP stack tries to ask for DHCP = when the
> machine just booted tries to actually use the NIC for the first time
> to generate traffic on the network. See a screenshot attached.
> I believe the misbehaving piece of software is called TCPTSR.EXE .
>
> I'm using QEMU's "-net nic -net bridge" to hook the guest into the
> host's LAN. I actually have a soft-bridge instance prepared in the
> host OS, before I start QEMU, and Windows PE 7/10 guests work just
> fine on top of that arrangement: QEMU instantiates a tap0 and adds
> that to the host's soft-bridge, and the Windows guest starts like a
> cheetah.
>
> So in that context, in the Debian-based host OS, I've tried sniffing
> the traffic coming out of tap0 with tcpdump. And, I'm seeing
> something interesting.
> In perfect correlation with the DOS guest's DHCP client starting up,
> I can see a "packet of all zeroes" every now and then. As if, for
> some reason, the DHCP Discovery packets got zero-padded.
> A short snippet is attached (packet header, as reported by tcpdump).
>
> I've tried with or without KVM acceleration in QEMU.
> I've tried several variants of the emulated NIC hardware.
> I've tried JEMMEX (5.78=latest) with NOVDS and I've tried HimemX.EXE.
> I've tried booting with Debian's stock SeaBIOS or with a more modern
> OVMF UEFI+CSM (got pre-compiled binaries somewhere upstream).
> None of this makes a difference, the resulting symptoms are exactly
> the same.
>
> The next step would be to upgrade the distro and compile a fresh QEMU
> from source. Which would take a bit of effort...
> So in that context, I'd be grateful for any opinions if this is worth
> the bother, if someone has seen this before etc.
>
> Thanks for your attention :-)
>
> Frank Rysanek
>
> P.S.: the "Debian host" itself is actually PXE-booted in UEFI mode,
> with / mounted RW on top of overlayfs on top of a read-only NFS
> volume, and the soft-bridge gets inserted early during initrd boot
> (before ipconfig asks for DHCP). It's nifty, it all works like a
> charm, and it wasn't all that much work. I love Debian. A howto will
> follow soon.
>
>
> Attachments:
> N:\Install - only LEGAL !!!\FreeDos\FreeDOS_QEMU_DHCP_hangs.jpg
> N:\Install - only LEGAL !!!\FreeDos\zero_padded_pkt_dump.txt
...so after more than a quarter, I got back to my "DOS in QEMU in a
diskless-booted Linux" side project. And, I have some success to
report.
I've bitten the bullet and massaged QEMU 4.1.1 into my diskless
booting environment.
With the QEMU Xwindows GUI front-ends being what they are, with all
their
Re: [Freedos-user] Debian 9 64b / QEMU 2.8.1 / FreeDOS 1.3rc2 as a guest: DHCP requests end up zero-padded
On 1 Jan 2020 at 17:19, Tom Ehlert wrote: > > in short: when debugging network problems, avoid EMM386/JEMMEX. > > HIMEM and friends should be fine, though. > Okay, I'll try to figure out my way through this... I definitely do need something to load all the resident drivers "high" wherever possible, otherwise I'm out of conventional memory. AFAICT the XMS managers are okay for this (e.g. himem.sys). Next, I strongly prefer to stick to FreeDOS because some important scripts use features not supported by the MS-DOS command.com. So first I'll try MS himem.sys under FreeDOS. HimemX.sys did not seem to make a difference compared to JEMMEX... Makes me wonder if JEMMEX with NOEMS would have a chance of working = if NOEMS changes something relevant about the JEMM's "back end behavior", or just disables the EMS interface (front end). Maybe if I cannot get this to work in FreeDOS, I could try a very bare-bones setup in MS-DOS, with hard-coded drivers and their configs, just to see if I have a chance in MS-DOS (= if it makes sense to try to massage all the scripts into MS-DOS syntax / limitations). Thanks for your insight :-) I seem to recall trying to program something in DOS that needed more RAM, and I had a choice of XMS vs. EMS. I picked XMS, because it allowed me to allocate a large window of memory that I could just work with directly. Whereas EMS would swap 64k "pages" in and out of a single 64k window in the "conventional address space"... I really don't know how DOS drivers for PCI devices using MMIO would work without a memory manager / DOS extender (DPMI seems to spring to my mind as the way to have "physical to virtual" mappings established). I seem to recall that the 16bit PCI BIOS calls can arrange a number of things, but the memory mapping is not in its capabilities? Frank ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Debian 9 64b / QEMU 2.8.1 / FreeDOS 1.3rc2 as a guest: DHCP requests end up zero-padded
On 31 Dec 2019 at 13:30, Eric Auer wrote: > > Hi! As the links got line-wrapped, here are the contents: > > > http://support.fccps.cz/download/adv/frr/FreeDos/zero_padded_pkt_dump.txt > > contains the following text: > > > # tcpdump -n -i tap0 > > 16:47:39.592071 00:00:00:00:00:00 > 00:00:00:00:00:00 Null Information, > > send seq 0, rcv seq 0, Flags [Command], length 2586 > > 0x: > [etc.] > > ...etc. The last row starts at 0x0a10 and contains 10 bytes. > The e-mail client in Windows that I'm using for mailing lists (Pegasus Mail) uses a fixed maximum line length. Which used to be a rule in the old days... That's why long URL's in message body get line-wrapped and that's why I prefer to attach text with longer lines as a separate file, where the formatting is not subject to the MUA's intelligent interventions... > > http://support.fccps.cz/download/adv/frr/FreeDos/FreeDOS_QEMU_DHCP_hangs.jpg > > is a photograph (why not a screenshot?) of this text in QEMU: > It was just easier to take a photo. To take a screenshot, I'd probably have to install further software into the funny diskless client environment. > Defaulting to NIC found in slot 0x0002. > PCI\VEN_8086_1209_11001AF4_0F > > Permanent Node Address: 525400123456 > Current Node Address: 525400123456 > Configured Speed/Duplex: Auto > TransmitBuffers: 4 > ReceiveBuffers: 8 > > Microsoft DOS TCP/IP Protocol Driver 1.0a > Copyright (c) Microsoft Corporation, 1991. All rights reserved. > Copyright (c) Hewlett-Packard Corporation, 1985-1991. All rights reserved. > Copyright (c) 3Com Corporation, 1985-1991. All rights reserved. > Microsoft DOS TCP/IP NEMM Driver 1.0 > MAC/DIS to Packet Driver converter loaded. Version 1.19 > Copyrifgt 1991 FTP Software, Inc. All rights reserved. > Portions Copyright(c) 2000-2004 Symantec Corporation > > The command completed successfully. > - Starting netbind > MS-DOS LAN Manager v2.1 Netbind > - Starting umb > - Starting tcp/ip > Initializing TCP/IP via DHCP > Ohh amazing, it must've taken you quite some effort to type it all. I didn't bother, as it's just a log of a few drivers starting up... > (and that is where QEMU stops - maybe waiting for DHCP responses?) > Yes, that's where the TCP/IP stack (TCPTSR.EXE?) should report "okay, got an IP address" and then some messages about Samba logon. Again Windows or Linux just start up and start working with the emulated NIC, their DHCP queries succeed etc. Just in FreeDOS with JEMMEX or HimemX, I get the DHCP queries zero-padded on the outside - while the drivers seem to be otherwise happy with the emulated network hardware they should cater for. I have a faint awareness of PCI IOMEM mapping to the CPU address space on bare metal, I know how to ask for it in Linux driver source code and I seem to recall seeing that in DPMI as well, but I know next to nothing about how this could interact with a hypervisor (QEMU+KVM) and in what ways the DOS+DPMI environment (or DPMI-less, maybe) can differ from a full-fledged modern OS at the guest side... Maybe Japheth would have a clue, but the last update of his memory manager is several years old... And the version of QEMU that I'm using is not very new, either - if that should matter. Frank ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] Debian 9 64b / QEMU 2.8.1 / FreeDOS 1.3rc2 as a guest: DHCP requests end up zero-padded
...thanks to E.Auer for the hint that my attachments are too large to
be included in the message. See them at the following links:
http://support.fccps.cz/download/adv/frr/FreeDos/zero_padded_pkt_dump.
txt
http://support.fccps.cz/download/adv/frr/FreeDos/FreeDOS_QEMU_DHCP_han
gs.jpg
Dear everybody,
this is a superficial early question,
just in case this is a known problem,
or to get your feedback ("upgrade the distro
and stick to the distro kernel", etc).
I'm playing with Debian 9 64bit (so far I haven't been motivated to
upgrade) which happens to contain the following QEMU:
QEMU emulator version 2.8.1(Debian 1:2.8+dfsg-6+deb9u8)
Copyright (c) 2003-2016 Fabrice Bellard and the QEMU Project
developers
Actually I'm using kernel 5.2.7 on the box (boxes) = "somewhat"
younger, compared to the original 4.9.0 from the Debian repo... ;-)
As a QEMU guest, I'm trying to boot a DOS-based "Client for microsoft
networks", actually the venerable Net Boot Disk 6.5 "distro" based on
FreeDOS and some custom candy.
https://www.netbootdisk.com/
I've unpacked the NBD 6.5 onto an 8MB HDD image and deactivated
the original on-the-fly unpacking into a RAMdisk = so it effectively
boots off a harddisk partition. I've been using it this way for ages,
PXE-booted using PXElinux into a MEMDISK holding the whole HDD
image... I've just been updating the NIC drivers.
Now I'm trying to move this into a QEMU guest, where the disk image
is provided to the guest as an emulated IDE disk drive.
And it basically works - the FreeDOS boots and I can
do things inside the OS and the FS on the emulated disk.
While trying to work around some other problem (some software,
including pciscan.exe by Bart Lagerweij, and the low-level NIC
drivers, were exciting an error in the older FreeDOS 1.0-ish kernel)
I upgraded the guest side to the latest FreeDOS 1.3-rc2.
Unfortunately the BAT scripts involved apparently rely on FreeDOS
syntax, so I cannot easily port the whole thing onto MSDOS 6.22 just
to give it a try...
So I'm at FreeDOS 1.3-rc2, PCISCAN works and the network drivers
appear to load - they report a MAC address etc. I've tried about two
older Intel NIC chips and a Realtek RTL8139 (all of them as emulated
by QEMU).
Now finally for the problem:
The network "client" software consists of several resident layers
that get loaded step by step. And the progress gets stuck
when the TCP/IP stack tries to ask for DHCP = when the
machine just booted tries to actually use the NIC for the first time
to generate traffic on the network. See a screenshot attached.
I believe the misbehaving piece of software is called TCPTSR.EXE .
I'm using QEMU's "-net nic -net bridge" to hook the guest into the
host's LAN. I actually have a soft-bridge instance prepared in the
host OS, before I start QEMU, and Windows PE 7/10 guests work just
fine on top of that arrangement: QEMU instantiates a tap0 and adds
that to the host's soft-bridge, and the Windows guest starts like a
cheetah.
So in that context, in the Debian-based host OS, I've tried sniffing
the traffic coming out of tap0 with tcpdump. And, I'm seeing
something interesting.
In perfect correlation with the DOS guest's DHCP client starting up,
I can see a "packet of all zeroes" every now and then. As if, for
some reason, the DHCP Discovery packets got zero-padded.
A short snippet is attached (packet header, as reported by tcpdump).
I've tried with or without KVM acceleration in QEMU.
I've tried several variants of the emulated NIC hardware.
I've tried JEMMEX (5.78=latest) with NOVDS and I've tried HimemX.EXE.
I've tried booting with Debian's stock SeaBIOS or with a more modern
OVMF UEFI+CSM (got pre-compiled binaries somewhere upstream).
None of this makes a difference, the resulting symptoms are exactly
the same.
The next step would be to upgrade the distro and compile a fresh QEMU
from source. Which would take a bit of effort...
So in that context, I'd be grateful for any opinions if this is worth
the bother, if someone has seen this before etc.
Thanks for your attention :-)
Frank Rysanek
P.S.: the "Debian host" itself is actually PXE-booted in UEFI mode,
with / mounted RW on top of overlayfs on top of a read-only NFS
volume, and the soft-bridge gets inserted early during initrd boot
(before ipconfig asks for DHCP). It's nifty, it all works like a
charm, and it wasn't all that much work. I love Debian. A howto will
follow soon.
WPM$SNCH.PM$
Description: Mail message body
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] MODE not changing RTS or DTR of serial ports
On 28 Dec 2019 at 18:11, tom ehlert wrote: > >When I couldn't get a reading on my scope I decided a more direct approach > >by piping direct from > the console: > >ECHO TEST>COM1 > > good idea. unfortunately this only works with proper DTR/CTS/RTS/... status > lines > connected. > > > Tom Matt if you're conversant with an oscilloscope, I suspect it shouldn't be a problem for you to pull the CTS, DCD and DSR into a happy signal level, right? See their respective polarities: http://www.larvierinehart.com/serial/serialadc/serial.htm#8 I believe this should be read as: All the CTS, DCD and DSR are "active low" at the TTL level. But, as the RS232 line transceiver chips (level shifters) are inverting, at the RS232 levels the signals are actually active high...? I.e., pulling all three of them to +5V against GND should do the job. I.e., pull the three of them high, and send some data down COM1, and you should get something out the TX line. Frank Rysanek ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] MODE not changing RTS or DTR of serial ports
Dear Matt, first and foremost, thumbs up for approaching the problem with an oscilloscope. This is the right tool for the job. Mr. Bret Johnson (himself a programming wizard/veteran) has already provided a super-gentle debugging intro... If I remember correctly, the DOS and BIOS services that work with COM ports (serial UART's) are rather starved of sorely needed features, and so is possibly the stock "driver" towards the hardware. Not sure if flow control and other things can be configured in bare DOS. From my modest programming attempts towards serial UART's in DOS, I recall that the safest way has always been: talk to the UART directly, if you know what you're doing... Back in the day, I was a fond user of JCOM the terminal emulator: http://ftp.lanet.lv/ftp/mirror/x2ftp/msdos/programming/serial/jcom174d .zip JCOM has its own routines for talking to the UART hardware and can do "hardware flow control" via RTS+CTS - and can be configured to work with no flow control, which is probably what you want for a basic "signs of life" check. The trick in DEBUG.EXE that Mr. Johnson has mentioned, relies on the BIOS presenting the venerable "equipment table" at a well-known address in the system RAM - not sure how reliable that is, nowadays. In modern PC's, e.g. Linux probably gets to know about COM ports from ACPI tables (or earlier via PnP BIOS calls). Not something you would easily reach via DEBUG.EXE :-) BTW if you can boot some Linux live distro and type "dmesg | less" at the command line, you should find some messages about UART's being detected. That said, modern BIOSes typically have a pretty good information in the human-facing SETUP menu, about where the COM ports are located. (Conveniently, the fact that you can boot DOS means to me that you're not facing pure UEFI :-) In DEBUG.EXE, I wouldn't be ashamed to try some o 3f8 00 i 3f8 ...but other registers might come in handy too. Note that the basic 16C550A UART (or compatible) does not directly respect the CTS signal in hardware - rather, the "hardware flow control" is actually handled by a software routine watching the CTS input flag in the Modem Status Register. I mean to say that a direct outb(0x3f8, anything) should result in some activity on the UART's TX pin - unless this is some higher UART model (I've met 16C950) that can follow the CTS input in actual UART hardware, and has been so configured (this functionality is turned off upon HW reset / power-up). As for the "i(nput)" direction, empty space on the ISA reads 0xFF. If my memory serves, the input data register on an empty FIFO reads the last character previously received... If you're not afraid, here is a human re-phrase of the 16C550 datasheet: https://en.wikibooks.org/wiki/Serial_Programming/8250_UART_Programming #UART_Registers In hardware currently sold on the market, you are likely to get some UART's (COM ports) implemented in an onboard SuperIO chip, attached to the south bridge via LPC. LPC is a recent-ish narrowed-down flavour of the old ISA, and the LPC SuperIO UART's are typically available at the legacy IO ports and IRQ's. As far as you're concerned, they still *are* the good old ISA UART's - accompanied by due entries in the various BIOS interfaces that can be used to ask about the hardware available. The SuperIO chips unconditionally must be initialized by the BIOS on startup - hence it's fairly automatic, that the BIOS knows all the details about the setup of the UART's. It really tends to be pretty seamless in modern PC hardware, including detection by the OS (Windows or Linux). BTW there's a special tool for Linux called "superiotool" that can look for SuperIO chips directly, in the hardware - trying to talk to their configuration register banks at well-known base addresses such as 0x2E and 0x4E. If there are any add-on serial ports (UARTs) in the PC, it is *very* unlikely that they would collide with your onboard UART's. At least in any newly purchased HW setup, addon UART's would reside on the PCI, PCI-e or USB, thus having no chance of colliding with onboard UART's (including those appearing as legacy ISA devices). And, PCI/PCI-e and especially USB UART's would be harder for you to reach from DOS :-) In the last 5 years or so, pure ISA addon hardware tends to be vanishing from the industrial PC market - including the last obscure incarnations such as the original ISA-flavoured PC104 form factor. In theory, LPC-based addon UART's are possible, but in practice I've never seen such a board as a commercial product. I know a guy who has DIY'ed an LPC addon board with an extra SuperIO chip, but he had to route the board himself and write a piece of software to initialize the UART's :-) It's very unlikely that the peripherals in the addon SuperIO chip (not known to the BIOS) would collide with the onboard SuperIO stuff - the addon-on chip, pristine "after reset", should have all the peripheral devices disabled in
