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
...
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
this, and is the only program I'm aware of that does.
USB driver by Bret would also work there, I think. However MS DOS
has not had any updates for ca 15 years, many parts are outdated.
That may be true, but there are some parts of MS-DOS that still have not been
replicated by FreeDOS or any other alternative
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
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
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
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
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
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,
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
201 - 242 of 242 matches
Mail list logo
