Re: [Freedos-user] AUTO SHIFT keyboard on DOS??

[Bret Johnson via Freedos-user]

> It has been a very long time. But, if I recall correctly, I’m fairly sure 
> you
> can programmatically change the LEDs as well. But, I don’t recall the
> details. But, I might have code sitting around somewhere that has that
> functionality. 

The LED status is contained in the BIOS Data Area (BDA), but it is not always 
correctly synced with the actual LEDs, especially in some Virtual Machines.  I 
also have problems with my USB keyboard drivers maintaining this 
synchronization.  Simply setting the LED on (or off) in the BDA doesn't 
guarantee that the correct signal gets sent to the keyboard to control the LED 
(if the keyboard even has LEDs, which modern keyboards often don't, especially 
if they're wireless).

> However excluding CAPS LOCK LED, I don’t think I’ve had a keyboard with 
> the
> other LEDs for a very long time.  No real way for me to test that at present.

FWIW, I'm working on a TSR called LOCKEYS that displays the status of the Lock 
Keys (Shift, Num, and Scroll) and also the INSert status, on the screen.  It's 
basically ready to go, but I still have some tweaks to do.  But I can send a 
"pre-release" copy to anybody who wants a copy right now.

At first I thought what I should do with it is have it mimic the LED status in 
the BDA, but that turned out to be very problematic (especially in VMs).  So I 
have it mimic the Lock key status in the BDA instead (what the BIOS and 
therefore what most DOS programs think the Lock Key status is, not necessarily 
what the LEDs think it is).  I also added the INSert status to the display 
since that is useful to know and not always obvious in all situations.


___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] AUTO SHIFT keyboard on DOS??

[Bret Johnson via Freedos-user]

> is it possible in DOS (using BIOS?) to implement a tsr or so which allows the
> following:
>
> holding a key longer to return a SHIFT-key on screen?
>
> Example: 
>
> press key »a«  and HOLD the key for e.g. 500 milliseconds,  
> => print shift-a = »A« on screen.

You might be able to do something similar with my SCANCODE program, which 
allows you to change one key or key combination into another series of 
keystrokes.  Unfortunately, it doesn't respond to how long you press a key down 
before releasing it.  But I think you could program it to treat some other 
(innocuous) key, like ScrollLock or Right-Control or something, as a "sticky 
shift" key that is released when you press another key after it.  I haven't 
actually tried, but I think SCANCODE is flexible enough to do that.  This 
option requires pressing two keys instead just pressing and holding one, though.

I think your idea of pressing holding down the "a" key to capitalize it instead 
of holding it down and getting two (or more) a's is going to be more 
problematic than helpful.


___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] what cd rom drivers does freedos use?

[Bret Johnson via Freedos-user]

> The comparability issue is not in vied_cdd.sys
> It is in the dectalk drivers itself.
> I have the hardware driver for my cd and DVD rom drives, when
> vide_cdd.sys is run, it references the hardware drive in its command.

I looked up a little bit about DECtalk.  It looks like the earlier versions 
used a serial port but the later versions plugged directly into an ISA slot.  I 
assume you have one of the later versions?  I can't imagine how one that works 
with a serial port would have a hardware compatibility issue.

Hardware compatibility issues are usually either with Interrupt (IRQ) or I/O 
port conflicts, but IDE/ATAPI was such a widespread standard that it's hard to 
imagine how DECtalk would have a conflict with those.

Does the information you've found give any indication as to what the conflict 
might actually be?

--
Bret Johnson
It's oft been said that the Devil is in the Details.  I disagree completely.  I 
say God is in the Details -- the Devil is in the Fluff.


___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] what cd rom drivers does freedos use?

[Bret Johnson via Freedos-user]

> The driver providing an issue is one called vide_cdd

I found this reference to the file:

https://www.vogonswiki.com/index.php/VIDE-CDD.SYS

It doesn't mention any compatibility issues, but does say it's very small 
compared to most other drivers which may be why it has problems (there might be 
something missing that needs to be in there).

It also seems to indicate it's a "generic" IDE driver so should work with many 
CD drives.

> Do you know of a comparative substitute?

I think I would try OAKCDROM.SYS.  I see it referenced a lot as a good driver 
that works with many IDE CD drives.  I just looked and the one I use on my 
desktop computer is called AOATAPI.SYS, but I don't remember how I came to use 
that one -- I set it up a long time ago and my memory is not that good.  I 
think you should be able to search the Internet and find a way to download both 
of those.  I rarely use CDs myself, but am adding support for USB CD/DVD drives 
to my USB drivers.

> Would that substitute have to work with only specific cdrom or
> dvdrom drives?

I think either OAKCDROM or AOATAPI should work with most CD/DVD drives.  As I 
stated earlier, very early CD drives were proprietary and needed 
hardware-specific drivers, but after IDE & ATAPI became popular things became 
pretty standardized and generic drivers will work with most hardware.


___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] what cd rom drivers does freedos use?

[Bret Johnson via Freedos-user]

Karen:

Do you know which of the two CD-ROM drivers you are having trouble with?

It takes two drivers to install a CD in DOS.  One is the hardware-specific 
driver that may come with the CD hardware itself, but there are also several of 
them (like OAKCDROM.SYS) that will work with different hardware if they are 
"standard" enough (early CD hardware was not standard at all).  The "output" of 
this driver is a character device that has a name, and all this driver does is 
provide access to the sectors on the disk -- it doesn't actually "understand" 
what the data is (e.g., whether it is a music CD or a data CD or something 
else).

The second driver is usually MSCDEX, but there are also several clones of 
MSCDEX (e.g., SHSUCDX and NWCDEX).  That driver "interfaces" with the first 
driver (you must tell MSCDEX what the name of the first driver is) and the 
"output" is a drive letter (a block device instead of a character device) that 
DOS can use (like D:) to access the files.  Just like with floppies and hard 
drives where you can have different kinds of formatting (FAT12, FAT16, FAT32, 
exFAT, NTFS, HPFS, etc.), you can also have different kinds of formatting on 
CDs, DVDs, and BDs.  The second driver is the one that needs to "understand" 
the different kinds of formatting to be able to turn it into a drive letter.


___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] What DOS programs represent the 1980s and early 90s ?

[Bret Johnson via Freedos-user]

> I did not catch how to do LPT interrupt, real and protected mode. It
> would be a great help if there is an example.
> I work with watcom and realized it, but only once, then the ISR is
> never called again.
> May be LPT is not very often used.

It would help to know exactly what you're trying to accomplish.  In DOS you 
normally don't need to access the parallel port at the hardware (IRQ) level 
since the BIOS functions (INT 17h) normally work really well.  If you're 
wanting to do something other than print (e.g., using any of the IEEE 1284 
protocols including bi-directional, ECP, and EPP or downloading the printer 
identification data), then you might need to access the IRQ or at least 
manipulate the I/O port(s) directly.


___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] What DOS programs represent the 1980s and early 90s ?

[Bret Johnson via Freedos-user]

> I'm thinking about doing a video that shows how to do real work on
> DOS.  I sometimes see comments on YouTube with people asking "could
> you really do *work* with DOS?" And the answer is of course you can,
> that happened every day.
>
> So I'm collecting a list of things you'd do in the 80s and 90s with
> DOS to do work. Sure, I'll put a game it two in there, but I'm
> focusing on getting work done.
>
> What programs or types of programs would you like to see?

In the early 80's, I worked in an Engineering department where a bunch of us 
shared a single XT-class computer.  The main applications we used at the time 
were PC-Write (an early word processor) and Lotus 1-2-3.  We also had a 
secretary in the front of the office that used an IBM word processor (I think 
it was called DisplayWrite, but I don't remember for sure) to write "official" 
reports.  I do remember it used EBCDIC instead of ASCII.  And back in those 
days everything was transferred back and forth with floppies.

Later on everybody ended up getting their own networked computer on their desk. 
 We still mostly used PC-Write and Lotus 1-2-3, but we sometimes used other 
programs also.

The Company used an IBM mainframe for all the central services, and one of the 
main applications everybody used was a DOS program called Extra! by AttachMate 
which gave us access to the mainframe from our PCs.  One of the big projects I 
worked on was working with the mainframe programmers to create a database to 
keep track of some of the Engineering systems we worked on.  While the 
mainframe did a good job of maintaining the data, the only kinds of reports you 
could run from the mainframe were the "canned" reports which would be printed 
on paper.

I often needed to create special/custom reports or use special filters on the 
data.  I figured out ways to manipulate Extra! or DOS to extract the data I 
needed so I could manipulate it to get what I wanted.  That need was the main 
reason I ending up writing the first version of my PRTSCR TSR program, which 
essentially does a "screen scrape" of the text on the DOS terminal and sends it 
to a file instead of to a printer.

Another early TSR program I worked on was JOYKEYS, which turns joystick 
movements and button presses into keystrokes.  At the time I had some joysticks 
on my computer at home and thought a joystick might be useful as an input 
device for lots of different programs besides games.  It was a similar 
situation with my MOUSKEYS program, which turns mouse movements and button 
presses into keystrokes.  This allows you to use a mouse with almost any DOS 
program even if it wasn't originally designed to use a mouse.  Of course, using 
either a joystick or a mouse in a program that wasn't originally designed to 
use them as an input device has a lot of limitations that a fully-integrated 
implementation could overcome, but can still be useful in certain situations.


___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Codepage and keyboard setting for Czech language

[Bret Johnson via Freedos-user]

FYI, in MS-DOS divided the Internationalization aspect into four different 
subcategories: Keyboard Layout, Code Page, Country, and Language (which also 
includes dialects).  While they all overlap and inter-relate to some degree, 
they are distinct and are all handled separately.  The more "modern" operating 
systems also have the same issues but handle it differently than MS-DOS 
did/does, in part because of limited resources (like hard drive and memory 
space).


___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] FreeDOS or DOS based mail clients

[Bret Johnson via Freedos-user]

My understanding is that there are two major differences between POP and IMAP.  
The first is that POP only allows one-way communication (downloading from the 
server to the client) so there is no synchronization mechanism.  If you 
download the same e-mail to multiple devices, each one can be set up 
differently (specifically in terms of folders).  When you want to send mail, 
you must use a different protocol (SMTP).

The second difference is that IMAP is designed to be used in a client-server 
configuration where the e-mails stay stored on the server and are never 
actually downloaded (at least not permanently) to the client.  That allows 
access to the same e-mail account from multiple devices and there is only one 
"real" copy of the e-mail (stored on the server).  Programs like MS Outlook can 
store a local cached version of the e-mail, and there can be a lot of 
complication involved in making sure the cache stays synchronized with reality 
(what's on the server is "reality").

There are advantages and disadvantages to each approach.


___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Epson dot matrix printer emulator?

[Bret Johnson via Freedos-user]

I don't know of a DOS program to do specifically what you're asking.  But this 
reminds me of the old commercial DOS program called SIDEWAYS that was designed 
to take text-based printer output from Lotus 123 and print it sideways 
(commonly called Landscape mode nowadays).  I think it also worked with other 
types of programs too (like word processors).

I know that's not exactly what you're looking for, but maybe it will trigger 
something in someone's memory (like maybe a shareware/freeware "clone" of 
SIDEWAYS or something)?

As suggested, if you're running in a VM you can probably just print the output 
and have the Host OS capture it and convert it to PDF or EPS or something 
instead of actually sending it to a printer, but I'm not sure that's exactly 
what you're looking for either.


___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] piping .BATs (input and output)

[Bret Johnson via Freedos-user]

> What I'm wondering is if the following (piping into a .BAT) is
> considered acceptable or "standard" for DOS.
>
> "prog1.exe | %COMSPEC% /c work.bat | %COMSPEC% /c fixups.bat
> some.txt"
>
> Does that work like I'd expect? (Seems to ... barely.) Is it rare?
> Is it buggy? Is there a better way?

Though I don't know for sure, I have a couple of thoughts.  First of all, what 
you're doing isn't really piping into a batch file.  You're piping into 
%COMSPEC% which is then, at least in a sense, running the batch file sort of 
like a subroutine.  I would be very surprised if all the varied %COMSPEC%'s 
would be consistent in how they handle that.

I do know that in a "regular" program there are three different places from 
where you can normally gather input parameters: the command-line (which is 
stored in the PSP or, in certain cases, the CMDLINE environment variable), 
various environment variables, and the input pipe (through an INT 21h call).  
Those come from three very different places, and the program needs to decide in 
which order they will be processed.  Most programs I've seen don't even bother 
looking at the possibility of an input pipe and usually assume everything comes 
from the command-line via the PSP.


___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Some USB-Stick problems

[Bret Johnson via Freedos-user]

> Next problem: I tried to get printer support via USB (currently they
> use classic LPT, but those printers get very rare).

Indeed they are.  And many modern printers use protocols that aren't compatible 
with old DOS programs.

> But as soon as I load the basic USBUHCI driver, the USB-stick is no
> more available, due to reinitialization of the hardware, it seems.
> Is there a way to keep the USBdrive as C: available and get printer
> support?  Just loading USBPRINT (from Bret Johnson) doesn't get a
> connection to the printer.

According to the specs, you have six USB ports (using a VIA chipset) which 
means you have 3 UHCI host controllers (each one controls 2 ports).  If you 
load USBUHCI (or preferably USBUHCIL) with no options, it will install itself 
to control the first one it finds (called Index 0).  That must be the one you 
have your disk plugged into since your disk stops working.  What you need to do 
is install USBUHCIL for /Index:1 or /Index:2.  You'll need to experiment to 
figure out which physical ports are associated with which host controller index.

Since you're booting from USB, you're going to need to make sure the printer is 
plugged into a port from a different host controller than the boot disk is.

USBPRINT is only compatible with USBUHCIL, not with the BIOS.  You must install 
USBUHCIL for the host controller index that controls the port you want to plug 
the printer into, and then install USBPRINT.  That should let you use a USB 
printer (or an old LPT printer and a USB-to-LPT adapter cable) as if it were an 
LPT printer.  You may also need to provide some command-line options to 
USBPRINT to make sure it virtualizes the correct printer port (I assume you'll 
want it to be LPT1).


___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Sved, yet another text editor

[Bret Johnson via Freedos-user]

> Because I felt that the world needed another DOS text editor, I have
> spent past month's evenings on a new project named SVED.

> SVED (short for "the SvarDOS editor") is designed for basic editing
> of configuration files and such. It is NOT meant to be a full-
> featured text editor. On the pro side, it has a low memory footprint
> and is only a couple kilobytes big, which makes it a good fit for
> bootdisks or systems with extremely limited resources.
>
>  - runs comfortably on a 8086-class PC with 256 KiB of RAM
>  - auto-detects color and monochrome video modes
>  - supports unusual text modes like 80x43, 80x50, 40x25...
>  - multilingual UI
>  - only 7 KiB of disk footprint
>  - screen estate dedicated to text (no stupid frames, menus and
 such)
>  - loads files larger than 64 KiB
>  - no line length limit
>  - can load up to 10 files simultaneously
>  - handles CR/LF and LF line endings and can convert between them

Does it have copy/cut/paste functionality?


___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Confusing details about SET and redirection inFreeC OM

[Bret Johnson]

> Maybe put in quotes?

In some circumstances you can put things in double-quotes at a DOS command-line 
to enclose "special" characters, but that doesn't always work and different 
versions of DOS do things differently.  Probably the simplest example of this 
is enclosing a long-file-name (at least if it contains spaces) in double-quotes.

But, as Eric noted, the double-quote character does some unexpected things when 
used with a SET command (like not even needing a closing quote).  Enclosing 
things in quotes won't fix the problem, at least not consistently across all 
DOS versions.

E.g., I just did a couple of simple tests in both MS-DOS 6.22 and 7.1:

  SET "Test=8"

creates an environment variable named "TEST with the contents of 8".

I also did:

  SET  Test=Test=8
  SET "Test=Test=8"

and got syntax error messages in both versions of MS-DOS.

***

In FreeDOS 1.2:

  SET "Test=8"

does the same things as MS-DOS.

But in FreeDOS 1.2:

  SET Test=Test=8

creates (correctly, IMHO) an environment variable called TEST with the contents 
of Test=8, and:

  SET "Test=Test=8"

creates an environment variable called "TEST with the contents of Test=8".

Bottom line is that FreeDOS (at least version 1.2) doesn't work the same way as 
MS-DOS, but I'm not 100% sure which way is "buggier".


___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Confusing details about SET and redirection in Free COM

[Bret Johnson]

> Hi fellow users :-)
>
> I have been wondering which chars are special in SET
> in FreeCOM and whether they can be escaped or similar.

I don't know specifically about FreeCOM, but I know in some versions of DOS an 
environment variable can't contain an equals sign.  For example, in some DOS 
versions you can't do this while in others you can:

  SET ParameterList=Var1=1,Var2=2

This has caused me some grief in the past when I try to allow the user to enter 
option parameters either from the command-line or from an environment variable. 
 For example, if the program I'm trying to run is called PROGRAM I allow the 
user to set an environment variable named PROGRAM that contains the "default" 
command-line parameters:

  SET PROGRAM=Option1=Yes, Option2=No

I want that to work the same way as if the user had done this:

  PROGRAM Option1=Yes, Option2=No

Sometimes it works and sometimes it doesn't, depending on which version of DOS 
I am using.  And I'm not even sure it is consistent across all different DOS 
versions from the same manufacturer.  BTW, the way I get around this problem is 
to allow the user to either enter an equals (=) or a colon (:) as the separator 
character and explain the situation in the documentation..

The reason I bring this up is that in a recent post there was some discussion 
over whether or not FreeDOS should fix all the bugs in MS-DOS (essentially, 
improving MS-DOS) or duplicate the bugs, and the consensus seemed to be to 
duplicate the bugs.  I don't know if allowing an equals sign in an environment 
variable would be considered a bug or a feature, but I would classify it as a 
bug, and I don't remember specifically how MS-DOS handles it.


___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Mouse not working on real silicon

[Bret Johnson]

> Found a post with same problem
> "To get your mouse working under DOS, you can try Bret Johnson's USB
> programs.  You'll need one of the USBUHCI drivers, USBMOUSE, and
> CuteMouse."
>
>Hope that helps.

You can try my programs but it may nor may not help.  Your computer will need a 
UHCI-compatible USB host controller, which are the older ones made by Intel and 
Via.  Things made by other manufacturers, or newer USB hardware, probably 
aren't UHCI.

> I don't think having USB mouse in BIOS is the problem.  I believe my
> configuration uses BIOS to boot by default.

It more than likely IS the problem.  Booting from USB and having the USB mouse 
and/or keyboard enabled in the BIOS are not the same thing.  You need to make 
sure the USB mouse is enabled in your BIOS -- this is usually called something 
like "Legacy USB Support" in the BIOS (though different BIOSs label things 
differently).  Not all BIOSs have USB mouse support, but a lot of them do and 
you should to make sure it's enabled until you understand a little more about 
how USB works.

In addition, it's also possible that when you boot from USB you can't use the 
USB mouse even if it's enabled in the BIOS.  It's all convoluted and confusing. 
 Let's just say USB is VERY complicated and I can almost guarantee that it 
doesn't work the way you think it does.


___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Questions about link files

[Bret Johnson]

> All true, but you forgot about the most important: COM links are not
> limited to 9 command line params (%1-%9). This is actually the reason
> that made me design the COM links files that are used nowadays in
> FreeDOS.

That's not true.  The SHIFT command in batch files allows you to access more 
than 9 parameters.  But it is more cumbersome and confusing to use than how you 
handle it in an executable file.

As a sidebar, a "normal" command line is limited to 126 characters total, but 
some command shells (notably 4DOS) extend that by using the CMDLINE environment 
variable.  From what I can tell, the FreeDOS command shell doesn't support 
that.  Allowing more than 126 characters can give you access to a HUGE number 
of parameters.


___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Questions about link files

[Bret Johnson]

> What I still don't understand is, why use binary .com files for links
> instead of .bat files? In my C:\FreeDos\Links directory I have 6 .bat
> files and 9 .com files. What is the difference between creating a
> link file as a batch file vs creating it as a binary .com file?

An executable file (.COM or .EXE) might operate a little bit faster than a 
batch file, but in most cases I doubt that you would even notice the difference 
in speed (unless you were running from a floppy).  An executable file would be 
harder to change when you wanted/needed to since you would need to modify the 
source code and then compile/assemble.  Batch files are interpreted instead of 
compiled so you don't need the extra step of creating an executable file -- all 
you need is the "source" (.BAT) file itself.  Needing a compilation would make 
it harder for someone to "accidentally" change things, which can either be good 
or bad depending on exactly what you're trying to accomplish.

In terms of actual operation, though, it does make a little bit of difference.  
Inside a batch file if you have a line that contains an executable file name 
(.COM or .EXE) or an internal DOS command name (like DIR or COPY) when the 
execution is finished DOS automatically returns to the original batch file and 
continues running.  If the line contains the name of another batch file you 
must CALL the second batch file or it never returns to the original batch file 
(it JUMPs instead of CALLs).  You can use this "trick" to exit a batch file 
early (e.g., create a QUIT.BAT file that doesn't do anything and when you want 
to exit a complicated batch file early just enter a "QUIT" instead of a "CALL 
QUIT").

There is also a limit on how many nested batch file CALLs you can have going on 
at the same time (IIRC it's six).  You can also "nest" executable files (using 
something called the EXEC function), and in theory you could do more than six 
levels, but EXECing can use a LOT of memory while nesting batch files doesn't.

In short, there are advantages and disadvantages to both methods.


___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Questions about link files

[Bret Johnson]

> The link files in C:\FreeDos\Links set an environment variable. For
> example I found this in the file blkdrop.bat
>
> set _LINK.BLKDROP=%DOSDRV%\GAMES\BLKDROP\BLKDROP.EXE
>
> If I run this, I expect the environment variable _LINK.BLKDROP to be
> added to the system, but when I do a "set" I don't see it. Why is
> that? (I must be misunderstanding how the "set" command works).

After you type SET xxx=yyy you should see it show up when you type the SET 
command afterwards.  There are two reasons I can think of why it wouldn't show 
up.  One would be if you are out of environment space so it never actually got 
added.  The amount of environment space is limited, and I'm not sure how 
different DOS versions react if a variable never got added due to a size 
limitation (some may just fail silently).  I don't remember having that problem 
myself, so I'm not sure.

The other reason would be that there are (or at least can be) multiple copies 
of the environment space.  There is a master environment space and as programs 
and shells are executed sometimes they only a receive a copy of the environment 
space.  If they make any changes they only appear in the copy and are never 
transferred back to the master environment.  The details can get complicated, 
so I think we'd need to know a little more about the entire sequence of things 
you're doing to try to do to isolate the source of the problem.

> All .bat link files run the programs with 9 parameters (%1 - %9) I'm
> guessing this is because a dos program can take a maximum of 9
> parameters and by doing it this way, all program parameters should be
> covered. Is that correct?

No, they can have more than 9 parameters.  %0 is the name of the batch file 
itself, and you can use the SHIFT command to access the higher-numbered 
variables (the tenth parameter would move into %9, the ninth into %8, etc.).  
The lower numbered parameters just disappear so you need to make sure you don't 
need any of them again after the SHIFT.

When you're running an executable file (.EXE or .COM) instead of a batch file 
you can do and access all kinds of things that you can't do from a batch file.  
That's where batch file utilities are helpful -- they let you "expand" the 
capabilities of a batch file.

> Why are some of the link files .COM files containing binary data?

I'm not sure what you mean by "link files .COM files".  COM files are binary 
executable files and always contain binary data.  They can (and usually do) 
contain some readable text data embedded in the binary code, but they don't 
have to.


___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Writing date and time into log file

[Bret Johnson]

> For a tool look at
> :
> timestmp +JMD:HIS>>logfile.txt
>
> This will append, e.g., "20221223:172247" to logfile.txt.

If your only concern is this date/time thing, a utility like TIMESTMP will work 
perfectly.

If you're interested in learning something that will help you more in the "long 
term", you may want to experiment with something like SED (or AWK or ...) as a 
way to manipulate text files, or "whipping up" a custom executable file in ASM 
or Basic or C or whatever.

Those are useful learning experiences to have in your tool bag for "special" 
situations where an off-the-shelf solution isn't available.


___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Writing date and time into log file

[Bret Johnson]

> I just can't figure this one out: From a .bat file, I want to write
> entries to a log file. Each entry should have a date and time in the
> form MMDD:HHMMSS I have searched the internet for solutions on
> how to do this, but none of the solutions work (I think they are for
> cmd.exe in modern Windows which is more advanced than command.com).

You're correct.  Most of the time these days if you search for some kind of 
"DOS Batch" solution to a problem on the web they assume "DOS" and Windows 
command prompt (NTVDM) are the same thing.  They aren't.

You're not going to be able to do this straight from DOS prompt itself.  You'll 
need some help from some external utilities. 

> My first problem is, that I just cannot figure out how to write just
> the date without all the preceeding text (Current date is Thu
> 12-23-2022).

You really can't manipulate the way the date and time are formatted with the 
DATE and TIME command, at least not very much.  The output of the DATE and TIME 
command should comply with the current COUNTRY (locale) settings you have DOS 
set up for.  E.g., some COUNTRY settings will output the date as 12-23-2022 
while others will output 2022-23-12.  You probably don't want to mess with your 
COUNTRY settings, though, since that will change how a lot of other things 
appear in DOS also. 

> I tried some a substring routine like this, which I found on a web
> page
>
> set MMDD=%DATE:~10,4%%DATE:~4,2%%DATE:~7,2%
> echo %MMDD%
>
> I changed the numbers to reflect my date output

That's an NTVDM (CMD) thing.  It won't work in "real" DOS.

> I ran the .bat file, but all it says i "ECHO is on", so first problem
> is: How do I write a date to a file from a .bat file?

What you need to do is redirect the output of the DATE command to a file:

  DATE > Date.Txt

This will create a file called Date.Txt and it will contain what the DATE 
command normally send to the screen.  You could then follow it up by appending 
the time to the same file:

  TIME >> Date.Txt

Note that this one needs two arrows ">>" to append to the end of the file.  If 
you just do one arrow it will overwrite the file instead of appending to it.  
You could then manipulate the Date.Txt file with a macro in a text editor or 
something like that.  I would probably use a DOS port of the Unix utility 
called SED.  SED is a good way to manipulate text files automatically, but it 
can be a little tricky to use.

> Second problem is, that I want to alway have the date formatted as
> MMDD no matter which locale it is run on. Is there any call that
> can be made in FreeDOS to automatically format the date in a specifc
> way no matter which locale is used?

That's another level of complication.  Even the above solution of redirecting 
the DATE and TIME outputs will be Locale-dependent, so manipulating things with 
SED will get really complicated.

If this were me what I would do is create a custom utility.  I actually have a 
utility I call DATES, but I've never officially released it.  The output of 
DATES looks like this:

  DATES 1.00, (C) 2022, Bret Johnson.
  
   DATETIME
mm-dd-  hh:mm:ss.dd
--  
  BIOS: 12-23-2022  07:53:54.21a
  CMOS: 12-23-2022  07:53:55.00a

The main reason I wrote DATES was to be able to see the difference between the 
BIOS clock (which is what DOS uses) and the CMOS clock (which is the one that 
the computer uses to initialize the time when you first boot up).  The format 
of the date and time outputs are locale-specific, though, so the output will 
not always be mm-dd-yy for the date.

What I would suggest is that you take the source code for DATES (it is written 
for NASM which you can get for free) and manipulate it so it gives you the 
output you desire.  I'll send you the source code for DATES if you want it.


___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] keyboard spacecharacter automatically repeated

[Bret Johnson]

Keyboards can sometimes do funny things, especially keyboards like the ones 
you're describing that have special timing-related "features" built into them.

I would suggest starting with my SCANTEST program (attached) and see what the 
keyboard is actually sending to the computer (SCANTEST is one of the test 
utilities that is included with my USB drivers).  Rename SCANTEST.CO_ to 
SCANTEST.COM and run it.  This sounds like a keyboard (hardware) issue rather 
than software, but more testing is needed to sort it out.


SCANTEST.CO_
Description: SCANTEST.CO_
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] DOSshell replacement

[Bret Johnson]

I realize I'm a little late to this party, but I've got a couple of comments.

The first thing I think to note is that DOSShell was MUCH more than just a 
program launcher.  It include the same basic implementation and functionality 
that were in early versions of Windows (3.x) to perform task-switching.  With 
DOSShell, you could literally have several DOS applications running at the same 
time and switch between them with a few keystrokes.  This was similar to other 
task-switching programs from the same era, like DesqView and Software Carousel. 
 It sounds like that level of functionality is not required here.  I always 
found DOSShell to be "clunky" and even though I experimented with it a little I 
never really liked it for what I was trying to do.  I personally never tried 
any of the other task-switching programs besides DOSShell (and, of course, 
Windows).

Many of the suggested alternatives are really designed as file managers, which 
you can also be used to start programs by "selecting" an appropriate executable 
file and having the file manager "shell out" and start running the executable.  
Some of them have a more "advanced" menu system where you have a special list 
of programs where the file manager knows where the appropriate executable file 
is so you don't need to "look for" the executable file yourself (DOSShell had 
this also).  I remember using an old program called Pop-Up DOS which was 
basically a simpler version of the more advanced modern file manager programs.  
Pop-Up DOS came bundled with some versions of the Logitech mouse drivers (if 
you bought a Logitech mouse Pop-Up DOS came included on the disk with the mouse 
drivers).

Even though I don't use it myself (I prefer the command-line), I developed a 
menu system that simply uses a batch file and some DOS utilities (like ANSI and 
CHOICE).  I also use a couple of my utility programs, SCANCODE to automatically 
select the "Screen Saver" from the menu if nothing is selected for a long time 
and MOUSKEYS to enable use of the mouse to select things instead of just the 
keyboard.  I can create a ZIP file with the main MENU.BAT file and some of the 
utilities if anybody is interested.  You configure/customize the Menu by 
editing the batch file so it's less "automated" than some of the other options 
(though you could have one of the menu options set up to edit the MENU.BAT file 
with your favorite text editor).  One advantage to using a batch file is that 
it provides more free memory than a regular executable since it doesn't need to 
"shell out" to execute another program.


___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] CD drive always gets the letter H: - can't change

[Bret Johnson]

> I haven't been able to change the drive letter for the CD drive, no
> matter how hard I try, it always defaults to the letter H:

Do you have a LASTDRIVE= line in your CONFIG.SYS (or FDCONFIG.SYS) file?  If 
so, what is it?

> It was a little hard for me to unravel cdrom.bat to make sense of
> how it works but I managed to reduce the important part to this:
>
> DEVLOAD /H UDVD2.SYS /D:FDCDX001
> SHSUCDX /~ /D:FDCDX001,D

According to the documentation for SHSUCDX (typing "SHSUCDX /? at the 
command-line), where the drive letter is assigned is with the ",D" at the end 
of the SHSUCDX line.  This tells SHSUCDX to start by trying to use D: as the 
letter for the CD.  If D: isn't available, it will try the next available 
letter (E:) and keep going until it finds an available letter.  Apparently on 
your system the letters D:-G: are already assigned to something (like maybe 
some USB drives or some extra partitions on the hard drive(s)?).

You can try seeing if anything exists on the D:-G: drives (e.g., by doing a 
"DIR D:") and see if you can figure out what's going on.


___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] More on OpenGEM

[Bret Johnson]

> If one maps the \OPENGEM directory to another drive letter, e.g.
>
> swsubst g: c:\opengem
>
> ... and then runs GEM from drive G, it can find its resources and
> windows get frames, title bars, etc.

FWIW, I use SWSUBST (or SUBST) a lot.  SWSUBST doesn't work with all versions 
of DOS -- sometimes you need to use the SUBST that came with the DOS.

My system is set up with several different Virtual Machines and DOS versions 
and manufacturers so I can test various things.  I can also boot DOS to real 
hardware (my computers still have a BIOS).  Because of all the various 
configurations, my drive letters are not always consistent.  To try and make 
all the different configurations as similar as I can, I have a small C: drive 
that just contains a few basic boot utilities, but the majority of useful 
programs (including the "extended" boot utilities) are on a different drive 
letter (usually D: or E:, but it depends on the exact configuration).  The D: 
or E: drive can be seen by all the different configurations so I only need one 
copy of everything.  I use {SW}SUBST to create an S: (System) drive that points 
at the drive where the "real" programs are.  I normally run things from the S: 
drive instead of the C:, D:, or E: drive so I don't get confused about where I 
am.

I also set up a few other {SW}SUBST drives, such as T: (for all my Batch 
files), U: (for my Utilities), V: (for the DOS utilities associated with the 
DOS I'm currently booted to), and R: (for the RAM drive where TEMP and TMP are 
pointed to).  Sometimes when I'm installing a new program that expects to be 
installed from a floppy I use {SW}SUBST to create a "virtual" A drive that 
points at the subdirectory where I have the installation files from the floppy 
image stored.  That usually avoids the need for an actual floppy drive (but 
sometimes it doesn't work, depending on the installation program).

Similar to your GEM issue, I also have a program that expects backups to be in 
the root directory of a specific drive letter rather than in a subdirectory.  I 
start the program with a batch file that uses {SW}SUBST to create a virtual 
drive letter for the backup, and when the program exits the batch file removes 
the {SW}SUBST drive letter.

In summary, I think your approach of using {SW}SUBST to create virtual drive 
letters is a good one.


___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] DOS ASM resources

[Bret Johnson]

> What i don't like about A86 is that allows you to do stuff that is
> actually "forbidden".
>
> For instance, from what i remember, A86 allows you to do something
> like:
>
> MOV ES, B800h
>
> This is absolutely not supported by the CPU, and you need to use a
> general purpose register to move a value onto a segment register. So
> the actual A86 assembled code looks like this:
>
> PUSH AX
> MOV AX, B800h
> MOV ES, AX
> POP AX
>
> I believe that it is very important for a begginer to understand how
> the ISA works otherwise this will just lead to confusion later.

All assemblers have "quirks" in them that you just need to learn.  The A86 
thing for putting a direct value into a segment register is basically just a 
built-in Macro, and you could do the same thing with any other assembler (at 
least if it supports macros) if you wanted to also.  That particular A86 thing 
is in the documentation, so if you read that you will see it.  You will also 
see it when you're debugging.

When I use A86 (which I still do sometimes), I know about this "quirk" and 
bypass it and use one of the general purpose registers (sometimes AX and 
sometimes another register) to set a segment register to a direct value.  But 
the A86 macro is handy for a beginner -- IMHO, putting a direct value into a 
segment register SHOULD be something the CPU supports.

The "weird" one I find in NASM is that you normally need to use $-$$ (instead 
of just $) for the current memory address.

> What i like about FASM is that it is very strict so you learn to do
> things properly from the get go. Its raw and gritty so it might be a
> little more frustrating at start but you'll really learn things.

When I found I was needing to "upgrade" from A86 I looked at both FASM and NASM 
and ended up choosing NASM, in part because it wasn't as "strict" and was a 
little more similar to the A86 I was used to.  I also have a set of macros I 
use to make NASM to work a little bit more like A86 and some of the built-in 
"special features" that are nice in A86, which makes it easier to port the code 
over to NASM.  I still need to make quite a few changes to the code, but not as 
many changes as I would need to make if I didn't have the macros.

It's really all personal preference.  But, when you start introducing macros 
and libraries (especially ones that others write) then "strictness" kind of 
goes out the window, anyway.


___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] clipboard support utilities

[Bret Johnson]

Slightly tangential topic, but there is also my MOUSKEYS program which includes 
a small internal "clipboard" (limited to one screen's worth of text).  The 
clipboard functionality is somewhat similar to MouseClip.  MOUSKEYS does a LOT 
more than just provide a clipboard, though -- it actually lets you use a mouse 
with almost any program (including just at the DOS prompt itself).


___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] DOS ASM resources

[Bret Johnson]

> Interestingly enough, I also bought a86/D86, and have found it to be
> the best assembler/disassembler I've ever found for dos.  I ran
> across it after (mostly) trying to use debug for things, so it was a
> welcome relief.

I still like A86/A386 also, but like I said my programs are getting so 
complicated these days that they no longer work because of the limited memory.  
Specifically, I have so many symbols (structure elements and equates and 
labels) that the symbol table overflows when using A86/A386.  That's why I've 
had to switch to something more capable (specifically, NASM).  The problem I 
have with NASM, and most other assemblers, is that they don't come with a 
useful debugger.

To me, the real "gems" of A86/A386 are the D86/D386 debuggers.  I still use 
them all the time when I'm debugging the programs I'm writing.  There are two 
things I really like about D86/D386.  One is that you can put the screen in a 
50-line mode and have the debugger "window" on the top half of the screen and 
watch the program output on the bottom half of the screen.  That's a very nice 
setup.

The other thing is that if you create a .SYM (Symbol) file in the D86/D386 
format you can refer to the symbol names instead of memory addresses as you are 
debugging, another VERY useful feature.  Unfortunately, the .SYM file format is 
proprietary and can only be generated by an A86 or A386 assembler.  But I have 
a method automated where I can take the .MAP output file generated by NASM and 
create the .SYM file (I only convert the subroutine labels and not the equates 
or structure elements) so I can use the symbolic capabilities of the D386 
debugger with NASM-generated programs.  This makes debugging much easier.

I've also experimented a little bit with 386SWAT, but haven't used it enough to 
really get comfortable with it.  I know you can also provide symbols to 386SWAT 
which definitely helps.  But my main debugger is D386.

I also sometimes use ECM's lDebug, but that is mostly when I'm trying to figure 
out what someones else's program is doing and don't have the source code or 
some other way to look at the symbols/names to help try and figure out what's 
going on.  lDebug is much better/easier than D86/D386 for certain kinds of 
debugging/research. 


___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] DOS ASM resources

[Bret Johnson]

Santiago:

I agree pretty much with ECM.  The best way to learn is to look at the code 
someone else has written and try to understand it.  Unfortunately, most ASM 
coders aren't very good at comments/documentation, and you really need the 
comments to help you figure things out.  Looking at uncommented code doesn't 
seem to help me very much -- I need to try and figure out how the coder was 
thinking, not just the result of the thinking.

I put LOTS of comments in my code -- I'm sure at least some people think too 
many.  Almost every line of the source has a comment, and each "subroutine" has 
a comment header similar to what ECM has (but my "style" is different than 
ECM's).  The comment header includes details about what the subroutine does, 
its inputs and outputs, and what it may change.  The header MAY also include 
the "context" of when and where the subroutine should get used, and why the 
subroutine even exists at all (especially if it is there to address some 
"special" situation).  For example, most of my programs are TSR's and in the 
most recent versions I'm working on the programs can use different kinds of 
memory: conventional, upper, Expanded (EMS), and/or Extended (XMS, which I 
access through a DOS Protected Mode Services or DPMS server).  I have comments 
to try and explain why I do something that requires a special consideration for 
one of the different types of memory.  An example of this would be that you 
NEVER want a stack to use Expanded memory, so sections of the code related to 
the stack need to take that into account and should make some comment about it.

When I first started (a LONG time ago), modern assemblers like NASM & FASM 
didn't exist, and I didn't like MASM (though it was and still is kind of "the 
standard" I find it confusing), so I ended up buying A86/A386 from Eric 
Isaacson.  Unfortunately, Eric hasn't updated those in a long time and it's not 
possible to do large projects with them because they don't take advantage of 
extended or expanded memory.  I've since switched to NASM, but I think FASM is 
also pretty good, and they're both free (unlike A86/A386).

I've got a couple of books, but really the only "fixed" resource I use is Ralf 
Brown's Interrupt List (RBIL).  I've found looking at other people's actual 
production code is the best way to learn things.

I also think the best way to get started is to actually write a small but 
useful program from scratch -- a program that you will actually use when you 
get done.  Don't make it try to do too much -- just something relatively 
simple.  The very first program I wrote was a simple version of JOYKEYS, a 
program that allows you to use a Joystick with almost any DOS program.  The 
first version was pretty basic, and it's changed a lot over the decades 
compared to how it started.  There are lots of things you need to understand 
(memory, I/O, Interrupts, BIOS, DOS, etc.) to even write a simple program.  The 
ASM part of it, while pretty complicated, is not the hard part.  The hard part 
is figuring out WHY you do (or don't do) certain things.


___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Keyboard issue - wondering about typematic rate for keyboard repeats in different VMs and emulators

[Bret Johnson]

Most modern computers seem to support INT 16.03 to set the Typematic rate.  
I've personally never had it fail with real hardware, but in some Virtual 
Machines (VMs) it doesn't actually do anything.

I've had lots of failures with support of INT 16.09 to get the current 
typematic rate, both in real hardware and in VMs.

> Our MODE just calls the BIOS. There is no DOS typematic rate driver,
> DOS only asks the BIOS to set the rate for it.

When DOS MODE calls the BIOS to change something about the typematic rate, 
there is no "driver" involved.  If the keyboard is a regular PS2 (or older) 
keyboard, the BIOS just sends a special serial packet to the keyboard telling 
it what to do.  Control of the actual typematic stuff is handled COMPLETELY by 
the keyboard hardware.

In addition, in the PS2 keyboard serial protocol there is no way for the BIOS 
to "ask" the keyboard what the current typematic settings are.  This means the 
BIOS must keep track of the current typematic settings internally since it 
can't ask the keyboard (it can't do a "Read-Modify-Write", it can only do a 
"Write").

USB keyboards are actually "dumber" than the PS2 keyboards.  PS2 keyboards 
handle key presses, key releases, and all the typematic stuff all by themselves 
and just send data to the computer when something has happened.  USB keyboards 
must constantly be polled and only return information about key presses.  The 
USB keyboard driver needs to handle the key releases and the typematic stuff in 
software since the USB keyboard doesn't do it.


___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Reply to keyboard issue and debug

[Bret Johnson]

I'll chime in a little bit late now that you've got it figured out.  In 
troubleshooting it's good to know how things are supposed to work, at least 
enough to narrow down whether the problem is most likely hardware or software.  
Based on the symptoms and the fact that you are running on real hardware pretty 
much eliminates this being a software problem.

In PS2 (and earlier) keyboards, the Typematic rate is controlled by the 
keyboard hardware.  The communication between the keyboard and the computer 
(the keyboard controller in the computer) is a relatively simple serial 
communications link that sends small packets of data.  The computer (BIOS) 
sends a packet of data to the keyboard telling it what the Typematic rate 
should be and the keyboard hardware handles all the details as keys are pressed 
and released afterward.  Eric's DEBUG example talks to the BIOS, and the BIOS 
in turn talks to the keyboard over the serial communications link.  The fact 
that your keyboard is sending some data indicates that the communications link 
(including the cable between the keyboard and computer) is probably OK, and so 
is the keyboard controller in the computer.  The problem, as you discovered, is 
in the keyboard itself.  If you're feeling ambitious you can try to open up the 
keyboard and see if there's anything obvious (like a broken wire or something), 
but it's probably best just to toss it.

A couple of things to note, though.  In the packet protocol that is used, there 
is no way to ask the keyboard what the current Typematic rate is.  So, the BIOS 
needs to keep track of it internally.  There is a standard BIOS function to 
retrieve the current Typematic rate, but a lot of BIOS's don't implement it.  
When it is implemented, the BIOS needs to keep track of the Typematic rate 
internally since it can't query the keyboard about it.

Another thing to keep in mind is that the (CapsLock, NumLock, and ScrollLock) 
LEDs in the keyboard are NOT controlled by the keyboard itself but are instead 
controlled by the computer (BIOS).  When you press the CapsLock key, for 
example, it causes the BIOS to send a packet of data to the keyboard to change 
the state of the LED.  The keyboard just does whatever the computer tells it to 
do when it comes to lighting the LEDs.  Also, it is not possible to tell the 
keyboard to change the state of just one LED -- you need to send the state of 
all three LEDs as a single packet of data.  And, similar to the Typematic rate, 
there is no way to query the keyboard about which LEDs are currently turned on 
so the BIOS also needs to keep track of that internally (but unlike the 
Typematic rate, there are standard BIOS memory locations where the LED statuses 
can be found).

If you're running inside a Virtual Machine (VM), as Eric noted sometimes the 
Virtual BIOS doesn't respond to Typematic rate requests.  I've never seen that 
problem with real hardware, though I suppose it's possible.  Another thing that 
can happen inside VMs is that the state of the LEDs on the keyboard doesn't 
always stay synchronized.  For example, the CapsLock state can be On in the 
Host (usually Windows or Linux) and Off in the Guest (DOS), and the CapsLock 
LED on the keyboard should (at least theoretically) change to reflect the state 
of whichever application currently has the focus (the Host or the Guest).  I'm 
not sure that happens correctly all the time.  I know I have lots of keyboard 
problems in my VMs, including the fact that the state of the keyboard LEDs is 
not always synchronized properly.

Lastly, all the above stuff only applies to PS2 and older keyboards and does 
not apply to USB keyboards.  In a sense, USB keyboards are dumber than PS2 
keyboards in that all they do is provide information about which key(s) are 
currently pressed.  All the Typematic related stuff and keeping track of when 
keys are released must all be handled in software since the USB hardware 
doesn't handle any of that. 


___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Installing freedos to virtualbox them copying dice contents to an actual computer

[Bret Johnson]

Seeing as how you've referred to "chapters", it sounds like you're making 
contributions to a book or dissertation or script or some sort of larger 
document.  I'd be wary of using a text editor instead of a word processor -- 
they are two very different things.

A text editor is really designed for editing things like batch files and source 
code for programs.  Even a "fancy" text editor with features like the ability 
to open multiple files at the same time or handling really large files doesn't 
turn it into a word processor.  At least from a simplistic perspective, the 
main thing that separates a text editor from a word processor is that a word 
processor understands what sentences and paragraphs are while a text editor 
only understands lines (rows) and columns.  What a word processor brings to the 
table compared to a text editor is much more than a spell-checker.  You CAN use 
a text editor to create a document with sentences and paragraphs, but it's very 
cumbersome.

A word processor understands what sentences and paragraphs are, and if your 
ultimate goal is to create a document a word processor is much less frustrating 
to use than a text editor.  Similarly, if your ultimate goal is to create the 
source code for a program, a word processor is much more frustrating to use 
than a text editor (though it can be done).

If you're only doing small tasks, you can use either tool and "suffer through" 
the shortcomings associated with using the wrong tool for the job.  For larger 
projects, though, you should really use the correct tool, even if only for your 
own sanity.


___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] How to add AHCICD.sys in the auto check-list for US B BOOT?

[Bret Johnson]

Might it be possible to use DEVLOAD in AUTOEXEC.BAT instead of needing to load 
AHCICD.SYS in CONFIG.SYS?  You can do "automatic" IF/THEN things in 
AUTOEXEC.BAT but you really can't in CONFIG.SYS.  In addition, though, you will 
probably need some kind of utility that can detect whether AHCI is even 
enabled, and I don't know if such a utility exists.


___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] retro gamer review of FreeDOS 1.3

[Bret Johnson]

I heard/read somewhere that the "Runtime Error 200" was actually caused some 
sort of subroutine that was trying to figure out how fast the computer is.  
It's certainly ironic that it doesn't work on really fast computers since 
that's exactly the "problem" it's trying to address.

The other interesting thing about it is that in most programs there is no 
legitimate need to know how fast the computer is (the program is bloated and 
wasting time trying to figure out something it doesn't even need to know).  Of 
course, with some programs (like interactive games) the speed of interaction is 
critical, but those are the exceptions.  A well-written program (even an 
interactive game) wouldn't rely on a specific speed of computer, anyway, as 
long as the computer was some "minimum".

It's also interesting that CPU speeds are pretty much maxed out at a few GHz.  
For a long time it looked like they were going to be able to keep increasing 
CPU speeds, but they've pretty much reached the physical limits of electrical 
physics.  They've needed to figure out other ways of increasing speeds besides 
creating faster oscillators.

Some of the early attempts were things like pipelining in the CPU (performing 
two CPU instructions at once) and caching, but the most common solution 
nowadays is multiple cores/CPU's.  Of course, that takes special programming 
techniques and lots of complication at both the hardware and software level.  
They're also experimenting with things like optical and quantum computing, and 
even things like  "three-dimensional" CPU's where the different parts of the 
CPU send signals with back and forth with magnetic waves or photons instead of 
signals running along "wires".

The other interesting thing is that people are still obsessed with speed, but 
sometimes speed is your enemy instead of your friend.  I remember talking to a 
guy one time who used to be in the Air Force and he talked about how they still 
sometimes use prop-driven planes instead of jets because the jets are too fast 
to do the specific job they're trying to accomplish.

Anyway, just some passing thoughts. 


___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] I never saw one

[Bret Johnson]

>> Is it possible to have a ZZZ9: drive
>>  in DOS (or other many letter ID) ?
>
> unlikely. some DOSes allowed 0x40..0x59
> ie A..Z + @[]\^
>
> but none allowed anything other then x:

As Tom indicates, later versions of MS-DOS allowed up to 32 drive letters.  You 
set this up by using the LASTDRIVE=32 command in CONFIG.SYS (instead of the 
usual LASTDRIVE=Z or whatever).  The problem is that even though this let you 
have something like \: as a "legal" drive identifier, you can almost never get 
any programs to recognize it as such (and it can cause great confusion).  You 
can't even use it at an MS-DOS command-line to identify a file (I've tried), 
even in versions of MS-DOS where it is legitimate.

I read or heard somewhere that 4DOS implemented some special escape sequences 
or something you could enter at a command-line or in a batch file to identify 
such drives, but have never tried it myself.  There may be other ways to do it 
also, but I'm not sure.  It's best to leave it at 26.


___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] ECHO vs @ECHO

[Bret Johnson]

I normally don't use DOS < 3.3 myself, either.  But I do have programs that 
claim to work with DOS 3.0 or 3.1 so I want to make sure they actually work 
where they claim to.  I guess hardly anybody really uses DOS < 3.3 any more, 
except maybe the few people who still have working PC/XT/Jr hardware.


___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] ECHO vs @ECHO

[Bret Johnson]

> There is one other thing to try via v8power tools. Instead of using
> vgotoxy up | vecho /n /e, there is another combination to do it as
> well.
>
> echo off | vgotoxy up | vdelete
>
> Anyhow, vdelete is a far simpler program than vecho. You may even
> have better compatibility results.

I'll try it and see, but am still not expecting it to be a universal solution, 
especially for DOS < v3.3.

> However, you may be better off writing a HUSHECHO program that does
> all of this. It could test the DOS Version and perform any
> additional stuff required. As you find exceptions, just add a little
> more to it. Probably only be 100-200 byte com file total even with
> the exceptions. 

Unless I get a really strong urge for some screwy reason, I don't think I'll be 
writing a custom program for such a trivial and obscure issue. In fact, rather 
than fixing the screen, if I wrote anything I think it would be something that 
actually tries to manipulate the ECHO state (if that's even possible without a 
WHOLE lot of work).

But, I still think this provided an interesting discussion and generated some 
good ideas people may be able to use in other situations.  I definitely found 
it interesting how the different DOS versions handle something as seemingly 
benign as processing the ECHO command in batch files.

I'll probably end up just learning to live with the screen clutter and leave it 
at that.


___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] ECHO vs @ECHO

[Bret Johnson]

> Multi-booting all those OSes off a single partition is very *VERY*
> much a hard way of doing this.

Actually, no it's not.  It's fairly easy with System Commander.  And AFAIK, 
System Commander is the only multi-boot manager that works this way 
(manipulating the boot files instead of manipulating disks or partitions).  
Both approaches have advantages and disadvantages.

> VirtualBox is free. It runs DOS with aplomb. You could run all these
> DOS versions in separate VMs, with no overlap, and custom config
> files.

As are QEMU, BOCHS, PCem, etc.  All the VM's have advantages and disadvantages 
in various respects.  The way I have my system set up I only need one VHD and 
it will work with (almost) any VM, including VirtualBox, and a bunch of 
different versions of DOS.  In terms of the amount of work it takes to set 
things up, I think my setup is less work than creating 20 (or whatever) 
different VHDs (each for a different OS).  My setup is definitely less work 
than trying to track and maintain all the different VHDs to make sure they 
remain consistent with each other.

> You could have a separate D: drive on a separate virtual disk, with
> the programs you're testing in it.

That's what I do now (or at least can do if I want).  But, I can also put the 
test program on the common VHD if I want instead of a separate VHD (and if it's 
small enough I usually do that).  With your setup it MUST be on a separate VHD 
or I would need to copy it 50 (or whatever) times instead of just once.  So, my 
setup is more flexible in that sense.

> Or you could use VMWare Server, which is freeware, and in which this
> is a built-in facility.

In addition to the VMs mentioned above, I also have others including VMWare and 
DOSBox and do tests with all of them.  VMWare and DOSBox are somewhat unique in 
that they can mount physical hard drives instead of just virtual hard drives.  
That allows you to have similar setups in both a VM and on the real hardware 
(if you boot the real hardware to DOS, which I also sometimes do).

There are lots of different ways to "skin the cat" and there is not one 
"correct" way.  There are tradeoffs and problems with every approach.  But, for 
what I'm trying to accomplish, I think my setup is better (at least easier to 
track and maintain) than what you're recommending.


___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] ECHO vs @ECHO

[Bret Johnson]

Well, I've run some tests with V8 Power Tools and let's just say they are 
inconsistent.  In summary, the V8 Power Tools approach sometimes works and 
sometimes doesn't, so it's not a universal solution.  In fact, there doesn't 
seem to be a good, universal solution and I just may need to live with the 
annoying screen clutter.

I am doing these tests in a Virtual Machine (specifically PCem) and a 286 CPU, 
so I'm not testing with MS-DOS v7+ since that requires a 386+ CPU.

I have two batch files set up, one with the "one-liner" solution and the other 
with the "two-liner" solution:

TEST1.BAT
-
:Begin
  ECHO Off | VGoToXY Up | VEcho /N /E
  ECHO Test Line 1
  ECHO Test Line 2
:End

TEST2.BAT
-
:Begin
  ECHO Off
  VGoToXY Up
  VEcho /N /E
  ECHO Test line 1
  ECHO Test Line 2
:End

If I run either TEST1.BAT or TEST2.BAT with MS-DOS 3.0, 3.1, or 3.2, it crashes.

If I run them with MS-DOS 3.3 or 4.01 the session looks like this:

C:\>test1


C:\>  ECHO Test Line 1
Test Line 1

C:\>  ECHO Test Line 2
Test Line 2
Test Line 2

C:\>test2

Test Line 1
Test Line 2
Test Line 2

C:\>

If I run them in MS-DOS 5.0 thru 6.22 the session looks like this:

C:\>test1


C:\>  ECHO Test Line 1
Test Line 1

C:\>  ECHO Test Line 2
Test Line 2

C:\>
C:\>test2

Test Line 1
Test Line 2
C:\>

If I run them in DR-DOS 6.0 thru 8.0 the session looks like this:

C:\>test1

Test Line 1
Test Line 2
C:\>test2

Test Line 1
Test Line 2
C:\>

If I run them in FreeDOS 1.2 or 1.3 the session looks like this:

C:\>test1
Test Line 1
Test Line 2
C:\>test2
Test Line 1
Test Line 2
C:\>


As you can see, there are extra blank lines (though that problem is not a 
deal-killer), extra ECHO's, and extra DOS prompts (extra  keys being 
pressed) depending on the specific environment.  I think FreeDOS is the only 
one works the way I think it should (no extra "stuff" appearing on the screen 
anywhere).


___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] ECHO vs @ECHO

[Bret Johnson]

Thanks everybody for the input!  Lots of interesting suggestions/ideas.

I think the proposed solutions generally fall into four categories:

1.  Always use ECHO OFF without the @ and don't worry about it
2.  Try to fix the problem before it happens
3.  Just let the problem happen and "fix" the screen afterwords
4.  Create distinct AUTOEXEC.BAT files for every situation and don't
  try to create a "master" version

As far as I can tell, none of the suggestions will do #2 (at least not reliably 
in all cases).  I think almost every suggestion that tries to do #2 just 
replaces the unwanted "ECHO OFF" on the screen with something else unwanted 
(like an "@ECHO OFF" or a "CTTY NUL" or an "IF ...").

I'll try to address my thoughts on all of them received thus far in this single 
response.

*

Mercury Thirteen:

> Would it be feasible to throw together an "@ECHO.COM" application
> which would manually execute a normal "ECHO OFF" line if the DOS
> version is below 3.3 and simply terminate otherwise? The only caveat
> to this is that I''m not 100% certain that a command executed from
> within a .COM file from within a batch file like this would
> work back "upstream" and turn ECHOes off for the rest of the
> original batch file.

I thought of this, but unfortunately it won't work.  First of all, it needs to 
test for more than just the basic DOS version since things like DR-DOS and 
PTS-DOS (and even FreeDOS to a lesser degree) can get "weird" since they are 
not always as compatible as they should be.

In addition, you would still see the "@ECHO OFF" line, so all you're doing is 
replacing "ECHO OFF" with an errant "@ECHO OFF" and would still need to issue a 
real ECHO OFF (without the "@") to actually turn ECHO OFF.

An @ECHO.COM (or .EXE) file could be interesting, though, except it would 
actually need to legitimately tell the command/batch processor to turn ECHO OFF 
and I don't think there's a way to do that from inside an executable file.  It 
would be nice if there were some INT 21h functions to manipulate the ECHO state 
(and perhaps also other things like determining if you are running from a 
command-line or batch file or being EXEC'd from another program, or determining 
the state of the CALL stack if being run from a batch file, or other similar 
things) but none of that exists.

An executable file could manipulate the screen (similar to the V8 Power tools 
suggested below by Jerome) but since it can't actually manipulate the ECHO 
state it won't do any good.

*

Jose Senna:

> I have not used any DOS for some months but, as far as I
> remember, @ECHO OFF worked with DR-DOS 5.

I don't have DR-DOS 5 installed.  But I do have DR-DOS 6, 7, and 8 installed 
and the "@" trick does not work with any of those.  It's conceivable it works 
with DR-DOS 5, but I really doubt it.

*

Jim Hall:

> The simplest solution is to use ECHO OFF without the @ at the start
> of your BAT file. That will work everywhere. If you don't like
> seeing this line on the screen at boot, you could run CLS after
> that.

Running a CLS afterwords is sort of a "nuclear option" to fix a small problem.  
I normally want to see all the output of the various programs and CLS blows 
away everything, including things I want to see.  Jerome's V8 power tools 
suggestion below I think is a better option than CLS since it only does a 
"selective cleaning", but it's definitely more complicated than a simple CLS.

> I suppose another way to solve this is with a simple tool that
> detects the DOS version.

Unfortunately, this would not be a "simple" tool.  I've never seen a tool that 
reliably detects all the different manufacturers and versions of DOS.  If 
there's one out there, I've not seen it.  

> So your MKENV program would detect the DOS version and write a BAT
> file that looks like:
>
> SET VENDOR=MS
> SET MAJOR=5
> SET MINOR=0

That's what I do now (albeit manually) with the individual AUTOEXEC.BAT files 
(except I call the environment variables DOSMfg, DOSMajor, and DOSMinor), but 
same idea).

> If you need AUTOEXEC to do different things depending on the DOS
> version, you could carry the MKENV idea further by having a set of
> "stubbed" AUTOEXEC files like AUTOEXEC\MS50.BAT, and so on for other
> versions, that you could load as needed. But I'll leave that for
> you.

Again, that's basically what I'm doing now, except in the reverse order.  I do 
the OS-specific stuff in a small AUTOEXEC.BAT file and the jump to the "master" 
or "common" AUTOEXEC.BAT file.  Your suggestion is to try and create more 
levels of complication (more "levels" of batch files) instead of creating a 
"master" like I'm trying to do.  The problem with that is when I want to make a 
"global" change to what I'm trying to do (like add or remove one more utility 
to all OS's while 

[Freedos-user] ECHO vs @ECHO

[Bret Johnson]

This question is more about DOS in general than specifically about FreeDOS.  
But, there are enough experienced and creative users around FreeDOS that 
someone may be able to help me come up with a solution.

I have a large set of DOS environments I use for testing.  Basically, I have a 
bunch of different versions of DOS that I can boot to (MS-DOS, PC-DOS, FreeDOS, 
DR-DOS, from versions 3.0 to the latest of each).  DOS versions 1 & 2 were so 
lackluster that I don't bother even testing with them.  I have a copy of the 
commercial program called System Commander which allows me to install and boot 
all these different versions of DOS from a single partition on a hard drive.  I 
know there are other ways to accomplish the same feat, but I bought a copy of 
System Commander a long time ago so that is what I use.

I have all these DOS's installed on a Virtual hard drive so that I can run them 
in different Virtual Machines with different types of CPUs (from the lowly 8088 
all the way up to modern CPUs).  Again, this is a test environment so that as I 
write programs I can verify they work whenever and wherever they're supposed to.

On the Virtual hard drive part of what System Commander does as you boot is 
"restore" the hidden boot files (IO.SYS & MSDOS.SYS for MS-DOS, IBMBIO.COM & 
IBMDOS.COM for PC- and DR-DOS, or KERNEL.SYS for FreeDOS), along with the 
COMMAND.COM, CONFIG.SYS, and AUTOEXEC.BAT files so that the virtual machine 
boots with the correct test environment.

The problem is that the older versions of DOS don't work exactly like the newer 
versions, particularly when it comes to batch files.  For example, prior to DOS 
version 3.3 you couldn't CALL one batch file from another, and also prior to 
DOS version 3.3 you couldn't use the @ symbol at the beginning of a line in a 
batch file to hide the output of the line (sort of similar to what happens with 
the ECHO OFF you normally put at the beginning of batch files but the @ symbol 
only works for a single line instead of the entire batch file like ECHO OFF 
does).

So, I have a relatively short AUTOEXEC.BAT file set up for each OS I boot, 
which is unique to each OS.  The main thing this small AUTOEXEC.BAT does is set 
up some environment variables to identify the OS that booted which can be used 
later in other batch files.  At the end of the "simple" AUTOEXEC.BAT file, I 
then jump to a "master" AUTOEXEC.BAT file that is common to all the booted 
DOS's.  Because each version of DOS is a little different, the "master" 
AUTOEXEC.BAT file needs to do some "IF-THEN" scenarios based on which version 
of DOS is running.  I want the overall environment to be pretty much the same 
(as much as I can, anyway) no matter which DOS is running.  Having a "master" 
AUTOEXEC.BAT file lets me make most of my changes in one common place instead 
of needing to do the same thing a bunch of different times for each DOS version.

One problem I haven't figured out how to handle correctly is the ECHO OFF vs 
@ECHO OFF issue.  In older versions of MS- and PC-DOS (prior to version 3.3), 
and all versions of DR-DOS, the "@ECHO OFF" command does not work at the 
beginning of batch files.  You need to use a simple "ECHO OFF" instead.  If 
they see an "@ECHO OFF" they display an "unknown command" error (it tries to 
find an executable files called "@ECHO").  I'm trying to figure out a way for 
all the "common" batch files (all batch files other than the small AUTOEXEC.BAT 
file) to detect whether they can put the "@" at the beginning of the line or 
not to keep the screen from getting unnecessarily cluttered and confusing.  I 
cannot figure out a way to do this.  I'll go through some of the things I've 
tried (to no avail -- the all put "unnecessary stuff on the screen).

I've tried creating an ECHO environment variable.  With older versions of DOS:

  SET ECHO=ECHO OFF

and with newer versions of DOS:

  SET ECHO=@ECHO OFF

then at the beginning of all batch files I put a:

  %ECHO%

That works with older versions of DOS but not newer versions.  With newer 
versions, it sees the "%" at the beginning of the line instead of the "@" and 
looks for an executable file called "@ECHO" instead of seeing the "@" as the 
"hide this line" character.

Another option would be to create an actual @ECHO.BAT file and always put an 
@ECHO as the first line of all batch files, but that won't work either.  The 
"@ECHO OFF" line will show up on the screen (which is what I'm trying to 
avoid), and in addition you must CALL the @ECHO.BAT file instead of just 
running it.  And you can't use CALL in older version of DOS.

I've also thought of trying to use aliases/macros with ANSI or DOSKEY (or 
clones of those) but that won't work either.  ANSI will only create 
aliases/macros for single characters (not entire words like ECHO or @ECHO), and 
DOSKEY (or a clone) macros only work at the 
command-line and not in batch files.  Something like aliases in FreeDOS or 4DOS 
might work (I'm not sure), b

Re: [Freedos-user] Dual Boot winth Windows 98

[Bret Johnson]

>> The problem with this approach is that the programs are almost
>> never on C:, and they may not be on D: either.  The way I manage
>> that is to set myself up an S: ("System") drive which is where the
>> programs are located.  I use whatever tools I have available in the
>> DOS I'm using to do that (usually SUBST or SWSUBST, but e.g. in
>> DOSBox I need to use MOUNT).  I have the programs and batch files
>> set up to assume S: instead of C: for the default drive.
>>
>> That's probably too complicated of a setup for most people, but is
>> how I do it.
>
> Aha. That's a good idea. Thank you -- I may try that.

Just as an FYI, if you're going to do something like that, as you're booting 
you'll also want to set up environment variable(s) to indicate which VM you're 
in and possibly which version/manufacturer of DOS you're using.  You may need 
that in some of the batch files since there are certain times when things work 
a little differently depending on the operating environment.

The main one that pops to mind right now is that I have a batch file called 
ETHERNET that sets up the LAN packet driver.  When I'm running in "real" DOS, 
the driver that needs to get loaded is the one for the real NIC in the 
computer.  In a VM the NIC is always virtualized, and exactly which NIC is 
virtualized varies by VM.  The ETHERNET.BAT file looks at the environment 
variables to determine which packet driver to load.  The ETHERNET.BAT file will 
also unload the packet driver if it is unloadable (some are and some aren't).

I know I have a few other batch files where the operating environment makes a 
difference, though most of the time it doesn't matter.  The main VM I have a 
problem with sometimes is DOSBox, since it's actually a Virtual DOS rather than 
just a Virtual Machine, so (among other things) not all of the DOS internal 
structures are there which causes problems with some programs.


___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Dual Boot winth Windows 98

[Bret Johnson]

> Small primary FAT16 partition with FreeDOS. Bigger primary FAT32
> partition with Win9x. Then an extended partition, with some logical
> drives in it, which will be visible to both.

Even in Virtual machines, I always set up very small "boot drive" (usually only 
a few MB) as C:.  It only contains the things required to boot and a few basic 
utilities (including a simple text editor).  All of the useful programs are on 
a separate drive (usually D:, but it depends on the specific environment).  
That way I only need to manage one copy of all the programs and can use them 
consistently no matter how DOS booted.

The problem with this approach is that the programs are almost never on C:, and 
they may not be on D: either.  The way I manage that is to set myself up an S: 
("System") drive which is where the programs are located.  I use whatever tools 
I have available in the DOS I'm using to do that (usually SUBST or SWSUBST, but 
e.g. in DOSBox I need to use MOUNT).  I have the programs and batch files set 
up to assume S: instead of C: for the default drive.

That's probably too complicated of a setup for most people, but is how I do it.


___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Dual Boot winth Windows 98

[Bret Johnson]

I still have a computer (not hooked up to a keyboard or monitor any more) which 
uses an old commercial program called System Commander.  System Commander would 
let you load several different versions of DOS on the same C: drive.  I think I 
have about 10 different versions of DOS on the same C: partition (different 
versions of MS-DOS, PC-DOS, DR-DOS, etc.).  I don't remember the exact details, 
and I don't remember if it works with FreeDOS, and it would be a hassle to get 
the system booting again to see exactly what all I have on it.

What System Commander does is make copies of the hidden system files needed to 
boot (IO.SYS & MSDOS.SYS or IBMBIO.COM & IBMDOS.COM), along with COMMAND.COM, 
CONFIG.SYS, & AUTOEXEC.BAT for each version of DOS.  When you boot, you select 
from the System Commander boot menu exactly which version you want to load and 
it does all the manipulation of the hard drive needed to accomplish that 
(backups and copies the necessary files) and then finishes booting.  If you're 
wanting to experiment with several different versions of DOS, I found that the 
best program to use.

Since you're only wanting to experiment with two DOS versions, you probably 
don't need anything as sophisticated as that.  Something like Eric's METAKERN 
might work (I've never used it), or the other suggestion of using two separate 
partitions would also work but you would probably also want some kind of boot 
manager to go along with it.  IIRC the Ranish Partition Manager would let you 
build/manipulate the partitions and also provided a simple boot loader.

I personally use a commercial program called BootIt to manage my booting with 
DOS, Windows, and sometimes Linux.  I know lots of people use *nix utilities 
GRUB or LILO but I have never used those myself.  I also know there are other 
boot managers available out there but haven't used any of them.

Bottom line is that you can do it and there are several ways it can be done, 
and you'll get lots of opinions on the "best" way to do it.  I wouldn't suggest 
doing it the way I do (with commercial programs), though.  I use commercial 
programs because at the time (many, many years ago) the available free programs 
really didn't do what I needed.  I think you can find something free today to 
do what you want.


___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Difficulty with serial communications

[Bret Johnson]

> For what it's worth, the raspberry pi is an opensource board.  That
> means you could easily build your own pi using components from the
> original, and have a company produce the board for you.

As he was intimating, in an industrial environment there are many more factors 
to consider than "producing a board".  In industrial environments you need to 
worry about all kinds of environmental things: EMI/RFI, power fluctuations, 
vibration, shock, temperature, dust, chemicals, volatility, etc.  E.g, in some 
environments you aren't allowed to use any type of fans for cooling or the air 
has "contaminants" (like natural gas or grain dust) which makes it potentially 
explosive so the equipment must never generate any sparks.  In addition, the 
systems must be highly reliable -- running 24x7x365 with no crashes or reboots 
or software upgrades needed.  "Hobby-quality" devices simply won't work.

> On the other hand, I wasn't aware USB had so many issues in noisy
> environments, since they're essentially fast serial ports, I'd
> expect them to be the same as regular serial ports ...

Uh, no.  Even though both they both have the word "serial" in them, USB and 
RS-232 are not even remotely the same thing.  Going back to the environmental 
issues above, I know some USB implementations that have used the USB 
software/protocols but use completely different kinds of cabling and connectors 
which are far more robust than the standard USB hardware.  Of course, that is 
then custom, not compliant with the USB standards, and not necessarily a viable 
long-term solution.


___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Difficulty with serial communications

[Bret Johnson]

I don't know how much you're willing to rewrite your program, or how much 
you're willing to make fundamental changes to how it works since it may corrupt 
what you've already done, but this solution may be worth a shot.  I'm doing 
something similar in some of my other programs (not related to serial ports).  
This is sort of a variation of what Eric suggested earlier in the thread, but 
instead of constant polling it is still interrupt driven so it does not consume 
the entire CPU like a constant polling loop would do.

Instead of relying on the normal serial port IRQs, just disable those IRQs 
altogether.  Instead, setup and use INT 70h/IRQ 8 to generate IRQ's at 1024 Hz 
(you can even set them up to go faster or slower than 1024 Hz, but that may not 
be necessary).  When you receive the IRQ, gather ALL the data from ALL the I/O 
ports you care about (all the serial ports).  Particularly if your serial ports 
are the newer ones that have some sort of internal buffer (more than one byte 
like the original serial ports had) I don't think you'd ever miss any data.

To speed up the processing even more, instead of completely processing the data 
as soon as you received it you could just store the data received in some sort 
of buffer and process it outside of the IRQ handler (or at least after you had 
issued the End-Of-Interrupt for IRQ 8 so you're not "hanging" the machine).

That would avoid all the issues with APIC and/or PCI programming, IRQ sharing 
(at least on the serial ports, but you will still potentially need to share IRQ 
8 which is one reason why you shouldn't change the frequency from the default 
of 1024 Hz), etc.  As long as all the serial ports use "regular" I/O ports 
(PIO) instead of MMIO you shouldn't have any issues getting the data.  But, 
there are ways to get the data from MMIO without using DPMI if that is required.


___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Difficulty with serial communications

[Bret Johnson]

> One small correction here.
>
> Yes, there are 16 IRQ lines, only 9-16 are not generably accessible,
> so the pc or dos or something in hardware (not sure which) uses IRQ
> 2 to reach IRQs 9-16.  I was able to trick a couple network cards
> into working for me by using irq 9, but then setting the software to
> IRQ 2, since it didn't have IRQ 9 as an option.

Yes, there are LOTS of details and complications associated with the IRQs that 
you may need to work around.  The IRQ 2 cascade to the second PIC is one of 
them, but there are also others like some of the IRQs being dedicated (and even 
hard-wired) on the motherboard to certain devices.

If you're going to be messing around with IRQ's, and especially if you're going 
to re-route them, there's a lot more information needed than can be included in 
a simple e-mail.

I think the overall goal here is to have the PCI serial port look like a 
"regular" serial port (probably COM1 or COM2) so the original software doesn't 
need to change.  Exactly how to make that happen is the question.  If the PCI 
card came with some sort of configuration utility it may be fairly easy to do.  
If not, then things get much more complicated.


___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Difficulty with serial communications

[Bret Johnson]

> If for example there's a TSR or something which can say route IRQ19 to
> IRQ3 I think that would do for the forseeable future, but I don't even
> know yet if that makes sense.

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 don't think you'll find an existing TSR that will do what you want.

You may also just be able to share IRQ 3/4 between several applications.  It is 
possible to share IRQ's if ALL the software is written correctly, but most 
software is written assuming only one program manages each IRQ.


___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Cutemouse /O OR keeping your source code secure

[Bret Johnson]

> a) in germany we have a saying "Kein Backup, kein Mitleid" which
> translates roughly to "no backup, no pity"

> b) one of the advantages of open source software is that you have
> automatically backups on a bazillion of computers.

It happened a long time ago, and I actually did have backups that all managed 
to get messed up around the same time.  I was fortunate that MOUSKEYS was the 
only program I lost -- I managed to salvage all the others.  I don't do things 
that way any more.


___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Cutemouse /O

[Bret Johnson]

> CuteMouse doesn't have any of these "elevating" resources. But
> whatever the mouse sends is passed over to the application. In DOS
> it is up to Appication to uses it.

Not quite.  CTMOUSE does support a mouse wheel, but it has a "special" way of 
accessing it in the Mouse Driver API (INT 33h).  The "regular" API (as defined 
by Microsoft) doesn't include access to the wheel, but CTMOUSE has provided an 
API extension that does.  It is described in the WHEELAPI.TXT file that comes 
with the CTMOUSE documentation.  There are only a few DOS programs out there 
that are new enough to even know about the API extension, and even fewer that 
actually use the wheel for anything.  In fact, there aren't even a lot of DOS 
programs that use more than one button.

As also noted, there is a special series of "hoops" that CTMOUSE must go 
through to "turn on" the wheel in the mouse hardware.  CTMOUSE does that (if 
the mouse supports it).  There is also a second set of "hoops" that CTMOUSE 
could go through to enable the second wheel (on mice that have a second wheel) 
and as many as 5 buttons (on mice that have more than three buttons).  CTMOUSE 
does not currently jump through that second set of "hoops", and the API 
extension that currently exists would not support a second wheel or two more 
buttons even if the hoops were jumped.  It would be possible to modify the 
mouse driver API yet again to support those extra buttons and the second wheel 
if somebody wanted to do that.

BTW, by USBMOUSE program (which enables USB mice to work in DOS) supports both 
sets of hoops if CTMOUSE (or some other mouse driver) is ever upgraded to 
support them as well.  If you're using the BIOS to support USB mice at boot 
time (which is what most people do), you will probably never get the wheels for 
a USB mouse to work in DOS.  The BIOS doesn't jump through the hoops.

There is a program already out there that lets you use the mouse wheel with 
almost any DOS program (similar to what my MOUSKEYS program does with the 
movements and buttons on the mouse).  It's called WheelK and is available here:

http://ninho.users.micso.fr/wheelk

It requires CTMOUSE (the only DOS mouse driver available that includes the 
wheel API extension), along with either a PS2 mouse that has a wheel or a USB 
mouse that has a wheel along my USBMOUSE program (and the supporting programs 
it takes to get USBMOUSE to work properly, which can be many).

As an FYI, I would like to add wheel support directly to MOUSKEYS someday, but 
that is VERY low on my priority priority list right now and don't have hardly 
any time to work on any of my programs.  The WheelK program has some 
limitations that wouldn't necessarily be there if the functionality were moved 
up into MOUSKEYS.  Also, through a series of unfortunate hard-drive problems 
and corruptions, I managed to lose the source code for MOUSKEYS.  So, in order 
to "upgrade" MOUSKEYS to support wheels, I would need to start by recreating it 
from scratch again (basically, I would need to reverse-engineer my own program 
since I lost the source code).

Bottom line is you CAN use a mouse wheel in DOS today provided you have the 
correct hardware and software installed (and getting it all installed is not 
easy or trivial).  But, wheel support in DOS is still a long ways from being 
what it could (or even should) be.


___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Question about FreeDOS 3.0

[Bret Johnson]

> MBR and GPT are partitioning systems. MBR can be used on any disk up
> to 2TB but not more.
>
> GPT can be used on any size of drive but must be used on drives bigger > than 
> 2TB.

Close, but not quite accurate.  MBR can be used on any disk which contains up 
to 2^32 (4G) *sectors*, not necessarily 2T *Bytes*.  It is true that most disks 
use 512 Bytes/sector (which equates to 2 TB), but not all do.  E.g., optical 
media (CD/DVD/BD) use 2k Bytes/sector), and large modern hard disks use 4k 
Bytes/sector.  Oftentimes there is firmware in the 4k hard disks to 
virtualize/emulate 512 bytes (they usually call this 512e).

We can have a much lengthier discussion about the practical implications of all 
this (and there are plenty of them), but the point is that 4G sectors does not 
*necessarily* equate to 2T Bytes.


___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] MKEYB related stuff

[Bret Johnson]

> how would MKEYB detect that code point 213 represents dotless i or
> €, or what the correct code point for € is in the new selected
> codepage? and how about äÄáàâÁÀÂ?

The same way it knows that Code Point 213 is the Euro symbol in Code Page 858 
-- by the programmer (you) doing the research and building the appropriate 
logic into the program.

> a pop up messagen Box "you have choosen to change the codepage, so €
> no longer looks like €" ?

That is certainly one possibility.  You could put a table of Layout/Code Page 
information in the MKEYB documentation.  You could have a command-line option 
in MKEYB that lists all the supported Layout/Code Page relationships.  You 
could talk a little bit about Code Pages and DISPLAY and MODE CON CODEPAGE and 
... in the documentation.  You could mention that there are other possibilities 
besides MKEYB that are more comprehensive, but MKEYB uses less memory because 
it specifically isn't comprehensive.  At installation time, it could detect the 
current Code Page (that's pretty easy to do) and if it's the wrong one, do 
something like, "The GR keyboard layout will only work correctly with Display 
Code Page 858 but you are currently using Display Code Page 437.  As a result, 
some characters typed from the keyboard may be displayed incorrectly on the 
screen.  Are you sure you want to continue installing MKEYB?"

You could do any or all of those things, and there are probably other 
possibilities as well.

> in fact MKEYB already warns the user by showing a  ý if the wrong
> codepage is selected.

A warning is something that happens before there is a problem, not after.  
MKEYB can know ahead of time that there will (or at least may) be problems.  
The user seeing the wrong thing appear on the screen with no explanation from 
MKEYB is not a warning.  It may make the user think DOS is "broken" when it's 
not, or that they did something wrong when they didn't.  MKEYB did the wrong 
thing, not the user.

> in fact an american who has never seen an international US-ASCII
> keyboard (or even an Euro note) is probably not the right person to
> argue here.

When you don't like the message, you shoot the messenger?  What we're talking 
about here is a much larger issue than the Euro symbol -- the Euro symbol is 
just a specific example we can use to discuss the larger issue.


___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] MKEYB related stuff

[Bret Johnson]

> Only highly desirable to those who don't use screen readers.
>
> Using a graphical mode but simulating a text mode would not work for
> anyone using a screen reader, since there's no possible way for the
> screen reader to "read" the graphical screen.

Actually, there is a way.  I've never used a screen reader, but if the screen 
reader "reads" the screen using INT 10.08 instead of directly reading video 
memory, INT 10.08 could be emulated by the graphical driver.  INT 10.08 will 
"read" characters from both graphics mode and text mode screens, but if INT 
10.08 is emulated properly by the CON driver it could return the appropriate 
data.

I'm not necessarily suggesting that this is a good idea, but it is possible.

> Emulating a text screen certainly isn't the same as actually using a
> text screen, and if there aren't methods for the screen reader to
> know what's supposed to be on the screen, then there's no way for
> the screen reader to read said characters.  Your solution might
> work, but it would break many things, (not just screen readers). 

You're correct that it could potentially break lots of things.  The good thing 
about DOS is that you can do almost anything.  The bad thing about DOS is that 
you can do almost anything.


___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] MKEYB related stuff

[Bret Johnson]

> send a keyboard code �

That doesn't always work work.  Let me use a Star Trek analogy (I hope most 
people can relate to this).

Let's say someone in the Enterprise wants to get down to a planet that the Star 
Ship is circling.  There are two ways they can do this.  One is to use the 
Transporter, where they just suddenly "appear" on the planet.  This is like the 
"stuff the keyboard buffer with an ASCII code" scenario.  The ASCII code just 
"suddenly appears" in the keyboard buffer with no intervening steps.  However, 
what appears in the keyboard buffer is an ASCII Code AND a Scan Code.  Since 
you don't know the "correct" Scan Code to use, you just make one up.  In the 
Transporter Scenario, this would be like the Transporter correctly transporting 
the upper half of your body but always making the lower half of your body 
always be that of a chimpanzee.  In some (in fact, most) cases, that is "close 
enough".  In other cases, it isn't.

The other way you can get from the Enterprise down to the planet is with the 
Shuttle.  This is comparable to the SCANCODE method of "typing" -- "taking the 
long way home".  It is slower and more cumbersome, the end result is the same 
(if it is done correctly), and you always get to the destination fully intact.

Now, let's take the analogy one step further.  Let's say that instead of trying 
to get down to a planet, you are needing to investigate some "space anomaly" 
that is not a solid planet you can walk on.  In that case, you would NEVER use 
the Transporter -- that is simply the wrong tool.  In such a case, you would 
NEED to take the Shuttle instead.  That is analogous to needing to "type" 
something like Pause or Ctrl-Alt-Del or PrtScr or CapsLock which have nothing 
to do with ASCII codes or the BIOS keyboard buffer.

The Shuttle (like SCANCODE) will get you to where you need to go all the time, 
while the Transporter (like ASCII codes) have many more limitations on when and 
how they can be used.  The ASCII method will work 99% of the time, SCANCODE 
will work 100% of the time.  Sometimes, 99% is good enough and sometimes it 
isn't.

>> this dynamic codepage switch on keyboard that MKEYB does not
>> implement (afaik).

> it doesn't. Does FD-KEYB?
> if so, on what conditions (as explained above)?

Yes, it does.  As already explained, INT 2F.AD81.  That's exactly what the 
function is for and why MKEYB is supposed to monitor it.

We have here a similar situation as we do above with SCANCODE and the Star Trek 
analogy.  What FD-KEYB does is the "correct" way to do it, but it is more 
complicated and cumbersome and will always work (as long as everybody "follows 
the rules").  What MKEYB does will work 99% of the time (as long as the user 
never needs/wants to change keyboard layouts or Code Pages).  For most 
users/applications, that is good enough.  For others, it isn't.

> Norton Commander and friends look horrible in codepages
> different from 437. but this should be the problem of Norton (who
> wants to display something), not the keyboard driver.

But MKEYB is wanting to display things on the screen, too, so it is the EXACT 
same problem.  Norton didn't do it correctly, and neither does MKEYB.

>> When will the hot codepage change happen? The preferred way: the
>> user issues a CHCP DOS call and NLSFUNC is loaded.

> so not a keyboard driver problem.

Yes, it is.

>> Another popular,
>> memory saving, but inconsistent manner: issue a MODE CON CP
>> SELECT.  

> not a keyboard driver problem either.

Yes, it is.

> under
> what circumstances this is relevant so we can reproduce the problem
> and it's solution.

We've already showed you the problem and how to fix it.  With MKEYB, the Euro 
character is not generated correctly unless the Code Page is one where the Euro 
symbol is ASCII 213.  This is true for some Code Pages but not others.  That's 
a problem which you can easily reproduce yourself.  The solution is for MKEYB 
to be aware of the current Code Page instead of ignoring it, or at least 
warning the user that if they use the wrong Code Page some things may be 
displayed incorrectly.


This actually reminds me of another thing that has been in the back of my mind 
for a long time.  Normally, when the screen is in a text mode the mouse cursor 
is just a block that is the reverse color that it would be if the mouse cursor 
wasn't there.  As you move the mouse around the screen, all that changes is the 
color of a single character (the character that the mouse cursor is pointed 
at).  When the screen is in a graphics mode, the mouse cursor is (usually) an 
arrow.  In DOS programs, the size and shape and color of the mouse cursor is 
(normally) controlled by the mouse driver, which for FreeDOS is usually CTMOUSE.

In the past, I've seen programs (including some later versions of the Norton 
Utilities) where even in a text mode the mouse cursor was an arrow instead of 
just a colored block.  There weren't a lot of programs that did this, but ther

Re: [Freedos-user] changing keyboard layout after booting from CD-ROM

[Bret Johnson]

> Well, a summary for both: I was thinking of providing an interface
> to actually return the KeybCB, you'd have all the information (but
> would be given the chance to mess around with it) :)

> With that you have the entire Scancode-to-codepage (rather than
> ASCII-to-scancode).

Thanks, Aitor.  I think that will work for what I'm doing.

For older versions of FD-KEYB and KEYB programs from other places (including 
MKEYB),  I was thinking of maybe doing something with an Environment variable, 
similar to what FreeDOS has implemented with the COUNTRY environment variable.  
I was thinking of an environment variable either called KEYBID or KEYBLAYOUT.  
The contents of the variable would be the two-letter keyboard code followed 
optionally by the ID.  Some examples:

  KEYBLAYOUT=US
=US103   (same as US)
=GR
=GR129   (same as GR)
=GR453

With that, there is a way for a program to figure out what the current keyboard 
layout is if it needs to know for some reason (like some of mine do).  This 
variable could be set in the FreeDOS installation program or by the user if the 
user wants to "automate" things sufficiently.  I think adding the special 
FD-KEYB interface would still be valuable though, since it provides MUCH more 
information than just the ID.  The fact that it will rarely get used is not a 
valid reason to not implement it.

> Note that may take a while, I am not being able to program so
> actively as I used to in the past. :(

I'm in the same situation.  I have way too many complicated things I want to do 
but have very little time to work on them. 


___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] MKEYB related stuff

[Bret Johnson]

>> So you made up your own GR mapping that is different than everybody
>> else's (there is a "Tom's custom GR keyboard layout")?

> of course not.

Exactly.  This was me responding to you saying there were no standards, but you 
followed a standard (whether de facto or explicitly documented, still a 
standard).

> that's true(and a bug). for whatever reason MKEYB GR will generate €
> with AltGr+5. (most likely because that's the € position on my
> US-ASCII keyboard, but that's ~20 years back in time)

That's quite possible, but I don't think it was a US-ASCII keyboard.  I've 
never seen a Euro symbol anywhere on any of my US keyboards.  In fact, since 
the normal situation in the US is a US keyboard layout with Code Page 437 
(which doesn't even have a Euro symbol), a Euro symbol printed on any of the 
keys would be, at best, misleading.  In addition, if your right-Alt key is 
labeled "AltGr" instead of just "Alt", it's not a US keyboard, either (US 
keyboards don't have an AltGr).  Most US users don't even know what an AltGr 
key is.  You probably had a "Germanized" or "Europeanized" keyboard.

> I took this opportunity to fix the € sign in all supported keybords,
> at least I hope so.
>
> now they will generate 213 with AltGr+E, whatever the codepage. with
> a proper codepage, this will look like €.

Again, you're misunderstanding the problem.  You shouldn't just automatically 
generate an ASCII 213 no matter what the Code Page is -- you should only 
generate an ASCII 213 when that's the Euro character on the Code Page currently 
in use.  ASCII 213 is the Euro character on some Code Pages (like 858) but not 
on others (like 437 & 850).  There are also Code Pages where there is a Euro 
character but it's not ASCII 213.  To be fair, it's unlikely that a user would 
be using anything other than 437, 850, or 858 with a GR keyboard, but you just 
can't assume that ASCII 213 is always the Euro character even with those three 
Code Pages.


___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] MKEYB related stuff

[Bret Johnson]

> it's not uncommon  for germans to use US-ASCII keyboards (QWERTY).
> other use german keyboards (QWERTZ).

Yes -- lots of countries have multiple keyboard layouts.  Even in the US with a 
standard QWERTY layout, you can use a keyboard driver that implements it as 
straight US or as US-International (UX) where there are dead-keys.  In the US, 
there are also the Dvorak, Dvorak Left-hand, Dvorak Right-hand, and Colemak 
keyboard layouts that are at least somewhat common (common enough the Microsoft 
and Aitor/Henrique made drivers for them, anyway).

In any case, the relationship between the keyboard layout and the Code Page is 
still there and will NEVER go away.

> in both cases the codepage is 437 (BIOS default) or 858 (with €),
> but Y and Z are swapped.

The Code Page could be lots of other things as well -- including 850 (the 
Primary Code Page that was originally used with GR).  At least according to the 
documentation, the FD-KEYB GR ill also work correctly with Code Pages 852, 853, 
859, 30009, and 30020.  I've never actually tested all those possibilities, nor 
do I know what all the differences in the Code Pages are.  But FD-KEYB will 
work correctly with several different Code Pages.

> what you want is "GR" or "FR", which is not avaliable in a
> documented way.

So you made up your own GR mapping that is different than everybody else's 
(there is a "Tom's custom GR keyboard layout")?  I know it's possible to create 
a totally custom keyboard layout like that, but that's not what you did.

Going back to the KEYB - Code Page relationship, I just ran a little "Euro 
test" to see how MEKYB and FD-KEYB handle the Euro symbol with Code Pages 437, 
850, and 858.  At least in modern KEYB drivers, you are supposed to be able to 
generate the Euro key using AltGr-E.  Of course, Code Pages 437 and 850 don't 
have the Euro symbol at all (they were both invented before the Euro symbol 
even existed), but Code Page 858 does.  With MKEYB GR loaded, you can't 
generate a Euro symbol with AltGr-E no matter what Code Page is installed.  
MKEYB simply assumes the Code Page is either 437 or 850 (I'm not sure which) so 
it will NEVER generate a Euro with AltGr-E because it (incorrectly) doesn't 
think it ever can.

FD-KEYB GR will generate a Euro if Code Page 858 is installed, but will not if 
437 or 850 is installed.  That is how it should work.  And, if FD-KEYB GR is 
installed first and then the Code Page is changed afterwards, it recognizes the 
change as it should and generates Euro symbols when it can using AltGr-E.  You 
can also generate it with the Alt-NumPad method.

In addition, if you have a Euro symbol on the screen (such as one generated by 
FD-KEYB GR, using Code Page 858, with the AltGr-E method), and then change the 
Code Page to something else, the Euro symbol changes to something else.  If you 
change the Code Page to 850, the Euro symbol becomes a "dotless i".  If you 
change it to Code Page 437, the Euro symbol becomes one of the box-drawing 
characters.

Code Pages and Keyboard layouts are completely intertwined with each other and 
are not independent.


___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] MKEYB related stuff

[Bret Johnson]

> the user told you to type ASCII 13. why don't you 'type'  0x13 using
> INT16, AH=05h? use scancode 0x02 and send complains to me?

I'm not actually "complaining" about MKEYB since KEYB is available and does 
things "correctly" -- so there's no need for me to use MKEYB.  In fact, as a 
user, I live in the US and there's no need for me to even use FD-KEYB except 
for testing.

Why would I assume I should use Scancode 02h and not some other Scancode?  
That's the point -- in at least some cases, the user would also need to tell me 
which Scancode to use, but they can also JUST tell me the Scancode since I 
don't even care about the ASCII code.  Some programs treat Ctrl-M very 
different than Enter while others don't know the difference.  With SCANCODE, 
the user can tell me to "type" Enter or Ctrl-M and it does EXACTLY that.

Again, what I'm trying to do is make it easier for the user, not necessarily 
easier for me.  You can also provide the Scancodes directly to SCANCODE if you 
want (the very first versions of SCANCODE from a long time ago required that).  
The ASCII codes are there to make it easier for the USER to use the program.

> in addition, many keyboard handlers were able to produce 'keys' by
> holding down ALT and hitting 3 decimal keys to produce a 'ASCII'
> code.

I think they all do that (or at least should do that).  SCANCODE will "type" 
the keys that way also when it's required (like when it doesn't think there's 
another keystroke combination on the keyboard that will work).  You  can also 
tell it specifically to type as an Alt-NumPad combination.

SCANCODE is actually far more flexible in what you can do with it than the 
other keyboard-stuffing programs.

> the best solution that "ÄÖÜà" survives the the back and forth
> translation is to use INT 16, AH= 5

No, not unless you (in at least some cases) also provide the appropriate 
Scancodes to go along with the ASCII codes.  I also know some programs will 
accept almost any Scancode (it doesn't even need to be "correct").

> as there are no standards about 'keyboard translation tables', you
> would have to carry all this information in your SCANCODE tsr.

There are no standards about how the translation tables are laid out, but there 
are absolutely standards about what each keyboard layout is supposed to 
accomplish, which is what matters.

SCANCODE doesn't actually need to keep the information in the TSR itself.  The 
Scancodes are stored in a buffer, and they are "typed" later as they are 
needed.  After all the keys have been "typed", SCANCODE removes itself from 
memory when it detects that it is safe to do so.  SCANCODE can "type" the keys 
milliseconds or months later than when the TSR is installed in memory.  The TSR 
monitors things like screen contents and time delays and even other keystrokes 
so the keys are "typed" at the correct time.

So, the installation part of SCANCODE needs to know the ASCII-to-Translation 
tables, but the TSR itself does not.  In addition, this means that the 
state/environment of the computer (including things like the current keyboard 
layout or code page) may be different when the keys are "typed" than it is when 
the TSR is installed into memory, and the directions the user provides to 
SCANCODE as to what Scancodes to type when need to take all that into account.

SCANCODE can do anything a keyboard-stuffing program can do (at least any that 
I've seen), but it doesn't work the other way.  SCANCODE can also be difficult 
to use, and allows you to automate almost any process that normally requires 
you to sit in front of a keyboard and "babysit".  The way SCANCODE does things 
is not the WRONG way to do them -- it is certainly different than what you're 
used to, but is also far more powerful.

Allowing the user to enter ASCII codes as input parameters just make it easier 
for the USER.

> I still think that
>
>   SCANCODE some options   'a'
>
> should send 'a' to my program, whatever the codepage is.

It will, but it does it by "typing" the appropriate keystrokes from the 
keyboard (whatever those are) instead of just sending an "a" with an arbitrary 
Scancode attached.  For example, if the keyboard is currently in Foreign mode 
where there is no "a", it can temporarily switch the keyboard into English 
mode, type the "a", and switch back to Foreign mode again, or it can do the 
Alt-NumPad thing, or even something else.  It simulates exactly what you would 
do if you were sitting at the keyboard, not what happens after the computer is 
done "processing" and "translating" what you would do if you were sitting at 
the keyboard.  Those are very different things.

In many cases it doesn't matter which way you do it, but in other cases it 
does.  And when it does matter, SCANCODE is the only program that will work.

> good luck with that.
> I don't think that is solvable in 8-bit land. and xxDOS is very much
> 8-bit land.

It's already done.  SCANCODE has been doing it for years.  It is not 100% by a

Re: [Freedos-user] MKEYB related stuff

[Bret Johnson]

> codepage is a display thing, essentially it's the table how to
> convert 8-bit bytes into a visable character set, and mostly
> unrelated to the way the keyboard driver converts scancodes into
> bytes.

The Code Page and the Keyboard layout are not unrelated at all -- they are 
HIGHLY related.  Mateusz provided a Polish example, but probably the more 
common one is the Euro symbol.  Cod Page 850, which was the "original" one for 
western Europe, didn't have a Euro symbol -- the Euro didn't even exist when 
when the Code Page was first developed.  Code Page 858 is Code Page 850 with 
the "dotless i" (ASCII code 213 or D5h) character replaced by the Euro symbol.  
In other Code Pages the Euro symbol is not in the same place as it is on 858, 
and many Code Pages don't have the Euro symbol at all.  KEYB needs to know what 
ASCII code is (or even if there is one on the current Code Page) for the Euro 
symbol if the user presses the appropriate keys to generate the Euro symbol.  
US/English-only users almost never even need to worry about these kinds of 
things.  BTW, there are also Code Pages for printers which are managed by 
PRINTER.SYS, but that is even a much bigger can of worms than keyboard layouts 
and display Code Pages.

> of course a brasilian KEYB might produce different values for á then
> a french KEYB (I don't know), but they still produce the same value
> consistently.

No, they don't, unless they are using the same Code Page.

> please provide an example where this is necessary AND plausible.

See above.  A user who speaks/writes in multiple languages would need/want 
something like this.  E.g., Thraex, who has been helping some people (including 
me) recently with language translations, speaks/writes English, French, and 
Turkish.  I've never inquired of him exactly how he manages the different 
languages on the same computer (and he may not even do that in DOS -- I'm not 
sure).  Even though the vast majority of users will not have issues, there are 
some users who would need/want the ability to change things around.  In my 
case, I swap things around for testing to try and make my programs are 
"international friendly" if there's a way to do it.  I wasn't as concerned 
about this in the past as I am now, but it seems like a good way to go.

> nope. you intend to do "ASCII-to-Scancode" lookup, then feed these
> scancode to the KEYB program, in the hope that this KEYB program
> converts it back to the same ASCII character that you started with.

Do it merely "hoping" that it will work?  I need to KNOW it will work before I 
start "typing" anything that can potentially screw up something the user is 
doing.

> there's a BIOS call for this:
> KEYBOARD - STORE KEYSTROKE IN KEYBOARD BUFFER (AT/PS w enh keybd
> only) ...

Uh, no, that won't help.  That provides a scan code AFTER it has already been 
pressed, and only works with scan codes that produce ASCII codes -- not all of 
them do.

Plus, you can have situations where there is not a unique set of ASCII/scan 
code combinations.  E.g., ASCII 13 (Carriage Return) can be generated by Enter, 
Grey Enter (on the NumPad), Ctrl-M, Alt-013, and maybe other ways too.  If the 
user tells me to "type" an ASCII 13, which key(s) do I use?

> otherwise you have to implement what the KEYB program does in
> reverse direction. not only different scancodes with different shift
> states, but also dead keys: á is produced by hitting ´, then a; à is
> produces by holding SHIFT, hitting `, hitting a, releasing SHIFT.
> for the german keyboard at least ;)

Exactly.  That's why I need to know what the keyboard layout is, including 
things like dead keys.  There are also some keyboard layouts with more than one 
mode (like various Hebrew, Cyrillic, & Greek ones) where there is a 
"Latin/English Mode" and a "Foreign Mode" and pressing the "a" key when it's in 
Foreign Mode doesn't generate an "a".

> yes that's complicated. how about sending 'Z' to the program?

Because some programs don't look at the "Z" -- they look only at the scan code 
and don't even care about the "Z".  You're correct that most programs only look 
at the "Z", but SCANCODE will work both with programs that do and those that 
don't.  SCANCODE can even "type" the correct keystrokes it takes to switch the 
keyboard between the English and Foreign modes (Ctrl-Alt-F1 & Ctrl-Alt-F2) 
which you can't do with ASCII codes.

> there are enough 'non-controversial' keys to use for hotkey; just
> use B-X and avoid Q.

No, there are enough controversial keyboard layouts to make it a big problem.  
The main keyboard layouts I'm aware of that are VERY different than "common" 
keyboards are Dvorak, Dvorak Left-hand, Dvorak Right-hand, Colemak, Bulgaria 
(BG) 241, and Turkey (TR) 440.  They are not commonly used, but there are DOS 
drivers for them (in FD-KEYB) and they are used by some people.  There are also 
keyboards where even the number keys at the top of the keyboard are different, 
not just the letter keys.

Re: [Freedos-user] changing keyboard layout after booting from CD-ROM

[Bret Johnson]

Thanks for the info, Aitor.  It is indeed ugly, but doable.

I was also looking at the source code for FD-KEYB, and it looks like you have 
provided several extended functions for INT 2F.ADxx that aren't listed in RBIL. 
 Would it be possible to add another one that would provide both parts of the 
keyboard ID?

Of course, what I would really like is a way to determine the entire 
ASCII-to-Scancode map (or at least details on where the current keyboard map is 
different than a standard QWERTY layout) without needing to build lookup tables 
for every possibility, but that is probably not feasible.


___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] changing keyboard layout after booting from CD-ROM

[Bret Johnson]

> how should a KEYB scancode->keycode driver react to copdepage
> changes, and how are these communictated?

Well, first of all the keyboard driver should detect the current Code Page on 
installation and not just assume one.  And, the KEYB program should work with 
multiple code pages when it can.  If DISPLAY.SYS is installed, you can use INT 
2F.AD00 and INT 2F.AD02 to detect the current Code Page.  If DISPLAY.SYS is not 
installed, you can use INT 21.6601.  If neither of these work, you should 
assume code page 437 (which is the default on most systems).

DISPLAY.SYS calls INT 2F.AD81h when the Code Page is changed to inform KEYB so 
it can change its mapping.

> why would any other TSR need insight into KEYB installed/not
> installed state or a pointer to private tables?

Unless the tables are in a "public" format, the data contained in the tables is 
irrelevant.  E.g., MS KEYB and FreeDOS KEYB tables do not use the same format.  
I'm not sure about any of the other DOS's out there, but wouldn't necessarily 
expect them to be the same as MS.

The reason that other TSR's (at least mine) may need to know what the keyboard 
mapping looks like is because they need to do an "ASCII-to-Scancode" lookup.  
That is, the program allows the user to provide an ASCII code as an input 
parameter (since ASCII is far easier for the user to enter than a scancode), 
but the program itself uses the scancode.

My SCANCODE program, e.g., "types" scancodes automatically (it is useful for 
creating "macros"), but the user can tell SCANCODE what to "type" with ASCII 
codes.  To do this, SCANCODE needs to know what scancode(s) to type (what 
physical key(s) on the keyboard to press) to generate the ASCII code the user 
wants to see.  For example, if you tell SCANCODE to type a "Z" it will press 
the shift-key, press the "z", release the "z", then release the shift-key.  
But, it needs to know where the Z key is on the keyboard to do that, and the Z 
key is in different places (different scancodes) depending on the keyboard 
layout and, in some cases, the code page.  So, it has internal tables of a 
bunch of different keyboard layouts so it knows how to "type" the different 
ASCII characters.  It would be nice if SCANCODE could somehow "ask" the KEYB 
program what its tables look like, but that's not really feasible.  I realize 
you may think "typing" scancodes may be a "silly" thing to do, but there are 
cases where it works and ASCII codes do not (e.g., SCANCODE is able to "type" 
into older DOS-based versions of Windows, and can actually "type" things like 
PrintScreen or Pause or the multimedia keys or the Sleep/WakeUp/ShutDown keys 
that some keyboards have).

Another kind of TSR that needs to know is a TSR that has some sort of "hot-key" 
to enter into the TSR as it is running to make configuration changes.  My CLOCK 
and SERIAL programs do this.  TSR's usually (though not always) monitor scan 
codes for hot-keys rather than ASCII codes, but the user usually enters the 
hot-key as an ASCII code.  The current versions of CLOCK and SERIAL simply 
assume the keyboard is a standard US QWERTY layout, but I'm in process of 
changing them to be "keyboard-layout aware").  To do this, they need to know 
the current keyboard layout so they can do the "ASCII-to-Scancode" lookup using 
the internal tables.  If the KEYB program doesn't identify itself using INT 
2F.AD80, the TSR's don't know what the current keyboard layout is, and the user 
will get frustrated because the keys they are supposed to press on the keyboard 
are in the wrong places.

What this boils down to is making it easier on the user, trying to make things 
as "automatic" as possible, even though it can make it MUCH harder on the 
programmer.

BTW, this brings up another issue I've been trying to figure out regarding 
keyboard layouts.  There are two different parts to the keyboard layout 
identification -- there is a two-letter code (for example, US = United States), 
but most keyboards also have a code number to go along with that (for the US 
keyboard, it is 103).  But there are also cases where the there is more than 
one keyboard layout for the same two-letter code.  An example of this is 
Bulgaria (BG) which has three different layouts with three different numbers 
(103, 241, & 442) even though they are all "BG".  Unfortunately, the standard 
KEYB interface (which MKEYB doesn't use) only tells you the "BG" part and 
doesn't tell you the number part.

Does anybody know of a way to automatically/programmatically determine the 
number part of the keyboard ID from KEYB?


___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] changing keyboard layout after booting from CD-ROM

[Bret Johnson]

>> Another one is that MKEYB doesn't
>> report itself correctly as a "standard" keyboard driver to other
>> programs which can cause some compatibility problems.

> no one complained so far. ever. in 15+ years.

Well, then consider this your first complaint.  I don't use MKEYB for this and 
other reasons.

> how would this report look like?

Look at RBIL, INT 2F.AD80 and related calls.

As Aitor alluded to, KEYB interacts with the various other things in DOS 
(COUNTRY, DISPLAY, CHCP, NLSFUNC, ...).  If KEYB doesn't report itself through 
that mechanism the other DOS functions may not work correctly.  But, it's 
usually only a problem if you try to switch between languages or keyboard 
layouts or code pages on the same computer, which very few people do.

It's also a problem for other programs (including other TSR's) that need to 
know the current keyboard layout for some reason (which some of mine do).


___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] FW: Re: Somekind of Game Port Emu/Converter ?

[Bret Johnson]

I've already written down a bunch of basic USB information in the USBINTRO.DOC 
file included with the drivers.  It's not a book, but hopefully something from 
which you can glean some useful information.  The source code for the programs 
also has lots of comments if you want to get your hands dirty.


___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Somekind of Game Port Emu/Converter ?

[Bret Johnson]

> Bret, you are one of the few people who know how
> to write USB software. How did you learn to do it?
> Are there any good books on the subject?

It's mostly been trial and error (with a heavy emphasis on the error).  My main 
reading for USB is just the USB specifications.

Unfortunately, almost none of the USB hardware is 100% compliant with the 
specifications (which, believe it or not, Microsoft seems to encourage, at 
least indirectly).  So, in addition to the specifications, I need to 
occasionally do Internet searches for how problems are handled by others, and 
also occasionally look at Linux source code.  I normally can't use the Linux 
source code directly, though, since it's written in C instead of ASM and the 
Linux architecture is completely different than DOS (Linux doesn't have TSR's 
and doesn't have the same kinds of memory limitations that DOS has).  I don't 
know if you've really ever noticed, but TSR's that are written in high-level 
languages (like C or Pascal) usually have lots of in-line ASM since high-level 
languages don't work very well when manipulating hardware.  But, the Linux code 
reveals a lot of experience in what doesn't work and some information about 
non-compliant or non-standard hardware and where the non-compliance occurs.

The main USB-related web page I frequent is: 

http://janaxelson.com/usb.htm

and she (Jan Axelson) has written some USB books, though I've never read them.  
A lot of the questions on the PORTS Forum have to do with how to get things to 
work with Windows and are not "general" USB-related as such, but are sometimes 
still interesting or relevant.


___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Somekind of Game Port Emu/Converter ?

[Bret Johnson]

> Bret, if we talk about real hardware with FreeDOS (or even DOS), using
> your USB drivers. Is there any way to attach an USB gamepad and have
> some kind of program that maps that USB gamepad as a game port
> gamepad, so old games that use the gameport can work with a USB
> gamepad?

That's exactly what the USB drivers do, though it can be fairly complicated to 
setup, and again only works with certain hardware.  There are several factors 
to consider -- the first is to make sure you have a compatible (UHCI) USB Host 
Controller.  UHCI Host Controllers are made by either Intel or Via.  Probably 
the best/easiest way to do that is to download the USB drivers from my web site 
(http://bretjohnson.us) and run the USBHOSTS program.  It will tell you what 
kind(s) of USB host controllers you have installed.  If they're not UHCI, my 
drivers won't work.


___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] changing keyboard layout after booting from CD-ROM

[Bret Johnson]

While MKEYB is small, there's a lot of things it doesn't do that the larger 
KEYB program does that you may find you need or at least be useful.

One of them is the manipulation and correct handling of different Code Pages as 
Aitor indicated.  Another one is that MKEYB doesn't report itself correctly as 
a "standard" keyboard driver to other programs which can cause some 
compatibility problems.  MKEYB may work just fine for you, though.


___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Standy in FreeDos?

[Bret Johnson]

What exactly are you trying to accomplish?  Save Power?  Save the current state 
of a program?  Make booting faster?


___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Somekind of Game Port Emu/Converter ?

[Bret Johnson]

> I think what Martin meant was using an actual USB gamepad connected
> to the computer's USB port & having the virtual machine running
> FreeDOS interpret the gamepad as if it were a joystick-port gamepad.

The solution depends on whether he is actually using a Virtual Machine or not, 
and if so which VM.  Some VMs virtualize gamepads/joysticks and some don't.

> Check ebay for USB to 15 Pin Joystick Gameport Converter Adapter.

This would only make sense if he has an old analog/gameport joystick that he is 
particularly attached to for some reason and wants to keep using it.  
Especially on EBay, the cost of a used USB gamepad/joystick is probably about 
the same as a USB-to-GamePort adapter.  You can also get new USB 
gamepads/joysticks without spending a lot of money (depending on how 
"sophisticated" you want them to be).

> Some old DOS games used to work with a joystick and/or gamepad using
> the very old and discontinued game port.
>
> I was wondering if there is any kind of solution to play old DOS
> games with an USB gamepad, but the old DOS game will recognize that
> gamepad as an old game port joystick.
>
> Any solutions? or ideas?

If you're running DOS inside a Virtual Machine of some sort, it SHOULD be able 
to virtualize a USB gamepad/joystick as a regular analog/gameport joystick 
inside the Virtual Machine.  You may need to play around with some of the VM 
settings to get it to work, or may need to switch to a different VM if the one 
you're using doesn't support joysticks.

If you're running DOS on real hardware, there is only one solution available 
but it does not work with all hardware and can be daunting to set up (USB is 
EXTREMELY complicated).  You will need to use my USB drivers (available at 
http://bretjohnson.us).  AFAIK, those are the only drivers available for native 
DOS that support USB joysticks/gamepads.


___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] changing keyboard layout after booting from CD-ROM

[Bret Johnson]

> {harr...@vtxmail.ch}
>
> {.ch is the country code top-level domain (ccTLD) for Switzerland in
> the Domain Name System of the Internet.}

I understand that, but that really has nothing to do with what keyboard layout 
he wants to use.  There are two "standard" keyboard layouts for Switzerland, a 
French one (code SF) and a German one (code SG or SD).  They are both QWERTZ, 
but some of the other punctuation characters are in different places.  That is 
often the case with different keyboard layouts  -- many times the Latin 
alphabetic characters are the same (usually QWERTY, QWERTZ, or AZERTY) but the 
rest of the keyboard can be VERY different.  People can also design their own 
custom keyboard layouts if they want, but that can create all sorts of 
compatibility problems.

He'll also need to worry about the Code Page, especially if he ever needs to 
use the Euro symbol.  He may also need to worry about the Country settings for 
sorting and punctuation.  And if he ever wants to print from DOS, there's a 
huge can of worms related to Printer Code Pages (which FreeDOS really hasn't 
addressed at all).

In addition, just because his e-mail address is from Switzerland doesn't 
necessarily mean that he uses either of the Swiss keyboard layouts.  There are 
also several "International" keyboard layouts that might work well for 
Switzerland.  Even having a Swiss email address doesn't necessarily mean that 
he actually lives in Switzerland (he probably does, but that's not guaranteed).


___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] changing keyboard layout after booting from CD-ROM

[Bret Johnson]

Harry:

> Is there a way to change the Keyboard layout as well?

There is, but you'll need to provide a little more detail -- specifically which 
keyboard layout you're wanting to use (presumably one that matches your 
country, language/dialect, and physical keyboard layout).  International 
support in DOS is complicated -- it can take a combination of several DOS 
commands to setup the computer correctly.

Do you know which keyboard layout you're wanting to implement?  If not, you can 
just start by stating which country/language you want to support (some 
countries/languages have multiple keyboard layouts to select from).


___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] [Freedos-devel] game protections (was: Tracking bug s...)

[Bret Johnson]

> I think it would be easier for both the game owners
> and me to let me help them to break some individual
> features in copies of their OAKCDROM (UPC, subchannel)
> and then ask them whether it made their game fail.
>
> That way, I only have to send a debug script or file
> to modify their OAKCDROM driver and no physical game
> CD or DVD have to be sent around.
>
> When we know which of the 2 features (or maybe others)
> are relevant for the copy protection, only then can
> we start thinking about implementing those features.

I would take the opposite approach.  I would start by adding the standard 
features we know are missing in Jack's drivers and see if it fixes anything.  
Those features should be there anyway, and (at least to me) it doesn't really 
matter if they are actually used by existing applications or not.  If that 
doesn't fix the copy protection then some further investigation would be 
required.  You can either do this by breaking things or by monitoring the calls 
that get sent to the device driver.  I admit it would be kind of nice to know 
how the copy protection works, if for no other reason than to try and avoid 
something like this again in the future.

I think the first thing to do is fix Jack's driver to make it a 100% driver, 
not try to figure out ahead of time whether making it a 95% or 100% driver will 
fix a specific problem.

As you've also pointed out with the DOSBox code, sometimes there's enough 
ambiguity in the different specs (like the between the SCSI commands and the 
MSCDEX spec) that it's not always clear what the correlation is.  For example, 
"Audio Sub-channel" vs. "Audio Q-channel" -- I'm not 100% sure what the 
difference is and the existence of the sub-channels isn't related to whether 
the CD contains audio or not.  It could be that Jack's implementation of one of 
the (supposedly) working IOCTL calls is somehow faulty in some respect and is 
returning incorrect data.  I doubt that's the case, but it could be.  I know I 
get confused when reading the different specs and looking at specific 
implementation code from others and wondering if they really did it correctly 
or not.


___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Clairifcation on USB drives.

[Bret Johnson]

> Anyone has an idea if USB ports have a sequence or so? All the internal 
> USB-related stuff (including PCI cards/slots, USB host controllers/slots, USB 
> hub ports, for USB disks the number of partitions, etc.) have internal 
> numbers associated with them (normally hidden so that you don't know what the 
> numbers are unless you look really hard).  The drive letters are assigned by 
> a combination of the BIOS and Operating System (DOS), but exactly how that 
> works will vary by machine (for example, some things can be counted forward 
> and others backward).  In DOS, the drive letters assigned should be 
> consistent by physical slot (as you seem to indicate), but in other OS's it 
> may vary.___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] command.com and long commands: command.com, SET and detection

[Bret Johnson]

> Hi Jeremy, while you are at it:
>
> Wondering how Jerome could test whether the current shell
> is FreeCOM without needing temp files, ... FWIW, at one time I was trying to 
> figure out a way to automatically determine whether my executable program was 
> being called from the commend line (any command line -- FreeCOM or 
> COMMAND.COM or whatever) or whether I was being EXEC'd from another program.  
> I could never figure out a reliable way to do that.  The best I could do was 
> go back through the MCB chain and glean the name of my parent and compare it 
> to a list of known command shell names (COMMAND, 4DOS, etc. -- there are 
> several of them including the Windows & OS/2 command shells, and IIRC DOSBox 
> doesn't show any parent at all).  That turned out to be so unreliable and 
> convoluted that I abandoned the idea. I know you're not trying to do the 
> exact same thing, but it may be similar enough that it could give you some 
> ideas.  I'd be interested if you can figure anything out.___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] command.com and long commands

[Bret Johnson]

FWIW, in my programs (written in ASM) what I do while parsing the command line 
is look at the length stored at PSP:80h.  If it is less than 126, I use the 
data stored at PSP:81h up to the first 0Dh (Carriage Return) character.  If the 
length is 126 or more, I look for the CMDLINE environment variable and use it 
(if it exists).  If I can't find a CMDLINE environment variable, I go back and 
use what is stored at PSP:81h up to the first 0Dh character.  I never actually 
use (or trust) the value stored at PSP:80h to provide the actual length, but 
simply use it as a flag to tell me whether or not I should bother looking for a 
CMDLINE environment variable.  ___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Print via USB

[Bret Johnson]

I've only a few things to add to this discussion about printing in USB -- most 
everything has already been said.  But, I will summarize. USB support in the 
BIOS (for computers that even still have a BIOS) is usually limited to some 
subset of mouse, keyboard, and/or mass storage (disk drives).  Some BIOSs will 
support all three, others only one or two.  Most BIOSs also do NOT support 
"live" connects or disconnects of the USB devices --- the devices must be 
plugged in when you boot the computer or they will not be recognized by the 
BIOS at all.  The same problem also exists with most (if not all) DOS USB 
drivers except mine.  BTW, supporting live connections and disconnections in 
DOS is a pretty significant feature in itself -- DOS was never designed to 
support it and it's far from trivial to implement. I have never seen a BIOS 
that supports USB printers, serial ports, Ethernet NICs, joysticks, etc.  I've 
also never seen a BIOS that has a way to "extend" it to add new types of USB 
devices or features.  My driver architecture provides a way to add new types of 
USB devices. Specifically regarding printing, I do provide a USB print driver.  
But what it does is virtualize the printer port (usually LPT1) so that anything 
that DOS normally sends to LPT1 gets sent instead directly to the USB-attached 
printer.  It does not do any type of protocol conversion -- it acts just like 
your printer is attached to a parallel centronics port.  As has been noted, a 
lot of modern printers can't handle regular text being sent to them -- they 
don't know what to do with that.  You have to send the data to the printer in a 
format the printer can understand.  As has also already been noted, other than 
plain ASCII text the most common types of printer commands that some of the 
more "sophisticated" DOS programs can send out are Epson ESC/P, HP PCL3, and 
PostScript.  Most modern printers won't accept any of those (including modern 
Epson and HP printers).  Modern Brother printers are usually pretty good about 
accepting these "old" protocols, as may a few other brands, but that is far 
from universal. The other thing with USB is that it is pretty much an "all or 
nothing" scenario when it comes to BIOS support.  That is, for each USB Host 
Controller, only one piece of software can be controlling it -- it must either 
be the BIOS or it must be an OS-specific driver.  When you boot, the BIOS will 
normally be controlling the keyboard, mouse, and/or disks.  If you have any 
other USB devices besides those (including printers), the BIOS completely 
ignores them and you cannot use them in DOS.  You can install drivers for those 
other devices if drivers are available.  But in order to install the DOS 
driver, you need to disconnect the BIOS.  The good thing is that you can do 
this for each individual host controller.  So, you can leave your mouse and 
keyboard and disks plugged into the host controller(s) that are being 
controlled by the BIOS and plug the other devices (printers or joysticks or 
whatever) into the host controller(s) that are not controlled by the BIOS. I 
also provide mouse and keyboard and disk drivers (though the disk driver 
admittedly doesn't work all that well) so you don't need to let the BIOS 
control anything if you don't want to.  The problem with that scenario is that 
if your keyboard is being controlled by the BIOS, when you install a DOS driver 
for the host controller that keyboard is plugged into your keyboard will stop 
working (because it has been disconnected from the BIOS).  So, you can't 
install the keyboard driver using the keyboard because you keyboard has stopped 
working.  As mentioned earlier in this thread, the way around this is to run 
some sort of "LOADUSB.BAT" batch file that will install everything you need 
(including the USB keyboard driver) without ever needing to type anything on 
the keyboard.  This is the way I need to set up my computers for testing. USB 
in DOS is challenging, but possible.


Choose to be safer online.
Opt-in to Cyber Safety with NortonLifeLock.
Plans starting as low as $6.95 per month.*
https://store.netzero.net/account/showService.do?serviceId=nz-nLifeLock&utm_source=mktg&utm_medium=taglines&utm_campaign=nzlifelk_launch&utm_content=tag995&promoCode=A23457
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] CTMouse Buttons programming?

[Bret Johnson]

Thomas: In DOS, only one program at a time can control the mouse.  It will 
either be MOUSKEYS or it will be the other program, but it can't be both at the 
same time.  If a program already interfaces with the mouse, it is usually 
better to let the program control the mouse since it can change what the mouse 
does based on the current context the program is in.  If you want MOUSKEYS to 
control the mouse instead of the program, you will need to disable the mouse in 
the program (if the program will let you do that -- some programs will and 
others won't). Also, MOUSKEYS doesn't actually send any keystrokes when you 
press a mouse key -- it only types keystrokes when you release a mouse key.  It 
does this for timing reasons.  For example, if you want to press both mouse 
keys at the same time but don't press them at EXACTLY the same time MOUSKEYS 
may not do what you want it to do.  USB has a similar situation -- only one 
piece of software can be controlling a particular USB host controller at a 
time.  This will usually either be the BIOS or it will be something like 
USBUHCI, but it can't be both at the same time.  Each UHCI USB Host Controller 
has two ports, and each additional host controller will add two more ports.  
You can also add additional ports with USB Hubs.  If you have more than one USB 
Host Controller, one can be controlled by the BIOS and the other by USBUHCI. If 
your keyboard and your drive are both plugged into the same USB Host 
Controller, either the BIOS will control both devices or USBUHCI will control 
both.  If you need USBUHCI to control the keyboard by taking control away from 
the BIOS, you will need to start USBUHCI with a batch file that installs both 
USBUHCI and USBKEYB at the same time.  If you don't do that, as soon as USBUHCI 
installs itself the keyboard being controlled by the BIOS will stop working so 
you can't use the keyboard to install USBKEYB.  If you have a batch file 
install both programs at the same time, your keyboard will work when the batch 
file finishes. --
Bret JohnsonIt's oft been said that the Devil is in the Details.  I disagree 
completely.  I say God is in the Details -- the Devil is in the Fluff. 

-- Original Message --
From: Thomas Desi 
To: bretj...@juno.com
Cc: "Discussion and general questions about FreeDOS." 

Subject: Re: [Freedos-user] CTMouse Buttons programming?
Date: Sat, 17 Apr 2021 12:46:27 +0200

Hello  Bret,
 allow me to ask you, the author of »mouskeys« and am I right the »usbutils" 
(usb drivers for dos) two questions?  1) Some DOS Programs (text editors) seem 
to »override« the mouskeys settings (what is summarized in "mouskeys /t«). 
Is there a trick to obey to mouskeys.com? - I am not able to have the 
»CONTROL« on the Right Mousbutton. (mouskeys/t looks nice, saying »Scancode 
29« - which might be CONTROL, - I tried a couple of editors (e3, vde, TE216, 
EVE, Ne…) Does »holding« the button fire many repeated keyresses? Is 
that so? Could the »repeat rate" be changed or set to »no repeat«? Same goes 
to »ALT«. I would want to press CONTROL on the Right Mouse Button (/BR:Cntrl) 
 and whilst holding press a key on my keyboard which makes for a command. I 
tried with my USB-keyboard (which works fine) and a PS/2 keyboard. To no 
avail.(On FreeDos) Any hint what’s wrong? 2) Talking of USB, the 
USB driver from usbutils in my case stops the keyboard working.(As the warning 
in the program says) -  I guess there is no way out to use the usbdrive.com 
without a proper usb keyboard driver installed beforehand? Right? No chance? 
Any chance to find out what driver my keyboard would need or is it generic or 
just outdated? (Or I am just not getting it right.) best regards, Thomas

On Tue,20210413- week15, at 15:07, Bret Johnson  
wrote:Thomas: Glad you were able to find something that works. And also thanks 
for the encouragement with the documentation -- it takes a lot of time and 
effort to write documentation and good to know it's appreciated.


Choose to be safer online.
Opt-in to Cyber Safety with NortonLifeLock.
Plans starting as low as $6.95 per month.*
 NetZero.com/NortonLifeLock ___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user


Choose to be safer online.
Opt-in to Cyber Safety with NortonLifeLock.
Plans starting as low as $6.95 per month.*
https://store.netzero.net/account/showService.do?serviceId=nz-nLifeLock&utm_source=mktg&utm_medium=taglines&utm_campaign=nzlifelk_launch&utm_content=tag995&promoCode=A23457
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] CTMouse Buttons programming?

[Bret Johnson]

Thomas: Glad you were able to find something that works. And also thanks for 
the encouragement with the documentation -- it takes a lot of time and effort 
to write documentation and good to know it's appreciated.


Choose to be safer online.
Opt-in to Cyber Safety with NortonLifeLock.
Plans starting as low as $6.95 per month.*
https://store.netzero.net/account/showService.do?serviceId=nz-nLifeLock&utm_source=mktg&utm_medium=taglines&utm_campaign=nzlifelk_launch&utm_content=tag995&promoCode=A23457
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] CTMouse Buttons programming?

[Bret Johnson]

What exactly does the EVE.EXE program do?  It's possible that you just don't 
have the correct options set up in MOUSKEYS (or EVE).


Choose to be safer online.
Opt-in to Cyber Safety with NortonLifeLock.
Plans starting as low as $6.95 per month.*
https://store.netzero.net/account/showService.do?serviceId=nz-nLifeLock&utm_source=mktg&utm_medium=taglines&utm_campaign=nzlifelk_launch&utm_content=tag995&promoCode=A23457
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] CTMouse Buttons programming?

[Bret Johnson]

You might be able to use my MOUSKEYS program (available on my web site, 
http://bretjohnson.us. What MOUSKEYS is designed to do is let you use a mouse 
with programs that don't normally use a mouse (including using a mouse at the 
DOS prompt itself).  It does this by mapping the various mouse actions 
(movements and button presses) to keystrokes.  It is highly configurable so 
that you can map the various mouse actions to almost any keystroke.  It even 
has a small clipboard that allows you to copy something from the screen and 
"type" it in later. The problem you might have is that it converts ALL mouse 
actions to keystrokes and you can't have it just modify the right mouse button 
without modifying everything else on the mouse as well.  But, it may be 
suitable for what you're trying to do.  


Choose to be safer online.
Opt-in to Cyber Safety with NortonLifeLock.
Plans starting as low as $6.95 per month.*
https://store.netzero.net/account/showService.do?serviceId=nz-nLifeLock&utm_source=mktg&utm_medium=taglines&utm_campaign=nzlifelk_launch&utm_content=tag995&promoCode=A23457
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

[Freedos-user] any mouse configuration app recommendations?

[Bret Johnson]

Eric: I accidentally deleted this from my e-mail before I was able to respond, 
so am not sure if this will show up in the same thread as your original 
question. You're wanting a utility that will configure the mouse sensitivity, 
resolution, etc.  You would also like it to be "versatile" (TSR, hot-key, 
command-line, etc.).  Unfortunately, I know of no such utility. But, my 
USBMOUSE driver does have a limited capability to do it from the command-line.  
Of course, USBMOUSE is really designed to be a USB Mouse driver and not simply 
a configuration utility.  If you run any of the USBMOUSE options related to 
mouse configuration (/Resolution, /ScalingFactor, or /SamplingRate) and also 
use the /Install:No option it will simply change the current mouse 
configuration without attempting to install itself as the USB mouse driver.  
This is described in the USB program documentation (USBINTRO.DOC) starting on 
page 117.  I realize this is a little bit cumbersome, but is an option if you 
don't want to write a new program.

Sponsored by 
https://www.newser.com/?utm_source=part&utm_medium=uol&utm_campaign=rss_taglines_more

Australia to Kill US Pigeon That Made It Across the Pacific
http://thirdpartyoffers.juno.com/TGL3141/600063491d1463486910st03vuc1
Trump Made 'Misguided' Space Command Call: Governor
http://thirdpartyoffers.juno.com/TGL3141/60006349243a363486910st03vuc2
NYC's 'Vessel' Closed Indefinitely After Third Suicide
http://thirdpartyoffers.juno.com/TGL3141/600063494763e63486910st03vuc3___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] 2 printers on DOS

[Bret Johnson]

> As already asked, how are the printers connected, and what are you
> trying to print *from?* Exactly.  Some programs will only allow you to print 
> to one place (usually LPT1) while others will let you print to different 
> places, including to files.  If you in fact have two printers connected to 
> two parallel ports, you need to make sure the ports are configured properly 
> (e.g., one as LPT1 and the other as LPT2).  That configuration is probably 
> done with jumpers or DIP switches on the card but at least one of the ports 
> may be configurable with the motherboard BIOS. > IIRC, what DOS itself sees 
> is *ports*. What is connected to the ports
> is the business of what will be using the connected device. Not exactly.  
> While a few programs will print to Ports, most print to Devices (LPT1, COM1, 
> etc.).  While Ports and Devices are related, they are not the same thing. > 
> If the second printer is connected to a serial port try,
>
> ECHO "Some line of text" >COMx
>
> where x is the number of the com port and see whether anything prints.
> It will at least tell you whether data can be sent to that port to
> that device.

You can do the same thing to parallel ports (LPTx) to test them, too.  But some 
printers expect a whole page of text to be sent before they'll actually print 
anything (this is usually the case with laser and inkjet printers).  A lot of 
modern printers (lasers and inkjets) won't print plain text, either, but 
require special "startup codes" before they'll print anything at all.  Older 
printers (dot matrix, daisy wheel, etc.) will normally let you print single 
characters or single lines of plain text. Bottom line is that you have not 
provided enough information to do much troubleshooting.

Sponsored by 
https://www.newser.com/?utm_source=part&utm_medium=uol&utm_campaign=rss_taglines_more

US Death Toll Hits Mark Beyond Fauci's Prediction
http://thirdpartyoffers.juno.com/TGL3141/5fb5f9a1dd3779a04f67st03vuc1
Trump Campaign Is Paying for a Partial Wisconsin Recount
http://thirdpartyoffers.juno.com/TGL3141/5fb5f9a13233079a04f67st03vuc2
Danish Mask Study Doesn't Align With CDC Guidance
http://thirdpartyoffers.juno.com/TGL3141/5fb5f9a1556e079a04f67st03vuc3___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Is there such a thing as an add-on SATA host contro ller that works with DOS?

[Bret Johnson]

The problem I have found in writing disk drivers in the past (like my USB 
drivers) are the disks that do NOT show themselves as removable when they 
actually are, not the ones (like SanDisk) that show reality.  If a disk says it 
is not removable it means you should NEVER need to worry about somebody 
removing it and replacing it with something different.  That is never the case 
with CF media.  Even though the SATA controller may not be removable, the CF 
cards are and they should be treated as such.  SATA is designed for use with 
removable media. I'm not sure about SATA, but at least with floppies and USB 
the hardware doesn't have a disk eject sensor so you need to mange the 
potential media changes with software.  At least on floppies, this is normally 
done with a timer and if the disk hasn't been accessed for more than a few 
seconds when the OS asks the driver if the disk has changed the driver must 
respond with "I don't know" (which DOS must effectively treat as a "yes").  Of 
course, this decreases throughput speed since DOS must read the first part of 
the disk (boot sector, BIOS Parameter Block, FAT, etc.) to try and decide if 
the media has really changed or not instead of just relying on what's in the 
cache from the last access.  You can also continually poll the disk (every few 
seconds) and then you can definitively tell DOS "yes" or "no", but that uses 
power so may not be a good idea on something running off batteries (like a 
laptop). Bottom line is that the SanDisk CF cards are they way they should be 
even though some computers may have a problem with them.  In addition, I 
believe SATA drivers should always (at least by default) assume removable media 
unless you can verify they have a hardware media change sensor. > There are 
SATA adapters sold on Amazon that let a CF> chip work on an SATA interface. You 
might checkout
> cf chips sold on Amazon by Komputer Bay.
> Sandisk sell the best chips but they are setup
> for cameras not computers. Sandisk chips
> are internally marked as removable this
> can cause a lot of problems on computers.

Sponsored by 
https://www.newser.com/?utm_source=part&utm_medium=uol&utm_campaign=rss_taglines_more

Kushner Says Black Americans Must 'Want' Success
http://thirdpartyoffers.juno.com/TGL3141/5f973472bf5b434727fcdst03vuc1
Not-So-Close Race Also One of the Most Expensive
http://thirdpartyoffers.juno.com/TGL3141/5f973472df28234727fcdst03vuc2
Suspect Nabbed in Ballot Fire
http://thirdpartyoffers.juno.com/TGL3141/5f973473b81b34727fcdst03vuc3___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] A few suggestions to improve debug

[Bret Johnson]

> I'm not sure, but probably a program can distinguish whether it's in
> "interactive mode" or used for batch processing? It seems like this should be 
> possible, but I don't think it is.  I've tried doing something similar 
> (though not quite the same), where I tried to automatically detect whether my 
> program was being run from the command-line or being "called" (via the DOS 
> EXEC function) from another program.  I could never figure out a way to 
> automatically detect this.  The closest I could come was figuring out the 
> name of the "parent" program and compare it to a list of known command-line 
> interpreters (from MS, FreeDOS, 4DOS, etc.).  I abandoned the idea since it 
> was pretty unreliable. If there are some keystrokes you ALWAYS want to "type" 
> at the beginning of a particular program, you should start the program with a 
> batch file and use a "keyboard stuffing" utility (there are several of those 
> available, including my SCANCODE program). However, you should be able to 
> tell whether your input is coming from the keyboard or being redirected from 
> a file (which I believe is what is being meant by "batch processing").  With 
> some of my programs, I do something similar with the output.  These programs 
> have an "automatic pause" feature that stops when the screen gets full 
> (similar to piping the output of the program to MORE).  However, if the 
> program detects that the output has been redirected to something other than 
> STDOUT (the screen), the auto-pause is disabled so the entire output is 
> redirected with no pauses.

Sponsored by 
https://www.newser.com/?utm_source=part&utm_medium=uol&utm_campaign=rss_taglines_more

Suit: McDonald's 'Intentionally' Hurt Black Franchisees
http://thirdpartyoffers.juno.com/TGL3141/5f4e725a866b9725a7d46st04vuc1
Cheater's NYT Wedding Story Gave Away a Little Too Much
http://thirdpartyoffers.juno.com/TGL3141/5f4e725aa9c70725a7d46st04vuc2
Trump Mentions Plane Filled With 'Thugs' in Dark Uniforms
http://thirdpartyoffers.juno.com/TGL3141/5f4e725acdaf4725a7d46st04vuc3___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Temu Soundblaster Emulator

[Bret Johnson]

> Not sure why JLM also needs it, but I guess it
> is part of your plans to port VSB together with some USB sound
> driver to some JEMM JLM? No, it's just because the JLM/JLOAD structure 
> already supports I/O virtualization.  To add "generic" I/O support (via INT 
> 2F.4A15) I had to change the way I/O trapping is done in JEMM which makes it 
> incompatible with the way originally Japheth did it with JLM's.  I've see at 
> least one example of a JLM that uses I/O traps, so to keep compatibility with 
> other programs I need to keep JLM's working.  I personally think JLM's are a 
> bad idea since they only work with JEMM and nothing else and don't intend to 
> implement anything via a JLM. > I think USB serial would be cool,
> even when you only support access using the BIOS serial API I've considered 
> that, but the problem is that almost no serial programs use the BIOS serial 
> API (INT 14h).  For it to be useful, it really needs to virtualize the serial 
> port hardware.  I went through the same issue with the USB joystick driver -- 
> hardly any programs use the BIOS joystick API (INT 15.84) and they almost all 
> access the game port hardware directly.  My USB parallel port driver works OK 
> using the BIOS (INT 17h) API since almost all DOS programs print through the 
> BIOS instead of the parallel port hardware.  For an Ethernet port, a 
> software-based packet driver would get you most of the way there but I also 
> think it needs to virtualize something like an NE2000 at the hardware level 
> for older networking applications.  In fact, for security reasons (if nothing 
> else) I can see someone using something like an isolated NETBEUI/NetBIOS LAN 
> for certain applications instead of IP since hardly anybody even understands 
> how they work any more. There are similar issues on the USB side, too.  While 
> there is a standard USB protocol for USB serial port adapters, almost nobody 
> uses it.  The major USB serial chipset manufacturers (including FTDI) use 
> proprietary protocols instead of the USB standard, so writing a USB serial 
> port driver is going to be vendor-specific.  The same thing is true with USB 
> Ethernet ports -- while there is a USB standard almost nobody uses it (one 
> USB chipset that does implement the USB standard is the Realtek RTL-8153).  
> I'm also playing with some support for touch-screens with my USB mouse 
> driver, and those are mostly proprietary on the USB side also. It's a real 
> mess when vendors decide to not implement the standards.___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Temu Soundblaster Emulator

[Bret Johnson]

Just FYI, it is at least theoretically possible to do SB virtualization in DOS 
using USB devices.  It's on my list of things to get around to someday in my 
scant free time. But, SB virtualization would require I/O virtualization which 
is currently only available with the aid of MS EMM386 or 386MAX.  None of the 
current FreeDOS EMM's support I/O Virtualization.  I've been experimenting 
recently with adding support for I/O Virtualization to JEMM, but don't have it 
fully implemented yet.  I do actually have it working pretty well in JEMM, but 
now need to add support for JLM I/O Virtualization. I haven't even begun to try 
and do the USB part yet, but it is theoretically possible.  This could allow SB 
virtualization with almost any USB sound device.  BTW, I've also got ideas to 
do things like USB Ethernet cards and USB serial (RS-232) devices. So many 
ideas, so little time.___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Press Alt key via ssh

[Bret Johnson]

You might be able to use my SCANCODE program to do that, available at 
http://bretjohnson.us.  It's actually way overkill for what you're trying to 
do, but it might work.  One thing it will let you do is convert one keystroke 
(or keystroke combination) into another.  Since you're remoting in with a 
terminal, though, SCANCODE may not work since you are sending high-level ASCII 
codes and SCANCODE works at the keyboard hardware level and may not be able to 
"see" what you're typing.  It can "type" the Alt key just fine, but it may not 
be able to recognize when you want it to do the typing.  You'll just need to 
try it and see. I've not seen a small TSR that will do your specific task,.  
You could maybe do some kind of custom keyboard map with the KEYB program, 
though I'm not sure KEYB will let you manipulate the modifier keys (Shift, 
Control, or Alt). Similarly, I don't think the FreeDOS ALIAS command (or ANSI 
and other similar utilities that work at the ASCII level) will work with 
modifier keys, so I don't think those will help either.___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] WinWorldPC disk images...

[Bret Johnson]

I personally like DOS WordPerfect a lot -- version 6.2 is what I have and what 
I use to write the documentation for my DOS programs. I've never used WordStar 
myself. Anyway, like Dennis indicated the files probably aren't "split" like 
you might be thinking and need to be "combined" again before they are usable.  
In DOS programs there are usually just a bunch of separate files, several on 
each floppy with the installation program on the first disk.  With many 
programs, all you need to do is copy all of the files into a common directory 
and install from there.  I think WP works that way, but don't remember for 
sure. I have seen installation programs where it determines which floppy is 
installed by the "software name" of the disk (which you can give it when 
formatting or with the LABEL command), but most programs don't work that way.  
You'll have some issues if WP works that way.  I've also seen programs where 
there is a special "name file" on the disk which contains the disk number in 
the file (something like a text file that contains inside it something like 
"Disk1").  You'll have problems with those kinds of installations also.  Some 
programs also require the installation to be from the A: drive instead of a 
directory on the C: drive, but you can get around that problem with the SUBST 
(in DOS) or SWSUBST (in FreeDOS) utility. Also like Dennis mentioned, there is 
a lot of information about WP on the website he mentioned.  It's run by Ed 
Mendelson who was a frequent contributor to the venerable PC Magazine back in 
the day when DOS was still pretty popular.  The site is mostly oriented towards 
running WP in a virtual machine called vDosWP, a fork of DOSBox specifically 
oriented at running WP under newer versions of Windows.  I'm able to run WP in 
other VM's as well -- as long as it will run FreeDOS, it will probably also run 
WP.___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Off topic - hardware survival.

[Bret Johnson]

I still have an old Pentium-class machine that I boot up every once in awhile.  
I think it has an AMD CPU instead of Intel, but don't remember for sure.  Last 
time I booted it up was probably 6 months ago. The problem with older computers 
usually isn't the electronic parts (CPU's and RAM) but rather with the 
mechanical and heat-generating parts (disk drives, power supplies, and monitors 
-- especially CRT monitors).  That may be why my Pentium-class machine still 
works -- I rarely even boot it up so the hard drive doesn't spin very much. 
Your question reminds me of one of my old friends, back in the days before 
486's had even come out and all the hubbub was on the differences between 386DX 
and 386SX.  He was a contractor doing some work for a large waste disposal 
company who had a contract with local law enforcement to incinerate "illegal" 
things that had been confiscated.  The waste disposal company had an autoclave 
to do the incinerating, and needed a computer setup to automate and monitor the 
process to guarantee everything worked like it was supposed to.  My friend's 
job was to help the waste disposal set up a computer to do that. Instead of 
using a "new" computer (with a 386 processor), he chose to use an older XT 
clone (with an 8088 processor).  His reasoning when I asked?  "An XT is the 
kind of computer that won't die all by itself.  You have to kill it on purpose."___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Introducing myself, and inquiring about using FreeD OS as a blind user

[Bret Johnson]

Karen: Inside a Virtual Machine, ALL hardware is virtualized  to some degree or 
other -- you never get direct access to the real hardware (whether it's 
keyboard or mouse or video screen or hard drive or serial port or even the 
clock).  Exactly what gets virtualized through to the VM and exactly how it 
gets passed through depends on the VM.  Different VM's do some things better 
than others. I've played around a little bit with different VM's (VMWare, 
Bochs, DOSBox, QEMU, VirtualPC, PCEm, and others).  None of them are very easy 
to set up. and they all have their limitations and quirks.  At least for my 
purposes, I still find VMWare to be better than the others even though I still 
consider it really pretty bad and don't do anything serious with it.  And 
again, the main problem I have with VMWare is that it does not pass the 
keyboard though to the VM like it should and the keyboard is VERY critical in 
DOS (far more critical than the mouse).___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Introducing myself, and inquiring about using FreeD OS as a blind user

[Bret Johnson]

I'm not sure if it will end up being relevant to this discussion or not, but I 
use VMWare version 14 under Windows 10 to create a virtual machine for DOS.  I 
prefer MS-DOS to FreeDOS for various reasons, though I do use some of the 
FreeDOS utilities.  I actually have the machine set up to dual-boot, where I 
can either boot Windows 10 or boot directly to "real" DOS.  Virtual machines 
are nice for some things, but they are far from a panacea. The main reason I 
like VMWare is that it allows you to use a real partition on the hard drive as 
one of the disks in the DOS virtual machine.  You are not limited to "software 
hard drives" like you are in most other VM's.  That is, whatever I do to the 
hard drive in the DOS VM (or even directly from Windows) automatically shows up 
when I boot to real DOS and vice versa.  I don't need to do any FTP'ing or 
creating new ISO's or even remembering what I need to change the next time I 
boot up to keep my real DOS and my Virtual DOS synchronized. The ability to 
access a real hard drive (or partition) from inside the DOS VM is the part of 
VMWare that I really like.  The part I really dislike is that it does a VERY 
bad job of handling the keyboard.  Inside the DOS VM the modifier keys (Shift, 
Control, Alt) are constantly getting "stuck" and the keyboard releases for some 
reason are not always correctly sent to the VM.  I'm constantly needing to 
press the modifier keys in the middle of my VM sessions so the key releases are 
recognized like they're supposed to be.  For that reason, I don't use the 
VMWare Virtual DOS for any serious work since it's a real PITA to use the 
keyboard. I do know that DOSBox will also let you access real partitions, but 
almost none of the DOS programs I use work properly in DOSBox.  DOSBox is FAR 
from being a "real" DOS environment and is very limited in what you can do with 
it.___
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

[Bret Johnson]

The first thing you should do is to make sure COM1 is even set up correctly on 
your computer.  On older computers the COM ports were automatically enabled, 
but on newer computers they aren't always turned on.  I think the easiest way 
to check is to get into DEBUG (from the DOS prompt and enter: D 40:0 The base 
I/O addresses of the first four COM ports are listed at this address, with COM1 
usually being at address 03F8h.  Intel stores number in little-endian format, 
so the first two byte you should see are F8 03. You can quit DEBUG with a: Q If 
the first two bytes you see are not 03F8, you have a problem.  If they are 
h, COM1 is not set up in the BIOS.  You'll need to get into the BIOS setup 
(usually by pressing some special keystroke combination as the computer is 
first booting up) and enable COM1. Keep in mind that it's also possible to have 
two different sets of COM1 hardware (for example, one on the motherboard and 
one on a plug-in card).  If you have something like that going on, things get 
REALLY screwed up and you never how how the computer will react. If that is 
working OK, you can try my SERIAL program (available at http://bretjohnson.us)/ 
 It's a TSR that shows the status of a serial port on the screen in "real 
time".  Actually, what SERIAL does is constantly poll the UART (Universal 
Asynchronous Receiver/Transmitter), which is the chip that the computer uses to 
control the serial port.  It will show you the status of all the serial port 
pins (including RTS & DTR) as the UART sees them. If you're not using hardware 
flow control (and both the computer and the device at the other end of the 
serial cable both know that) then the status of the pins doesn't matter.  But, 
it's still good to know that they work in the UART to make sure everything is 
OK.

Urologist Is Shocked That This Has "Fixed" ED
Med Journal
http://thirdpartyoffers.juno.com/TGL3141/5e07608c34b6d608c3b9bst04vuc___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] HP laptop touchpad

[Bret Johnson]

Late to the party regarding this, but there is a lot of misinformation being 
stated.

USB and PS2 protocols are COMPLETELY different from each other -- barely even 
in the same universe.  You can't "convert" from one to the other.  You can talk 
to the mouse hardware with one protocol and then virtualize the other to the 
software, but you can't just plug PS2 wires into a USB port (or vice versa) by 
moving wires around and expect it to work.

The first mice used regular serial ports (RS-232) or a special card that 
plugged into the spare slots that old computers had lots of (these were called 
bus mice).  After that came the PS2 mice, which pretty much became the standard 
before USB was developed.  When USB was just starting out, there were mice 
being made that understood INTERNALLY both PS2 and USB protocols and came with 
a simple wiring adapter.  Those particular mice understood both PS2 and USB 
protocols, automatically detected which kind of port they were plugged into, 
and selected the correct internal parts to do what they needed.  AFAIK those 
USB/PS2 "dual-mode" mice aren't being made any more, but they were popular for 
awhile.

I think you can also still get adapters that will let you plug PS2 mice and/or 
keyboards into modern computers that only have USB ports, but those are much 
more than simple wiring adapters.  There is a "block" in the middle of the 
cable which has a bunch of hardware and software/firmware in it that talks in 
two different directions with two different protocols and does the necessary 
buffering/translation/virtualization so the the computer believes it is talking 
to a USB mouse when it actually isn't.

When USB was first being contemplated, one of the main goals of computer design 
efforts was to move everything up into the Operating System so that a BIOS was 
no longer needed.  That goal has now essentially been achieved with modern UEFI 
systems that don't even have a BIOS any more.  The problem with that idea was 
that you still need a keyboard and/or a mouse when the computer first boots up 
(before the Operating System even loads) so you can do things like change BIOS 
or UEFI settings.  You also need a keyboard and/or mouse in older Operating 
Systems (like DOS) that were developed way before USB was created (though 
computer manufacturers don't care very much about that any more).

The USB protocol is WAY more complicated than the PS2 protocol and they 
couldn't expect the BIOS manufacturers to provide USB support directly (after 
all, the intent was to move USB support up to the Operating System and not even 
have a BIOS).  So they needed to come up with a way to virtualize a PS2 mouse 
from USB before the Operating System is loaded.  This virtualization can't just 
occur in software, but must also be assisted by the hardware (PS2 is a hardware 
protocol, not a software protocol).  The hardware portion of the virtualization 
is provided by a combination of the USB host controller, special capabilities 
of the PCI bus, and a special operating mode of the CPU called System 
Management Mode (SMM).  The whole process is really a giant, complicated 
kludge, but was one of the first steps necessary for the ultimate elimination 
of the BIOS.

This is a complicated subject and I can go on for awhile longer about details 
if anybody cares -- some if it is already discussed in the documentation 
provided for my USB drivers.  Bottom line, though, is that you CAN'T just 
interchange PS2 and USB mice with wiring adapters and expect everything to work 
out just fine.  In some cases it will, but in most cases it will not.

Urgent Alert: Doing This In The Shower Destroys Testosterone
pro.healthresponses.org
http://thirdpartyoffers.juno.com/TGL3141/5d544f1d6c3a44f1d37b6st03vuc


___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] ot: run time issues?

[Bret Johnson]

The Runtime Error 200 issue has been around a long time, and is fairly 
well-known among DOS enthusiasts.  It is actually an interesting "feature" of 
programs that were compiled with Turbo Pascal (TP).


Supposedly, the problem occurs in the startup/initialization code of programs, 
before the program starts to actually do anything useful.  It is supposedly a 
small piece of code that is intended to measure how fast the computer is 
running, which is information needed by some of the TP libraries (or something 
like that).  Most programs run fine once they get past that particular section 
of the program (most programs don't really care how fast the computer is).  
Unfortunately, if the computer is too fast the routine that's supposed to 
measure how fast the computer is blows up and you get the 200 error.  Overall, 
not a very good design by Borland.


Anyway, there have been several patches, work-arounds, and fixes for this 
particular issue.  There are several of them listed here:


http://reimagery.com/fsfd/system.htm#oldprogs


and here:


https://www.bttr-software.de/freesoft/system.htm#oldprogs


BTW, the second one is from the DOS Ain't Dead web site you mentioned.


These include the TPPATCH program mentioned by others, which actually modifies 
the original executable file.  The one I normally prefer to use is PROT200, 
which is a TSR that traps the error (it is a Divide by Zero error) and then 
let's the program continue as normal.  You can also use my SLOWDOWN program (or 
perhaps one of the other slowdown-type programs available -- there are several 
of them), though that makes the entire program run slowly instead of just the 
part that needs slowing down (the part where the CPU speed is measured).  
SLOWDOWN does have a hot-key option that lets you speed the computer back up 
again, but for the very specific Turbo Pascal Runtime Error 200 problem I think 
something like SLOWDOWN is overkill.  I prefer to use programs specifically 
dedicated to the TP problem (like PROT200) for this.


It is rare for a program to crash if the computer is too fast (unless the 
program was compiled with Turbo Pascal), but of course a program can run too 
fast to be usable (especially highly-interactive programs, like games) even if 
it doesn't crash.  In those situations, SLOWDOWN (or even a combination of 
SLOWDOWN and PROT200) may be more appropriate.

Drink This Before Bed, Watch Your Body Fat Melt Like Crazy
Diet Insider
http://thirdpartyoffers.juno.com/TGL3141/5d03ce155cbfd4e151edast01vuc


___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Not sure is it possible - but maybe I'm missing som ething?

[Bret Johnson]

FWIW, I prefer NASM myself also.  I started out using A86/A386 a long time ago 
(before NASM and FASM even existed in a useful form) but my source code 
eventually got too big for A86 to handle.  A86 doesn't take advantage of 
extended or expanded memory or protected mode so it can't handle large or 
complicated source files, plus it's not free.

When I started looking for a new Assembler, I compared FASM and NASM and a few 
others and chose NASM since it appeared to be the most appropriate for what I 
do in DOS.  All Assemblers are a little different and all have their quirks and 
different things I like and don't like about them.  I REALLY don't like MASM or 
its clones at all.

Since then, I've converted a few of my older programs from A86 to NASM.  I 
started with a "simple" program to see how hard it was to do the conversion, 
and it is quite difficult.  As a result, I don't convert an existing program 
from A86 to NASM until and unless I have to.  All of my new programs I do in 
NASM.

Also FWIW, I still prefer the D86/D386 Debugger (though even it has its 
quirks).  The Debugger is at least as, if not more, important as the Assembler 
itself.

Bret

-- Original Message --
From: "C. Masloch" 
To: freedos-user@lists.sourceforge.net
Subject: Re: [Freedos-user] Not sure is it possible - but maybe I'm missing 
something?
Date: Fri, 10 May 2019 11:45:06 +0200

On 2019-05-09 18:02 +0200, ZB wrote:
> BTW: which macroassembler you prefer?

I prefer NASM. The reason I initially forked lDebug was actually to keep
its source in the NASM dialect. Also, I adjusted the (default)
disassembly display to mostly match NASM's syntax.

Regards,
ecm 

Chemical Linked to Popcorn Destroys Brain Health
clearstateofmind.com
http://thirdpartyoffers.juno.com/TGL3141/5cd59a0e506541a0e7be6st04vuc


___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] FreeDOS Internet Security Protocols and Graphical I nterface

[Bret Johnson]

Thanks for the comments, Karen.

I'll check out Lynx once again based on your recommendation and see what I 
think now.  I do see that Lynx recommends my MOUSKEYS program to enable mouse 
support, so it can't be all bad ;-).

It has been a long time since I've tried Lynx, and I don't remember which 
version I had when I did test it.  It may be worthwhile to use now, plus I may 
have different thoughts now about what "useful" is compared to what I did back 
then.

Judge Judy Steps Down After 23 Years Over This Controversy
glancence-hality.com
http://thirdpartyoffers.juno.com/TGL3141/5c3764785d4964770fccst01vuc


___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] FreeDOS Internet Security Protocols and Graphical I nterface

[Bret Johnson]

Hi Karen:
 
I've tried various DOS browsers in the past, and they've all been less than 
stellar.  Arachne, Lynx, Dillo, Links -- all have problems that make them 
unsuitable for me.  Arachne in particular was very unstable for me and seemed 
to crash constantly.

I do like Michael Brutman's MTCP stuff, though it doesn't include a browser.  I 
use HTGET from a DOS batch file to automatically download a bunch of data files 
from some government sites, and use SNTP to synchronize the time to an atomic 
clock.

So, I do use DOS Internet connectivity for some things, but find it too limited 
for web browsing.

Judge Judy Steps Down After 23 Years Over This Controversy
glancence-hality.com
http://thirdpartyoffers.juno.com/TGL3141/5c35efefc3a5f6fef7ee5st03vuc


___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] FreeDOS Internet Security Protocols and Graphical I nterface

[Bret Johnson]

For the wireless connection, Michael Brutman (maker of MTCP) has this page that 
discusses another option: 
http://www.brutman.com/Wireless_for_Classics/Wireless_for_Classics.html I 
haven't used on of these for DOS, but did use one (the one that Michael 
recommends) in another application where the device only had a wired Ethernet 
port and I needed it to be wireless since it was clear on the other side of the 
house from where the wireless router was. In the past, I know there were a few 
wireless NIC's that came with DOS drivers, but I haven't seen any new 
DOS-compatible wireless devices in a long time.  Your best bet if you want to 
go wireless with DOS is to use the wired Ethernet port on the computer and hook 
it up to one of these "bridges".  Of course, you still need a DOS driver for 
the wired Ethernet port and those can be difficult to find as well. Also, even 
if you get DOS to access the Internet, what you can actually do is pretty 
limited.  Even just simple web browsing is difficult, since most modern web 
pages require JavaScript and DOS browsers don't support it.  There are some 
things you can do with DOS (like automated file downloads and such), but 
overall it's pretty limited. 

Bad News About Metformin
simplebloodsugarfix.com
http://thirdpartyoffers.juno.com/TGL3141/5c353aba592c53ab97d00st03vuc___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Using a timer with an ISR in watcom

[Bret Johnson]

Just as an FYI, other people have tried to do the same kinds of things 
(particularly with fast polling of a parallel port) with mixed results.

Some TSRs and device drivers, for example, don't work properly if the the clock 
interrupt is reprogrammed.  They use the counter you want to reprogram as an 
input parameter for their own timing and depend on it not changing.  If none of 
the TSRs or device drivers you depend on use this technique, you may be OK from 
that perspective.

The bigger problem usually turns out to be legacy USB devices (USB keyboards 
and mice using the BIOS in "legacy mode").  In legacy mode, the BIOS uses the 
CPU's System Management Mode (SMM) and the System Management Interrupt (SMI) to 
process mouse movements and keystrokes.  The SMI completely bypasses the normal 
IRQ process, the PIC, and the CLI/STI CPU instructions.  The SMI has higher 
priority than anything the PIC controls, so once the SMI is triggered there is 
no way to stop it and it is usually very slow to process.  The SMI can even 
interrupt the highest priority IRQ in the PIC (the clock).  So, you can end up 
missing a lot of polls waiting for the SMI to complete its processing.

In general, it's a bad idea to reprogram either of the clocks (IRQ 0 or the 
CMOS clock) in a "general use" program where you can't control what the user 
may do.  If it's a dedicated computer in a controlled environment, you can 
probably get away with it.


-- Original Message --
From: Tom Ehlert 
To: "Discussion and general questions about FreeDOS." 

Subject: Re: [Freedos-user] Using a timer with an ISR in watcom
Date: Mon, 31 Dec 2018 20:14:40 +0100

> Just out of curiosity, if I write something for a DOS4GW 32bit
> environment, would I choose the same way for having a timer or are there
> better ways for having a timer callback function?

the idea will be the same, the routines to use are different.

> For a later experiment project I want to capture parallel port data on a
> Pentium 3 which is very fast compared to a parallel port's speed.

> I thought about having an ISR capturing the data being called at capture
> rate, which should be something around 100kHz to 150kHz
unlikely. expect *each* inp()/outp() operation to use O(500ns)

there is also a notable delay between applying an input 0/1 voltage,
and this voltage available as inp()

usually people read until 2 readings are identical.

try polling first to get an idea what input rate will be possible.

> to get a hard
> real time measurement.
don't mix 'fast measurement' with 'real time, deterministic
measurement'. DOS is anything but hard real time.

> Are there any interrupt priorities interfering with this concept?
in a DOS environment, the current interrupt will be served until
finished. so any incoming interrupt (USB, keyboard, mouse) will defer
your input routine until done.


> There should be plenty of time on this machine to process data after 
> capturing from parallel port.
yes. with real time linux.

Tom



___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user


Drink This Before Bed, Watch Your Body Fat Melt Like Crazy
Celebrity Local
http://thirdpartyoffers.juno.com/TGL3141/5c2a767082ad0767018a5st04vuc


___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] FreeDOS on SSD

[Bret Johnson]

Just as an FYI, USB flash drives (a.k.a. thumb drives, pen drives. etc.) do 
something similar but it's called wear-leveling instead of TRIM.  In flash 
drives, though, it's all automatic (built into the hardware/firmware of the 
drive) and you never see it or interact with it directly.  The flash drive 
periodically does a "clean-up" process in the background where it moves data 
around to different places.  The very first flash drives didn't have this and 
tended to wear out pretty quickly, but later flash drives all have it and last 
a lot longer than the old ones did.

The reason for this is that even though things are solid state, there is still 
some "wearing" or "degradation" that goes on over time.  It supposedly only 
happens when you write to the disk but not when you read from it.  So, at least 
in theory, you can read an unlimited number of times but if you keep writing to 
the same places all the time things will eventually wear out and stop working.


___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] rcal v1.0

[Bret Johnson]

> Can you point out exactly which of these are:
> - 8086-compatible
> - 'normal' applications (not TSR)
> - floating point-aware
> - free to use, modify and distribute

No, I can't.  As I said earlier I haven't tried any of them, at least that I 
remember (I may have tried some of them a long time ago but ultimately chose 
HOC).  The web page does list some of those features (like which are TSR's).  
All of them are free to use and distribute (as are all the programs on that web 
site).

Oncologists Are Freaking Out After Officials Release This
pro.naturalhealthresponse.com
http://thirdpartyoffers.juno.com/TGL3141/5b69b3fd3ea6e33fd75ecst02vuc

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user