There has been some discussion lately on the FreeDOS mailing list about the
comparison between the DOS USB drivers made by me (Bret Johnson,
http://bretjohnson.us), and those made by Georg Potthast
(http://georgpotthast.de/usb). The discussion has been around three major
points, and I would
Pat is correct.
A device driver is no different than any other executable, it just normally
gets loaded via CONFIG.SYS instead of AUTOEXEC.BAT or at the command line. If
a GPL OS only allowed GPL applications to run on it, it would be useless. In
the DOS world, almost no programs are GPL,
Hi JVP, thanks for testing the Bret Johnson USB drivers :-)
{snip}
cd\usb
usbuhci IRQ 11 DisableLegacySupport
I assume the IRQ can also be set automatically?
Yes, the IRQ is normally set automatically, either by the BIOS or by
USBUHCI{L}. The reason JVP needed to change it was because
I pretty much agree. I actually don't really need or even want access to even
the full 4GB that a 32-bit CPU allows, but would like what's there to work
correctly no matter how much memory there actually is. My newest computer came
with 6GB (64-bit Vista), which I multi-boot to DOS. I had to
though the distribution requirements are not
GPL-compatible. I will be continuing to work on those, and could use help with
them if anybody is interested (documentation, testing, additional device
drivers, etc.).
--
Bret Johnson
The only things you get to keep forever are the ones you give away
LFNs on FAT was a very clever hack! It's now generally forgotten that
it was Windows NT 3.5 that introduced the system, long before Windows
95.
I personally don't think LFN on FAT was clever at all. It broke many
programs that worked just fine before that, including Microsoft's own SCANDISK
I normally don't use FDAPM or POWER, but did a little bit of testing after
reading this. If you load FDAPM first and then load my USB drivers, there is
indeed a problem and the keyboard doesn't work properly. If you load the USB
drivers first and then load FDAPM afterwards, everything seems
Hi Bret,
I checked the system's state with INSTALL=DEBUG.COM on a boot disk
(Rugxulo's bare DOS disk, with a 2008-03-08 kernel, build 2038) and
it appears fine to me. Memory that belongs to the
configuration/initialization program is allocated to a PSP at
segment 60h (!) which is properly
I was using kernel 2036. Just tried 2038 -- no effective difference. The JEMM
error is different now (Error 06 at a seemingly random CS:EIP, near the top of
conventional memory but where there is no associated PSP).
--
Bret
Marcos has already responded to some of this, but I will as well.
Bret's USB keyboard driver worked perfectly for my two notebooks
(Compaq and IBM, both year 1999) and one desktop (Pentium 166).
It is unusual that the BIOS did not already do the keyboard for you.
I'm not surprised at all by
Maybe on some machines USB has IRQ uses which are not reliably
enabled during HLT? Maybe even NMI/SMI?
Hard to say exactly what the problem might be, though I don't suspect it has
anything to do with HLT, NMI, or SMI. It is interesting (and encouraging, at
least to me), though, that it only
... usb keyboard; slow and not properly responsive.
It is this way both with the BIOS and with my programs? Note that I can't
guarantee that USBKEYB will work with Windows -- it will probably work on some
computers and not on others, depending on the BIOS. USBMOUSE definitely won't
work
FWIW, I still have and occasionally use a 9-pin dot-matrix printer. It's a
Panasonic, and to print graphics (like from a DOS CAD program I used to use all
the time) I have to tell the program I have an IBM Graphics Printer, not any
kind of Epson. You should also at least consider the
Google up TSRCOM35 and download it. It's a package that's been around for a
LONG time, and has two programs called MARK and RELEASE that are specifically
designed to remove a TSR from memory. They don't work with all TSR's, but they
do work with many. Also included in the package are MARKNET
SCRDUMP - a utility to dump parts of the screen to a file
With a hotkey as TSR, I assume?
Nope. Again this utility is most useful within batch files (e.g.
autoexec.bat). Typically it is called twice, once before and a second
time right after the command whichs output is to be copied to a
You can look at my PRTSCR utility which works with the PrintScreen
key, available on my web site:
http://bretjohnson.us
Oops!
There is indeed a PRTSCR utility there, but it is an older, simpler version
that doesn't have all of the features I mentioned. The version with all of the
new
But isn't it the advantage of a free operating system that there are
several alternative approaches available (often more or less
different) and the user has the freedom to pick the one that fits
best his special requirements? But before someone can make a choice
one has to know that there is
Points for creativity, but you have to admit that actual support
for command-line (or environment variable, script) driven operation
of PRTSCR would be simpler, and would suffice in at least most cases.
I'm not exactly sure what you mean here. I think you can usually do what
you're talking
I meant that support for controlling PRTSCR in this way could be a part of
the PRTSCR
program, without requiring the detour via SCANCODE.
I can see where that might be desirable is some circumstances, though I
purposely decided to go with a more modular design. Having separate programs
is
I think it could bounce off attempts to use it recursively but
I do agree that it should not do I/O, so it can only be used in
combination with something else which does the I/O and/or buffers.
Not true. It does not ONLY need to be used in combination with something that
does the I/O. In my
We (well, at least I) have a severe dilemma going on here.
int 15.4f is supposed to be called from the BIOS from the INT 09
handler, and NOBODY else.
I've done some more research regarding this, and it is never stated anywhere
that this function can ONLY be called from the INT 09 handler.
I disagree here. You would only need reentrant handling if it could
happen that int 15.4f is called while int 15.4f already is busy.
This is unlikely for two reasons ...
Agreed: Unlikely, but absolutely not impossible. Drivers should be designed to
handle even unlikely events without
use the 8042 keyboard controller command 0xd2 to simulate scancode
received. that's documented (again in the IBM technical reference)
this will simulate a scancode all the way through interrupt handler,
int15.4f, ...
That is exactly what I call Method 1 does. The problem is, function D2h
Returning ignore this scancode or returning the scancode
untranslated would not crash anything, at most drop a key.
That's true, as long as the INT 15.4F code could do that re-entrantly (i.e.,
not crash when it received the re-entrant request). INT 15.4F handlers are
usually pretty simple,
I believe you that you tried almost everything; I still think that
0x shouldn't hurt, and CLI is even a bug
Tried both of those -- didn't help. Came to a reasonable value of 200, which
was far more long enough to work on any computer I had for testing, but did not
take too long (and slow
Appart from turning DISPLAY into a DOS device driver and override
kernel's CON, but not only IOCTL, but also write.
FWIW, you don't actually need to turn DISPLAY into a device driver in order to
replace/enhance CON. You can do that with a TSR also. See my USBPRINT if you
want an example of
Ok, sorry, that's what I meant. That you find the chain at the List
of Lists, right?
Yes. The first Device Driver header (NUL) is in the LoL. From there, you can
follow the chain (a linked list of pointers) as far as you want, and can
insert/remove new headers wherever you want.
Most programs could already be loaded earlier in CONFIG.SYS if they
were adjusted in that way, though some of the DOS structures aren't
available yet in that case.
That's one of the big advantages of TSR's, in my opinion. While CONFIG.SYS is
being processed, DOS is not yet all there. As a
They works when I DEVLOAD them post boot-up, but the USB flash drive
steals the DVD-RW drive's letter (E:\ in my case). USBUHCI, and
USBDRIVE don't work at all for me. It not only wont load my USB
drives, it doesn't even find them. Strangely enough if I load them
before USBASPI/NJ32DISK, my
Yes, do! I'd be curious to see it.
I realize this is many weeks late, but I finally have the new version of PRTSCR
ready to go. The documentation was in far worse shape than I remembered, so
that's what took most of my time. It's available from my web site:
http://bretjohnson.us
With some limited exceptions (like 4DOS), the expansion of batch
functionality has generally been provided by external utilities, rather than
being integrated into the kernel. E.g., once in awhile I use the old PC
Magazine utility called STRINGS, and I know there are other similar utilities
I'm retired and I fool around with lots of hardware, some of which
is nothing more then a motherboard, a keyboard and a lcd. Virtually
all motherboards come with a USB. Also when I have to deal with a
broken disk Spinrite is great but not if you can't boot it. Some
claim it will run great
The USB drivers make a flash drive look like a removable hard drive, not a
floppy drive (though the drivers will also work with a USB floppy drive). You
can't start with a floppy image.
If the BIOS will correctly boot from an external USB hard drive or flash drive,
you can simply use the
On the topic of wear leveling I would go with the DOM products, as
they are designed as hard drive replacements. It's pretty easy to
burn up FLASH so wear leveling is important.
FWIW, they claim that FLASH has unlimited read capability, but is limited in
the number of writes. So, at least
This is unavoidable. When you intercept system interrupts, you only
can safely uninstall when the nobody else has trapped the same
interrupt or, in other words, you can only uninstall when the
interrupt vector is pointing to the TSR you are trying to uninstall.
This is an opportunity to jump
I'm aware of AMIS. I could implement it in vmsmount. Then you'll only
have to convince the maintainers of shsucdx, doslfn and some more or
less popular proprietary tsrs like ntfs4dos... :)
Please, don't get me wrong. I think AMIS is a great idea, maybe just
a bit too late, and I'm open to
FWIW:
In my USB disk driver (USBDRIVE), here's what I've done.
USBDRIVE does not try to virtualize the sector sizes as others are suggesting
here as a possibility -- I figure doing that has the potential to cause as many
problems as the alternative (using defective utilities/programs that are
USBDRIVE does not try to virtualize the sector sizes as others are
suggesting here as a possibility -- I figure doing that has the
potential to cause as many problems as the alternative...
Maybe you could make that configurable, so people can experiment
with virtual 512 byte sectors at their
maybe virtual 512 byte sectors are actually not that evil:
Imagine a NORMAL 4096 byte sector based FAT32 filesystem.
...
Actually they are, or at least potentially are, at least from a compatibility
perspective. In the case of USB, the SCSI protocol is normally used. The
sector size is not
yes you would see a problematic mismatch if you were to talk raw
SCSI or CHS to a disk while being inconsistent about whether you use
512 byte or rather 4096 bytes per sector...
That's precisely the problem. Depending on which DOS programs you use, some
simply call DOS, some may use INT
...
No cache will ever compete with a RAM disk. RAM is always faster
than disks with their seek/rotational latencies and their much
slower transfer rates.
I knew this would provoke a comment from you, Jack.
The purpose of a cache is to put as much data in RAM as it can, so that the
disk
I had a look at Bret's open source USB drivers, unfortunately they
only support Intel/Via (UHCI) controllers yet.
True. Working on that.
I also think they have hard coded 512 bytes per sector.
No. USBDRIVE reads the maximum buffer size from the DOS List of Lists (as
discussed some earlier
That's promising, even to see if your drivers can really make FDISK
work.
Trust me, it works. I've partitioned many USB disks from DOS, though I
normally use Ranish Partition Manager instead of FDISK (it's MUCH easier to
use, and will also format the partitions).
I know MS FDISK will crash
I am saying that for gaining speed on modern disks, in particular
flash disk ands large sector disks, you should already make a big
difference with a small pooling cache and a short delay,
That's true -- but I don't think either LBACACHE or UIDE actually do that. I
could be wrong, but I
My motherboard BIOS update program afud3410.exe (made by MSI) seems
to freeze up when I try to start the BIOS update. The directions for
? using it say never update the BIOS from a floppy drive, then proceed
to give directions for doing exactly that, but using Windows 98 or
Windows XP bootable
INTxx.yy is a shorthand notation people use to indicate an INT xx with
subfunction yy. The yy is usually put into one of the CPU registers before the
call (AH in many cases). In addition, the xx and yy are assumed to be hex.
Example:
INT 21.4C would be coded as:
MOV AH,4Ch
INT 21h
Somewhat amusing that Bret would describe this shorthand in a
much shorter way than I did.
There is no formal definition of this, at least that I've ever seen. It's just
a convenient way of talking about code at a high/conceptual level in forums and
e-mails, without actually needing to
What kind of USB controllers are on the mobo (UHCI/OHCI/EHCI/XHCI)? My drivers
in their current state will only work with UHCI.
--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online
As an extension to what Jeffrey suggested, at one time I used a simple batch
file with some of my utilities, along with CHOICE and ANSI, to set up a menu of
commonly used applications. I don't use it any more, but following is the
latest version I was using. It allows up to 36 options (26
As I was designing USBDRIVE, I considered writing it as a straight ASPI driver
(similar to the architecture of DIDD1000 or ASPIDISK), but decided against it
for a multitude of reasons. The most important reason was the lack of freely
available DOS ASPI support programs (e.g., to format or
Yes, they are. There's a mouse driver called USBMOUSE.
The thing you have to be careful of with USB, though, is that many times it's
all or nothing. That is, you may not be able to have my programs control the
mouse and have the BIOS control the keyboard. Sometimes you can do this, and
No. As Tom said, large sectors are only a workaround for WinXP and
similar MBR partitioned operating systems. With GPT, you have no
relevant limit to the number of sectors any more and sectors can be
small again :-)
Well, CAN and WILL are entirely different scenarios. If I had to guess, I'd
Unless of course DOS refuses to use (old?) drivers which do not
advertise these functions. Someone knows ?
I find that a minimalistic approach almost always leads to problems and
compatibility issues. Even if you think a function/feature/API may not be
needed, it's still better to put it in.
1). I wouldn't use the PIT, sounds unreliable, but then again, I
don't know how anyways. ;-)
Strictly in terms of reliability, it's probably the best choice of all. It
exists and provides consistent timing on all computers, even those with lowly
8088 CPU's. You don't need to worry about
I defer to your greater knowledge, obviously. It's just that messing
with the PIT can conflict with other things, so you have to be
careful (or so I thought).
There are issues with the PIT if you reprogram it, but you don't have to do
that to use it. You can simply access the PIT countdown
actually I would not even OFFER a boot menu item to skip loading the
XMS driver at all: You cannot even boot the install CD / USB on old
pre-XMS PC.
Probably a bad idea for compatibility reasons, unless you offer multiple
choices for which XMS manager to install. E.g., I have a computer
Have you tried explicit I=- and X=- commands with
JEMM386/JEMMEX??
I've tried several different JEMM options -- none of them fixed the problem on
that particular computer. I finally just gave up and went to other
alternatives.
My personal vote would be for bringing a little more order, I mean:
to suppress recognizing such input as option, if slash is directly
after some string of characters - in such case path recognition
should be assumed.
Problem with that is that I've seen programs that _require_ the options to
Yes, they do. But my fundamental question is still valid. What is
your use case? Do you actually *need* to boot DOS, or is a VM or
emulator a better solution?
In my case, I do it mostly for speed, but there are other reasons also.
Booting real DOS only takes a few seconds. So, if I'm
I am trying to use the Joykeys driver included with the FreeDOS 1.0
distribution to send keystrokes to a program.
After the driver is installed in memory, everything works until I
run the program, which does not recognize them.
After I return to the shell, everything works again. I have
While only indirectly related to mtcp and netcat, I accidentally ran across
this site recently:
http://lspppacm.narod.ru
It creates a DOS packet driver using a ppp connection through a USB modem. I
haven't tried it (don't have a USB modem), but I think it's at least
interesting, if not
An easy way to install Freedos safely to a desktop computer
involves the following:
0) Back up all existing systems.
1) Disconnect all existing hard drives.
2) Buy a hard disk to put Freedos on, if you have room for
another one and a place to plug in.
3) Install Freedos to the whole
Actually a GOOD thing in emulation is that you do not need DOS
drivers for all your new hardware, be it for example UMTS or WLAN
internet, HDA or AC97 sound, USB or Bluetooth keyboard and mouse,
touchpad, tablet...
This _can_ be a good thing, depending on the emulator. The emulation of
Your problem is that that you're using a USB printer, rather than a parallel
port printer. MS never added USB support to DOS, even though they actually
continued to make DOS for several years after USB came out (mid-1990's). No
version of DOS today has native support for USB (printers, mice,
Jack:
The FAT file system is defined by DOS, and I want UIDE/UIDE2 to
have NO run-time dependencies on the DOS system.
Nice in theory, but unfortunately doesn't work in practice.
DOS's management of the change line is under the sole auspices of the block
device driver, not hardware/BIOS (INT
I tried using your programs, but for some reason they did not
work. When I loaded the usbprint app, I ran this command
usbprint status and it said on the bottom no printer
installed when I clearly had the printer plugged in. I also
tried it where I loaded it and then plugged in the printer,
Jack:
Are you more interested in actually getting your program to work, or in trying
to prove that you're smarter than everybody else?
Let's take this from the perspective of someone trying to write a BIOS. If I
were trying to do that, I would do my due diligence and obtain as many
i used a batchfile *g*
Of course. That's the only way you can do it (if you don't have another
keyboard of some sort, like a PS2). Glad you figured that out by yourself.
should I delay loading device drivers after USBUHCI?
You could try, but it probably won't help. It's never helped on
in short:
everyhing works now, and there weren't any real problems, one
couldn't solve by following a short how-to. Your drivers are
great! :)
Thanks. Glad you got it working.
And I discovered the USBHUB program, which made me find mouse and
keyboard behind the hubs (keyboard internal
This really seems to be a problem with Freedos Edit and USBDOS.
The other software works fine.
I'll look into that.
hot-plugging (ie switching PCs) does not work at all.
crashes far too often.
the only way is switch, load drivers, use devices, unload drivers,
switch, start from the
I've been having a problem with the edit command. Nothing big or
anything, but every time I open the editor, the word wrap is
turned off. I tried using the save options button, but it just
won't work. It resets itself every time the editor is opened.
If you can't get EDIT to save that as an
but likely that's already being taken care of by caching
software.
???
UIDE and LBACACHE will only work with INT 13h (local) drives, not network
drives. Caching shouldn't be an issue, at least for the clients -- could be a
problem on the server, though.
According to RBIL, DR/Novell/Caldera
Whatever the issue is, it is apparently not that easy to find or fix. Reading
RBIL for INT 21.5C, it seem to indicate that DR-DOS never was able to figure
out how to do it, and it wasn't until Novell got involved that it actually
started working correctly.
(E)DR-DOS could be another
HP does still make printers that will print text in DOS -- you just need to
make sure it supports the PCL protocol, and not one of the Windows-only
protocols (HP calls their Windows-only protocol LIDIL). The inexpensive HP
printers are almost always LIDIL -- you'll usually need to spend some
So if they aren't overly concerned, I guess I shouldn't be either.
FWIW, I use MS-DOS on a daily basis instead of FD for reasons like this.
MS-DOS is, by far, the most stable of the DOS's, and is still the minimum
standard to which others must compare. I would classify possible file
You do always load its SHARE though, right?
No, not by default. According to the official documentation (e.g., the
MS-DOS on-line HELP utility), you only need SHARE in a network or multi-tasking
environment, which doesn't apply to my current situation.
Are you absolutely sure there are no errors when when you are installing the
EMM? What screen messages do you get when it is loading?
I'm guessing what may be happening is that you have enough poorly placed
(virtual) hardware ROM modules that the EMM can't find a contiguous 64k block
of upper
Perhaps just semantics, but I never considered Windows 9x to be Operating
Systems -- I consider them to be Operating Environments just like the
previous versions of Windows call themselves (3.x earlier). Windows 9x isn't
conceptually much different than GEM or GEOS or similar DOS applications
As Dave suggested, if your printer is attached to a parallel port (unlikely
unless it is a very old printer), you should be able to map the physical port
to the VMWare guest OS (never tried it myself, but it should work). You could
also try the file approach that Dave suggested -- that would
You could try this, at least as a place to start:
http://lspppacm.narod.ru/
--
Got visibility?
Most devs has no idea what their production app looks like.
Find out how fast your code is with AppDynamics Lite.
I personally use Ranish Partition Manager most of the time:
http://www.ranish.com/part
It's not been updated in a long time, but it's always worked well for me --
much better than FDISK.
--
Don't let slow site
You can look at the output of my DRIVES program for the D: drive when using
FreeDOS. It will probably indicate that something is wrong in one or more of
DOS's internal tables. DRIVES is not intended to be used in batch files, but
simply displays some information about all of the drive letters
Do the problems also happen with MS-DOS on the client, or plain FreeDOS
(without 4DOS) on the client? Also, does XCOPY work even if COPY doesn't
(don't know if 4DOS even has an XCOPY)?
I'm not necessarily suggesting any of these as a permanent solution (though
they could be), but simply
I an loading usbuhci and usbdrive with LH. They both load low.
All of the USB drivers will load themselves automatically into upper memory if
it is available -- you do not need to (and, in fact, shouldn't) use LH. If,
for some reason, you want them loaded into low memory even if upper memory
I think by this you mean a USB hard drive (or floppy drive?) with magnetic
media, as opposed to a flash/pen/thumb drive with solid-state media? If so,
then yes I have.
What;s the question?
--
Symantec Endpoint
Unfortunately, the /X parameter is the only one you can really play with that
might have any effect. Sorry about that.
I'm working on updates to all of the USB drivers, but don't have a lot of time
to devote to it. Hopefully, the next version will have problems like these
solved. In the
I wish to use an external usb hard drive for backup purposes.
OK, but with my current drivers it will probably be very slow. You may want to
try some other drivers if you care about speed (at least for now).
While the driver loads, and seems? to find the device, I cannot
well understand the
Hi USB users :-)
This is a reply to FDOS basic how-to questions, trying to
give an introduction to Bret's drivers and a summary of
the documents or at least ideas about which bits to read.
Quite a job, Eric. Thanks. Just a few comments and corrections:
You create the bootable stick using
... a user who is able, one way or another, to have usable RAM
mapped above the 640 k so-called limit into the video memory'
segments, up to 736 k (B7FFF), will be forced to use the added
memory as UMBs instead of an extension of *contiguous* so-called
conventional mem.
Is this what you're
I was giving this as one example of why FreeDOS having
relegated the master environment copy to the top of conventional
mem /can/ break things
From my perspective, whether the XBDA, master environment, or anything else is
at the top of memory instead of the bottom shouldn't make any
I see... following a very famous lead, you think that 640 kilo
bytes are more DOS memory than anybody will ever want :=)
No, that's not what I'm saying at all. One thing I am trying to say is that if
you're going to use DOS memory, then you should use the memory allocation
functions
I still haven't figured out any simple way of performing time
polling with sub-55ms precision, so I will probably leave it as is
(that's not a very big deal anyway).
There actually is a way to do this, but you have to combine BIOS data with I/O
data directly from the PIT. A little
Don't forget about FDCONFIG.SYS (if you have that you don't need CONFIG.SYS).
--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP,
Should anyone care (mostly I think it would be the power users), I've taken
most of these suggestions and combined them together to take them to an even
higher level.
On the same machine, I can get into DOS several different ways. I can boot
straight to DOS, and even have several different
FWIW, I've had computers where MS HIMEM.SYS + EMM386.EXE worked and one or more
of the FreeDOS ones (JEMM, HIMEMX) crashed, and vice versa. On the majority of
systems I think they all work OK, but it really depends on the hardware.
If he's running real DOS, he can try my USB drivers (available at
http://bretjohnson.us), but no guarantees. If he's running in some kind of
virtual machine underneath Windows, there are lots of discussions on how to do
it under various scenarios at http://www.columbia.edu/~em36/wpdos/.
It could be that you need to load a driver, but that's unlikely. The most
probable cause is a funky BIOS in the computers, and in particular the
laptops (I've had laptops where the internal keyboard doesn't work quite right).
I would start by testing the keyboard with my SCANTEST program,
Since the computer works with SCANTEST, it means it's not a hardware problem,
so a software driver could potentially fix it.
You haven't said what program this is for, and that could possibly be useful to
know.
You can try the KEYB driver from the FreeDOS site (look in the BASE section),
Quoting from the MS-DOS 6.22 Help program (HELP DISPLAY.SYS at a command
prompt):
The EGA value supports both EGA and VGA display adapters. If you omit the
type parameter, DISPLAY.SYS checks the hardware to determine which display
adapter is in use. You can also specify CGA and MONO as
At least for the programs I write (mostly TSR's), there is additional
functionality provided if the executable is not compressed. Specifically, if
you TYPE the executable program file (e.g., TYPE FileName.com), you will see
some usable information displayed on the screen. For TSR's, this is
1 - 100 of 238 matches
Mail list logo
