Re: [Freedos-user] Freedos Install Problem

[Eric Auer]

Hi Andrew,

> 1) Both use IDE connectors, no sata.
> 
> 2) The error simply says disk read error in the pentium 2. The i486 simply
> has a black screen, like it is trying to load the OS but cannot. Both
> computer see the hard drive in the bios ( no hard drive post errors).

At which point, using which exact wording? Could
it be that your BIOS has a bug in LBA support?

> 3) I installed DOS 6 on the pentium 2 on a hdd, moved the hdd to the i486,
> and it boots up every time, and works correctly. Currently the i486 does
> not see any floppy drive or the gotek I have, but it sees the hdd

What is a gotek? Does the floppy work with another OS?
Proper wiring, proper jumpers, proper BIOS CMOS setup?

I assume you mean MS DOS 6 by DOS 6? And you had to use
the Pentium2 to install it for the 486 because even MS
DOS cannot use the floppy on the 486? Note that MS DOS
6 never uses LBA, so if your LBA BIOS has a bug, this
would not affect MS DOS, but this also limits it to at
most 8 GB usable disk size. You can also use a special
feature of our SYS command to modify a flag in your
FreeDOS kernel file to either disable or force LBA,
in case LBA or CHS is broken. Depending on whether you
use FAT16 or FAT32 partitions, you can use different
boot sectors to prefer CHS or LBA, but I am not sure
how to access this via SYS command line options. This
depends on the specific version of our SYS you use.

This may also depend on your BIOS CMOS setup choices.

> 4) it does not get far enough to offer the JEMMEX option on either computer.

How far exactly does it get?

> 5) When you load either a Windows 98 CD, or a freedos CD in the pentium 2,
> both give an option to boot from hdd. When I do this freedos boots.

You say FreeDOS boots okay from harddisk when you first start to
boot from a Win98 or FreeDOS CD and then abort that to continue
booting from harddisk, on the Pentium2?

> 6) I tried formatting it on 98 then installing freedos to the partition,
> but it still gives the same error. However this is with automated
> installer, perhaps with manual installation the problem can be fixed.

That sounds like a question for Jerome. But as said, if you can,
skip partitioning (and maybe even formatting) the disk in case you
ran into a bug of FDISK (which that recent update may have fixed).

It is indeed possible that the MBR itself causes troubles with
booting. Our FDISK has some options to overwrite the boot code
with one of the built-in templates of FDISK, but you could also
just keep the boot code left behind by Win98. Our FDISK has he
options /MBR and /BMBR and you can also use the /SMBR to copy
the MBR to a file and /AMBR to copy a file to the MBR etc.

> When DOS or 98 sees the freedos partiton, with it installed,
> it calls it a non-dos partition. Not sure why.

You would have to be more specific about that, for example using
FDISK /INFO /TECH or /STATUS or /DUMP or similar, although for
my taste, those are still not verbose enough, so maybe simply
show hexdumps of the right MBR after copying it to a file ;-)

> 7) I downloaded freedos last week, if should be up to date. I did see some
> old forums from 2002 or so with similar, but not exactly the same problem,
> that were fixed however.

I meant the FDISK update by Japheth and Tom, see:

https://www.bttr-software.de/forum/board_entry.php?id=17440

Given that this was about 1.3.1 while GITHUB as 1.3.4:

https://gitlab.com/FDOS/base/fdisk/-/tree/master/BIN

While the 1.3rc4 boot CD has 1.3.4a, it should be up to date:

http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/1.3/previews/1.3-rc4/report.html

> 8) Could the bios not be able to compensate for the cylinder problem,
> causing it not to boot? Which is why it can boot from bios to cd to hdd,
> but not bios to hdd?

It could be that the BIOS and DOS disagree about the geometry,
but given that both agree about sector and head, just not about
the cylinder, I would rather expect this to be a problem with
FDISK or a bogus warning from the kernel in case it has a bug
regarding the decision when to show the message. But unlikely.

Regards, Eric



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

Re: [Freedos-user] Freedos Install Problem

[Eric Auer]

Hi Andrew,

I assume your 486 and your Pentium2 both use ATAPI
CD drives and IDE harddisks, not SATA? Can you be
more specific about the (harddisk?) read errors on
the Pentium 2 after install? What does the BIOS and
CMOS setup say about your i486 which does not boot?

In general, I recommend the following: When asked
at boot, do NOT select the option with JEMMEX or
JEMM386. The default config sys uses options for
those two which require some level of compatibility
from your hardware and firmware. We should use more
humble defaults for that! As said, the easiest way
to avoid this is to select one of the other boot
menu options which simply load no EMM386 at all.

What do you mean by the following?

> However in the pentium 2 when I boot to any CD then boot
> to the hdd, it is able to read the hdd and boot to freedos.

> However the i486 I have not been able to get the cd/
> floppy drive to work, but it can run dos off the hdd,
> and the pentium 2 can run dos or windows 98.

So the 486 does actually boot? Or not? How have you
installed DOS to the harddisk without using the CD?

By using a boot USB (unlikely for 486)? Or floppy?
Or by installing while the harddisk of the 486 was
in a more modern computer for easier installation?

You say you have used different partitioning schemes,
but all had some (?) problems with FreeDOS? Have you
tried to keep the partitions from Win98 and just put
FreeDOS on them, optionally after formatting them?

If your problem is specific to FreeDOS FDISK, there
has been an update recently which may fix it, but as
said, if you already have a bootable FAT32 partition
from Win98, you could simply recycle that as-is.

Which warning does FreeDOS produce when booting from CD?

> if I have freedos installed on the hdd: initdisk warning using
> suspect partition pri:1 FS 06: with calculated values 260-254-63
> instead of 261-254-63 cant get drive parameters for drive 01.

Apparently this describes a 2 GB partition and the last
cylinder of the partition mismatches by 1 between CHS
and LBA values. The last head and sector both do match.

Regards, Eric



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

Re: [Freedos-user] How to list "active" drives?

[Eric Auer]

Hi Paul,

next to Jerome's tools, you may also like WHICHFAT and CDROM2:

https://auersoft.eu/soft/specials/

C:\>whichfat /?
WHICHFAT [x:]
Returns: generic:
0=FAT32 kernel, 1=FAT16 kernel 2=/? found.
For 1 drive:
0 not FAT, 1 no local drive,
12 FAT12, 16 FAT16, 32 FAT32.
C:\>

In other words it returns errorlevel 2 after showing the help.

For example:

C:\>whichfat e:
Drive is FAT16.
C:\>echo %errorlevel%
16

C:\>whichfat f:
Drive is FAT32.
C:\>echo %errorlevel%
32

C:\>whichfat
Kernel limit: FAT32.
C:\>echo %errorlevel%
0

Also, check CDROM2UI:

https://auersoft.eu/soft/

C:\>cdrom2

Freeware CDROM toolkit with audio support - written and
conceived in 2003 by Eric Auer 

Usage: CDROM [EJECT|CLOSE|LOCK|UNLOCK|RESET] X:
Example: CDROM EJECT N:

Audio: CDROM [PAUSE|CONT|INFO|PLAYnn] X:
(xx is audio track number)

Ask *CDEX 2.0+ if a CD-ROM exists: CDROM N:

Errorlevels: 0 okay, 1 failed / no such drive.
Shows a list of valid drives if invalid selection.
Not all drives do all commands.

C:\>cdrom c:
C: is no CD-ROM drive, but < N: > is.

C:\>cdrom2 info n:
Command: INFO
Valid audio track numbers: 01-03
To see individual track start and end times,
please PLAY the track in question. No track
listing to screen implemented yet...
Audio play in progress. Q-Channel tells:
Track 01.00, relative position 00:00.42, absolute position 00:01.66
Done.

C:\>cdrom2 play01 n:
Command: PLAY

Playing audio track 01
Already playing? Sending PAUSE command to be safe...
Valid audio track numbers: 01-03
Playing audio from seek position 00:02.33 to 04:16.33
Audio playing should now start. Returning to DOS.
Done.

Audio then continues to play in the background, you
can use the INFO command to check the current position,
or possibly non-position, as shown above.

Of course this only works if you have the audio out
connector of your drive connected to your sound card
or mainboard, or use a drive headphone output socket.

Regards, Eric

> DRIVE.EXE - reports some info on all drives or a specific drive / disk.
> DTYPE.COM - reports a one-liner piece of information about current drive.
> INFO.EXE - reports some system information, including a section on drives.




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

Re: [Freedos-user] game compatibility CD/DVD drivers: comparing UDVD2 to OAKCDROM and DOSBOX

[Eric Auer]

Hi Jim,

> This is an interesting analysis and comparison between Oak
> Technology's OAKCDROM (proprietary) and Jack's UDVD2 (free
> with sources).
> 
> Have you shared this with Jack? I think he would want to
> see this so he can improve compatibility in his driver.

Yes, but was is busy with improving UHDD instead, as hinted
earlier today: The new version will support all sizes from
5 MB up with full features, as opposed to requiring larger
caches for some features before, or multiple-of-5-MB sizes.

It also will be smaller on disk, making UIDE more obsolete.

A relatively exotic feature to reserve "low XMS" for games
which are unable to use XMS > 16 MB will be dropped, but I
think HIMEM already has a command line option to reserve
XMS 2 in that way, letting only XMS 3 prefer "high" XMS?

Jack has shared another important warning: RayeR has seen
BIOS / hardware combinations where UHDD has to be loaded
after HIMEM, before EMM386 and outside UMB. Broken UMB
DMA or VDS support, I guess? So it is good that the docs
now present this workaround. Of course this will not be
possible with JEMMEX at all, because there is no "after
HIMEM, before EMM386" moment with when you use JEMMEX.

Another FreeDOS work-around from Jack: If you use the
HMA option /H of his drivers, you have to load them via
DEVLOAD in autoexec, because the FreeDOS HMA allocation
offerings while config sys is running are incompatible:
They would not allow the drivers to acquire HMA space.

Some final performance remarks: XHDD has a /P option
to keep more metadata in DOS RAM instead of XMS, which
uses more DOS RAM, but is slightly faster. UHDD does
not have that option. Making int 15.87 faster while
JEMM386 is active would improve speed: MS EMM386 is
faster, in spite of JEMM386 supporting vm86 VME as
far as I remember? An item for a Japeth-wishlist :-)

Still, I would prefer MS EMM386 style I/O traps first,
because various Sound Blaster emulators need those.

To get back to the "read UPC code" function: Jack is
not convinced that this would be useful and I can see
in online forums that users can simply select the UPC
they want to burn, so it seems odd that copy protected
games would just rely on UPC. I suggest that somebody
performs my suggested experiment first: Test whether
blocking the OAKCDROM "read UPC code" function will
result in breaking copy protected games with similar
symptoms compared to testing those games with UDVD2.

Regards, Eric



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

[Freedos-user] game compatibility CD/DVD drivers: comparing UDVD2 to OAKCDROM and DOSBOX

[Eric Auer]

Hi gamers and coders, in particular Lukas :-)

Wondering why some (copy protected?) games work with OAKCDROM
but not with UDVD2, I checked which differences exist between
the two. I also found a relevant DOSBOX code snippet, assuming
that DOSBOX cares more about game compatibility. Things which
are not supported in UDVD2, but are supported in OAKCDROM are:

*driver functions*

Driver function 3 IOCTL IN and 0x0c IOCTL OUT both have
various sub-functions, but some are not supported in UDVD2
while others are not supported in DOSBOX. As I assume that
DOSBOX is good with games, functions which ARE supported
in DOSBOX and OAKCDROM, but not in UDVD2, are most likely
candidates for game copy protection compatibility issues.

Driver function 7 flush (DOSBOX does not support this either)

Driver functions 0x0d and 0x0e (open or close driver:
DOSBOX ignores this, just as UDVD2 does, no problem)

Driver functions 0x80, 0x82 and 0x83 (0x81 is reserved) do
differ a bit, but within specs: 0x83 read long prefetch is
synonymous to SEEK (0x83) in UDVD2, while it actually behaves
as READ LONG (0x80) in DOSBOX and in OAKCDROM, all three are
different from each other (no idea what exactly they do).

Interestingly, neither OAKCDROM nor UDVD2 support WRITING
to CD/DVD, neither with nor without verify (0x86 and 0x87)
but users of "DOSCDROAST" are probably the only ones who
notice that? Also, both drivers support play, stop and
resume audio (0x84, 0x85 and 0x88) which is great :-)

*differences for IOCTL support*

IOCTL OUT function 3 "audio control" (volume control?)

IOCTL IN function 4 "audio control" (volume control?)
In DOSBOX, you can read with the latter what you wrote
with the former.

IOCTL OUT function 4 "write bytes" (not supported in DOSBOX
either, so this is apparently not relevant for games?)

IOCTL IN function 1 "head location" seems to be supported
in UDVD2 and DOSBOX but not OAKCDROM, but I might have
messed up my probing for that one.

IOCTL IN function 3 "error statistics" is not supported
in UDVD2, but DOSBOX does not support it either

IOCTL IN function 5 "read bytes" is supported by neither
UDVD2 nor DOSBOX, so probably not relevant for games

IOCTL IN function 0x0d "subchannel info" is not supported
by UDVD2 and there seems to be a *bug* in DOSBOX because
it seems to mix up the function and 0x0c "Q-channel info"?

IOCTL IN function 0x0e "read UPC/EAN code" is not supported
by UDVD2 and seems to be an obvious choice for doing some
minimal copy protection check in games?

*background*

I have used the UDVD2.ASM sources, an OAKCDROM binary
and the following two web references for my comparison:

MSCDEX text, describing the driver API:
https://gist.github.com/abrasive/7a615e6dde0c1da962f9930cc63ee43d

DOSBOX implementation, for comparison:
https://sourceforge.net/p/dosbox/code-0/4167/tree/dosbox/trunk/src/dos/dos_mscdex.cpp

*conclusion*

If you ask me, *READ UPC CODE* (IOCTL IN function 0x0e) would
be an interesting candidate to check for DOS game compatibility.

*other thoughts*

Audio volume control calls do not seem relevant and as far
as opening or closing the driver, reading and writing drive
control bytes or reading error statistics are concerned:

Those are not supported by DOSBOX EITHER, so if that would
break games, DOSBOX users might have already mentioned it?

Which of the two allowed styles "read long prefetch" does
should not matter, as long as the driver does consistently
whatever it does. I think some flag also announces that.

Note that checking the audio playback "cursor" location is
usually done by reading the Q-channel, not head location,
but it is great that UDVD2 implements both :-) Checking the
head location can give useful "seek" progress info, I think.

*proposed game experiment*

I suggest the following experiment: If your OAKCDROM has
md5sum 7ed28c4b926dae81a4e9ccf1f5378f64 then changing the
bytes at offset 0x281 from 0xd6 0x04 to 0xf5 0x05 should
deliberately "break" the "read upc code" function, so if
that keeps everything else working, BUT breaks the copy
protected games, then my theory would be correct and it
might help to implement that one more function in UDVD2.

In DOSBOX, this function returns 1 attribute byte, 8 UPC
bytes and a 0 byte. We can return ten 0 bytes on failure.

Regards, Eric

PS: Note that OAKCDROM has exe style relocations, so you
have to use a hex editor, not debug, to change the 2 bytes.

PPS: The ELTORITO driver, of course, does not support any
audio and similar functions and does not implement several
other functions which are available in the other drivers.



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

[Freedos-user] FreeDOS 1.3 driver selection, configuration and packaging wish list

[Eric Auer]

Hi :-)

I would like to refresh the discussion about 1.3 updates...

*Part one, quick driver selection improvements*

Questions about the next update of the 1.3 boot media,
has the following already been taken care of? Thanks!

 - provide XMGR as alternative for HIMEM at least in "full"
   (it can have better compatibility than HIMEM or JEMMEX)

 - provide CTMOUSE 2.0 as alternative for 2.1 in "full"
   (one uses BIOS, the other hardware I/O for PS/2 and
   USB legacy support can be broken in one of the two)

 - move UIDE from "base" to "full"...
   (UIDE is more for people who want tiny boot disks)

 - ...while moving UHDD from "bonus" to "base"!
   (UHDD and UDVD2 together give best performance)

 - ...and moving LBACACHE from "base" to "full"
   (CDRCACHE already is "full"-only, but see below!)

The rationale for the latter is the following: If you want
to cache both harddisk/SSD and CD/DVD, you will either have
to load both LBACACHE and CDRCACHE, or have to load UHDD
before UDVD2. Because using UHDD allows sharing cache XMS
between harddisk and CD, that is the more modern method.

Note that only UDVD2 uses UHDD cache. In every situation
where the ELTORITO driver is used, I recommend loading
CDRCACHE for ELTORITO. So the BOOT CONFIGURATION of the
installer should be able to use both: UHDD+UDVD2 in one
setting and ELTORITO+CDRCACHE in the other. Note how the
two styles differ in which part must be loaded first.

See my 3 May 2021 mailS "Distro autoexec/config wishes"
which also discusses some other config issues.

In case Lukas is reading this: You can also use CDRCACHE
with OAKCDROM, but let me know if that breaks your game
copy protection checks! Also note that some games need
to use XMS below the 16 MB boundary. Both XMS drivers
and some XMS-using drivers such as UHDD and RDISK have
command line options to keep "low" XMS free for games.

Of course it would also be fine to have more drivers
in "base", but if only either UIDE or UHDD can be in
there, then it should be UHDD, not UIDE or LBACACHE.

*Part two, slower package choice suggestions*

Can we promote HX RT / HX GUI more? It runs Win32 apps.
If you are okay with the license, please include it.

Can we promote XFDISK next to FDISK? "Upgrade" XFDISK
from "Bonus CD only" to "full" or even "base" for that.

Can we add INFOPLUS (COMPINFO tends to crash) as "MSD"?

Can we promote DOSZIP (and DN2?) as "DOSSHELL"?
Lukas' 2 June mail says DN2 is slower etc.?

Can we promote DOS32A as cure for DOS4GW problems?

Can we add the MPXPLAY media player, with AC97 and HDA
support, great to show off support for modern hardware!

Please add FDSHIELD to "full" or even "base" again,
it is our resident (TSR) virus protection thingy :-)

Please add RDISK next to SRDISK: While the latter
is resizeable, the former is very lightweight.

In general, the Legacy CD is missing a number of things
compared to the Live CD (aka Full CD?) or the Full USB
medium. I would give all three the same set of packages
and make Lite USB less lite (at least 60 MB FAT16) but
you already know my issues with too small USB media.

As people have to burn a CD anyway, Legacy need not be
Lite, but if you want to offer a Lite CD, you could
offer one with Legacy and one non-Legacy boot style:
The ISO would be small enough so you can offer both.

I remember people have also missed RAREAD and RAWRITE.
Which other packages should be move to higher categories?

Maybe ARJ and CABEXTRACT? Command and freecom probably
are not REALLY "less included" on various media?

And why are LHA and UNRAR not included at all?
Any license problems I have overlooked?

http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/1.3/previews/1.3-rc4/report.html

Thanks for looking into those :-) Regards, Eric



PS: I would have included 386SWAT (debugger) and DPMIONE
(DPMI host for DOS extenders etc.) but those are closed
source: http://www.sudleyplace.com/download.htm Still
cool enough to mention in this mail ;-)

PS: Does ANY of you know contexts where CTMOUSE 1.9.1
works, while 2.1 would not, even when the mouse wheel
mode of 2.1 is not activated via command line option?



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

Re: [Freedos-user] GUI libs: Turbovision and FLTK (nanox), Dillo browser

[Eric Auer]

Hi Paul,

as you mention Nano-X and Turbo Vision, Georg Potthast has
ported some apps to DOS using Nano-X and FLTK, with screenshots:

> https://sourceforge.net/projects/fltk-dos/

> https://sourceforge.net/p/fltk-dos/wiki/NanoX_Introduction/

> https://freedos-user.narkive.com/bIGRt11t/new-xfdos-freedos-distribution

He also has written shareware USB drivers with USB 3.0 support:

> http://georgpotthast.de/usb/ "DOSUSB"

The unregistered version only works 20 minutes after you
load it and you can load it only 5 times in one session.
After each reboot, 5 times 20 minutes can be used again.

He supports printers, serial ports and storage media.

Turbo Vision has been released into the public domain by
Borland when they did the same for the rest of their IDE:

> https://en.wikipedia.org/wiki/Turbo_Vision

As you can imagine, it looks like your Turbo Pascal and
Turbo C IDE looked like. Colored text, frames, menus etc.
As only the C version became open source, Free Pascal has
made a Free Vision clone for those who prefer Pascal.

For comparison, Nano X and FLTK apps look pretty much like
your usual GRAPHICAL apps known from Windows or Linux, of
course with a bit of a retro look given the very lightweight
approach of the building blocks. License: LGPL for FLTK
and MPL and GPL for Nano-X see the FAQ on their website:

> http://www.microwindows.org/

Regards, Eric



___
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

[Eric Auer]

Hi Jeremy, while you are at it:

Wondering how Jerome could test whether the current shell
is FreeCOM without needing temp files, I found out that
half of the SET options are not yet listed in SET /? help.
The currently available actual options of SET would be:

SET test=one results in TEST=one
SET /C test=one results in test=one (keep case of variable name)
SET /U test=one results in TEST=ONE (uppercase variable value)
SET /P test=one shows "one:" as prompt, TEST = user entered value
SET /E test=one runs command "one", uses 1st returned line as value
SET /I displays information about environment size and memory usage

Note that SET /E requires a temp file, so it has the same
problem as pipelines: It only works with writeable temp dir.

You usually want to add a space after the prompt, for example:
"SET /P test=please enter a value " with " " after "value".

Also note that while SET /E test=vol sets TEST to the message
which VOL produces about your volume label (which will depend
on which language your FreeCOM has) you cannot SET /E test=ver
because VER always first displays one EMPTY line before starting
to show version information, so it behaves like "SET test=" and
deletes the varible TEST instead of setting it to anything ;-)

Maybe you could update the help messages. Thanks!

Do you have suggestions for easy, temp-file-free detection of
FreeCOM in BAT which works even with older versions of FreeCOM?

Regards, Eric



___
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

[Eric Auer]

Hi Paul,

> When I run a long command, e.g.
> 
> pdptest  ... (to exceed 126
> characters), and it is a Win32 executable so HX
> gets involved, I get a crash.

You write that Japheth writes:

> IMO it's a bug in FD command.com. If a command
> line exceeds 126 bytes, the value at [PSP:80h]
> "should" be 0x7Fh ( and a 0x0D "should" be placed
> at [PSP:FFh] ) - that's at least what COMMAND.COM
> of Win95/98 does. The environment variable
> CMDLINE will then contain the full command line.
> It's documented in RBIL.

In FreeCOM, MAX_EXTERNAL_COMMAND_SIZE is 125, because
for normal command lines, psp_cmdlineLength is max that,
followed by psp_cmdline with trailing \r AND \0 chars.

Note that FreeCOM unfortunately never uses psp_... so
the code is harder to read.

Now when you have a LONG command line, two areas of
the C code become relevant:

shell/init.c is what received the command line when
you start a new instance of FreeCOM, which probably
is what HX does to start a Windows program, although
I am not sure why it does it like that.

https://github.com/FDOS/freecom/blob/master/shell/init.c

int initialize(void)
{
...
  /* Aquire the command line, there are three possible sources:
1) DOS command line @PSP:0x80 as pascal string,
2) extended DOS command line environment variable CMDLINE,
  if peekb(PSP, 0x80) == 127,&
3) MKS command line @ENV:2, if peekb(ENV, 0) == '~'
&& peekb(ENV, 1) == '='

Currently implemented is version #1 only
  */
  cmdlen = peekb(_psp, 0x80);
  if(cmdlen < 0 || cmdlen > 126) {
error_corrupt_command_line();
cmdlen = 0;
  }
...

This would show, if you are using the English version:

Corrupt command line. This is an internal error and is related to
the system COMMAND.COM runs in. Please report this error.

The other part is that when you already have FreeCOM running
and want to execute some other app, via lib/exec.c

https://github.com/FDOS/freecom/blob/master/lib/exec.c

int exec(const char *cmd, char *cmdLine, const unsigned segOfEnv)
{
...
  assert(cmd);
  assert(cmdLine);
  assert(strlen(cmdLine) <= 125);
...

as well as shell/command.c, bad indent caused by tab size 8
in my viewer while apparently the file assumes tab size 4:

https://github.com/FDOS/freecom/blob/master/shell/command.c

void execute(char *first, char *rest, int lh_lf)
{
...
if(strlen(rest) > MAX_EXTERNAL_COMMAND_SIZE) {
char *fullcommandline = malloc( strlen( first ) + strlen( rest )
+ 2 );
error_line_too_long();
if( fullcommandline == NULL ) return;
sprintf( fullcommandline, "%s%s", first, rest );
if( chgEnv( "CMDLINE", fullcommandline ) != 0 ) {
free( fullcommandline );
return;
}
free( fullcommandline );
}
...

This displays "Commandline longer than 125 characters."
and leaves it up to the user to wonder whether that is
a problem. Actually it cannot know which apps support
long command lines, so thata probably is OK.

Also note: CMDLINE is only used for com and exe, not for bat.

Unfortunately, the above part is the ONLY place which uses
MAX_EXTERNAL_COMMAND_SIZE, while the assert above hardcodes
125 and init.c hardcodes "negative or above 126" and fails
to to anything about long command line used when it is
started with one itself, by some outside caller.

shell/cswapc.c contains this:

https://github.com/FDOS/freecom/blob/master/shell/cswapc.c

DoExec(char *command,char *cmdtail)
{
...
len = strlen(cmdtail);
if (len >= 127) len = 127; SEE BELOW
dosCMDTAIL[0] = len;
dosCMDTAIL[1+ len] = '\r';
...

Because dosCMDTAIL is ((char far*)MK_FP(_psp, 0x80))
this would actually overflow the buffer by 1 byte :-p

Japheth's description implies that 127 has to be used
as magic length, together with injecting an early \r
into the PSP and not bothering to put an \0 after it.

So proper code without long command line support was,
only changing the SEE BELOW line:

if (len > MAX_EXTERNAL_COMMAND_SIZE) len = 126;

But proper code for long command line support would
make a case distinction for long versus short lines.

Note that the assembly language parts of FreeCOM do
not process long command lines at all, they simply
assume that the C parts have already limited the PSP
command line in a sensible way and do not care whether
or not the environment contains any CMDLINE variable.
This probably is OK.

You could probably change SHELL or COMSPEC to let HX use
for example DJGPP BASH instead of FreeCOM to see whether
HX itself works okay, but that will have big side effects
and BASH does not use the same "command.com /C command"
style syntax as command.com, while /C likely is hardcoded
into HX when it invokes programs.

In short, the CMDLINE support of FreeCOM looks sketchy
at best, in spite of having been added at 0.84pre7 and
me looking at https://github.com/FDOS/freecom today,
not 17 months ago when CHANGED got the 0.84-pre7 info.

Jeremy and Bart seem to

Re: [Freedos-user] Fwd: FreeDOS make better compatibility with DOS games [current status]

[Eric Auer]

Hi Lukas,

Glad to hear that you found a solution for copy protected games!
I assume none explicitly demanded OAKCDROM? What do the docs say?

The question will be what exactly OAKCDROM does better than UDVD2,
regarding copy protected games. Not easy to say with closed source.

But good to know that SHSUCDX works equally well as MSCDEX.

I think DOS32A generally works better than old DOS4GW these days.

> Now I need to solve Terminator 2029 from floppy, which gives JEMMEX
> exception. I guess it just needs more memory or something.

Probably not. Simply try without JEMMEX, only loading HIMEM.
Background info: JEMMEX is HIMEM and EMM386 combined, while
JEMM386 is just EMM386. Most games only need HIMEM, so you
would use neither JEMMEX nor JEMM386. You can also try XMGR,
which is another alternative to HIMEM, if our HIMEM is not
what Terminator 2029 wants.

Regarding the DN2 problems: Would you say DOSZIP is better?

http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/repositories/1.3/pkg-html/doszip.html

DOSZIP is also available on our FreeDOS CD, of course.

> crash exception in DOS32A: warning (9003): real mode interrupt vector
> has been modified: INT 23h. And you will end up in command line.

That is not necessarily a crash, but a warning about unclean
exit of apps. Many apps even show it for intentional exists.

> Restarting with CTRL+ALT+DEL a.k.a. WARMBOOT according to your FDAUTO.BAT
> works only sometimes. Mostly after some DOS32A app changing the interrupt

You mean WHILE you are in DOS32A apps? Or after you leave them?
Does this happen with JEMMEX, JEMM386 or without any EMM386?

If it only happens with the two EMM386 variants, there are some
command line options for those to influence the reboot strategy.

Regards, Eric



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

[Freedos-user] Fwd: FreeDOS make better compatibility with DOS games [current status]

[Eric Auer]

Hi! Forwarding a message from Lukas, accidentally sent only to me.

To already reply to his points: It is a common problem that 486 can
not boot from CD-ROM, but we provide a boot floppy image with the
right drivers to boot your 486 and then start our CD installer :-)

Note that our installer expects FreeDOS command.com, not others,
as it uses some extended functionality from that.

You write that you have tried our floppy, but ran into other bugs:
Please explain which bugs you saw. I think Jerome would tell you
to switch to advanced mode while inside the installer to avoid the
bugs, but without knowing WHICH bugs, I cannot say for sure.

Lukas, please keep us posted about the CD-ROM based games and the
drivers which they do or do not like, e.g. UDVD2, SHSUCDX, JEMM386
(but remember: the best EMM386 version often is the one which you
do not load at all, unless the game really needs to use EMS). You
can also compare XMGR to HIMEM if any game would dislike our HIMEM,
or use our HIMEM command line options to limit RAM. Some games are
known to fail if they see more than 31 MB of XMS2: /X2MAX32 helps.

What exactly made DOSBOX bad in playing your 486 games, by the way?

That OSSC - http://junkerhq.net/xrgb/index.php?title=OSSC - really
is fancy! It upscales SCART, Component or VGA input to HDMI or DVI
using small fractional N/M scaling factors in HARDWARE (an Altera
Cyclone IV FPGA, DVI out chip, analogue I/O chip, CPU/SoC, 110 EUR)
https://videogameperfection.com/products/open-source-scan-converter/
Common modes seem to be deinterlace and multiplying lines by 2 to 5.

Of course running 320x240 games on 4k screens is a bit strange, you
have to turn every retro pixel into 108 ultra high resolution ones,
but for those who happen to have 4k screens with bad built-in scalers
it still is a very elegant solution. You should ASK the DOSBOX people
to implement the scaling algorithm of your choice instead of just
telling US how bad DOSBOX looks according to your taste.

You say you dislike having to reconfigure DOSBOX for each game: In
Linux, there is Plays on Linux which automatically uses a collection
of optimized configs and dependencies for your Windows games in Wine,
so I imagine something similar would exist for DOSBOX and DOS games?

Regards, Eric



@Jerome: The installer will fail somewhere at the end, like 99% or 100%.
Even with BASE install. It will say that it failed to copy some package on
the drive. Another use case: adding 10 packages from 5 categories in
already installed FreeDOS system -> you will get runtime error / out of
memory on 486.

My previous e-mail without photo:
Hi, yes I did use Win 98 floppy. That found my CD-ROM, which is connected
to onboard IDE, not to soundcard. Just 486 BIOS did not know CDROM / ATAPI
back then.

I tried even FreeDOS floppies, but it goes straight to the installer and
that installer has some other issues. So that's why I ended with Win98
floppy + FreeDOS CD. But it is impossible to install it on 486. I had to do
it on Pentium machine.

Today I am experimenting with FreeDOS drivers. Regarding the CDROM drivers,
I did not try MS-DOS 6.22 yet. Only MS-DOS 7.1 from Windows 95 and Windows
98. There are some cdrom drivers out of the box that MSCDEX will find the
drive.

I have plenty of CD and DVD roms. From oldschool NEC, through LG, to
Pioneer and Plextor. I have even some installation disks with drivers for
these units. So this should be easy to fix.

You know, every review is a little bit biased. Yes, a lot of classic DOS
games do run in FreeDOS. But only classic DOS games without CD-ROM. If I
would make this kind of review, it would be biased towards opposite
direction because the percentage of games I have that is not working is
much higher.

So Arkanoid II on 5.25'' works :-). But Mass Destruction on CD does not
work. On the same configuration, with different OS, it works as well. So
I'm going to figure out why is that.

I tried DOSBOX on my Windows 10 machine. I did not like it at all. Because
I played these games on 486 like 10 hours every day. I remember it was not
like this. That was the point when I decided to invest hundreds of dollars
into retro stuff. DosBox will scale the graphics in a wrong way. It is
always like 1024x768 then it will upscale to 4K HDMI display. On the other
hand OSSC, the FPGA unit, will scale it naturally. You can even add
scanlines for more CRT feel. Sometimes DosBox will feature some GoG update,
which will "update" the game to 16:9 instead of the original 4:3. That
completely destroys the aspect ratio. For example Jazz JackRabbit does
this. So I don't get the feel that I would enjoy playing in DosBox. For a
lot of stuff, you need to change dosbox config game by game. For example if
you use external MPU-401 device such as Roland SC-55. So instead of messing
with hardware, you start messing with software. And as it is my daily job,
I want to get rid of it. Also you have the distractions of the internet and
notifications. When I boot my 4

Re: [Freedos-user] FreeDOS make better compatibility with DOS games [current status]

[Eric Auer]

Hi Jerome,

if FDIMPLES is specifically used in advanced mode, where
more data has to be processed, I would suggest to consider
automatically enabling support for XMS when XMS is found.

Do you say that the amount of required RAM does not depend on
the number of packages, but on the size of the largest ZIP? How?

> FDIMPLES was really only designed to modify the package
> list for advanced mode installs. All the the other stuff
> it does and restrictions that were added came later.
> It’s really not designed to do that.
> It really needs to just be redone.

That sounds tedious. But please explain in more detail.

> What OS let’s you boot a different OS to perform your install?

I generally agree, but it is easier for people who do not know
how to use a disk image to make our boot floppy, or are simply
too lazy because they assume DOS is DOS which may seem plausible.

Maybe the installer could test if it runs on FreeCOM and abort
with a complaint if it is not? Should be easy enough for users
to start FreeCOM and not worth the effort to automate that.

And as you say, if people load FreeCOM on top of another shell,
maybe even without having XMS drivers, it will severely limit
free RAM, so they better update their config and reboot again.

Do you require any other FreeDOS specific things apart from
FreeCOM? I assume you require working XMS and CD-ROM drivers,
but not much else, so people could use other DOS boot disks
at their own risk. A good example would be that they already
have some DOS on their harddisk and know how to configure it,
so they want to use that to run our CD installer manually.

Regards, Eric



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

Re: [Freedos-user] FreeDOS make better compatibility with DOS games [current status]

[Eric Auer]

Hi Jerome,

thanks for the explanation, but are we talking about DOS
RAM (at most 640 kB) here? Or EMS, XMS, protected mode?
In FDIMPLES, FDINST of FDNPKG, and other involved apps?

How much RAM do you recommend to be free? Could FDIMPLES
shrink before calling FDINST and grow back when it exits?

Note that Lukas had been booting from a Win9x floppy to
run the CD installer, as his BIOS does not boot CD and
he did not use the special installer boot floppy either,
so I expect his context to be rather unusual for the
installer and wonder which parts are likely to fail in
that situation and what could be done to warn the users
or, better, to work with arbitrary DOS boot disks :-)

Regards, Eric




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

Re: [Freedos-user] FreeDOS make better compatibility with DOS games [current status]

[Eric Auer]

Hi again,

>>Not sure why Michał mentions Yamaha YMF724

> I've lots of issues with this card.
> Shame on me for not getting a
> motherboard with ISA slots.

After trying several different PCI soundcards which claim
some level of ISA Sound Blaster compatibility, I can tell
you that your luck will also depend on how much ISA your
PCI mainboard still supports with special retro DMA etc.

So basically this only worked well for computers which were
only slightly too new to have ISA slots. After that, things
do indeed get ugly and success also varies from game to game.
But this most likely also happens with MS DOS.

None of the cards worked for more than non-DMA or OPL3 on
too new mainboards. Maybe SB PCI or SB Live would be the
exceptions. I have not tried those because those are known
to require protected mode drivers to simulate compatibility
in software instead of relying on mainboard hardware help.

The SB Live drivers may work better with MS EMM386, but the
drivers fail to work with specific games in the way they do
or do not cooperate in protected mode use in all DOS brands.

And the nicer protected mode SB16 simulation is DOSEMU2 or
DOSBOX, I think. Some "SB16 on HDA hardware" could be nice
to have in real DOS, but that has a bad balance between the
complexity and desire to have it if you have DOSBOX/DOSEMU.

> A lot of games I tried with JEMM386/JEMMEX had some really jarring
> issues. They varied from the game gracefully crashing to...

In context of the above: Does the same happen if you do
NOT load the special PCI soundcard drivers? I would think
that the trio JEMM386 plus PCI sound plus protected mode
games is most evil, while real mode games and ISA or no
sound might be just fine with the same JEMM386. Of course
some daring command line options for JEMM386 are still a
source of stability risks. You are free to change those.

Please be more specific about how FreeDOS DOSFSCK fails
to repair FAT (FAT16? FAT32?) damage by crashing games
in situations where Linux (also with DOSFSCK?) fixes it.

Having crashes which cause FAT damage is really frustrating,
but I would have to know more details to think about which
repairs types FreeDOS repair tools (either CHKDSK or DOSFSCK)
fail to offer yet.

Regards, Eric



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

Re: [Freedos-user] FreeDOS make better compatibility with DOS games [current status]

[Eric Auer]

Hi Lukas,

> Phil has even FreeDOS starter pack, but it is for FreeDOS 1.2. I tried it.
> The driver VIDECDD is not working at all. It will not find my CD-ROM drive.

Such is life. Try OAKCDROM or stick to UDVD2 in that case. This should
not depend on your BIOS, though. As long as the CDROM is connected to
the mainboard, it should be easy. If your CDROM is connected to some
ATAPI-style connector on your soundcard, additional configuration or
command line options may become necessary in DOS.

> Perhaps because 486 bios cannot find the CDROM.
> But driver such as MSCDEX or SHSUCDX will find the drive.

This actually is a two layer system: UDVD2, OAKCDROM or VIDECDD are
what talks to your hardware as layer 1. MSCDEX and SHSUCDX only talk
to layer 1, NOT directly to your hardware. There also is ELTORITO,
which talks to the BIOS which in turn talks to your hardware, but
that only works when you boot from the CD drive in question. When
UHDD is loaded first, UDVD2 will additionally talk to UHDD to cache.

In short, if VIDECDD does not work, use UDVD2 or another layer 1
driver. Whether you use MSCDEX or SHSUCDX makes no difference in
that point, but it might make a difference for copy protections.
Different layer 1 drivers may ALSO make copy protection differences,
so you really have to try a few combinations to find out more.

> Yes, he mentions that a lot of games will fail because they cannot
> find a CD drive at all. And this must be something specific to
> FreeDOS (I think it can be driver for CD or EMM386).

You forget that he also mention many games which work immediately.
If you say EMM386 is a likely source of problems, I repeat my
recommendation to simply avoid loading it. Much easier than to
wonder whether another version or other options make it better.

> You know I spent last 3 days with FreeDOS, trying to make it work. I don't
> think I'm impatient. We spent one day here and I did not have any solution

I spent at least half an hour finding and watching Phil's videos,
youtube comments, pausing short screenshots of error messages etc.

It would have been a lot easier if you just answered my questions
and actually you would have saved four hours of experiments with
Windows boot floppy and our installer if you had carefully read
the instructions, or had asked immediately, to know that there is
a FreeDOS boot disk which should be used with the install CD when
your BIOS cannot boot from CD (in general, this is common for 486).

So again, life is hard with DOS. When we used it in the 1980s or
1990s, it was not uncommon to spend some time wondering about the
drivers or configuration for some new hardware or software. This
is not specific to the FreeDOS style of DOS. Remember that with
MS DOS 6, you were not even able to use more than 8 GB of your
harddisk (often less, depending on BIOS) or more than 2 GB for
each drive letter. Hardware has not become simpler since then,
so it is quite nice that UDVD2 covers a large range of systems.

Thirty years ago, you just used the driver which came with your
CD-ROM drive and hope that it was of good quality, but nobody
would have complained about having to copy that BRANDCD.SYS from
the CD vendor to their DOS directory and read the docs and so on.

Compared to that, UDVD2 is very plug and play. For everything
not automatically done right by that, pretend that it is 1990.

> Therefore I will try hack my way around. Copy MSCDEX and EMM386.

That would be a very interesting experiment, yes. Please tell
me which games work better with those. Again, you should also
try different layer 1 drivers if MSCDEX is not sufficient to
make the CD-ROM detected by copy protection schemes.

> If that won't work, I will format the drive and install Windows 95.

You do know that DOS games are not exactly famous for running
inside Windows, right? Or do you mean the MS DOS 7 which came
with Windows? That might work, but it may actually have fewer
drivers for modern hardware than FreeDOS does. Again, let me
know how well your games work with it if you test MS DOS 7.

> PS: CD Audio was fixed in Freedos 1.3 RC2 thanks to updated UDVD2 driver
> and I use XT-IDE custom BIOS attached on Realtek NIC. That allows to
> unlimited disk size (limited only by filesystem, 8TB for FAT32).

That is a pretty fancy way to solve the disk size limitation
compared to your expectations about plug and play DOS drivers.

Note that disk size is limited to 2 TB, not 8 TB, because DOS
only supports MBR partition tables and 512 byte sector size at
the moment, but both can be fixed in future FreeDOS updates :-)

> ...took a vacation this week to solve stuff like this. Because I won auction
> with 15 retro gaming PCs after someone's brother deceased. And it was whole
> weekend for me with only FreeDOS installation crashing because of out of

Sad thing about the brother! Still, if I had FIFTEEN new PC, I
would not be surprised to spend a lot of time to install them.

> memory. Then other stuff and now I see the compa

Re: [Freedos-user] FreeDOS make better compatibility with DOS games [current status]

[Eric Auer]

Hi Lukas,

> Ok, I was born 1987. Had 386 and 486. Today I am software developer. I have

As a software developer, you have to know that "My computer is
not working, make it work" while hesitating to provide details
is not making our life easier. A good bug report contains as
many details as possible.

> cd in the tray. Tried to remove second hdd so it is on drive D and it does
> not help. Same use case is working in Windows 98 and its ms dos. So it is
> clearly some incompatibility in Freedos driver.

If you would be less impatient, you could have noticed that
SHSUCDX lets you use any drive letter you want, possible range
limited by LASTDRIVE, of course. So stop running around in
circles, take a deep breath, read the documentation or at the
very least the output of "NAMEOFTHEAPP /?" before you state
that NAMEOFTHEAPP is "obviously broken" or start searching for
a 90% unrelated "solution" such as removing your harddisk. The
young people today just have too little patience ;-)

> Please look at youtube, PhilsComputerLab. He has Youtube video about
> freedos gaming. He mentions exactly these issues and that he need to
> replace some files, but I dont know which files to replace.

https://www.youtube.com/c/philscomputerlab/videos this guy has 677
videos as of today. Also 120 000 followers, so if I would know which
of those 600+ videos you mean, it would be a promising channel.

None of the videos has "copy protection" in the name, nor protect,
but there are a few called "Create Installation CD from GOG.com
DOSBox Game with ..." where ... can be ISO image or BIN/CUE image,
optionally with audio. There is one called "Indiana Jones and the
Fate of Atlantis CD Roland MT-32" and two called "Space Quest 4
CD Roland ..." for MT-32 or SC-55 which showcase some soundtracks.

There are 78 videos mentioning "DOS", but only 6 mentioning "CD".
Only a single video mentions "FreeDOS":

https://www.youtube.com/watch?v=zGmCVeAKR4w
FreeDOS 1.2 Review - Can it replace MS DOS for retro gaming?

It mentions that some BIOS boot the standard and some boot the
legacy image. At 1:17 he shows a screenshot which apparently
shows MEMDISK 4.05 int 13, 15 and 1e vectors, followed by the
FreeDOS kernel booting, but then crashing as soon as HIMEM loads
with invalid opcode. Probable MEMDISK-HIMEM-ELTORITO conflict?
Might be fixed in newer MEMDISK or with better boot options?

The installer asks for language, whether to overwrite the whole
harddisk, keyboard layout and amount of installed packages, for
which he suggests BASE packages only. Interesting that he likes
manual install because he can delete even more old partitions.

The boot menu seems to be the same as in 1.3, which means 1. JEMMEX
with NOEMS, 2. JEMM386 "and SHARE", 3. no drivers and 4. few drivers.
Phil recommends the first two options, but non-EMM386 options for
e.g. Turrican.

Wing Commander crashed for him with exception 06 at 1:bc0d while
DS, SS and ES are 0 and FS and GS look like real mode segments,
code at CS:IP is FE 50 9a 94, CR0=8011, EFL=33002, ESP=f076,
ESI and EDI use 32-bit values, other registers do not etc.

Phil mentions that FreeDOS uses different config.sys menu syntax,
so you cannot drop-in his MS DOS config file examples, but he has
provided FreeDOS style config and menu files for us :-)

https://www.philscomputerlab.com/ms-dos-starter-pack.html

He uses IDE DVD, K6 CPU, AGP Matrox graphics, 32 MB RAM, SD
card via IDE adapter, SB16 with wavetable board and, notably,
tried SOFTMPU. As said, with SB AWE32, you do not need SOFTMPU.

Most games worked fine for him. Screamer 2 failed to detect
the CD. Some games failed to have full sound without SOFTMPU.

Need for Speed failed to detect the CD and the message was
"cdromdirectoryentry - ERROR 2 READING DIRECTORY
/frontend\movielow\ea.tgv" (note the mixed slash directions)

Phil complains that playing "CD digital audio" does not work
at all. You can test this by inserting an audio CD and using
my CDROM2UI tool to tell your drive to start playing a track:

http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/repositories/1.3/pkg-html/cdrom2ui.html

CDROM2 [EJECT|CLOSE|LOCK|UNLOCK|RESET] X:
Audio: CDROM2 [PAUSE|CONT|INFO|PLAYnn] X:
Ask *CDEX 2.0+ if a CD-ROM exists: CDROM2 N:

Note that you will have to connect the internal audio cable.
Phil later explains that audio failed because 1.2 used an
outdated UDVD2 version. We now use the version about which
Phil says that CD audio works fine with it, so there should
be no need to switch to Acer VIDECDD for that. Given that
Phil still prefers VIDECDD over updated UDVD2, my guess is
that VIDECDD works better with some copy protection schemes?

http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/1.3/previews/1.3-rc4/report.html

Unfortunately, Phil only SUSPECTS that switching from SHSUCDX
to MSCDEX could fix copy protections, but has not TESTED that.

I wonder why Strike Commander crashes after the intro
and whether that is supposed to be a copy p

Re: [Freedos-user] FreeDOS make better compatibility with DOS games [current status]

[Eric Auer]

Hi Lukas,

> Please please I solved sound. I shared only experience. Please focus on cd
> drive not found. Forget dosbox. I use original floppy discs from 1992. Dont
> overcomplicate. Can u recommend which files replace from ms dos?

Okay then. So there was no sound problem, you just used a DOSBOX
driver outside DOSBOX? If it is supposed to work with SB16 on real
hardware, supporting MS EMM386 style I/O traps would still be one
feature that I would like to see from Japheth in JEMMEX/JEMM386 :-)

But you ask "please focus on CD drive not found". Then I ask: Please
tell me, do you have the CD in the drive? Can you access the files
on the CD? In other words, is only your game complaining, because it
does some copy protection check which has compatibility issues? Or
are you completely unable to access any files on the CD? Those are
two different problems which have two different solutions. Please
specify which versions of which drivers with which options you use.

You also have not answered those questions: Out of which memory did
the installer run? Why have you used a Windows boot floppy instead
of the real FreeDOS installer boot floppy? As you have circumvented
the problem, you are free to ignore that question if you have no
time to tell me whether the installer would still fail if you use
it properly, but I am curious.

I assume AWEUTIL /EM and Intel ICU for ISA PnP is what you have now
used to solve the MIDI sound problem, but it would be nice to know.

Also, CTCM, CTSB16 and CTMMSYS are probably not perfect for AWE32:
https://comp.sys.ibm.pc.games.rpg.narkive.com/duCiqd7H/ot-configuring-sb16-for-dos
But as long as it works for you, it is better to have a working than
to have an overly elegant solution.

As you do NOT want too complicated answers, you should wait with
MSCLIENT and SAMBA attempts until you have the easy things fixed!
This means you should not load IFSHLP at the moment, I think.

I also assume that the mouse works fine with CTMOUSE and that
your compact flash drive works great now?

As nothing is known about the Terminator 2029 problem, you have
several remaining problems, but ALL relate to the same issue:

Games which are not able to access the game CD.

To solve that problem, you could start by answering my question
whether or not you can access files on the CD outside the game.

For example, if the CD drive has letter D: then does DIR D: work
fine and show you a directory listing of the CD contents? Or is
there some error message? Which? Do you get error messages earlier
while booting, from UDVD2 or from SHSUCDX? What do those messages
say? You could also make screenshots if you prefer. You can press
F8 when DOS starts to boot: Then it will ask you for confirmation
for each line, which makes it easy to read or screenshot messages.

>>> 3) Mass Destruction PC DOS game: installs from CD, fails to start.
>>> Tried both DOS4GW and DOS32A
>>
>> It says DOS/32A warning 9003: real mode vector has
>> been modified, and exits.

According to http://dos32a.narechk.net/manual/html/user/8.htm
this is the fault of Mass Destruction itself, when it exits
without cleaning up vectors. Which leaves only the CD problem.

Regards, Eric

PS: This should be 123?DOS=HIGH and 23?DEVICE=...HIMEM... My
earlier comments about I=TEST, I=B000-B7FF NOVME and NOINVLPG
still apply. If games need EMS 3.2, you must also remove NOEMS
and you should not load IFSHLP until you have solved the rest.

>> 12?DOS=HIGH
>> 12?DOS=UMB
>> 12?DOSDATA=UMB
>> 1?DEVICE=C:\FDOS\BIN\JEMMEX.EXE NOEMS X=TEST I=TEST NOVME NOINVLPG
>> 234?DEVICE=C:\FDOS\BIN\HIMEMX.EXE
>> 2?DEVICE=C:\FDOS\BIN\JEMM386.EXE X=TEST I=TEST I=B000-B7FF NOVME NOINVLPG
>> 34?SHELL=C:\FDOS\BIN\COMMAND.COM C:\FDOS\BIN /E:1024 /P=C:\FDAUTO.BAT
>> 12?SHELLHIGH=C:\FDOS\BIN\COMMAND.COM C:\FDOS\BIN /E:1024 /P=C:\FDAUTO.BAT
>> 123?DEVICE=C:\CTCM\CTCM.EXE
>> 123?DEVICE=C:\SB16\DRV\CTSB16.SYS /UNIT=0 /BLASTER=A:220 I:5 D:1 H:5
>> 123?DEVICE=C:\SB16\DRV\CTMMSYS.SYS
>> 12?DEVICEHIGH=C:\NET\MSCLIENT\ifshlp.sys



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

Re: [Freedos-user] FreeDOS make better compatibility with DOS games [current status]

[Eric Auer]

Hi Lukas,

> Guys, I built regular 486DX2 66Mhz. I would not be that guy and put PCI
> soundcard in that machine. Of course I have ISA soundcard. I have even VLB
> slot, but I use TSENG 4000/W32p for ISA. In PCI, there is only Realtek NIC
> with XT-IDE EEPROM.

Actually Realtek PCI Network cards and older PCI, AGP and PCIe graphics
cards work really well with DOS, but you made a good choice to use an
ISA soundcard for your old games on that 486DX2 PC.

As said, your ISA soundcard is supposed to come with appropriate tools.
If it is SB16 compatible, games should be happy, but you may still have
to load some activation or volume control tool, set BLASTER and other
environment variables, maybe set jumpers. If the card is PnP, you may
have to install that large Intel DOS PnP manager thing.

> A) 486DX2 66Mhz, 32MB Ram, onboard 256kB cache. BIOS does not allow CDROM
> boot, but combination of Windows98 floppy to boot and running installation
> from FreeDOS cd works. At the end there it will crash due to out of memory.

Out of DOS memory or out of XMS, EMS or other memory? Those 32 MB
should certainly be enough for our installer, so the problem will
be something more specific than your overall size of RAM.

Note that your install style is very non-standard, because the
installer has not been tested with MS DOS 7 (from your Windows
floppy). I recommend that you use a FreeDOS boot floppy instead,
or even better, our special boot floppy for the install CD :-)

The CD installer may expect specific drivers to be loaded, while
your Win98 boot floppy may be using completely different drivers.

http://freedos.org/download/ explicitly mentions the boot floppy
for those who want to use the CD without booting it. Sorry that
you had to spent 4 hours searching other workaround approaches.

> said it is memory issue and solved also by installing FreeDOS on hard drive
> in Pentium machine. That's how I did it as well and it works. Even
> installing a lot of packages on 486, the fdimples will crash with out of
> memory while browsing packages tree and selecting many packages.

That sounds as if FDIMPLES had too little DOS memory free? Anyway,
while the solution to install your target harddisk into a PC which
CAN boot from CD is very nice, it does not really tell me which
solution would have worked for the 486 and whether it was really
the amount of memory. 32 MB sounds very okay. Maybe it was the
amount of DOS memory, because the Win98 floppy loaded too many
unnecessary drivers or something like that?

> B) I have Realtek original DOS packet driver, default interrupt 0x60. No
> problem with that. Just documentation for MTCP tells me to install FDNET

Ah okay. I think if you have the Realtek (8139 or similar, I guess)
packet driver anyway, you only have to complete some config settings
for mTCP and the packet driver. No need to install extra components
as far as I know. Ask Michael Brutman (e.g. here) for config hints :-)

> C) I have Sound Blaster AWE 32 and AWE 64.

The AWE 32 is pretty cool for DOS games! I remember that it came
with a volume control tool and a setup-at-boot tool and that it
was recommended to install the intel plug and play configuration
utility: https://drivers.dosreloaded.de/Plug&Play/Intel%20ICU/

> I have sound + cdrom + network (including Samba support) with dhcp +
> mouse + compact flash working. Everything is working on this side.

Sound should be relatively easy. For CDROM, use the three drivers
which I have recommended. You may replace UDVD2 by whatever came
with your CD/DVD drive, but UDVD2 probably works better.

Networking with Samba is a bit complicated to configure, but Bryan
and Frantisek have recently done that for Bryan's computers, so
they can probably share some tricks.

Mouse (PS/2 or RS232) should be easy, too: Use CTMOUSE. If you have
USB mice, modern BIOS will have some legacy support which translates
it to a simulation of PS/2 which you can use in CTMOUSE. If you have
an old BIOS, you can try Bret Johnson's USB drivers.

Not sure what you mean by compact flash, do you mean a card reader
or do you mean a purely mechanical adapter to connect CF to your
IDE/ATA connectors on the mainboard? The latter should work without
any drivers, but you cannot change "disks" while DOS is running and
you may have to be careful to use proper geometry and partitioning.

> some games install from CD and won't run because they complain cannot find
> CD. Mostly computer will seek floppy drive A: when searching for CD. I
> guess it is some kind of copy protection.

No idea, but I assume you do have CD drivers loaded and working in
general? In that case it would be interesting to know whether there
is indeed a copy protection using exotic functions which differ in
how SHSUCDX and UDVD2 differ from MSCDEX and ancient CD-ROM drivers?

> So making ISO image will not work unless you...

I would not be too sure about that. Simple copy protections might
already be happy with finding the "actual" CD as CD or ISO,

Re: [Freedos-user] FreeDOS make better compatibility with DOS games [current status]

[Eric Auer]

Hi Lukas,

> Please help with solution, don't waste time with asking why and why

You will have to ask specific questions when you want
specific answers. If you want to visit your uncle, it
does not help to tell your taxi driver "bring me to
my uncle, do not ask me where he lives" either ;-)

You will not have to "hack your way around", you simply
have to patiently describe the problem so we can give
answers which fit the problem, too.

You mentioned that UDVD2 is outdated. Updates are here:
http://mercurycoding.com/downloads.html#DOS

I certainly agree with Michał that FDNET should be there,
as far as network driver licensing permits distribution.
For the rest, we should offer vendor download links.

Not sure why Michał mentions Yamaha YMF724 drivers, do
you have a Sound Blaster 16? Or do you have a sound card
based on Yamaha YMF724? Which sound card do you two have?

As Michał already said: If your game has a problem with
our brand of EMM386, simply try without EMM386. Easier
than hoping for MS EMM386 to work better, which may or
may not be the case :-)

Also, in the unlikely case that your game even has some
problem with our HIMEM, you can use XMGR instead, same
download link mentioned above.

No idea why Michał is so negative about our HIMEM and
EMM386 versions and even our filesystem checking and
repair tools. Actually FreeDOS includes DOSFSCK which
is the same tool which you would also use in Linux :-p
The Linux DOSFSCK version is updated more often, though.

I disagree with Michał about completely avoiding parts
of MS DOS. I kept QBASIC from MS DOS for quite a while,
as far as I remember. Now there is the big FreeBASIC.

Of course this is no option when you have no license for
MS DOS, but even if you have one, MS DOS is extremely old
and for many components, the FreeDOS versions are better.

Cheers, Eric



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

Re: [Freedos-user] FreeDOS make better compatibility with DOS games [current status]

[Eric Auer]

Hi Lukas, thanks for testing!

> Hi, the current status for FreeDOS 1.3 RC4:
> A) cannot install from CD on 486 due to low cache or low memory

How much memory does your 486 have? Can it boot from CD?

> solution is to install on Pentium, then put the drive in 486
> 
> B) FDNET has been removed, for networking download FDNET from FreeDOS 1.2
> if you need

Then we should include FDNET again, if possible. This might
depend on licenses for individual drivers, BUT as suggested
earlier, we could include a PCISLEEP based shell script to
tell you where to download the driver for your specific
network controller in cases where we cannot include it :-)

> C) CDAudio is working, but you have to install proper Sound Blaster
> drivers and also open the mixer to unmute CD Audio (set volume)

It is normal for DOS compatible soundcards that they are
bundled with the appropriate drivers, but we cannot usually
distribute those proprietary drivers ourselves. Which model?

> *I NEED HELP WITH THIS:*
> *1)* If game has problem with DOS4GW.EXE, just replace it by DOS32A.EXE
> from C:\FDOS\BIN (copy and rename to DOS4GW.EXE in game's directory =>
> sometime can even speed up the game)

While this is a trick which has been used before, I would
not suggest to make it the default. Instead, we should
advertise the trick, so users can decide themselves :-)

Which problems occur with which games, specifically?

> *2)* Most of CD games will report CD is missing and are unable
> to start ==> this is important => how to fix it? Use MSCDEX?

Please be more specific. Which CD games? What type of CD drive
are you using? Which drivers do you load? I recommend that you
load the following:

1. UHDD
2. UDVD2
3. SHSUCDX

This gives you a disk cache and fast, cached CD/DVD/BD access
for ISO9660 media. SHSUCDX is our alternative to MSCDEX. You
can even use SHSUCDHD to open ISO image files and pretend that
they would be a CD. If your controller is not IDE, ATAPI or
classic SATA, you can replace UDVD2 by AHCICD from R. Loew:

https://rloewelectronics.com/distribute/AHCICD/1.1/ for AHCI
which is a non-backwards-compatible SATA mode. Sometimes, you
can also use BIOS settings to switch to a non-AHCI SATA mode.

> *3)* A lot of games will crash because of JEMM386 exception ==> how to fix?
> Use MS-DOS 6.22 or Windows 98 MS-DOS 7.1 EMM386? What do you think? Can you
> please help what to copy from DOS 7.1 or DOS 6.22? I have original discs.

A far easier solution should be to not load JEMM386 unless
you really need UMB or EMS :-) Also, you have the choice
between JEMMEX and JEMM386, does one of them work better
than the other? What EXACTLY is the way in which which
game crashes? If you have a SB PCI or SB LIVE or similar
PCI soundcard, you may need special command line options
for JEMMEX or JEMM386 to enable compatibility mode with
the special protected mode use of their PCI sound drivers.

To answer your other question: You would simply copy the
EMM386 EXE file from MS, but this driver is very outdated
so it could actually work worse than our newer driver ;-)
> Can 100% MS-DOS gaming compatibility be made by copying
> some files from MS-DOS?

You really have to tell us FAR more details about which
games fail in which way and which drivers you have loaded
and which hardware you have. Unless you have a classic
ISA Sound Blaster of some sort, you can expect that the
sound will be the main problem for your games. This does
not depend on the brand of DOS, however, so using MS DOS
will not help Commander Keen to use your HDA sound either.

> Some example of working FDCONFIG.SYS and FDAUTO.BAT with
> these files would be very nice!

I suggest the other way round: Tell us what is in your
fdconfig and fdauto (or just use config.sys and autoexec
bat! Only if you have both, FreeDOS prefers the FD ones,
to be more exact, it prefers fdconfig and then uses the
autoexec mentioned in the shell line) and tell us which
hardware and games you try to run, with which errors. I
can then tell you what you could change in your config.

That would be better than blindly recommending you some
complete config. After all, most things already work with
the config which you have adjusted to your own situation.

Regards, Eric



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

Re: [Freedos-user] CMDLINE

[Eric Auer]

Hi Paul,

> Thanks Eric - 32766 solved the problem!

Good, could you file a ticket on that github to
update the documentation to stop saying "32768"
instead of the correct 32766? Thanks! :-)

> C:\DEVEL\binutils-2.14a>gcc386 -S temp.c j
> d
> dd  jj 
> doing CreateFile with Xtemp.cX
> cc1: temp.c: An error has occurred
> 
> This isn't!
> 
> C:\DEVEL\binutils-2.14a>gcc386 -S temp.c
>  bb
> bbb jj
> k
> 
> Commandline longer than 125 characters.
> Exception 0D
> EAX=0282 EBX=549D ECX=0003 EDX=0274 ESI=0100
> EDI=0100 EBP=5898 ESP=5702 EFL=00013246 EIP=09FE
> CS=0097 (00111000,58CF,00FB) SS=008F (00111000,58CF,40F3)
> DS=009F (00029AF0,010F,00F3) ES=00D7 (000298C0,00FF,00F3)
> FS= (,,) GS= (,,)
> LDTR=0038 (FF80F000,0FFF,0082) TR=0030 (0002F770,0067,008B)
> ERRC= (,,) PTE 1. Page LDT=1FFEF467
> GDTR=07FF:FF80E000 IDTR=07FF:FF80E800 PTE CR2=0067
> CR0=E031 CR2= CR3=1000 CR4=0200 TSS:ESP0=2898
> DR0-3=    DR6=0FF0 DR7=0400
> LPMS Sel=0087(01) RMS=31F6:0200 open RMCBs=/ ISR=
>   [EIP]=F3 67 A4 F7 C7 00 FF 75 03 B0 0D AA

That would be "rep a16 movsb" if the task is 32-bit?
If the GPF is caused by ESI=EDI=100, maybe the "FF"
in the description of ES refers to segment length?
Which could mean a pointer overflow?

Does the ECX in the error message get larger when you
make the command line longer? If yes, it could mean
that something tries to copy the over-long command
line into the PSP?

> I think it is an HX problem, so I'll report it to Japheth.

No idea, but you could use another DPMI provider, such
as CWSDPMI, which would be the default for DJGPP?

Regards, Eric



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

Re: [Freedos-user] CMDLINE

[Eric Auer]

Sorry, I have to correct myself: According to

https://github.com/FDOS/freecom/blob/master/shell/init.c#L440

the REAL maximum possible environment size right
now is "only" 32766. Not 32767 and not 32768, but
FreeCOM texts (in all languages) claim it is 32768.

If you specify values below 17 or above 32766, some
default size of the environment will be used instead.

Regards, Eric



> Hi Paul,
> 
>> I believe that command.com can get involved in
>> the CMDLINE environment variable, just like any
>> other program can. And if it can't, it should say
>> so, rather than reporting a failed attempt to set it.
>>
>> C:\DEVEL\PDOS\SRC>ver
>>
>> FreeCom version 0.84-pre2 XMS_Swap [Aug 28 2006 00:29:00]
> 
> This seems to be the oldest version with CMDLINE at all:
> 
> https://github.com/FDOS/freecom/blob/master/CHANGED
> 
> Actually there seems to be a documentation error:
> The REAL maximum value of 16-bit signed integers
> is 32767 and not 32768 bytes. Try /E:16384 of, if
> you are less humble, /E:32767 :-)
> 
> https://github.com/FDOS/freecom/blob/master/shell/init.c#L102
> 
> Regards, Eric
> 
> PS: I suggest to include a NEWER version in our distro!




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

Re: [Freedos-user] CMDLINE

[Eric Auer]

Hi Paul,

> I believe that command.com can get involved in
> the CMDLINE environment variable, just like any
> other program can. And if it can't, it should say
> so, rather than reporting a failed attempt to set it.
>
> C:\DEVEL\PDOS\SRC>ver
> 
> FreeCom version 0.84-pre2 XMS_Swap [Aug 28 2006 00:29:00]

This seems to be the oldest version with CMDLINE at all:

https://github.com/FDOS/freecom/blob/master/CHANGED

Actually there seems to be a documentation error:
The REAL maximum value of 16-bit signed integers
is 32767 and not 32768 bytes. Try /E:16384 of, if
you are less humble, /E:32767 :-)

https://github.com/FDOS/freecom/blob/master/shell/init.c#L102

Regards, Eric

PS: I suggest to include a NEWER version in our distro!




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

Re: [Freedos-user] CMDLINE

[Eric Auer]

Hi Paul,

commands with their arguments are indeed limited
in length in DOS. As far as I remember, if you
use DJGPP based apps (including for example BASH
as shell) then they can exchange longer command
line arguments with each other by storing them
in environment variables, but I do not think that
command.com participates in this method. Also, I
am not sure whether /E:32768 is possible. There
could be a lower limit for allowed env sizes.

Which command.com version and which version of
hexdump are you using? As far as I remember,
neither MS DOS nor FreeDOS command.com use the
CMDLINE mechanism, maybe you mean the shell
(terminal) window of Microsoft Windows?

Regards, Eric



> Can someone please explain the below:
> 
> C:\>hexdump
> 
> 
> 
> bb
> Commandline longer than 125 characters.
> Can not set environment variable 'CMDLINE'.
> Environment full?
> C:\>grep shell config.sys
> File CONFIG.SYS:
> shell=c:\command.com /p /l:1024 /e:32768
> C:\>
> 
> "hexdump" is just a simple MSDOS program and it doesn't
> make any difference which program I try to execute.
> 
> It looks to me like command.com is doing the exact right
> thing, trying to set the CMDLINE variable for the long
> parameter, but I have no idea why it would fail to set it.



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

Re: [Freedos-user] Hold the date: FreeDOS Virtual Get-Together Sunday June 20 at 11am US Central

[Eric Auer]

Hi Bryan,

>> I wanted to plan another virtual get-together. Please hold the date
>> for *Sunday, June 20* at 11am US/Central.

> Here that will be 2 AM Monday!

> František Ryšánek has kindly been helping me network via Ethernet, a
> FreeDOS PC with two Ubuntu computers. Currently file sharing works
> between all three, using Samba.

Cool, do you two plan to write a how-to about it? :-)

Regards, Eric

PS: It seems there is an UNetbootin LiveCD/USB boot issue with FreeDOS?



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

Re: [Freedos-user] Virtualbox Networking Issue

[Eric Auer]

Hi again,

> Hi Ralf, I actually can't use traceroute to find the problem. This is in a
> VM and as far as I know traceroute doesn't exist for FreeDOS.

According to

http://www.bttr-software.de/freesoft/comm1.htm

there is a traceroute (tracert) included with wattcp32.

Other implementations could exist as well, but for example
classic 16-bit Watt/TCP and Brutman's mTCP do not seem to
include it. I probably overlooked a number of traceroutes.

Regards, Eric



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

Re: [Freedos-user] Virtualbox Networking Issue

[Eric Auer]

Hi!

> Unfortunately it does actually seem to be a networking issue. I just tried
> to wget the current fdnpkg file from ibiblio.org and it failed, reporting:
> "Resolving www.ibiblio.org... failed: No address associated with hostname.

Note that 8.8.8.8 is a nameserver outside your house, you could try
to set the IP of your network router or modem as nameserver. Those
often provide DNS proxy or cache services. Also, you could try DHCP,
which automatically asks the local network for suitable configuration.

In DOS, the disadvantage of DHCP is that it might have to ask again
for each network access, because there is no permanently active DOS
network running in the background: Only apps themselve use the net.

One idea would be to check another Linux or Windows computer in your
network to see which setting those use and derive one for DOS from it.

Regards, Eric



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

Re: [Freedos-user] FAT12

[Eric Auer]

Hi Dan,

the rationale for the "lite" installer to use FAT12 is
that it would fit on the most tiny USB sticks that way.

Which is something I also have complained about, because
nobody has ONLY THAT SMALL sticks available today ;-)

Note that there are different partition types for FAT
with and without support for 32-bit sector numbers, so
my preferred type would be "FAT16 between 32 MB and 2 GB"
for the installer image. No FAT12, no "max 32 MB" types.

Even when this means you cannot resize the installer
partition to more than 2 GB, it should still give you
plenty of space and you could add some FAT32 partition
of arbitrary size to make use of the rest of your drive.

I assume your report is about the type of the partition
on the install medium itself, not about the partition
on your target drive when you install to a built-in SSD
or harddisk in your computer? Be warned that FreeDOS is
NOT able to resize and preserve existing partitions, so
installing it to harddisk or SSD will cause data loss if
you already have other data there!

However, if you already have a primary FAT partition on
the target drive, you could install FreeDOS there without
formatting or partitioning the drive. If you have another
bootable OS on the partition, using FreeDOS SYS will of
course replace the boot sector and make the previous OS
no longer boot. Installing a boot menu is possible, but
requires some expertise and work to do properly.

Regards, Eric

> I've installed FreeDOS 1.3-RC4 with FD13LITE.img on a 4GB USB drive. This
> works and I can boot it just fine, but the primary partition uses FAT12 and
> is 97% full. I would like to expand this partition with gparted, but that
> no longer supports FAT12. Can I ask what the rationale is for using FAT12?




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

Re: [Freedos-user] DOS Related source code

[Eric Auer]

> Also, to be pedantic, I found e.g. the Microsoft C compiler
> on Vetusware, and it has quite a bit of example code.

Note that vetusware is about abandonware, so you will also
find things with questionable licenses there. Which is of
course not recommended in FreeDOS context.

Eric



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

Re: [Freedos-user] DOS Related source code

[Eric Auer]

Hi Martin,

> Are there any good lists of DOS software available
> (or that used to be available)?

I guess you mean commercial software, not just this?
Or at least shareware, freeware etc.? All old stuff?

https://gitlab.com/FDOS

Or the up to 20 GB (?) here:

http://www.ibiblio.org/pub/micro/pc-stuff/freedos/

in particular

http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/

and

http://www.ibiblio.org/pub/micro/pc-stuff/freedos/ftp.sunet.se/pub/simtelnet/gnu/gnuish/

or all the DOS ports here:

http://www.delorie.com/djgpp/ (do use the ZIP picker!)

Hmm Chrome and Firefox no longer support FTP? What the...?

http://www.delorie.com/djgpp/dl/ofc/dlfiles.cgi/current/v2gnu/

Mirror: http://djgpp.mirror.garr.it/current/v2gnu/

http://www.delorie.com/djgpp/dl/ofc/dlfiles.cgi/current/v2apps/

http://www.delorie.com/djgpp/dl/ofc/dlfiles.cgi/current/v2tk/

The FreeDOS website also has a number of links:

*entry point* http://freedos.org/links/ *check this out*

Many of those link to LONG lists of DOS things themselves:

Dosgames.com hosts almost 1500 games and you can even play
them inside the browser in an in-browser PC emulator :-)

Dosgamesarchive.com has over 1000 games as well.

RGB Classicdosgames.com is "small" with 500 games, but they
mention GOG which originally also had commercial DOS games:
At the moment, they only have Linux, Windows and OS X games?

On archive.org you can find 7000 pieces of old DOS software,
which seems to include a lot of abandonware? They also have
that "play in a dosbox in your browser". For example this:

https://archive.org/details/msdos_Bananoid_1989

There are way more than 100 CD-ROM full of DOS software on

http://www.retroarchive.org/cdrom/index.html

And you know that a lot of DOS stuff can fit on a single CD:

http://annex.retroarchive.org/cdrom/cotc-1/index.html

for example has more than 1000 ARJ packages with all sorts
of stuff. Quality is VERY mixed, but I guess you understand
that writing Wikipedia articles about every DOS package out
there would be impossible ;-)

Maybe a fun example: Speedkit 4.52 including HYPERDISK cache:

http://annex.retroarchive.org/cdrom/cotc-1/UTILITY/index.html

Note that Linux does not normally come with UNARJ, but our
Arachne browser package has it.

You probably also remember VGACOPY diskcopy with MOD music:

http://annex.retroarchive.org/cdrom/cotc-1/DISK/index.html

> I want to see if we can create a list with as much DOS software as possible
> and put that on the FreeDOS wiki.>
> Yes, it is going to be a big list, so I'm also asking for your help.
> 
> A starting point may be wikipedia, but they lack a lot of DOS software of
> course.
> https://en.wikipedia.org/wiki/Category:DOS_software

Those are only 160 pages ;-) On the other hand, 2300 (!)
DOS games already have Wikipedia articles:

https://en.wikipedia.org/wiki/Category:DOS_games

So... There might be chances to describe more DOS things, but
you can normally assume that almost everything has been done
before - the problem would be to bundle it. If you know the
name of the software, you will probably find it in some old
archives of shareware, freeware, abandonware and so on. But
making a list of everything which exists? Sounds adventurous.

Regards, Eric



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

Re: [Freedos-user] Forwarding and commenting a FreeDOS 1.3rc3 critical review

[Eric Auer]

Hi Robert, thanks for the reviews and details :-)

In short I suggest to add INFOPLUS, DOSZIP and DN to default install...

>>> Once I received (TASM) source code for
>>> 
>>> under "do whatever you want this it, but don't bug me".

Seems quite "benchmark oriented" (CPU, disk, RAM, PCI bus list etc.)

>  for an example.

>>> MSD is really nice for early hardware and easy to use.
>> Which features does it have which COMPINFO is lacking?
> 1) It doesn't barf on Windows XP. COMPINFO always gives me RTE 205.

Internet says this is a floating point error if Turbo Pascal?
Maybe trying to detect FPU in a way which upsets the protected
mode host? How well does it behave with various (J-) EMM386?

> 2) Here's a screenshot of the main window of MSD:
> https://winuxinfocenter.de/wp-content/uploads/2018/09/msd1.png

That lists: BIOS string, base/EMS/XMS size, VGA string, network,
kernel version, mouse version, joystick, drive letters, printer
and serial ports, Win 3.x, IRQ, TSR, drivers. As everything has
sub-menus, I guess it shows some BIOS-reported values, stats from
the memory drivers, strings and screen modes from VGA BIOS, some
unknown network details, mouse status details, stats about drive
letters, maybe status flags and settings for serial and printer
ports, which IRQ handler is in which area (BIOS, drivers etc.?)
and shows some nice TSR and driver overview with more status in
comparison to MEM output.

 https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/util/system/compinfo/
>>> - FOSS (GNU GPL & GNU LGPL)
>>> - it's already there
>>> - no docs
>>> - C and Pascal versions avaiable
>>> - "unfree" toolchain (Turbo Pascal)

> I dunno. I also couldn't get it to work in MS Virtual PC. Same RTE 205.

See above, floating point or EMM386 issue maybe?

>>> Also "unfree" toolchain (TP+ASM):
>>> INFOPLUS by Andrew Rossmann, last updated in 1993, public domain
>>> https://ftp.sunet.se/mirror/archive/ftp.sunet.se/pub/simtelnet/msdos/sysinfo/ifp1p158.zip
>>> https://ftp.sunet.se/mirror/archive/ftp.sunet.se/pub/simtelnet/msdos/sysinfo/ifp1s158.zip
>>> (binary, sources)
> It's very complete for it's time and is very similar to MSD.
> But because of it's age, it doesn't show anything about PnP, PCI

Neither does MSD, so INFOPLUS sounds very good.
I guess it also is a lot better than COMPINFO.

> I prepared some screenshots: https://www.bttr-software.de/tmp/infoplus/

BIOS string, CPU ID, RAM ID, MEM, graphics ID, graphics modes,
keyboard and mouse, parallel and serial ports, sound, DOS info,
"multiplex programs", environment variables, device drivers,
DOS and BIOS drive info, partition table, boot drive info, CMOS
info, TSR and drivers, "alternate multiplex", memory managers.

That sounds as if it is significantly better than MSD itself :-)

>> DOSZIP sounds like something to agree upon?
> Yes. It's small, fast, FLOSS.

Nice!

>> DOS Navigator, open source variant: Pros/Cons versus DOSZIP?

Pro: Editor, text screen grabber, calculator, calendar,
ASCII table, phone book, small spreadsheet, CD player,
flexible terminal, "navigator link", Tetris...

Very nice. I guess we could include both DOSZIP and DN OSP :-)

>> https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/util/disk/
>>
>> has Ranish, XFDISK, SPFDISK and FDISK, even FIPS and file managers,
>> apparently incl. DOS Navigator (1.51, 2.14, no NDN any more?) while
>> https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/util/file/
>> is where file managers should be and DOSZIP actually is, alone, now?

Cheers, Eric



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

Re: [Freedos-user] Print via USB

[Eric Auer]

Hi Bryan & Frank,

> As you had suggested, on the FreeDOS PC, in C:\MSNET\ I entered "start".
> Then I could ping from that PC to my printer, Ubuntu PC and Ubuntu laptop.

Cool! Thanks for creating the network zip :-) What is
in that start bat file and which packages with which
licenses are required to make this become a reality?

> I had worried that the DOS machine on my network, would 
> give easy access from the Internet for gremlins!

Because DOS normally does not run any servers, there is
not much which the gremlins could access. So it depends
on which servers you manually start on DOS: I guess the
plans to talk to your printer will not require anything
server-style to run on DOS, so you should be safe :-)

Regards, Eric



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

Re: [Freedos-user] Print via USB

[Eric Auer]

Dear Bryan,

> My FreeDOS PC's FDCONFIG.SYS file now says this.
> Should I put `!' before the BREAK and STACKS statements?

That is not necessary. Actually I find it a bit odd that
the default config used ! so frequently. Tastes differ :-)

Eric




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

Re: [Freedos-user] Forwarding and commenting a FreeDOS 1.3rc3 critical review

[Eric Auer]

Hi Robert,

> Once I received source code for
> 
> under "do whatever you want this it, but don't bug me".
> 
> I think, it's a 1.75 WIP version, so I'm not sure, it works or even
> builds. (Requires TASM to build.)
> 386+ required.

How well does it work? I think TASM is what that NoMySo (not my
source) script can use as input to translate to free assemblers?

>> I remember that MS DOS came with MSD (and MEMMAKER, a wizard to
> 
> MSD is really nice for early hardware and easy to use.

Which features does it have which COMPINFO is lacking?
>> As you can guess, FreeDOS is missing cool apps here. How about
>>
>> https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/util/system/compinfo/
>>
>> Would COMPINFO be sufficient?
> 
> Pros:
> - FOSS (GNU GPL & GNU LGPL)
> - it's already there
> 
> Cons:
> - no docs
> - C and Pascal versions avaiable
> - "unfree" toolchain (Turbo Pascal)

I would not worry too much about the toolchain. How much
work would it be to write documentation?

PS: would anybody want to donate work to update FreeDOS
MODE documentation? It still mentions "park disk", which
is a long-gone feature and does not yet mention codepage
and "modern text mode" support, see MODE /? for info:

https://gitlab.com/FDOS/base/mode/-/blob/master/DOC/MODE/MODE.TXT

> Also "unfree" toolchain (TP+ASM):
> INFOPLUS by Andrew Rossmann, last updated in 1993.
> License is public domain.
> https://ftp.sunet.se/mirror/archive/ftp.sunet.se/pub/simtelnet/msdos/sysinfo/ifp1p158.zip
> (binary)
> https://ftp.sunet.se/mirror/archive/ftp.sunet.se/pub/simtelnet/msdos/sysinfo/ifp1s158.zip
> (sources)

Nice license! How does it compare to MSD etc. feature-wise?

> There are probably more gems at https://www.sac.sk/files.php?d=13&l=

Happy gem-hunting! (insert game music here)

>> How about file managers? NDN (Necromancer's DOS Navigator at
>> ndn.muxe.com) apparently has closed sources, but even supports
>> 64-bit DPMI in DOS now? A free version of DOS NAVIGATOR, with
>> sources: https://www.ritlabs.com/en/products/dn/
>>
>> The https://sourceforge.net/projects/doszip/ Doszip Commander is
>> yet another Norton Commander clone, as is the open source CONNECT
>> shell from http://www.dorlov.no-ip.com/Connect/ Some of the file
>> managers already are packaged for FreeDOS distros on ibiblio:
> 
> I list some more on: https://www.bttr-software.de/links/#fileman
> 
>> So... Suggestions please :-) Which 1. SYSINFO TOOL, 2. FILE MANAGER
>> and 3. PARTITION EDITOR should be installed by default, used during
>> installation, be made available on the Live CD, etc.?
> 
> SI:
> - Info+
> - (one day...) System Speed Test
> 
> FM:
> - DOSZIP

DOSZIP sounds like something to agree upon?

> - DN OSP

DOS Navigator, open source variant: Pros/Cons versus DOSZIP?

> PE:
> - Ranish?

Maybe a bit too different? How about the classic XFDISK, SPFDISK,
AEFDISK? I guess AEFDISK is more for scripts and SPFDISK is not
part of the distro? How would you people like XFDISK then, in
comparison to Ranish? I think XFDISK deserves an upgrade from
being only on the Bonus CD. Ranish is not in the distro now?

https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/util/disk/

has Ranish, XFDISK, SPFDISK and FDISK, even FIPS and file managers,
apparently incl. DOS Navigator (1.51, 2.14, no NDN any more?) while

https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/util/file/

is where file managers should be and DOSZIP actually is, alone, now?

Cheers, Eric



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

Re: [Freedos-user] Print via USB

[Eric Auer]

Dear Bryan,

feel free to notify the bootablecd.de maintainer that you
would prefer less contrast for the Blinky mascot background
to distract visitors less from reading the text on the page.

> My FreeDOS PC's FDCONFIG.SYS file contents follow.

That seems to be one of the default versions. Indeed ! marks
a line as "always use" while ? marks it as "ask user". Note
that there are a few bugs in the config, which I have listed
in a mail about 1.3rc3 or rc4 recently.

> 1?DEVICE=C:\FDOS\BIN\JEMMEX.EXE NOEMS X=TEST I=TEST NOVME NOINVLPG
> 2?DEVICE=C:\FDOS\BIN\JEMM386.EXE X=TEST I=TEST I=B000-B7FF NOVME NOINVLPG

> device=DOS\JEMMEX.EXE X=TEST NOEMS

You could edit the "1..." line above by removing I=TEST NOVME NOINVLPG
to make it match the FD_NET example, while still being menu-driven: It
will still only be loaded when you select menu option 1 at boot.

Other differences worth copying are:

> break=off
> buffers=30
> stacks=0,0

You can add those lines to your config, at any place, but for
readability, I recommend "nearby the old settings for those".
Of course, you remove the "!buffers=20" in the old config.

> SHELLHIGH=C:\COMMAND.COM /E:4096 /P

That actually makes a big difference to your old

12?SHELLHIGH=C:\FDOS\BIN\COMMAND.COM C:\FDOS\BIN /E:1024 /P=C:\AUTOEXEC.BAT

The old line expects command.com to be in c:\fdos\bin\
while the FD_NET line has it in c:\ so only change the
old line if you want to use the command.com in the new
location.

Also note the different /E: values: They define how
much space you want for environment variables and you may
have to go from 1024 to 4096 if the network config needs
that much space.

Apart from that, I think you can keep your existing config.

I assume you have already added things from the FD_NET
autoexec to your existing autoexec? Which changes have
you applied to load the network things? Any other config
sys or fdconfig sys changes not mentioned in your mail yet?

Note: When FreeDOS finds a fdconfig.sys file, it will use
that and ignore config.sys, but if it does not find one,
it will use config.sys like any other DOS. So it will not
use both files at the same time. Check which one you use.

Eric



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

Re: [Freedos-user] FreeDOS and screen readers for blind users

[Eric Auer]

Hi Felix,

> The primary reason is that I want to keep Windows on my hard
> drive and I don't feel confident about using a boot manager.

Disclaimer: The following only works if your Windows C: drive
is NTFS! It does not work with ancient Windows on FAT C: drive.

You could try the following: Use Windows itself to resize
the NTFS Windows partition and add a FAT16 or FAT32 one
for DOS, which you format also using Windows. Note that
the FAT partition should be a primary one if you want it
to be bootable.

You can now boot a DOS installer and verify that it only
sees the empty FAT partition, but not the Windows drives.

Make sure that the installer does NOT change partitioning
or MBR boot settings. You can also skip formatting steps.

Once you have installed DOS in that way, you can either
use a boot manager on USB, floppy, CD, DVD or similar to
start the installed DOS, or you can use a simple DOS boot
disk (for example USB stick again) and enjoy having all
the apps and space on your DOS C: drive, which you will
also be able to access from Windows. Note that it will
be called another letter, not C:, when you access your
DOS drive from Windows.

This avoids possible speed and stability issues which
you would get by working only with USB. It also avoids
having to push a boot manager before Windows, risking
that Windows would not start properly.

Of course the "recipe" above only works for the newer
Windows versions: Those use NTFS for themselves, which
is conveniently invisible to DOS, so it will not mess
with your Windows files. And they already include the
tools to resize and add partitions, so you can insert
a FAT partition with less risk of damaging your Windows.

As Linux user, I would probably use a bootable CD, DVD
or USB distro and the graphical gparted tool to resize
my existing partitions and add new ones. Not sure whether
that can be done in a screen reader friendly way, but of
course I do not know whether the tools included with the
newer Windows versions are screen reader friendly either.

>> that is what your ASAP app does.
> 
> Yes, that's exactly what it's for. It's the Automatic Screen Access
> Program, a sophisticated tsr for blind users that actually lets me
> navigate graphics memory like a text file, and that also intercepts
> console output in many cases. It's a masterpiece of assembly language

Cool, thanks for the explanation!

Best, Eric



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

Re: [Freedos-user] FreeDOS and screen readers for blind users

[Eric Auer]

Hi Felix,

given that you have a hardware serial port speech synthesizer,
there is a lot more optimism now! By the way, why do you want
to boot from USB? While many PC can boot from USB, the access
speed can be quite low and a few BIOS fail to support writes.

I assume you also have the right DOS software to fetch the
on-screen text and send it to the serial port, but I guess
that is what your ASAP app does.
Eric




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

Re: [Freedos-user] FreeDOS and screen readers for blind users

[Eric Auer]

Hello Felix!

Not sure what the license of the ASAP screen reader is?

If I understand you correctly, it sends the text or an
encoded version over a serial port to the host OS, in
your case Windows? What is the license of the text to
speech tool on the Windows size?

Have people tried to do the same with Linux? There are
free blind-friendly tools for Linux, such as Braille
(BRLTTY) and text to speech output, Some distros make
it easy to activate those. Once you have those, either
use the general feature to make the contents of your
DOS window audible (e.g. dosemu2 or dosbox). You can
also run dosemu2 in terminal mode, so you can use the
default settings for making the contents of any Linux
terminal window audible.

If I understand you correctly, you like the navigation
and user interface of the DOS ASAP screen reader and
would prefer to use that to decide which text should
be sent to a separate text to speech in the host OS.

That could be for example MBROLA, eSpeak, Festival,
or FreeTTS. I remember having configured dosemu1 to
capture printer port data while I was developing the
"graphics" screen print tools for FreeDOS (ESC/P, HP
PCL, PostScript) so I guess redirecting serial port
data to some TTS would also be feasible with dosemu2.

Whether ASAP can be included with FreeDOS depends on
whether it is free and/or open source. Please tell.

Yes, you can boot FreeDOS from USB flash drives on
many computers which can boot from USB storage media.

Whether you have write access to the USB stick from
which you have booted depends on your BIOS: There
have been reports of computers where no writes were
supported or writes have been slow. Normally, I do
expect it to work, with limited performance. Note
that you must not change USB sticks after booting.

If you use DOS USB drivers, you get more flexibility
than when using BIOS USB boot drivers, but you will
need a driver which supports your specific hardware.

The biggest problem will be that you wanted a DOS
text to speech system which can run as a driver and
access HDA or AC97 sound hardware. This is highly
unlikely to exist: Modern text to speech needs a
lot of RAM and only a few apps such as MPXPLAY do
have the complex sound drivers needed for HDA etc.

So the text to speech would have to live in some
protected mode ecosystem, making it DOS instead
of the speech synthesizer being the background
task. Which in turn would be similar to the more
obvious option of using a Linux or Windows speech
synthesizer and letting DOS run inside a window,
which also avoids having to port a synth to DOS.

Of course you could also work with 2 computers:
One running plain DOS and the other, connected
via serial or bidirectional parallel port, would
run some text to speech system on any other OS.
That could even be a Raspberry Pi, for example.

Regards, Eric

> Long story long: Joseph Norton put together a FreeDOS bootable
> installation ISO with a DOS screen reader, becoming my hero in the
> process, and using this I was able to install FreeDOS on a virtual
> machine using a Windows-hosted speech synthesizer emulator listening
> on a virtual serial port. ASAP, from deep within DOS, sends its output
> to a serial port of my vm which is mapped to one end of a pair of
> COM0COM ports. On the other end I have a speech synthesizer emulator
> picking up that output and transforming it into actual speech using
> ESpeak...



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

Re: [Freedos-user] FreeDOS on UEFI and other present and future hardware tricks

[Eric Auer]

Hi Tom,

> now it would be interesting to hear about these 'heavy' updates, that
> happened completely in the dark for FreeDOS developers.
> 
> what do they do? fix bugs? improve compatibility? where are they
> documented?
> 
> it would be cool to let the freedos kernel developers decide if these
> changes are out of scope, or if cherry picking might be possible and
> worth the effort.

Well, have a look: https://github.com/dosemu2/fdpp/

My impression was that there are many changes related to pulling
the whole thing over into the dosemu2 Linux space and changing
the structure mixed with a variety of changes to improve for
example compatibility with apps. The new structure and style
has enabled some Valgrind checking, so potential bugs found by
that also have led to patches. The number of commits was too
high to even start looking at which of them are cherries, alas.

Apparently a few patches have already been backported, maybe by
Jeremy or Andrew, but as you know, Jeremy rarely talks about the
kernel work so I know very little about such plans and successes.

You can probably check https://github.com/FDOS/kernel

One example is changing how int 2f.1217 deals with pending CDS:

https://github.com/FDOS/kernel/commit/0dc6a02450ff170101ce911cf9f628187d17fe2f

This makes the kernel work with lredir drives in dosemu2 even
when no fake FAT "seed" is used (dosemu2 provides a FAT illusion
for C: during boot so you can boot from a Linux directory). In
dosemu1, there was a workaround in the emulator, but that had
to keep track of (potentially moving) data structures of DOS,
which was problematic. The patched kernel no longer needs that
FreeDOS-only workaround. Commercial DOS versions always worked.

You can also get automated builds, updated on commit here:

http://kernel.fdos.org/ which links to

https://github.com/FDOS/kernel/zipball/master
https://github.com/FDOS/kernel/tarball/master

That in turn makes me wonder whether it would be possible to
extract last-changed timestamps from the commit logs to stamp
every file in the ZIP or TAR with their respective change date.

At the moment, ALL files in the ZIP have the same timestamp
as the ZIP itself, which I find rather inconvenient.

Regards, Eric



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

Re: [Freedos-user] Print via USB

[Eric Auer]

G'day Bryan,

>> That would of course be the EASIEST option as long as your PC
>> and your printer both still have Centronics connectivity
> 
> The PC does, but the printer doesn't. Hm, I found the following.
> {USB to Parallel Bi-Directional Cable
> 
>     USB to Parallel Bi-Directional Cable   
> 
> USB to Parallel Bi-Directional Cable
> CAT.NO:XC4847
> Parallel printer ports have disappeared from most modern desk top
> computers and virtually all new notebook computers. This is not a problem}
> https://www.jaycar.com.au/usb-to-parallel-bi-directional-cable/p/XC4847

That sounds more like a cable for printers which have
Centronics and PC which have none. You would need the
other way round, but I think that would not help much.

Probably better to use network or USB :-)

Let us see what others say about your network chip in DOS.
Note that if your printer is of the GDI variety, you will
not be able to print from DOS *at all* without adding a
computer with GDI drivers as translator between your DOS
computer and your printer. If the printer understands
a language for which you have a DOS tool which speaks
it, such as HP PCL, ESC/P, PostScript, PDF or plain
text, you CAN print directly from DOS as soon as you
find a way to send data through suitable communication
channels between the two: Network drivers and netcat
or MS CLIENT, USB drivers and TYPE, COPY or similar?

Regards, Eric

PS: We have GhostScript for PostScript processing and
our "print screen hotkey" TSR exist for HP PCL, ESC/P
and PostScript output. We have PDF viewers and it might
be possible to use GhostScript to create PDF? Not sure.
Some text editors also have built-in output converters.



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

Re: [Freedos-user] Diskman in our Ibiblio collection

[Eric Auer]

Hi Jim,

the current Diskman website links to archive.org for some of
the content and "inside" the archived website you can jump to

http://web.archive.org/web/20070206182142/http://www.diskman.co.uk/license.aspx

Which contains the following, as of 2/2007, emphasis added by me:

"- Diskman is licensed as freeware for non-commercial use. Anybody can
download it and use it free of charge, for any purpose they see fit,
provided that the following conditions are met:

- Diskman can only be used for non-commercial purposes ('commercial'
includes use *for profit making* activities, *military* purposes or
incorporation within *any product or service for which a fee is
levied*) without a license.

- Diskman is also available on commercial terms. To license Diskman for
your commercial purposes please contact the author with details of the
purpose that it will be used for. Diskman may be evaluated for
commercial purposes for a period of thirty days. Commercially licensed
versions of Diskman will clearly indicate that they have been licensed
and have a clear notice of the conditions that they have been
distributed under. In most cases Diskman will be licensed for commercial
use without a fee being levied but this remains at the authors absolute
discretion.

- Diskman may not be used during the manufacture of computers or for
mission critical recovery work (see the disclaimer) without the authors
permission.

- Diskman may be freely used by any home user for an indefinite period
of time provided that they either downloaded it directly from this
website or received it in the package available for download from this
website and not, under any circumstances, as part of a product or service.

- Diskman may usually be used, free of charge, by any charity or
non-commercial organisation (including law enforcement) subject to
agreement with the author.

- The program is *not to be distributed* in any form other than that
available for download from this website or directly from the author.
- The program may be distributed provided that no charge is made for
program and that any charges for distribution are only to cover
reasonable media costs (< US$10)

- *Diskman may not be included on any internet download site* other than
that provided by the Diskman website *without the prior permission* of
the author. It is acceptable to link to the Diskman website but not to
a specific download (it won't work anyway!).

- Some revisions of Diskman are still beta software and must therefore
be used with great care. Other versions of Diskman marked 'stable' will
have been tested for an extended period of time by a large number of
users. In either case the author accepts no liability for any damage
that use of Diskman may cause. Please see the disclaimer for further
details."

However, the CURRENT website just provides version 4.2(A3) last alpha
release and NO license page. It simply says:

"Diskman is no longer under development. The following downloads are
provided for historical reasons and are not provided with any support."

As you have already mailed the author, we should just wait whether he
can offer the source code AND a more free license. I THINK the tool
would be a rather nice addition to our collection :-)

Regards, Eric




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

[Freedos-user] FreeDOS on UEFI and other present and future hardware tricks

[Eric Auer]

Hi Jim, everybody,

> I get a lot of the emails you described. People email me to ask why
> FreeDOS doesn't run on their Raspberry Pi like Linux does .. or why
> FreeDOS can't take advantage of multiple CPUs and cores like Linux
> does .. or why FreeDOS can't run on their UEFI-only system (no
> "Legacy" mode) like Windows can .. or why FreeDOS doesn't have a
> default GUI like Windows .. or the one [...] from the Facebook
> group asking how to run an Apache/MySQL/PHP stack on [...] FreeDOS

Actually I have been some of this as part of a long discussion
with Stas this week. As you may know, support for BIOS and even
for VGA and VESA VBE seems to have declined significantly 2020.

And for various reasons, Stas has spent a lot of work to pull
most of the FreeDOS kernel over into the protected mode space
in context of dosemu2. That module is now called fdpp. It lacks
the init-text and the hma-text part runs on the Linux side,
with dosemu-specific connectors residing on the DOS side.

This makes it somewhat convoluted to "package" the heavily
updated fdpp kernel back into a classic "kernel.sys loaded by
a boot sector" infrastructure again and of course some things
are now optimized for protected mode. So it can be frustrating
that many updates for the kernel have ended up somewhat out of
reach, backporting them would require tedious cherry picking.

But exactly that would allow an interesting scenario: You may
remember that VMware has their ESXi "operating system", actually
hypervisor, which boots on raw hardware and lets you start and
manage instances of VMware virtual machines.

Now imagine that you have a minimal protected mode "operating
system" which boots on UEFI hardware and loads one task which
simulates a BIOS, similar to what normal CSM for UEFI do. It
also loads other tasks which simulate VGA hardware with the
appropriate BIOS and VESA VBE, or a Sound Blaster 16 hardware
with yet another task pipelining the audio to some HDA driver.

The next task runs the fdpp kernel and yet another opens some
vm8086 task where all of the other stuff is used to create a
virtual environment where you can pretend that you are running
the normal rest of your FreeDOS installation on hardware while
in fact having just the right amount of virtualization layers
between you and the hardware :-)

This might be more feasible than it sounds (Stas had been told
that pulling the kernel into Linux space would be impossible
as well - it took a LOT of work, but it worked) and might be
yet another interesting idea for future hardware use along the
lines of for example:

- https://github.com/Baron-von-Riedesel Japheth's 64-bit HIMEM
  (also his JLM system for drivers in protected mode realm)

- http://ndn.muxe.com/download/ Necromancer's DOS Navigator,
  which has a 64-bit DPMI edition

- some libraries and proof of concept things for multi-core
  or multi-threading inside DOS applications

- https://dosbox-x.com/ which includes a version which lets
  you run DOSBOX inside DOS with Japheth's HX RT extender,
  so you can run DOS inside DOS and get emulated hardware

- http://mpxplay.sourceforge.net/ which plays audio and video
  even in DOS and even with modern sound hardware and network

- VSB https://www.dosforum.de/viewtopic.php?t=1188 (which I
  have mirrored, too) is an ancient Sound Blaster 1 simulation
  with I/O trapping to pipeline sound to Covox printer port D/A
  either by MS EMM386 I/O trap API or creates vm86 task itself

- https://cmaiolino.wordpress.com/dosbian/ which boots a minimal
  Linux to open Dosbox so you can use DOS on Raspberry Pi and
  other ARM-based hardware which is not DOS compatible at all

So I think tricks and modules which connect the DOS world to
new hardware and firmware worlds and help DOS apps to use the
abilities of hardware which has not existed in MS DOS times
are something which are getting increasingly interesting.

For people with REALLY old hardware (before 386) it is great
that our classic kernel can be compiled for 8086 and I would
like to remind everybody that FreeCOM command.com has a KSSF
special helper version to save RAM on 8086 where no XMS is
available for the XMS SWAP which is the "default" for us in
spite of not working on 8086. That makes the default FreeCOM
binary a memory hog until you load some HIMEM.

But even for something as "humble" as a Live CD which needs
at least a 486 to boot (simply because older BIOS rarely is
able to boot from CD, although you can use a loader floppy)
we COULD actually decide to be a lot more modern regarding
system requirements. And if a protected mode kernel can be
part of a FreeDOS CD which boots from UEFI-only hardware?

Well, why not. The thing is that writing some hypervisor is
going to require serious experts. Not available? Then how
about making a clone of DOSBIAN, but for, say, PC compatible
computers with at least a Pentium and maybe 32 MB RAM? That
would still be totally FreeDOS related :-)

In spite of always keeping support for ALL r

Re: [Freedos-user] Diskman in our Ibiblio collection

[Eric Auer]

Hi Jim,

interesting that the DISKMAN website just WORKED.
The idea to view it using archive.org came from
Robert, maybe it did not work from his area? Odd.

> I downloaded 4.2.a3 from the author's website
> http://www.diskman.co.uk/ and while there's no Readme
> file, running the program prints this notice:
> 
>> Licensed to : ALPHA RELEASE. DO NOT DISTRIBUTE...

The list of versions (on the website, viewed through
archive.org, as written) also suggests that, but how
about the most recent stable release 4.x instead then?

If the website still is active, the software may
still be freeware for non-commercial, non-violent
use BUT shareware for the rest, which might be an
issue for fitting it into our licensing policies?

> That's a live website, so you don't need to point to the Archive.org
> copy of the website.
> 
> There's a "Contact me" form at the bottom of his website, and I have
> just submitted a request there to ask if he would be willing to
> release Diskman under an open source software license. I pointed James
> to the OpenSource Initiative's website and their list of open source
> licenses.

Thanks! Regards, Eric

PS: I had encountered it when searching ibiblio for file managers,
partition managers and system info tools. Laaca just told me that
*DOS Navigator* is quite okay as file manager AND has a reasonable
system info feature :-) That and DOSZIP commander are the two file
managers which we have in our 1.2 ibiblio collection at the moment.

PPS: Making dozens of version-subdirectories cannot have been more
work than normalizing (within-package only!) versioned zip names ;-)



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

[Freedos-user] Diskman in our Ibiblio collection

[Eric Auer]

Hi! Recently I have noticed that our ibiblio contains "DM21"

https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/util/disk/dm/

which has only bare binaries inside. So I wondered what it is.
Now Robert, who says I should not thank him, has found the URL

http://web.archive.org/web/20070208031008/http://www.diskman.co.uk/about.aspx

which gives a comprehensive answer to the question :-)

DM means DISKMAN and is a (also scriptable) tool which can
backup/restore LFN, quickformat FAT12/16/32, manage, read,
write and mount disks, partitions and images of those, DOS
and BIOS style, including a raw disk editor and some extras
like CMOS backup/restore and a little bit of NTFS. Newest
version would be 4.x, while we have 2.0 and 2.1 archived.

Version 3 was the start of a clean-up with limited, but
more stable features and 4 is quite similar to 2.1 as far
as features are explained, but more clean and stable :-)

The website also features a manual, a reference guide, FAQ,
various examples and, in the news section, a list of known
issues and planned changes. Version 4 is from 2002, while
version 2 is from the year 2000.

What are your thoughts on this? It SOUNDS useful to ME,
so if somebody has time, they could recursively fetch a
bunch of documentation from the website and throw it into
an updated ZIP for ibiblio. The author hints that source
code could be made available on request.

While there is no address mentioned on diskman.co.uk on
archive.org, the binary contains the addresses debug@...
and jim@... with ... being the mentioned domain, which
makes it tricky to contact the author on his gone domain:
"James Clark, an electronics engineer, working for a
leading UK computer manufacturer"

Thanks! Regards, Eric

PS: Interesting observation: The Stallman support movement
seems to have >1/3 eastern supporters. Cultural difference?



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

Re: [Freedos-user] Forwarding and commenting a FreeDOS 1.3rc3 critical review

[Eric Auer]

Hi! Thanks for clarifying that the installer always asks (and
hopefully explains) before choices with big consequences :-)

>> Do not tell ME, announce it during the install ;-)

> Based on my interpretation of the design constraints
> required for the installer, that ain’t gonna happen.

Not sure which constraints make offering a README hard,
but of course you can alternatively put the README and
a document viewer in the root directory and path of the
CD or USB image and a second copy of the README into
the ZIP downloads, accessible outside the images :-)

For "Our enemies bless us by telling us our weaknesses!":

I would like to say that it is important to exchange info
about problems and weaknesses. Luckily even our FRIENDS
do that. While I have deliberately paraphrased instead
of quoted Laaca's post when starting this thread to get
more friendly moods than "1.3 is horribly disappointing"
there is no reason to assume that Laaca dislikes DOS :-)

Eric



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

Re: [Freedos-user] Forwarding and commenting a FreeDOS 1.3rc3 critical review

[Eric Auer]

Hi Jerome, others,

of course suggestions are just suggestions and depend on
whether you have time to work on them and what others
think :-) Some feedback to you replies...

Given the point "slow boot, slow install, too few apps",
I still think Lite should not be too lite and Live should
have significantly more (pre-extracted) packages ready.

I think games which come on CD often are INSTALL FROM CD,
not RUN FROM CD, so being able to remove the Live CD to
run apps from CD still seems not that important for me.

Also, I think even when the installer THINKS that an easy
target drive exists, it should STILL first ask the user
before installing DOS (pre-existing C: found) or creating
a new partition table from scratch (apparent empty disk).

The "no drive writable for DOS" situation is likely to be
common in "only Linux or NTFS partitions exist yet" context
and the BEST recommendation in that case would be to ask
the user to *abort installation, use their pre-existing*
*Linux or Windows to resize their OS and add some LBA FAT*
partition and then start the installer again :-) Of course
it is fine to let the user decide to throw other OS away,
but I would display a very clear warning about that first.

>> Are tricks like those announced and well-visible during install?

> I’ve mentioned it numerous times here and in other venues.

It would be important to have such crucial information self-
contained inside the CD / USB image, in a readme which will
be included in the ZIP but outside the image and advertise
it automatically during the install process, I think.

Doing something which may or may not be what the user
wants, without documenting what is going on, is not
what I would advertise as "quick, easy, uncluttered".

> It is officially mentioned in only one place... run
> “setup /?” or (/h or /help or several other variants)

That is a start ;-)

>> Also the thing that CTRL+C can either open menu or kick you out?

> Like I said, only do it when it is waiting for user input.

Do not tell ME, announce it during the install ;-)

>> Unless you make a temp file in a small RAMDISK which you should
>> have anyway because pipelines in DOS actually are temp files ;-)
> 
> And how would that help logging the partitioning process???
> 
> Reboot, bye bye log.

Display the log, waiting for confirmation, before reboot:
Better than only doing things behind the screen or letting
each step scroll away while it happens. The user still gets
a good summary bundled at one moment of the first half of
the install process. Second half can log to target drive.

> I have plans for things of this sort and many other improvements.
> But all take some amount of time. Only so much of that available.

Luckily WHATIS and APROPOS are pre-existing DOS tools :-)

Regards, Eric



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

Re: [Freedos-user] Forwarding and commenting a FreeDOS 1.3rc3 critical review

[Eric Auer]

Hi Jerome, Laaca, others,

Given that I have verbose thoughts about Laaca's review and your
replies to it, I hope you have some time. Thank you for reading.

> Many people run FreeDOS on bare metal...
> 
> However, the overwhelming vast majority of users do not do that.

I guess "many" are still many enough to add a nice UHDD cache to
make the install significantly faster. Also, try something like
DIR /S > NUL to pre-cache directory data at some early moment.

As I never use DOSLFN or LFNDOS, I do not know whether they have
the need to become "better"? I think UDVD2 already is quite nice,
not sure what "ASPI driver" is about, maybe USB storage drivers?

A task switcher does not sound like a core feature given that the
"overwhelming vast majority" rund DOS inside one or more windows
inside some other operating systems anyway. We have TriDOS. Hmm.

It is good that the CD contains separate app package zips, but it
is still a good suggestion to pre-install MORE in the Live CD area,
so FEWER of them have to be unzipped while entering Live CD mode.

All packages which are pre-installed to a directory on the CD
1. make the CD larger but 2. do not have to be unzipped (slow)
into a ramdisk (where space is limited) :-)

Please DISABLE swapfiles in your installer cwsdpmi configuration!

You could only swap to ramdisk until the target drive is formatted
and ramdisk is too valuable to be used for swap if you ask me.

As far as I remember, we have package managers with built-in
unzip library. Not sure whether they show progress bars BUT
I think a progress info like "N out of N APPS unpacked" will
be sufficient to at least get an idea of the unpack progress.

Note that 7zip WILL give a progress indication and is part of
the distro anyway :-) Have not compared RAM use to unzip though.

As you explicitly want to support people with low (HOW low? Do
not overdo it!) amounts of RAM, I think it is again better to
have more pre-installed and fewer live-ramdisk-unzipped packages
for the Live CD. Even when this means you can squeeze fewer app
packages into 700 MB. You now only have 20 MB and 600 MB zip
download categories and separate Lite, Live, Legacy and Full
versions. Lite ONLY exists for USB and I think it is TOO small.

Basically nobody will be limited to a 32 MB USB stick. Better
make the "lite" version a BIT larger with more non-BASE apps.
Like 55 MB or 110 MB or something like that :-)

The Live version only exists for CD, why not for USB? And why
do Live and Full (USB) or Legacy (CD) have to be separate
downloads? Also, why not call it "Full CD", like "Full USB"?

The purpose of a Live CD is that you can ENJOY APPS without
having to install the operating system in question. If you
only include BASE apps, you should call it "boot disk" ;-)

> Perhaps more software will be pre-extracted on the CD and
> not made “active” on a RAM disk in 1.3-FINAL. However, this
> has some trade-offs. You really can’t remove the CD...

It is still better to have (more) pre-extracted apps :-)

> Some programs cannot be run on a read-only filesystem.

Which? Probably only a few apps would complain about that.

You could provide a SIMPLE batch script which, when there is
enough RAM, can be run by the user to copy all pre-extracted
apps into the ramdisk and update PATH. Then they can remove
the CD and still use all apps. But I think it is quite okay
that a Live CD wants to remain inserted into the CD drive.

I would like to hear opinions about FDISK, XFDISK, SPFDISK,
AEFDISK and RANISH partition managers from *everybody* :-)
They were all part of the 1.2 distro after all.

> Regardless, RC4 does a much better job than RC3 to auto partition
> blank hard disks. On a clean system or VM, most users will no
> longer even see FDISK.

To ME that sounds like "it will auto destroy ALL your data
when it accidentally mis-detects the disk as being empty,
without even asking you first!" :-o Please clarify.

> The easiest way to run in advanced mode is to exit the
> installer and run “setup adv”. But, ... CTRL+C ...

Are tricks like those announced and well-visible during install?
Also the thing that CTRL+C can either open menu or kick you out?

>> FDCONFIG.SYS. It is important because on the tested notebook (Dell
>> Latitude 610) the first two options did not work for me...

Which options are the first two? Probably those with EMM386? Is
it possible to use more "humble" default options to fix them?

> There really is no way to store a log of “the whole process”. 
> Anything prior to having a formatted hard disk will be lost.

Unless you make a temp file in a small RAMDISK which you should
have anyway because pipelines in DOS actually are temp files ;-)

I support the request that HELP offers a README or INSTALL file,
for example outlining the step by step phases of install, with
info which are optional, which are required and at which moments
the user can make which rough type of choices, so people know
what expects them and get an idea where they got stu

Re: [Freedos-user] Forwarding and commenting a FreeDOS 1.3rc3 critical review

[Eric Auer]

Hi, forwarding a verbose update of the review from Laaca on BTTR :-)

My summary: Better LFN, faster disk I/O, problem of opening many small
files on CD being slow (how about using more CACHE, Jerome? Maybe even
with read-ahead or similar speed tricks?), problem of the Live CD not
having apps pre-installed (it has to unzip them first), problem of the
Live CD having too few apps available, lack of progress/status info,
lack of analysis of existing system structure before install, lack
(?) of ability to select install size (base, full etc.), lack of a
mechanism to dual-boot on FAT (you know my opinion about that),
lack of "what has been done where" summary log on the target drive,
wish that running "help" should initially display an introduction
or readme about what can be found where on the installed system,
lack of utilities for manual installs and repairs in the live cd,
wish for image viewer and mpxplay on live cd and default install,
wish to add image editors, wish for descript.ion or similar method
to let people know what zip contains what in the on-CD repository,
wish to have separate directories for apps which are multiple files?

The original update from Laaca on BTTR is below. Regards, Eric



Source: https://www.bttr-software.de/forum/forum_entry.php?id=17804

Well, I wrote quite crititical review about FreeDOS 1.3rc. It was
reposted into FreeDOS user forum and was few times commented and it is
of course commented also here.
Just to be clear - I don't complain about DOS as such but specificaly
about FreeDOS 1.3rc and mainly about installer.
I will try to summarize my criticism into several categories:
1) Missing DOS/FreeDOS features
2) FreeDOS live system from CD
3) FreeDOS installation
4) Help system
5) Packages

ad 1) Here is not much to say. I miss some feature in modern DOS system
but it is not fault of the FreeDOS community. I would like to see a
better LFN driver, better disk read/write/seek performance (much worse
than f.e. under Win98). We do not have a good ASPI driver we do not have
a good task switcher and so on and so on. But again, this is not the
point of my criticism.

ad 2) Why the booting starts with unzipping of many basic utilities like
ATTRIB.ZIP, FORMAT.ZIP, COMP.ZIP and so on. Why it just does not unzip
something like BASE.ZIP which would contain all this basic utilities?
You forgot how slow is the file seeking on the CD on the real hardware?
Sure, the contiuous read is fast on most of CD drives but seeking and
opening the large amount of small files is a pain.
And after this we have only very bare system with only few
applications/utilities. It is much worse than very ancient Live CD of
FreeDOS 0.9a which I have and occasionaly use (although it is also a
.BAT files complicated mess). In 0.9 it ended in rather primitive menu
system but working system which allowed many tasks. Even much better is
Hiren boot CD. I heard that it is based on Linux or Windows. But I have
a completely different experience. I have a older version (Hiren 9.5?)
which is DOS based. The boot proces ends in quite nice menu sorted into
categories and subcategories which instantly allow quite wide spectrum
of useful things what to do in DOS.

ad 3) Installer should be generaly much more user friendly and should
inform a user about the process. It would be nice if it could perform a
system scan in the begining and resume the system from point of view of
DOS compatibility.
Like "Warning, no IDE/ATAPI interface, optical drives will not work" or
"Your processor does not support a 32-bit protected mode - the install
set will be adjusted for it".
In case when some existing disk partitions are present it should offer
the installation of boot manager (preferably BootMGR by BTTR software).
FDisk should be replaced by some better alternative.
Also - the user should be prompted to choose a variant of installation
(very basic, extended, full) and also a list of desired applications via
a expandable list for custom modifications of the options above.
I like the point that current installer creates a multi configuration
FDCONFIG.SYS. It is important because on the tested notebook (Dell
Latitude 610) the first two options did not work for me and only the
other options were working.
And finally - after the installation must be displayed (and also saved
into some protocol file) some summarization of whole process.


ad 4) Help system must be totaly reworked. After writing "help" should
be displayed some overview like:
* FreeDOS core files and installed into C:\ and C:\FDOS\BIN. Other
available disks are: .
* For your convience are prepared these BAT scripts
- for filemanager write "dz"
- for system info write "sysinfo"
- for more info about applications in C:\EDITORS write "help editors"
- for more info about applications in C:\SOUND\ write "help sound"
...
- for more info about DOS core utils and DOS batch language write "help dos"

ad 5) In harddisk mode and live CD mode must be easily available
utilities for syste

Re: [Freedos-user] Forwarding and commenting a FreeDOS 1.3rc3 critical review

[Eric Auer]

Hi Jim,

>> https://www.bttr-software.de/forum/board_entry.php?id=17794

Of course, fresh replies keep coming in there, too :-)

> 1. Ugly FDISK
> 2. LiveCD is unusable

The Live CD is not useful as "Boot and get tools" CD, but
I am not sure whether that is the goal. However, just "Boot
as if you had put a DOS boot disk into your floppy drive"
would really miss most of the opportunities of having more
space on CD, even if you want to be humble. Do not be TOO
humble.

> 3. After installation, the installer doesn't set up a GUI
> or even a file manager by default

It seems the installation is BASE only. Again, only putting
alternatives for those things on a whole target harddisk
partition which you would have gotten from 3 floppies full
of MS DOS does not match the vast space even of a 20 year
old computer. We do not need th

> 4. Complaints about the programs and utilities, and how
> they are organized

By the way, there could be more "luring me into the LSM HTML
overview" for example at the root directory of the IBIBLIO
category directories of our classic package collection which
you link directly from http://freedos.org/download/ ==>
https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/
because there are no readme files or anything similar. Only
the inconspicuous "What's included" link, but not the big
colored "FreeDOS files archive" link gives you orientation:

https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/1.2/repos/pkg-html/index.html

Good to know that FreeDOS 1.3rc4 will bring improvements :-)

About FDISK, what are YOUR thoughts about xfdisk, spfdisk, ranish?

> - Compatibility is key.
> - FreeDOS 1.3 will remain 16-bit.

Nothing stops you from including 32-bit apps like DOSFSCK
in particular on a CD ISO which is almost impossible to
boot on 16-bit hardware anyway. You can limit stripping
down things to 16-bit only to the floppy edition of 1.3,
which should ALSO make KSSF loading for FreeCOM available
as normal XMS swap FreeCOM is a big memory hog on systems
which do not provide XMS. Of course, please also include
both FDXMS286, 8086-compatible (but FAT32-enabled?) kernel
and the 386+ EMS/XMS drivers there. After all, even 386
computers are still hard to boot from CD/DVD drives.

> - FreeDOS 1.3 will retain focus on a single-user command-line environment.

Agreed, no need to default-install a GUI and most GUIs are
somewhat large so the could be reserved to larger versions
of the ISO. Still nice to have a big ISO with plenty BUT
not all apps to have a good pile of apps without requiring
additional separate downloads :-)

> - FreeDOS 1.3 will continue to run on old PCs
> (XT, '286, '386, etc)

In particular the floppy edition. There is not much point
to say the CD edition is not allowed to require e.g. 16 MB
of RAM for cache and RAMDISK in a world where only such PC
which cannot boot a CD at all have less than that amount.

> but will support new hardware with expanded driver support,
> where possible.

Sure!

> - The "Base" package group will contain everything that
> replicates the functionality from MS-DOS.

YES, as a means of organizing stuff, but NO, the CD ISO
edition should make it very clear that BASE is only for
minimalists and it should already include MORE than BASE
ready for install without requiring additional downloads.

Also, the Live CD mode should already have a bit more
than BASE, but it could work with "unzipping selected
packages to a RAMDISK of maybe 12 or 128 MB" if we want
to avoid to include packages twice (packaged and live).

> I don't see turning FreeDOS into a "mini-Windows" or a "mini-Linux."

Indeed.

Regards, Eric



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

Re: [Freedos-user] problems with FreeDOS 1.3RC....

[Eric Auer]

Hi Ralf,

>> https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/1.3/previews/1.3-rc3/FD13-LiveCD.zip
>>
>> I don't have any blank CDs so burned the ISO onto a DVD+RW disc
> 
> That won't work, not sure how you have burned a CD ISO image onto a DVD

That should actually work without problems :-) And as you see at
the end of the mail, it has worked for one of his three computers
where the driver (UDVD2?) was able to work with the controller.

The others might have been SATA in AHCI mode, but SATA without
AHCI mode should also work with UDVD2.

When in doubt, I recommend the ELTORITO driver, which works with
BIOS assistance on most drives as long as you booted from them.

Of course you are right that DVD tend to use other formats in
various situations, e.g. UDF instead of ISO9660 filesystems.

But when you burn an ISO which is meant for a CD onto a DVD,
it is enough that both have 2048 byte sector size. It just
does not make use of the remaining space and nobody stops
you from putting ISO9660 filesystems on DVDs to boot them.

A more interesting problem are the CD/DVD drive DOS drivers.
The thread at the BTTR forum mentions this page about FreeDOS:

http://www.z80.eu/freedoscd.html

It explains how to replace the embedded XCDROM CD/DVD driver of
the old FreeDOS 1.0 distro by GCDROM for SATA, Panasonic for USB
or some other drivers. I doubt that GCDROM would be able to work
on more drives than UDVD2 and I doubt that the instructions are
easily translated into similar changes for FreeDOS 1.3, but the
described tools are still nice to know for WINDOWS users who want
to modify the content of FreeDOS ISO images :-)

Regards, Eric

PS Harald: Some of our package managers ARE written in C and DO
have built-in ZIP libraries. I agree that accessing many small
files can be quite inefficient (even with a bit of cache). Not
sure how bad it is if 1.3 uses more BAT. Maybe a RAMDISK helps?



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

Re: [Freedos-user] Forwarding and commenting a FreeDOS 1.3rc3 critical review

[Eric Auer]

Hi Liam,

there have been TSR to display a clock or other status in DOS,
at a selectable location or by reserving a whole line on screen.

About your suggestion to show which drives exist at boot: The
installer could use VOL, a FOR loop and testing whether or not
a drive exists to display such information. There also are some
left-over tools from older versions of the distro to check which
drives are CD/DVD, which are FAT12, FAT16 or FAT32, how much
space is free on them and so on.

I myself have the 4 kB VOLINFXL tool which shows the NAME, SIZE,
USED and FREE space of all drives. You can find a copy e.g. on
http://ericauer.cosmodata.virtuaserver.com.br/soft/specials/

> I always put a few commands in at the end of AUTOEXEC.BAT to display
> the disk cache size (SMARTDRV /V on PC DOS), the amount of free base
> memory (MEM /C), and the DOS version (VER /R). A list of available
> drives would be a really nice addition.

The output of MEM is so long (shortest style is without /C I think)
that you would not fit much else on the screen. Same for the output
of LBACACHE (when loading, or using the INFO or STAT options later).

The good thing about VER /R is that it shows both kernel and command.com
version in 3 lines (plus one empty line before that). As people probably
use UHDD+UDVD2 instead of LBACACHE+?+CDRCACHE, cache info will differ.

> For a more friendly FDISK, it might be possible to adapt the Linux
> `cfdisk` tool...

What would be the pros and cons relative to the already existing DOS
versions of Ranish, fdisk, xfdisk and spfdisk?

> I have long been pondering a very simple, very heavily cut-down,
> text-only Linux whose main purpose was to multitask multiple instances
> of DOSemu

Too late? ;-) https://cmaiolino.wordpress.com/dosbian/

Regards, Eric



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

Re: [Freedos-user] problems with FreeDOS 1.3RC....

[Eric Auer]

Hi Glenn, about booting 1.3rc3 ISO from DVD+RW:

> https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/1.3/previews/1.3-rc3/FD13-LiveCD.zip

> Booted it up on this Intel i5 machine which has a SATA DVD+RW drive
> ERROR: Unable to initialize CD-ROM drive.

> ... Intel DualCore machine which also has a SATA DVD+RW drive.
> ERROR: Unable to initialize CD-ROM drive.

> Will now try booting it on the old-as-dirt circa 1997 P-II machine
> which has an IDE/PATA DVD+RW drive.
> (quite slowly 'cus this P-II is only 266Mhz and has only 512MB of RAM)
> R:\>

> So, SATA DVD+RW drives seem to be a no-go.

Does version 1.3rc3 already offer the ELTORITO driver as option?
Then it should work with that as long as it has booted FROM the ISO.

Or does it always use the UDVD2 driver? The UDVD2 driver SHOULD
support SATA, but you may have to disable AHCI in your BIOS setup
and switch to legacy style disk controller support.

Regards, Eric



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

Re: [Freedos-user] Forwarding and commenting a FreeDOS 1.3rc3 critical review

[Eric Auer]

Hi TK Chia,

> Apparently the review was from Laaca --- the author of Blocek.

Yes, I mean that post. However, I have only quoted part of
the post and not mentioned the name because my impression
was that just publicly shouting how horrible and disgusting
FreeDOS is cannot be the start of a productive discussion:

https://www.bttr-software.de/forum/board_entry.php?id=17794

I do not think that FreeDOS 1.3 aims to be a competitor to
Hiren or any of the Linux based "boot this and get a toolkit
full of easy to use apps to repair your system" Live CDs.

However, FDISK obviously does look as ugly as the MS DOS 1990s
version which makes it look horrible compared to GPARTED and
very unfriendly to use compared to the average modern Linux
installer which says "I see you have Windows 10 here, should
I shrink the partition and install Linux next to it? Or is it
okay to delete everything and use the whole drive for Linux?"
with only a small footnote saying "if neither of those two
choices are what you like, you can partition manually here".

I do NOT think that DOS can achieve that and I do NOT think
that we should port GPARTED and all the tools which it calls
in the background to DOS. Whoever wants to resize partitions
for dual-booting DOS with Windows 10 can simply boot a Linux
tool Live CD once. No worries, they are easy to use. And even
then, DOS has no tools which would be able to automatically
create a foolproof dual boot menu.

Bernd et al HAVE tried that in older versions of the distro,
for Windows 95/98 on FAT partitions, but it was far from being
foolproof so I am quite okay with forcing the user to manually
mess with such things instead of having an install wizard which
tries to do it but then fails and fries your other partitions.

Of course this topic is open for discussion :-)

I had not been paying attention that Laaca advertised a system
information screen in his own BLOCEK app here, but given that he
has added that, he could also make a stand-alone sysinfo tool to
include in the distro, for those who do not know that they have
to look for that information inside a text editor.

Alternatively, which system information tools with suitable open
source license could be included? As RayeR already wrote on BTTR,
HWINFO (which? note the Linux open source one, I assume), NSSI
(Navrátil Software System Information, mirrored on BTTR actually:
http://www.bttr-software.de/freesoft/system.htm ), VC (NC style
file manager, last update 2001?) etc. are not open source. BTTR
also lists AIDA (benchmarks and sysinfo), PC Diagnostics, etc.

I remember that MS DOS came with MSD (and MEMMAKER, a wizard to
optimize your config/autoexec for TSR/driver order in UMB etc.)
but I also remember that MSD was not particularily useful when
you compared it to classics such as Quarterdeck Manifest MFT.

As you can guess, FreeDOS is missing cool apps here. How about

https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/util/system/compinfo/

Would COMPINFO be sufficient?

How about file managers? NDN (Necromancer's DOS Navigator at
ndn.muxe.com) apparently has closed sources, but even supports
64-bit DPMI in DOS now? A free version of DOS NAVIGATOR, with
sources: https://www.ritlabs.com/en/products/dn/

The https://sourceforge.net/projects/doszip/ Doszip Commander is
yet another Norton Commander clone, as is the open source CONNECT
shell from http://www.dorlov.no-ip.com/Connect/ Some of the file
managers already are packaged for FreeDOS distros on ibiblio:

https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/util/disk/dn151/

https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/util/disk/dn2/

https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/util/file/doszip/

Which of those are or should be included / installed by default?

Three alternatives to FDISK which are in our ibiblio collection are:

https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/util/disk/xfdisk/

https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/util/disk/ranish/
(Ranish Partition Manager, only version 2.37 comes with sources)

https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/util/disk/spfdisk/

Which of those are how good or bad in your experience? I guess the
installer uses FDISK because that can be scripted to some degree?

So... Suggestions please :-) Which 1. SYSINFO TOOL, 2. FILE MANAGER
and 3. PARTITION EDITOR should be installed by default, used during
installation, be made available on the Live CD, etc.?

Cheers, Eric





PS: Interesting that util/user contains LPTLINK, which might be
a 2005 laplink clone? Is vc.zip really VISICALC? License??

PPS: Buy my pathetic little TUI menu tool! (it is free, of course) :-D
https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/util/user/mausmenu.zip



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

[Freedos-user] Forwarding and commenting a FreeDOS 1.3rc3 critical review

[Eric Auer]

Hi! Forwarding something from the BTTR forum:

"I tried to use the FreeDOS 1.3RC installation CD. Because I found
a Dell Latitude610 notebook. And I am really dispappointed because
it is something really awful. The live system is unusable, the boot
process ends in the minimal configuration unable to do anything
useful. No file manager is prepared and the user has no usable help.
The user even has no information which disc drives are in the system."

The review also compares it to the Windows-based Hiren Boot CD,
making me wonder whether we play in the same usability league.

In Hiren, you get a hierarchical menu of available utilities at
boot. So for Live CD utility purposes, it is very easy to use.

Next, the review tests installation, given that the Live CD use
case is as unfriendly as you would expect DOS to be ;-)

"Ugly FDisk (although we have a more user friendly partition tools)"

Also, the install is slow. How slow is it? Are caches used? ELTORITO?

After the install: Again "No file manager, no infi about installed
drives. No utility for getting some system information" Interestingly,
the reporter mentions the BLOCEK text editor as the only source for
getting a system information overview?

Which better SYSINFO utilities could we bundle? HWINFO, NSSI
and VC probably are all closed source, what else is out there?

Finally, the reporter (the whole post has a quite harsh tone)
complains that the default install will install FAR too few
useful apps and that the package management groups are badly
sorted (e.g. no subcategories for utilities) and that there
should be no base64 tool in "base"...

Regards, Eric



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

Re: [Freedos-user] DOS on (very) small form factor PCs?

[Eric Auer]

Hi Adam,

while the ability to provide ISA-like DMA for PCI (e.g. sound cards)
or PCIe basically vanished at least 10 years ago, I am less pessimistic
about BIOS services. Can you give specific examples of too stripped
down BIOSes in recent mainboards? Wikipedia sounds more as if it took
until 2019 before a significant number of vendors stopped including
a CSM to provide BIOS-like services on their UEFI firmware? I have
also heard about VGA, VESA or VBE getting worse, for example no 8x14
font or only powers-of-two bytes per line in VBE framebuffer RAM etc.

Those do not sound as if they would seriously impact classic DOS apps
apart from the DOS game sound problem of having no Sound Blaster 16?

> If it doesn't matter "at all" then where can I get a modern CPU with
> working support for ISA DMA?  It was removed back in one of the Pentium
> 4 chipsets so the CPU model/generation is definitely important.
> 
> That's no guarantee though.  Some modern machines only provide partial
> BIOS services - only enough to get common operating system installers
> to run and no more.  I have had machines that booted to DOS and I could
> install an operating system on and it ran fine, but they would lock up
> when I tried to run most DOS programs because they were missing a
> bunch of ROM BIOS services.

> One of these was a small form factor Intel NUC I bought a few years
> ago with the intention of installing Windows 98...

Thanks for the NUC warning, but Win98 actually will switch from BIOS
to built-in drivers which are likely not able to cope with new chips.

How about classic DOS on the NUC? Which DOS apps locked up on which
other PC as you have mentioned above, trying to use which features?

Regards, Eric



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

Re: [Freedos-user] DOS on (very) small form factor PCs?

[Eric Auer]

Hi!

> There are PCEngines ALIX boards (AMD Geode) with VGA out, one
> minipci slot. They are known to run FreeDOS. You probably
> have to install it with PXE because there's no floppy or
> CDROM drive.

According to https://www.pcengines.ch/alix.htm they are
end of life and those few with VGA are out of stock.

https://www.pcengines.ch/apu2.htm seems to be with x86
CPU as well, but without any graphics?

Regards, Eric





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

Re: [Freedos-user] DOS on (very) small form factor PCs?

[Eric Auer]

Hi Tom,

>> ...the board format does not matter much.
>> It's the CPU model/generation that matters.
> 
> NOT. AT. ALL.
> 
> each Intel/AMD CPU produced the last 20 years is able
> to execute the same way that the previous versions did.

The point is that everything which is remotely
similar to a Raspberry Pi uses ARM style CPU,
but the SIZE and COST of Raspberry Pi (Thomas
has mentioned Asus Tinker Board as example) are
obviously tempting. It would be nice to have a
non-ARM, x86 compatible hardware in that range.

So I would like to hear whether single board
computers in similar size and price (not PC/104
price level) with x86 compatible CPU exist and
which of them can be recommended by people here.

Of course we can always buy x86 Mini-ITX with
even a single normal size PCIe or PCI slot and
many good old interfaces, but that would be a
LOT larger than Raspberry style. With Nano- or
Pico-ITX, even SATA becomes less common. Might
not be a problem if the on-board M.2 or mSATA
slot of other boards is what you want, but if
you want to recycle existing 2.5 inch drives,
SATA would be nice. I could name a number of
other interfaces, but I am mainly interested
to hear what YOU people have been using in the
category of tiny, affordable x86 computers :-)

Cheers, Eric

PS: While Thomas does not want sound, of course
I am also interested about variants with sound,
maybe even ISA Sound Blaster compatible sound.

> Ah, thanks, Frank. I don’t need sound, I actually don’t WANT sound 
> (and no fans)
> 
> Th.
> 


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

Re: [Freedos-user] hardware recommendations

[Eric Auer]

Hi Christoph,

> From what I've gathered getting FreeDOS running on "modern" hardware is
> not trivial (if certain features are required/wished for) and the
> general experience running it in a virtual environment might be much
> better. I'll probably first go this (virtual) route and later...

That depends a lot on the specific feature. I would say running DOS
on for example 2019 bare metal hardware really is trivial, but you
may not get any sound from your 1999 DOS game for Sound Blaster 16.

Mouse, keyboard and VGA support will probably work just fine and the
game may support internal speaker sound output as fallback.

As your goal is to write new games, I am looking forward to hear from
others about their experiences with Allegro (and maybe SDL) for games
and other apps which can run on DOS (and maybe all other platforms).

Regards, Eric

PS: About the UEFI discussion, it does not matter for DOS or apps
whether you have a BIOS or just a CSM on your UEFI. Both work LIKE
a BIOS for DOS and the apps and that is what matters. It might be
possible to load a third party CSM on UEFI-only systems, maybe by
boot loader, but I am not aware of any proven combination for that.



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

Re: [Freedos-user] hardware recommendations

[Eric Auer]

Hi Liam,

> CSM is short for Compatibility Support Module. It is a module that
> enables UEFI firmware to also support "legacy" booting, i.e. BIOS
> compatibility. Windows 7 required this.
> 
> UEFI vs BIOS is either-or. A single machine can't have both

There are machines where you can select whether you want to
boot an UEFI capable operating system or not. When you say
you want to boot a non-UEFI operating system like DOS, the
system might either activate a CSM or switch to BIOS based
booting - for me as user, the difference would be hard to
tell. But as said, machines exist which support both modern
UEFI style booting and DOS compatible booting in some way.

I agree that it will be tricky to ask vendors which styles
their machine supports, but actually my impression is that
support for booting DOS is not that exotic yet. At least in
computers ten years ago - which already had PCIe, space for
many gigabytes of RAM, multiple cores etc. - booting DOS was
no problem at all :-) Wikipedia says UEFI became more popular
since 2010 and some vendors have stopped to include CSM since
2020. That means *most computers made before 2020 had CSM* and
will happily boot FreeDOS from most MBR-partitioned drives.

An exception from the 2020 statement: In 2006, Apple sold EFI-
only computers, but added a Bootcamp CSM the following year.
Wikipedia writes 230 mainboards are supported by Coreboot, so
that and OpenBIOS might be useful in some special cases.

Regards, Eric



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

Re: [Freedos-user] game development for FreeDOS

[Eric Auer]

Hi!

> I'm looking for ressources regarding game development for FreeDOS.
> I couldn't find anything in the wiki, but maybe I didn't use the
> correct keywords.

For game development, there is no difference between FreeDOS and
other DOS versions. You can either read the classic resources from
the Nineties or work with modern toolchains such as OpenWatcom,
DJGPP, the Allegro library, old versions of SDL, etc.

> I would prefer to use C, C++ or flat assembler.

That should work well :-)

> Regarding graphics, is there a way to support larger resolutions
> and bit depths than VGA (e.g. SVGA/VESA)?

You typically want to use VESA VBE, for example with linear frame
buffer and a 32-bit compiler. There are tutorials for that out
there, it is not specific to FreeDOS and works with any DOS :-)

> Is there any development environment or compiler you would
> recommend for gamedev?

As said, you may enjoy libraries such as Allegro.

Regards, Eric



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

Re: [Freedos-user] hardware recommendations

[Eric Auer]

> which hardware would you recommend for running FreeDOS?
> Are there any "modern" main boards that provide the neccessary BIOS
> compatibility for running FreeDOS?
> Is there a hardware compatibility list available?

Regarding your hardware question: Obviously, you need a computer
which still has a BIOS at all. Computers which support ONLY UEFI
operating systems will not work (unless you load a CSM, but there
is none I could recommend for DOS). But most computers still do
support BIOS, I think. You also want a computer which has a VGA
BIOS, preferrably with VESA and preferrably with VGA compatible
hardware. This also is the case for many graphics cards, but if
you want to be on the safe side, check the web whether people are
complaining about the graphics chip or graphics card you want to
use. For example 8x14 fonts are often missing (TSR exist to supply
them) and some modern chips are less flexible regarding "geometry"
of your graphics memory. No problem, as long as your game is :-)

As DOS itself does not rely on direct hardware access, you should
be able to use ALL mainboards which can still boot OS with BIOS.
Note that only 1 CPU core and at most 2-4 GB RAM will be active in
DOS and games unless you load experimental drivers and libraries.

You will not find modern sound hardware with actual soundblaster
compatibility. So prepare for having to find or write drivers
for HDA (or AC97) class sound chips. MPXPLAY shows that it can
be done :-) Alternatively, just use the internal speaker/beeper.

I guess printer ports and serial ports are not a topic for you
in games. Analog joysticks were easy, but USB versions or game
pads will be hard (try the Bret Johnson drivers?) For networking,
some LAN chips are supported even when only a few years old, but
you will have to check before you buy. WLAN is NOT supported in
DOS. Your USB mouse or touchpad will be supported as simulated
PS/2 device if you have a well-behaved BIOS helping you with it.

Your USB keyboard will be supported by the BIOS. Same for all
built-in disks (harddisks, SSD, even eMMC or M2) although the
BIOS driver will not achieve the best possible speeds. Note
that GPT partitioning is not yet supported by the DOS kernel:
You will have to partition your disk MBR style which limits
you to using the first two terabytes ;-) I recommend to keep
FAT32 partition sizes limited (you can even use FAT16) as I
expect DOS to be sluggish when using very large partitions.

I am not aware of any DOS drivers for webcams and similar. You
can check the ongoing thread about whether and how to print in
DOS with modern hardware. USB storage is probably supported by
the BIOS only when you boot from it, but that can be enough for
getting files copied. Actual USB drivers for DOS exist, such as
the Bret Johnson or Georg Potthast ones or various classic and
vendor provided alternatives, but prepare to have to try some
variants and tune configurations. This topic is too complex to
describe all ins and outs here. Some USB controllers might not
be supported at all, apart from by the BIOS, which only lets
you use keyboards, mice and sometimes storage (USB sticks).

No Bluetooth support is available for DOS as far as I remember.
Optical CD/DVD/BD drives should be supported  in ATAPI or SATA,
but I would not rely on that to work on every modern computer.

Also, support for UDF is at best experimental, so prepare to
only be able to read ISO9660 formatted CD or DVD. Writing or
burning of CD/DVD/BD has been done by some DOS fans, but that
has been years ago. Nobody seems to care about that any more?

Regards, Eric



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

Re: [Freedos-user] Print via network

[Eric Auer]

Hi Bryan,

> PCISCAN showed:
> Bus 1
> Dev C
> Func 0
> Slot 2C
> Vend 0006
> Dev. 100E
> Class Name Network
> Subclass Name Ethernet.

In case the vendor is something else, this might be an
Intel 82540EM Gigabit LAN controller. If 0006:100e is
indeed correct, it is something not seen elsewhere.

Intel actually does provide DOS drivers for this chip
(but they say the stopped supporting DOS after 2019)
which contains at least NDIS support. I have not
checked whether it contains a packet driver as well:

https://downloadcenter.intel.com/download/29138/Intel-Ethernet-Adapter-Drivers-for-MS-DOS-?wapkw=82540EM

If you have only NDIS, you also have to install DIS PKT:

http://wiki.freedos.org/wiki/index.php/Networking_FreeDOS_-_NDIS_driver_installation

As you see, several other drivers can be required to
get a MS CLIENT "stack" which would let you access, but
only old versions of, Windows net drives and printers:

Load PROTMAN /I:X:\Y, then your network controller
driver, then DIS PKT, all three as device drivers in
either config.sys or using DEVLOAD, in that order,
with X:\Y\ being the directory where your config text
file PROTOCOL.INI resides (adjust accordingly). The
content of the text file is at least:

[protman]
DriverName=PROTMAN$

[YOURDRIVERNAME]
DriverName=YOURDRIVERNAME$

[PKTDRV]
drivername=PKTDRV$
bindings=YOURDRIVERNAME
intvec=0x60
chainvec=0x68

See also the documentation which gets installed when
you unpack the DOS driver package from Intel.

Apart from the 2 *.DOS files (device drivers, note the
unusual name *.DOS instead of *.SYS) you will also need
the PROTMAN and NETBIND command line tools and TSRs.

All drivers and tools may have problems with being loaded
into UMB (devicehigh, loadhigh etc.) so you should avoid
that until you have tested whether it works for your PC.

You have to start NETBIND after loading the three *.DOS
devices to activate things. The PROTMAN exe will be
started automatically by the PROTMAN device, but you
can also run it manually later for other purposes.

Depending on the type of your printer, you can install
the mTCP set of utilities as explained in

http://wiki.freedos.org/wiki/index.php/Networking_FreeDOS_-_mTCP

As explained, you need to

set MTCPCFG=c:\somewhere\yourfiletcp.cfg

which has to set your PACKETINT (0x60), IPADDR, NETMASK,
GATEWAY, NAMESERVER and MTU (1500). You can also use
DHCP instead: Then, only PACKETINT and the host name
which you want to give your DOS PC (e.g. mydospc) have
to be set and all other settings will be requested from
your router, modem or other available DHCP provider. If
the mTCP tools do not remember the DHCP answers, it can
mean that they have to ask before each activity, so you
may prefer non-DHCP for better speed, but I do not know
whether or not mTCP remembers DHCP data across calls?

Use the NC (netcat) tool to send files to the printer:

http://wiki.freedos.org/wiki/index.php/Netcat

nc -target 192.168.2.20 9100 -bin < testfile.txt

In this example, 192.168.2.20 would be the IP address
of your printer, which you will have to look up (it
may be shown on your printer display, or you look at
what Linux or Windows says about your printer) and 9100
is a popular port for streaming "page (or printer?)
definition language" data to printers.

Depending on your printer, it might accept all sorts of
file formats, as explained here:

https://en.wikipedia.org/wiki/Page_description_language

However, I would expect that PostScript, PDF, ESC/P,
HP PCL and plain text have reasonable chances to be
supported (at least one of them) by your printer if
it is a printer with sufficient built-in intelligence.

According to the website

https://support.brother.com/g/b/spec.aspx?c=au&lang=en&prod=hl3150cdn_us_as_cn

the Brother HL-3150CDN is unfortunately a non-intelligent
GDI printer. You have to send pre-generated raw pixel data
to the printer and you will probably NOT find a tool which
converts your DOS text into pixel data in DOS

If you had a HL-3170CDW, it would be intelligent enough
to understand HP PCL6 and a Brother PostScript 3 dialect.

In short, while your PC network controller is supported
by DOS, you will not be able to use your printer without
the help of other operating systems in DOS because the
printer expects too much of its work to be done by you.

Regards, Eric




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

Re: [Freedos-user] Print via USB

[Eric Auer]

Hi Thomas,

> If using a USB keyboard (and USB mouse), there is the problem that
> when starting the USB driver (USBUHCI from Bret Johnsons USButils
> collection), the Keyboard stops working. So you can’t start the
> keyboard driver next, which seems should done to get somewhere.

The trick would be to write a batch file (filename loadusb.bat,
content simply the commands you want to run, one per line) and
then run the batch file (by typing "loadusb" and hitting enter)
to run all commands as one sequence. After that, you should be
able to use your keyboard and other USB things, as long as you
load Bret's USB drivers for all things you want to support :-)

> Mr. Johnson was kindly replying to my inquiry on this.
> So my approach at the moment ist using a PS/2 Keyboard and Mouse
> to avoid this problem. („Hardware solution“)

Of course that is a possibility - if you HAVE a PS/2 keyboard
and PS/2 connectors in your system. For other people, it is not.

> As Eric et al. are pointing out, I have to agree that USB isn’t at
> all what I thought it was: neither „Universal“ in the sense of „easy“
> nor „universal including DOS". On my ITX with a recent Bios. that
> Bios lets me use USB mouse and keyboard nicely right from booting,
> also a trackpad with no problem. So it also seems to be much a
> question what the inbuilt BIOS supports.

But even on the system where you try to print things, the KEYBOARD
already works with the USB support of your BIOS, so that is more or
less the same. I just say that your BIOS is unlikely to help at all
for serial or parallel (printer) port simulations or for example
for printers or external modems or similar. So you still have to
use USB drivers for USB printers.

As you already say, only EITHER the BIOS OR the DOS USB driver
can manage one USB controller. You can either tell the driver
to manage only some, but not all of your USB ports/controllers,
or you will have to load DOS USB drivers for everything and no
longer use BIOS USB support at all, as in the "loadusb.bat" way.

> Regarding printing I think there are two basic concepts: Using fonts
> from the printer (I call this „generic“, but maybe this is my private
> lingo) or using graphics from the computer. As I am only interested
> in printing out pure text (A-Z, 1-0  :) 

As explained here earlier, printers differ in what they accept
as input. Some accept plain text. Some accept PDF or Postscript.
Some accept ESC/P or other "printer languages". Some actually
do NOT accept plain text. Some do not accept any "normal" file
format: Those can ONLY print graphics, which means you must use
special drivers which turn everything into graphics first. Your
printer luckily does not have that problem. So as Frantisek said,
your chances are quite okay to use the MTCP NETCAT trick to send
a TEXT (or at least PDF) file from DOS to the printer by network.
That could actually be easier than using USB, even when this is
counterintuitive for you. Not sure which network chip your PC has?

> I also had tried printing using the Centronics cable/port.
> Thanks to Eric for COPY x.txt PRN or COPY x.pdf LPT1

That would of course be the EASIEST option as long as your PC
and your printer both still have Centronics connectivity :-)

Regards, Eric


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

Re: [Freedos-user] Print via USB / deprecate or improve PRINT queue tools?

[Eric Auer]

Hi Bryan,

I believe you have to install DOS USB drivers first. And actually
it could work better to use the NETWORK for printing, because DOS
(wired LAN) network drivers are more evolved than DOS USB drivers
and you can use DOS versions of NETCAT or other tools to copy the
contents you want to print to the IP and port of your printer as
hopefully listed in your printer documentation or visible in some
status information screen when you print from Linux :-)

>> I have just connected my Brother HL-3150CDN laser printer to my Dell>> 
>> OptiPlex GX270.
> I used the FreeDOS "print" command, unembellished.

That is only needed for background printing. A more straightforward
way is to send the printer data to the printer port: COPY x.txt PRN
or COPY x.pdf LPT1 or similar.

> The FreeDOS PC monitor listed the following line at the end of
> information after I unsuccessfully attempted to print.
> 
>>  "Device to direct Print [PRN=0]".

This message seems to have the purpose of giving feedback regarding
which output device the background printing tool PRINT is using.

Unfortunately, there is no PRINT.TXT and only a PRINT.ASM about
James Tabor's PRINT 1.02 tool, but it seems to support only:

PRINT /1 file.txt

Which means "send file.txt to LPT1 in the background" where you
can also use /2 or /3 to use LPT2 or LPT3 instead. The MS PRINT
tool would also support /S:ticks /M:ticks /U:ticks /Q:count /B:size
and /D:device. For things which MS PRINT would support directly,
you need the separate PRINTQ tool in FreeDOS: Clear the queue or
add more files to the queue later. The whole toolkit seems to be
rather minimal in FreeDOS, probably because printing things in
the BACKGROUND has been a rarely used feature in the last decade.

This tool could use a lot of improvement, but maybe we could just
warn people that it is not really necessary and the current tool
version is only the most minimal implementation of the feature.

> I expect that no data went to the printer.

I agree, in particular if you have not loaded USB drivers.

>> What do I need to do?

Please try via network, or load USB drivers. Also, please use
COPY filename LPT1 or COPY filename PRN or similar instead of
using PRINT: Background printing adds complexity and gives you
less clear view on potential transfer errors.

Regards, Eric

> http://wiki.freedos.org/wiki/index.php/Printer

PS: PRINTQ is a small public domain tool by Robert Mashlan to
add or cancel files on PRINT (MS, FreeDOS, etc.) print queues.



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

Re: [Freedos-user] Dual Boot FreeDOS + WINDOWS ?

[Eric Auer]

Hi Thomas,

> A dual boot Windows+FreeDos would be absolutely my preferred system...

Can your Windows version resize itself? Can it create a FAT partition
for DOS in some other way? Then I think you should do that, maybe
already copy the contents of the DOS install disk there and boot
the DOS installer. In the installer, you can now skip the step of
partitioning and formatting the harddisk and just tell it to use
the FAT partition as install target. If your Windows itself uses
NTFS partitions, the FAT partition will be the only one visible
to DOS and it will be used as C: by DOS after install. It might
have another drive letter during install if C: is already used by
the install CD or USB stick, of course.

Obviously, you should only use a Windows version of which you have
a license. If that is not the case, it probably is not worth the
effort to install ANY Windows at all. You can just dual-boot with
DOS and Linux then and let your Windows apps run in Wine on Linux.

If you want a dual-boot system with Windows and Linux, the same
strategy as above should work: Use Linux to resize itself, or
maybe easier, tell it to create a FAT partition for DOS already
while you install Linux. Then boot the DOS install disk (CD, DVD
or USB stick) and tell the installer to use that FAT parttiion,
without FDISK changing partitions and without formatting.

I have no idea what XP embedded can do or cannot do, but when
in doubt, it probably can do a lot less than Linux, because it
sounds like a stripped-down version of XP and XP is very old.

Regards, Eric

PS: The FAT partition for DOS should be a LBA partition and it
must be a primary (not extended / logical) partition, because
it is complicated to configure DOS to boot properly otherwise.

You need to keep that in mind when making / resizing partitions,
but it should be quite feasible with GPARTED in Linux or maybe
with built-in or 3rd party tools of more modern Windows versions.



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

Re: [Freedos-user] Why I use DOS a.k.a. FreeDOS for Dummies?

[Eric Auer]

Hi Thomas,

indeed A: and B: are reserved for floppy drives. The rest
is for partitions found at boot and after that, drives
accessed by drivers can be added. So if you do not see
the USB stick after booting from harddisk, it probably
just means that the USB driver does not work. As said,
it can help to boot from USB to get BIOS-assisted USB
stick access.

If I understand the mails correctly, not finding packages
during install is caused by unsuccesfully switching from
BIOS-assisted to DOS-only CD/DVD drivers at some point, so
I am looking forward to Jerome's next update with a tuned
driver strategy. FDISK would not help with that.

I agree that there should be documentation about how the
install process works which can help you to push it a bit
when it gets stuck at some point. Of course the documents
should be available online, also outside the install disk.

> I could even take a photo from the screen instructions...

It is probably better to just look at the steps in a browser
on another PC or in the smartphone instead of having to use
a photo of the instructions.

You are of course right that creating a dual boot system
is tricky. In particular, it is not something the FreeDOS
installer can do for you. So depending on how much you want
it, we could write some howto about how to create a dual
boot system with Linux (or Windows) or even a triple boot,
using tools for Linux or Windows. DOS tools are not enough
to do dual boot with anything without the help of the Linux
or Windows system itself. So you have to use their tools.

Keep me posted about your USB driver adventures :-)

Regards, Eric



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

Re: [Freedos-user] Why I use DOS a.k.a. FreeDOS for Dummies?

[Eric Auer]

Hello Jerome,

> Without functioning support for the the CD/DVD drive, the CD should
> still boot. That is not handled by a CD/DVD driver in FreeDOS.

This gives you at least two possibilities:

1. Use the ELTORITO driver for BIOS-assisted access to the CD/DVD
drive. It only works after booting from the CD, but that is perfect
for installation purposes and has been used in most older DOS ISO.

2. Make the bootable disk image on the CD of "harddisk" type, so
it contains the entire set of files needed for installation. As
far as I remember, this is what our USB boot image already does.

The disadvantage of 1. is that people might be disappointed that
CD/DVD access works while installing but not for the installed DOS
itself when you later boot from the harddisk or SSD of your computer.

The disadvantage of 2. is that it is annoying to have all files
wrapped inside another layer of packaging, the disk image. When
the boot CD only has a minimal bootable floppy image and all the
other files are in plain view on the ISO9660 part of the CD/DVD,
it is easier for people to help themselves to some files which
they would like to access at other moments, beyond installation.

Also, 2. requires you to have enough RAM to fit the entire
virtual install disk in RAM, which makes the combination of
a "full" install CD/DVD with many packages and an "old" PC
with less than 100 MB of RAM problematic. But for those, you
can still provide classic-style install CD/DVD instead which
have improved chances to find CD/DVD drivers for THAT hardware.

> It is handled through the system BIOS and (depending on which CD)
> also SYSLINUX/MEMDISK. Once the CD has booted, the installer...

...can always access at least the MEMDISK part. So by moving all
package files into the image, you can make sure that you always
have access to the files while installing. Solution 2 suggested
above. But with the mentioned caveats.

I personally recommend solution 1, as that has apparently worked
okay for a number of our older distro releases: ELTORITO.SYS :-)

> I am not aware of any utilities to support such things under FreeDOS.

About GPT: It would be sufficient if the kernel supports it to
be able to deal with FAT partitions on GPT disks. Of course you
would also want a GPT-aware FDISK at some point and probably
GPT-aware USB drivers, but most utilities in DOS do not even
know about the existence of the concept of partitions at all,
so they would not care which style of partitions you use :-)

> RC4 is only days away. It uses a different method when attempting
> to initialize the CD/DVD ROM. It will attempt using several drivers.

Cool :-) Thanks!

Eric



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

Re: [Freedos-user] Why I use DOS a.k.a. FreeDOS for Dummies?

[Eric Auer]

Hi!

> I never managed to install Freedos on a harddisk via the “live CD 1.3” or 1.2 
> version (image).

There are two problems: 1. where the installer expects the packages
in terms of drive letters and 2. whether you can partition the disk
to create a primary LBA FAT partition, format it and make it bootable.

Assuming that DOS is reasonably simple, you could do things manually
when the installer fails to do them automatically, so the second one
is the more interesting question. There are FDISK and XFDISK and other
tools, in various versions. Recently, there was a discussion in the
BTTR DOS forum which resulted in fixing some FDISK bugs, but I do not
know whether FreeDOS 1.2 or 1.3 already has the corresponding update?
You could also use Linux with GPARTED to comfortably do partitioning.

> The USB “Problem”: has been discussed in the mailing list recently.
> Honestly I don’t consider it an advantage to FreeDos having to boot
> a linux system just to get to my DOS-.txt-files from the harddisk

In theory, you can often gain access to USB sticks in DOS context by
booting from that stick itself. Because some extra BIOS support will
be active in that context. Required tools: A bootable DOS on a stick.
Not sure how far your attempts in that direction have gone so far?

> Printing is still waiting -- haven’t had time to fiddle with that.
> It just didn’t work out of the box with my editors (LaserJet & Centronics

Such printers do have a tendency to still understand plain text, but
you could try whether something like "COPY testfile.ps LPT1" (or the
same with a PDF) works for your printer. If yes, you can reduce the
problem to having to convert your text to PS or PDF first, which can
be done with suitable DOS apps.

> Codepage (UTF-8 support? Maybe not possible without a converter program?
> »Boček« Editor can save in UTF mode in DOS.) 

As you already saw, DOS normally only supports 256 character codepages.
There are tricks for 512 characters on VGA, but everything above that
requires graphics mode which text editors for DOS rarely use. You will
have noticed that Blocek indeed uses graphics mode :-)

Of course it is a bit annoying when you have German Unicode text which
actually uses less than 256 different characters and most DOS apps still
fail to display it properly. This is because they all assume that each
character is exactly 1 byte "long". As work-around, you can convert the
files back and forth before and after editing or viewing: Tools such as
RECODE have been ported to DOS. Also, drivers for long file names in DOS
have various codepage settings which help you with non-ASCII file names.

> Whilst trying to make it work for my needs I get the feeling there is
> much discussion about technical (historical?) details, which might be
> of interest to some specialists.

Yeah but it depends on the mood of the community at specific times :-)

> I get the idea that DOS (“Disk Operating System”) is a sealed book for
> the initiated and not for ordinary people. This doesn’t comfort me...

The nice thing about DOS is that it HAS been very popular decades ago,
so you can still find tutorials for many things online. Of course you
can also ask here explicitly, but notice how I got criticized this week
for explaining something which is considered to be "too well known" so
you need some patience and explicitly state your needs until you get
the replies adjusted to your preferred knowledge level :-)

> if I just want to save my files to a usb stick or print out on paper
> a letter, feeling completely stupid after years and years...

The stupid part is not you. The problem is that neither USB nor the
current generation of printers have existed when DOS was young, so
we all have to use creative solutions on modern systems for things
in DOS which may look simple for Windows 10 or a modern Linux. That
is the downside of keeping DOS deliberately simple and less PnP etc.

For example I remember installing a very old Linux 2.0 on a PC with
only 16 MB RAM, some of which was shared with the graphics. It worked
reasonably back then but would find neither USB nor LAN on a 2021 PC.

Also, I think that so far my hardware failures have been limited to
a graphics card, power supply, CPU fan and some disks. Luckily, all
failures have stayed limited to the respective component and even in
the disk cases, thanks to SMART (even DOS apps available for that) I
was able to replace the disks before larger amounts of data got lost.

> what you CAN’T do with it. (See the questions about sound, viewers, video, 
> graphics)

That is a bit complicated. If you have one app which plays video with
sound on modern hardware at high resolution, you could say you CAN do
that. But basically all old games will be the same old low resolution
as in the past and, having no ISA sound card any more, limited to the
PC speaker/beeper unless you use creative solutions or run DOS inside
something else which in turn does have drivers for your modern sound.

> a wo

Re: [Freedos-user] HP 2133

[Eric Auer]

Hello Marcolino,

> Apologize me for not being very specific, but i was going to ask about
> sound drivers. My main idea is to use it for retrogaming, altough i'd
> like to know if i could use an Image Viewer or even a Media Player.
> Maybe even a eReader.

You could probably use a media player and image viewer, as some with
current updates exist. They might support AC97 and/or HDA sound with
some common chipsets, but probably not a wide coverage of chipsets.

> It's a shame however, since my idea was to play classic games in FreeDOS
> (in special The Elder Scrolls), but since no Sound Driver for Soundmax
> AD1984A exist, it won't be very worthful.

https://www.analog.com/en/products/ad1984.html#product-overview says
this is a HDA codec chip. I believe in HDA, you consider codecs and
the chip which provides the bus separately, but let me know whether
you get it to work in http://mpxplay.sourceforge.net/ or similar.

For games, there are various work-arounds. A good way would be to
run Linux and open a DOSEMU2 window there ;-) Of course, you could
also use generic virtual PC apps like QEMU. Or you can use DOSBOX,
which again is specifically for DOS apps, or use Windows as host OS
instead of Linux. But DOSEMU2 probably works pretty well for you.

Another way could be to use DOSBOX-X which you can interestingly run
as a DOS app, using Japheth's HX DOS extender! So it lets you run a
simulation of DOS inside a real DOS, giving you the ability to throw
in some additional hardware emulations.

Some very recent thing is that the source code of the VBE/AI SDK has
been made open source: This is for an audio extension for VESA VBE
which, while few graphics cards supported it in DOS times, does have
support in a number of 1990s DOS games. So people will soon be able
to write a "driver" which provides VBE/AI BIOS services to help old
games to send sound data to modern sound hardware by using existing
hardware driver source code for example from Linux. Still, this will
be a rather complex project, so do not hold your breath.

There also is the ancient VSB (virtual sound blaster) project which
uses protected mode to grab attempts of games to communicate with
the sound card in order to pretend that you have a very simplified
sound blaster even if you have none. In the original version, the
sound is then output via printer port D/A if I remember correctly.
Also known as Covox. Again, this could be combined with code from
modern sound drivers to simulate a sound blaster and make the sound
audible on modern hardware. Actually SB LIVE and SB PCI sound cards
used similar strategies to "pretend to be soundblaster compatible".

I think the easiest way would be to use Linux and DOSEMU2 or similar
"apps which run DOS and/or DOS apps in windows, while emulating some
classic hardware which classic games expect to exist" :-) Of course
it will be less "real", but even with your HP 2133, speed should be
sufficient for a simulation instead of running directly on hardware.

Regards, Eric



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

Re: [Freedos-user] HP 2133

[Eric Auer]

Hi Marcolino,

> I've restored an HP 2133 Mini-Note PC recently and i've
> installed FreeDOS on it.
> 
> Is there some driver compatible with this laptop?

If you could tell us which components you cannot use
at the moment because you are looking for DOS drivers,
I could give a more specific answer.

As https://en.wikipedia.org/wiki/HP_2133_Mini-Note_PC
says, those laptops have 512 MB to 2 GB of RAM, between
4 GB SSD and 160 GB harddisk, 1280x768 or 1024x600 LCD,
VIA Chrome 9 graphics (using a part of the normal RAM)
and a VIA C7 CPU. Touchpad, keyboard, microphone, VGA
webcam, WLAN, LAN, Bluetooth, USB, ExpressCard slot and
microphone / headphone jacks etc.

You can expect that WLAN, Bluetooth and webcam will not
be supported in DOS. Your sound will probably only work
with very few modern apps such as MPXPLAY media player.

Most old games have drivers built-in, so sound drivers
are not something provided by the operating system. It
also means that they can only use very old sound cards.

Using your RAM, SSD, harddisk, processor and keyboard is
not expected to be any problem for DOS. For USB and LAN,
various drivers exist, but I would have to know which
controllers your computer has to be able to think about
whether a DOS driver for those exists.

> What am i able to do with FreeDOS besides playing old games?

If you look at the mailing list archives, you will see
that we had a thread earlier this month where people
exchanged some thoughts and memories about what they
are and have been doing with DOS :-)

> Is there some way to emulate Graphics Cards?

As you can already use DOS, my question would be why
you want to emulate which graphics card. I can imagine
that many DOS apps (in particular games) use graphics
at 4:3 aspect ratio while your screen is roughly 16:10
so you will get black bars, distortion or fuzzy images.

You probably have hotkeys, similar to EEE PC, which let
your BIOS cycle between different methods to deal with
screen size to graphics resolution mismatches.

What are the abilities of your graphics system in DOS?
Do VESA graphics modes work? How about VBE and linear
framebuffers (LFB) in games? Is VGA compatibility okay?
How about EGA or even CGA for older games?

Either way, the extra acceleration features (for example
for 3d or video) of your hardware are probably not used
by DOS at all, so you neither have nor need drivers here.

If you connect an external screen, you will probably be
able to use the higher resolutions available there, but
probably limited to 1080p and below given the age of the
computer and the (graphics) BIOS which comes with it?

Regards, Eric



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

Re: [Freedos-user] Why do you use DOS

[Eric Auer]

Hi Liam,

if I understand you correctly then you say I behaved as if
you were not well-informed when you said that config files
have different names in FreeDOS. Now given that you ARE
well informed, you must have been talking about something
else than config.sys and autoexec.bat because those 2 CAN
use the same filenames in FreeDOS and MS DOS. Which means
you must have meant OTHER config files, but which ones do
you mean specifically? It was in no way my intention to
make you angry by MENTIONING file naming possibilities!

> Drive A: is the 5.25" disk drive
> Drive B: is the 3.5" disk drive
> 
> This does not work in 4DOS, because 4DOS insists that text output
> with the `ECHO` command has matching single or double quotes

Interesting. We do not advertise 4DOS that much, though,
given some licensing details, if I remember correctly. I
hope FreeCOM command.com has fewer such incompatibilities.

> FreeDOS commands are different in places; output is different in
> places. That is fair...

Now that we have been talking about config files: FreeDOS does
not implement the config.sys menu syntax of MS DOS 6, but uses
a different syntax, yes. There was some discussion about that
years ago. As there were too few users who wanted the kernel
to be a drop-in replacement for the MS DOS kernel, while many
users start with the default config dropped by the installer
and add their own extensions manually, there never was enough
momentum to add MS DOS style config menu syntax. Maybe there
even were some patches offered, but I honestly do not remember.

Actually I wonder whether DR DOS, PC DOS or other commercial
DOS kernels support the MS DOS config menu syntax and whether
they (also) support their own variations and extensions of it?

>> PS: No, I do not need downloads of other copyrighted DOSes.

That was related to DR DOS and PC DOS. As far as I know, only
the core files of DR DOS are freely available (also EDR DOS)
while PC DOS is at best abandonware? If PC DOS has officially
been made freeware, then I have missed the accouncement, sorry.

But no, this was not meant as complaining about AVAILABILITY,
it can be read explicitly as ME not planning to switch to a
less free DOS while I already have a more free one. Which I
do like to compare in features and compatibility to others.

I do know that MS has made very old versions of MS DOS free
or even open, but I doubt that people use such old versions.
I also doubt that any DOS vendor cares about whether their
twenty or thirty year old products are found in www today.

> You do not appear to be interested; you only seem to want to needle
> me. I am not rising to it. You do not seem to want to know.

To be more specific, I was hoping for some insights of how much
RAM you were using for what, to get an idea of where the areas
are in which FreeDOS is wasting RAM versus where it already is
doing okay. Both for kernel and shell and for various drivers.

It is not my intention to whine about copyrights, but it is not
my intention either to install a whole virtual machine just to
find out more about the vague hint that DR DOS or PC DOS uses
less RAM than FreeDOS. It would have been nice if you would have
been willing to talk about it, but it certainly is not worth the
stress to accuse each other of all sorts of things instead of
doing a little mailing list chat about compatibility and RAM.

No worries! Eric



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

Re: [Freedos-user] Why do you use DOS

[Eric Auer]

Hi Liam,

>> Please mention a few examples of differences :-)

> Different names for config files are the start.

If you have only autoexec.bat and config.sys then FreeDOS
will use those. The reason why FreeDOS first tries fdconfig.sys
is that you can install FreeDOS and MS DOS on the same drive
with a boot manager and people wanted to be able to have two
different sets of config files in that case :-) But again, you
can simply use the classic MS DOS style config file names with
FreeDOS as well if you do not need the distinction.

>> In that case, I guess you are now using some PC or DR DOS parts
>> combined with more modern, smaller drivers popular in FreeDOS?

> Nope. I prefer to keep things as original as possible.

In that case, which small classic drivers do you recommend?

Regards, Eric

PS: No, I do not need downloads of other copyrighted DOSes.



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

Re: [Freedos-user] Why do you use DOS

[Eric Auer]

Hi Liam,

> I personally prefer running PC DOS 7.1 or DR-DOS. The small differences
> in FreeDOS irritate me, and I am more familiar with these versions.

Please mention a few examples of differences :-)

> I was an expert in DOS manual memory management and could usually get
> circa 620 kB free conventional memory even on a heavily-loaded machine
> with multimedia, an optical drive and a network stack.

In that case, I guess you are now using some PC or DR DOS parts
combined with more modern, smaller drivers popular in FreeDOS?

Eric



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

Re: [Freedos-user] Why do you use DOS

[Eric Auer]

>> Or something like Dosbian Linux on Raspberry Pi which
>> just immediately boots into only a DOS window.   
>> 

> Is it known here whether this supports proprietary SVGA text modes, (e.g.
> Trident's 132x43, 132x30, 132x60)?

The website says it is based on a modified dosbox and
dosbox supports only Tseng Labs SVGA according to

https://www.classicdosgames.com/tutorials/advanceddosbox.html

but that page says you could try PCem if you want Trident.
Not sure if PCem is available for Raspberry Pi, of course.

In general, dosbox is quite versatile:

https://www.dosbox.com/wiki/Configuration:DOSBox

Hercules, CGA, Tandy, EGA, PCjr, VGA, S3 Trio64 SVGA,
Tseng Labs ET3000 SVGA, Tseng Labs ET4000 SVGA,
Paradise SVGA, VESA with VBE 1.3 etc.

https://devtidbits.com/2008/03/16/dosbox-graphic-and-machine-emulation-cga-vga-tandy-pcjr-hercules/

says the DOSBOX S3 Trio64 emulation is good enough
for VESA VBE 2.0 including LFB.

You can also check https://dosbox-x.com/ which funnily
enough provides a HX-DOS based version which lets you
run a DOS window inside DOS! Can help if your hardware
is not directly compatible with your app. No Raspberry
version, but supports ARM on Mac so maybe almost there?

Eric



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

Re: [Freedos-user] Using a USB stick and an optical drive

[Eric Auer]

Hi Thomas,

> I just found a recipe regarding USB-Sticks & MS-DOS.

> SOURCE: https://slomkowski.eu/retrocomputing/usb-mass-storage-on-ms-dos/

Well, the old USBASPI drivers might work for you, yes.
Or those by Bret Johnson. Or those by Georg Potthast:

http://www.georgpotthast.de/usb/

The general problem is that each driver only supports
a limited set of different controller chips, so it will
depend on your luck on whether one works for you.

The drivers by Georg are shareware and will only work
for a limited time after each boot, but that is probably
enough for what you want to do :-)

Regards, Eric




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

Re: [Freedos-user] Why do you use DOS

[Eric Auer]

Hi!

> - want to get rid of networking on my „composing tool“

If that means you want audio in DOS, then I strongly
recommend running DOS inside a hardware simulation
and NOT directly on hardware. Because VERY few apps
for DOS will be able to work with modern sound chips
directly. Accessing a simulated Sound Blaster helps.

> - want to have a lighting fast bootup

For that, installing DOS on raw hardware is best. Or
something like Dosbian Linux on Raspberry Pi which
just immediately boots into only a DOS window.

> - want to have 1 (one!!) single app that I use, 
> - don’t want the virus thing (do we?)
> - don’t want all those hidden spying/cookies/passwords/logins

Then just do not use the network ;-)

> - don't want "update nagging“, this has become crazyness.

Then you should probably not even connect the network.

> - want to be able to switch the thing off with a button

Again, installing DOS on raw hardware helps here.

> - single simple view of what I have written

Depends on how much you like DOS commands such as "DIR"?

> - want to have single files that represent an „app“.
> (not thousands of libraries, dependencies, installs, dlls

Even in DOS, that will depend on how simple your apps are.

> - a system of a handful of commands I program on my „macro pad“
> - and press it without need to type in, not even „dir“ or „cd ..“ or „type“

There are some hotkey or mouse menu apps for DOS to do that.

> - want to learn to understand a little how actually a computer
> works as a tool, not as a consumer gadget that could...

You can learn the necessary programming languages and read the
source code of FreeDOS and command.com in less than a year ;-)
For other DOS apps, your luck will vary depending on complexity.

So please be more specific on what you want to "compose" or text
edit and what should happen with the files once you have written
them. Without network, you probably plan some other, local uses.

Regards, Eric



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

Re: [Freedos-user] DOS was dead...

[Eric Auer]

Hi Thomas,

> Any particular Linux flavor you suggest for this?
> (I would go for a „command line interface“ only.)

That sounds masochistic ;-) As long as you do not
need 3d accelerated drivers, a graphical desktop
for Linux should work on almost all hardware just
automatically. Of course you will need a mouse :-)
You can still go plain text with a simple hotkey.

The "usual distro" of the day would be Ubuntu, with
MINT being a spin-off and with lightweight variants
such as Xubuntu or Lubuntu which default to install
less heavy graphical things than the normal Ubuntu.
MATE also is just yet another variant.

Under the hood, those are more or less the same, you
simply get different default packages/apps installed.
If you really want to avoid Ubuntu: Fedora, OpenSUSE,
Debian, etc. are more different from Ubuntu flavors.

How much RAM, disk space and CPU speed (including
the number of cores) do you have available? In other
words, do you want something lightweigth? Or will
any widespread Linux flavor do?

Distros now tend to require at least i686, so if
you have something older than Pentium Pro or II,
that will limit the choice of distros. If you have
a 64-bit capable (x86_64) CPU, you actually get
more choice than if you do not. And for Raspberry
and other ARM CPU, you get yet other choices.

Cheers, Eric



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

Re: [Freedos-user] DOS was dead...

[Eric Auer]

Hi Thomas,

>> "I want to boot to freeDOS using a CD ROM.

That should be easy.

>> Then I want to insert a memory stick into the computer and copy 
>> a file from the Windows HDD onto the memory stick.

That can be complicated. Often, the BIOS only helps DOS with
USB access after you have actually booted from the USB stick.
And separate USB drivers for DOS may or may not work for you.

The next problem: If your Windows uses NTFS - almost every
modern Windows does - you will NOT see your Windows disk in
DOS at all.

So it would be a LOT easier to boot Linux from CD or USB if
your goal is to copy some files to or from a Windows disk.

> I was trying to figure out how to use an USB Stick on a
> FreeDOS Harddisk installed system. This is absolutely crucial
> to me, otherwise how would I be able to get something out or
> in to the computer?? (I definitely don’t want networking!)

I would have said networking, but...

> My floppy-drive is USB, too :(

See above. BIOS tends to support USB for DOS if you boot
from the USB device in question, but often not if you do
not. And DOS drivers do not support all hardware brands.
So I guess I would again say use Linux to copy files ;-)

You also seem to have Windows on that computer, so you can
also use Windows to copy files. Windows supports both USB
and networking without big problems.

> I just installed FreeDos on an ITX and harddisk. I can
> read and write on the disk and the Usb Stick, if I boot
>  directly from the Stick. It doesn’t work the other way
> round, i.e. booting from the disk and trying to D:
> (=USB Stick) to read/write. Bret Johnsons USButils
> „driver.com“ shows me that dos recognises something,
> but not „enough“ to access when booted from the Disk.

As predicted above.

> I formated the disk with FAT32. Maybe not good? Should it be FAT16?

The default version of FreeDOS supports FAT32, LBA and
MBR. If your Computer uses GPT instead of MBR for the
partitioning, FreeDOS will not see and partitions on
your harddisk or SSD. If your disk is larger than 2 TB
then it will certainly use GPT. If your BIOS is older,
it may cause problems for DOS to access data beyond the
first 128 GB of the disk or even less.

> So: Would I have similar USB-issues using Freedos via EMU2
> on a raspberry?? Maybe we need to find out...

EMU2 is a bad example, but if you look at QEMU or DOSEMU2
or DOSBOX-X, you always run DOS in simulated hardware. So
everything outside your DOS window will be "connected" to
your Linux. For example if you try to print something in
the window, it will not talk directly to your printer at
all. Instead, the simulation will capture the print data
and, if you have configured things properly, send them to
your Linux printer driver.

Similarily, all floppy, CD-ROM or harddisk partitions in
your DOS window will just be a simulation. For example
they could be a disk image or the contents of a directory
visible to Linux. Obviously, when you open your USB stick
in Linux, it will become visible in a directory and you
could tell your DOS window, such as DOSEMU2, that this
directory has to be used to simulate a drive letter of
your choice. However, as you will use many different USB
sticks in everyday life, I recommend to just use the file
manager of Linux to drag and drop files between your USB
sticks and some fixed directory inside your home directory
which you use as a simulated C: drive or similar. Then you
do not have to change your DOSEMU2 config all the time.

Another nice thing is that the simulations can be told
to simulate a Sound Blaster 16 soundcard which you will
not find for a Raspberry Pi or any modern PC. The sound
data are captured and forwarded to whatever your Linux
is configured to use. Maybe the HDMI sound of your TV,
for which you will certainly not have DOS drivers :-)

Regards, Eric



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

Re: [Freedos-user] Using a USB stick and an optical drive

[Eric Auer]

Hi Stephanos,

> Dell ... looked at the problem and confirmed that:
> 1) there is no BIOS update offered for my laptop, N5030
> 2) that the BIOs update that I was using is for model M5030,
> which has an AMD processor.  Mine has an Intel processor

That explains a lot!

> 3) they are not going to offer a BIOS update for my laptop
> 
> Thanks to everyone for the assistance.  I now know how to make a
> bootable media and put files onto the media that I can see in that
> enviroinment.  That is going to be useful.
> 
> One question remains
> a) does anyone know anyone who can write a BIOS for me?

But you already HAVE a BIOS, it just is old? Please
explain what exactly you want to change in your BIOS,
why, and which type of processor you have exactly.

Regards, Eric



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

Re: [Freedos-user] Recovery of a file on a non booting Windows computer

[Eric Auer]

Hey!

> I want to boot to freeDOS using a CD ROM.  Then I want to insert a
> memory stick into the computer and copy a file from the Windows HDD onto
> the memory stick.  Is this possible and if so which version of freeDOS
> do I use?

If you ask me: Do not use DOS for that. Your Windows is probably
installed on NTFS and DOS is too old to understand NTFS data.

Simply boot Linux from a CD or USB stick to copy your file. You
could even take the harddisk out of the computer and plug it into
another computer. Make sure to NOT make it the boot disk, of course.

Or put it into an USB housing and connect it to another Windows
or Linux computer so you can access the data via USB, easily.

In both cases: Make sure to fully shutdown your Windows computer
first! If Windows is only in hibernate, standby or sleep mode, it
can have opened files which can get messed up when you interrupt
the sleep to do other stuff with the partition.

Regards, Eric



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

Re: [Freedos-user] DOS was dead...

[Eric Auer]

Hi!

> The Raspberry Pi which is sadly a proprietary hardware
> platform, does nut support DOS.  I thought it did by some miracle.  It
> doesn't.  Apparently, nobody has released a hypervisor for the Raspberry
> Pi 4 that will emulate an 80386 or earlier well enough to run FreeDOS or
> any DOS without issues. 

Hypervisors only isolate operating systems from each other
on hardware where they would run anyway. Because tiny single
board computers such as the Raspberry Pi are usuall based on
ARM, which is totally different from 386, there cannot be a
hypervisor which lets you run DOS on raw Raspberry hardware.

Instead, you have to use any virtual PC or PC emulator of
your choice, for example QEMU:

https://www.onmsft.com/how-to/how-to-run-dos-on-a-raspberry-pi

https://opensource.com/article/18/3/can-you-run-dos-raspberry-pi

Or DOSBOX-X, which is not a normal PC emulator, because it
also contains a lot of DOS specific stuff. Good for you:

https://magpi.raspberrypi.org/articles/build-a-dos-emulation-system

Another DOS specific thing for Raspberry Pi is RPIX86:

http://rpix86.patrickaalto.com/

(not sure whether PCEM would run on Raspberry Pi)

Or dosbian, which is a Linux which boots straight into dosbox:

https://cmaiolino.wordpress.com/dosbian/

I am sure there are a variety of other ways to do
what "nobody" has released yet ;-)

Cheers, Eric



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

[Freedos-user] AMI and other BIOS flash tools for DOS, Windows and Linux

[Eric Auer]

Hi!

Changing the subject to make this link-collection easier to
find, but feel free to reply in the original thread instead.

> Greetings one and all, here is an update
> 
> I followed the instructions on the Dell website:
> https://www.dell.com/support/kbdoc/en-uk/000131486/update-the-dell-bios-in-a-linux-or-ubuntu-environment#UpdateBIOS

Come on, it already recommends FreeDOS and UNetbootin! Why have
you asked all those questions when the answers were there? :-)

> I booted the stick, was a bit confused as to why freedos did not do
> anything and fdos was the option, and found the BIOS file in drive C:\.
>  I ran it.  It looked promising, but alas, alack, no.
> -Start to flash ……. [ Y / N]: Y
> - Error: Problem getting flash information

Does the documentation of your BIOS update tell what that means?
Google says this error message is something seen in the AFUDOS
AMI Firmware Update utility? You might be using the wrong version
of the tool or of the BIOS.

Interestingly, even a Linux version exists:

https://www.ami.com/products/firmware-tools-and-utilities/bios-uefi-utilities/

According to other websites, you have to give the name of the
BIOS update file as an option to the tool: "AFUDOS yourfile"

Also, the DOS and Windows versions of your BIOS update could
be different downloads, so make sure to use the right one.

Usually, you can also run "nameofthetool /?" to get a help text.

> I went back to the Dell website, entered my service tag: BQBD9N1 and
> downloaded the latest BIOS file “M5030A05.EXE” (again, and remember the
> A05 is a latter version to the installed BIOS which describes its
> version as A02).
> https://www.dell.com/support/home/en-uk/product-support/servicetag/0-YXhUR091TFhQWVdkR0VXeUY0cTREQT090/drivers

The website says: the A05 BIOS is for Dell Inspiron M5030,
while the A02 BIOS is for Dell Inspiron N5030 systems. The
A05 download is described as combined DOS/Windows CPG BIOS
update executable. md5sum: d916cc8e65b8f3fb9063270c08d749f9
Apparently it can also be used for the Inspiron 15 N5030.

On some computers, you can also press F12 at boot (might be
tricky to hit the right moment!) to load a BIOS from USB by
selecting the exe file in an update menu built into the BIOS.

> Making the USB stick bootable and being able to add files to it was
> so easy.  It is as though the root of the memory stick was C:\?

Good to know! If you have no other FAT partitions on your
harddisk then yes, the USB stick can be called C: drive.

Your download contains the text:

Flash BIOS Update Program - Version 8.00
Copyright (C)2010 American Megatrends Inc. All Rights Reserved.

Can you confirm that your BIOS brand is American Megatrends (AMI)?
The Windows tool seems to embed AFUDOS which you run as

AFUDOS ROMfilename

In also mentions AFUWIN and AFULNX so you could use the
Windows or Linux versions instead, too:

https://github.com/Zibri/afulnx/releases or even better:

https://www.wimsbios.com/amiflasher.jsp

https://soggi.org/motherboards/bios-update-flash-utilities.htm

Their English could be better: "Cann't flash to this version."

*If I have to guess, your DOS BIOS update tool may have a problem*
*with your DOS memory driver. Make sure to skip loading EMM386 and*
*possibly even HIMEM at DOS boot.* You can select a suitable boot
option when running the FreeDOS boot stick, or use the generic
F5 or F8 hotkeys.

The Linux version seems to be a bit of a pain to use, but there
are alternatives, such as flashrom:

https://opensource.com/life/16/8/almost-open-bios-and-firmware-update-tips-linux-users

Obviously, the question is how you can get the actual BIOS ROM
or BIN file out of the Windows/DOS integrated update tool. Try
running the tool in Windows, maybe it has a menu item for that?

If it does not have any user interface to click around in, then
some other trick for extracting the BIOS file would be nice :-)

Eric



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

Re: [Freedos-user] Using a USB stick and an optical drive

[Eric Auer]

Hi!

> OK, and thanks to all.  I have now read the Dell website about updating
> from within Linux and noted the fact that I should use FreeDOS base 1.0

Or newer, I guess.

> Although the upgrade will not give me Virtualisation, I have another
> reason for continuing with upgrading the BIOS.  It provides better
> support for the battery.  So it seems to me that although Windows 7 is
> on the laptop the issue remains, how to upgrade the BIOS using my 64 GB
> memory stick, FreeDOS and other things.  I was put off by the fact that
> something special had to be done to make the BIOS upgrade file available
> after the boot to FreeDOS.  I was comfortable with booting FreeDOS from
> a CD/DVD and just wanted to put the memory stick in, navigate to it and
> run the file, but that was not to be.

The main point is that you first have to boot DOS. Just opening some
DOS file in Linux or running DOS in a window in Linux is not what you
need. If you would do that, you will still have booted Linux, not DOS.

So you need a DOS boot disk. Because your update is so big, this is
not a boot diskette any more. In this century, you can use a CD, DVD
or USB stick. For making a DOS boot USB stick, you can use UNetbootin:

https://unetbootin.github.io/#distros

It already has a menu item to download and install FreeDOS for you,
apparently. The alternative is that you download FreeDOS yourself
and give the file to UNetbootin.

The next task is to put your BIOS update file and update tool at a
place where you can open it in DOS. As explained, if you use the
FreeDOS IMG file and dd, you end up having a 32 MB DOS USB drive
partition where you can add and remove files easily. If you use
ISO, replacing files works in a different way. Because you already
have Windows on your harddisk at the moment, you can also make a
FAT partition on your harddisk (DOS does not see NTFS partitions)
and put the BIOS tool and update files there instead of on the stick.

No matter which way you select, you always have to boot from your DOS
boot medium at some point. Then, when asked whether to install DOS on
your harddisk, you could say no. But as you only have Windows on your
harddisk at the moment, you can just as well say yes and throw Windows
out to have a look at FreeDOS, of course. Either after booting the DOS
installed on your harddisk or by simply leaving the install process
without installing DOS, you will have a DOS command prompt. As soon
as you are at the DOS command prompt, you can type the commands given
by the Dell BIOS update instructions to update your BIOS.

I guess we could also use some chat to help you interactively :-)

> We are, I suggest, still in business and that the objective has not
> changed, just the circumstances, the laptop has Windows 7 on it.  I want
> to prepare the memory stick using my PC with Windows 10 on it, insert
> the stick into the laptop, boot the laptop and then obey any instructions.

If you want to prepare your DOS boot stick on Windows 10, no problem!
You can use Rufus to make a bootable FreeDOS USB stick. Check this:

http://rufus.ie/

As soon as you have booted DOS from the stick, you can follow the
Dell instructions. Obviously, you want to add the BIOS update and
tools on your USB stick before booting from it, or at least put
the files at another location which you can access from DOS :-)

Regards, Eric



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

Re: [Freedos-user] Using a USB stick and an optical drive

[Eric Auer]

Now that we have clarified that the BIOS update tool can be
used with either Windows or DOS...

>> get a copy of RUFUS for Linux.

> https://www.how2shout.com/tools/rufus-for-linux-not-available-use-these-best-alternatives.html

Those tools are mostly for making bootable USB sticks from
ISO images. ISO images are for making bootable CD or DVD,
which explains why it helps to have extra tools to make
ISO boot from USB sticks in case the BIOS does not detect
what you are trying to do and helps you booting it anyway.

However, the FreeDOS diskimage for bootable USB sticks is
already MEANT for USB sticks, so you can avoid the hassle.

As explained, you can just use "dd" to copy the raw image
to the raw stick. I guess there also are other tools to
do that using the mouse and some nice menus.

If you are not experienced with dd, you can look up some
tutorial about copying diskimages to USB sticks with it.

Using dd the wrong way - as with all disk tools - could
result in overwriting the wrong disk instead of your USB
stick so you have to be a bit more careful when using dd.

After you do that, the stick will contain one 32 MB FAT16
partition and bootable MBR and bootable DOS boot sector
etc. to make everything boot FreeDOS once you boot from
the stick.

The only caveat is that the 32 MB are already full with
FreeDOS stuff, but as soon as you open the stick again
in Linux, you can simply use your file manager to throw
4DOS.ZIP away and instead add your BIOS file and BIOS
update tool instead.

Alternatively, you can use user friendly graphical tools
such as GPARTED to make the partition larger (because
your still will most likely be more than 32 MB) as long
as you keep it as FAT16. Then again you will have space
to add your BIOS file and BIOS update tool.

When you boot from the stick, you can abort the option
to install DOS to harddisk (of course) and instead run
the BIOS update tool at your normal DOS prompt.

I have no idea why your attempt to use Windows 7 to
update the BIOS has failed, but I would say there are
fewer unknown variables involved when you use DOS and
not Windows to update your BIOS version.

And I have no idea at all why you mention VirtualBox
or VMware in context of your attempt to update your
BIOS please explain that!

Now that you have overwritten your Linux with Windows
anyway, you could actually use the FreeDOS USB stick
to install FreeDOS to harddisk. Then, copy the BIOS
update and update tool to your DOS installation on
harddisk: That is actually even more foolproof than
running the tool on USB, because it will not depend
on how well-behaved your BIOS is for USB access. You
can just boot DOS from harddisk and do the BIOS update
in a really classic DOS environment.

I assume you do know how to run DOS apps? Simply type
the name of the file you want to run and hit enter.
There will be some documentation about the update
tool as well, I assume. For example you may have to
type something like NAMEOFTHETOOL NAMEOFTHEUPDATE
instead of just NAMEOFTHETOOL.

Regards, Eric



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

Re: [Freedos-user] CTMouse Buttons programming?

[Eric Auer]

Hi Thomas,

> I have a (normal) two button mouse and want to change the behaviour
> of a mouse button to act as if I pressed the »CONTROL« key on the
> keyboard.

> Use case: A DOS application where the mouse acts as a pointer without
> the need to click. This suggests to use the mouse buttons for
> productivity, e.g. assign the CONTROL key to the mouse.

I remember that Logitech mice for DOS had a tool
where you could "type" pre-recorded text snippets
by clicking the mouse while it was not used, so
I guess your idea to simulate control being held
as long as the right mouse button is held has some
similarity. Which leads to the question: Are there
freeware TSR floating around which already provide
what you need? I guess it is a bit uncommon that
your app does use the pointer but not the buttons.

In any case, I think it is better to use a separate
tool for what you want instead of adding it as a
feature to cutemouse.

Let me sketch the idea... Not necessarily for you,
but for people pondering to write a TSR for this :-)

Install check 1: check if int 33h vector is not null
Install check 2: int 33h, ax=0 check if ax=-1 returned
Check buttons: int 33h, ax=3, returns bx, cx and dx,
right button is second lowest bit of bx.

Callback for buttons: int 33h, ax=0ch, cx=18h, es:dx
pointer to far call to be invoked on right button
press/release. Call will receive ax=flags (10h for
release, 08h for press) bx=buttons cx,dx=location,
si,di=movement.

More modern callback: alternatively use int 33h, ax=18h
to register a far call (cx=0 to unregister in theory
and cx=18h, es:dx null in reality)

Either way, you probably are at risk to collide with
other apps also registering callbacks if you use those.

If you use function 3 to check buttons, you will have
to set a timer event to do that at regular intervals
and make sure to not do it while the mouse driver is
already busy with something else.

You probably also want to trigger only while a cursor
is visible or while the driver is enabled. For that,
you would intercept int 33h and check for ax=1fh/20h
(disable/enable driver), ax=1/2 show/hide cursor etc.

If it is only relevant to modify the state of keyboard
"control" in context of mouse activity itself, you can
intercept int 33h calls such that if your app looks at
the mouse status, you "look over it's shoulder" and use
the right mouse button status to update keyb "control".

Your app might look at the status of the "control" key
by calling int 16h, ah=2, which returns al bit 2 set if
control is pressed. So you could intercept that and set
bit 2 yourself based on mouse status, which you can poll
at that moment using int 33h, ax=3. On more modern keyb,
the call would be int 16h, ah=12h or, rarely, 22h. Both
let you set extra flags in ah: bit 0 for left and bit 2
for right control key, among others.

An even easier way to manipulate the apparent status of
"control" is to set bit 2 at 40h:17h or, if you also want
to manipulate left and right control, bit 0/2 at 40h:18h.

The difference is: If your app calls int 16h to check for
control, you can catch the calls as just the right moment
to check mouse buttons. In that case, you probably want
to avoid callbacks. If it does NOT, you probably want to
either use the mouse callback OR a timer event to get a
trigger when the mouse button changes and use that to set
the appropriate 40h:... bit, from where on the keyboard
driver will take care of the rest, in most situations.

If your app actually uses low level I/O to the keyboard
controller, things would get a lot more ugly, because
you would have to tell the hardware to fake keypresses.
Even in DOS, I would say that this is relatively rare :-)

Programmatically messing with keyboard input was sort of
popular in the old days, so I think it is quite possible
that a TSR which does EXACTLY what you want already is
out there and somebody here knows one :-) I remember to
have used a TSR which worked the other direction, moving
the "mouse" pointer with the keyboard, too.

In case nobody knows a suitable TSR for you, we would
have to play around with the ideas mentioned above, to
make something which does not interfere too much with
normal mouse usage of your app. Several methods possible.

I hope somebody can suggest a nice pre-existing TSR :-)

Regards, Eric

PS: There is no need to buy a "programmable" mouse. The
difference is just a more "programmable" driver, which
probably is not provided for DOS in modern gaming mice.
So I recommend standard mouse + driver + a special TSR.




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

Re: [Freedos-user] CTMouse Buttons programming?

[Eric Auer]

Hi!

> Has anyone out there achieved programming the right
> mouse button to a modifier key, e.g. Control?
> 
> I can‘t find any info on the forum or at CTmouse
> (CuteMouse) in Freedos which otherwise works fine.

Please explain your problem. Do you have a mouse with
only one button and want control-click to act as if
you had clicked the right button?

Regards, Eric




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

Re: [Freedos-user] Using a USB stick and an optical drive

[Eric Auer]

Hi Stephanos,

> 1) I have WINE on my laptop and run several MS applications.  Is it safe
> to treat the BIOS upgrade file as an application and run it in WINE?

That will not help. Wine can run Windows apps, but you want to update
the BIOS in your real hardware, not inside a Wine window on Linux.

> 2) I could install DOS Box, which is new to me, I have the same
> question, is it safe?

It is safe but will not solve your problem. You want to update the
BIOS in your real hardware, not inside a DOSBOX window on Linux.

> 3) Is running a version of Windows, 7 perhaps, in VMWare, and then
> executing the BIOS upgrade file feasible and safe.

It is safe but will not solve your problem. You want to update the
BIOS in your real hardware, not inside a simulated VMWare PC window.

> If I cannot do above and cannot get my head around burning images to
> memory stick, then I will revert to removing Kubuntu, installing Win 7,
> running the BIOS upgrade file, praying.

It would be a lot more complicated to install Windows on your entire
computer than to install FreeDOS on a little USB stick, no? Also, your
Kubuntu will probably get lost as side-effect and Windows 7 is very
outdated, making you a target for all sorts of hacks and viruses.

As mentioned, do I understand you correctly that you have BIOS update
tools available for both DOS and Windows, but not yet for Linux? Then
an interesting choice would be to use the DOS version because you can
boot DOS from USB, which is harder for Windows.

You could even make space for a DOS partition with gparted and, after
that, boot DOS from USB or CD and install it to that partition: This
has the advantage that harddisk access is more stable than USB access
while doing BIOS maniplations.

Also, you could first install Windows and then add Kubuntu to have both.
Of course you should not boot Windows unless needed for tasks such as
BIOS updates. By installing in that order, you can have both to choose
from at each boot.

Regards, Eric



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

Re: [Freedos-user] Using a USB stick and an optical drive

[Eric Auer]

Hi Michael,

so if I understand correctly, he has both DOS and Windows
versions of the update tool. I would NOT recommend to run
any of those in a virtual environment like DOSBOX and hope
to have any effect on the actual hardware. So indeed, to
use the DOS BIOS update tool, booting FreeDOS on the real
hardware is a good idea. DOBBOX has nothing to do with it!

> He should simply be able to do a:
> format /s a: ; copy bios.img a: ; cp programmer.exe a:

That will not work because he needs more space than what
would fit on a floppy. See my previous mail about putting
the FreeDOS USB installer on some USB stick. Then re-plug
the stick and use your normal file manager to change any
contents you like :-)

Regards, Eric



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

Re: [Freedos-user] Using a USB stick and an optical drive

[Eric Auer]

Hi! I do not understand where Windows and ReactOS are
getting into the equation here. If you have Linux, you
can search in your software center whether you find an
app to install BIOS updates. If you have some DOS tool
for that, you should run DOS for the tool, not Windows.

As your update is more than what fits on a floppy, you
can check whether the actual update is smaller. Your
file could be some sort of archive. Some BIOS even are
able to install updates from files on USB sticks etc.
when you find the right menu item. Read the manual :-)

http://freedos.org/download/ explicitly offers DIFFERENT
downloads for CD/DVD and for USB. Obviously it is easier
to use the USB version if you want to run DOS from USB.

The "Lite" FreeDOS 1.2 for USB contains an IMG file which
you can simply "dd if=FD12LITE.img of=/dev/yourusbstick"
(yourusbstick = the device name of the stick) which is
unfortunately not explained in the README.md text file.

According to the vmdk file in the download, the image has
62 x 16 x 63 DBB geometry at 512 byte per sector: 32 MB
decimal or 30.5 MB in powers of 2, at 503 x 2 x 63 CHS.

As the image starts with a partition table, you do not
use it as partition image, but install it on the whole
USB stick, overwriting any existing contents. The FAT16
partition on the stick (note that not all sticks can be
booted at all!) has only 112 kB free. You may use gparted
to resize it (but keep it FAT16, or it will not boot) or
simply delete some files you do not need, for example
/FDSETUP/PACKAGES/UTIL/4DOS.ZIP which frees up 4 MB for
your BIOS update files and tools :-) You could also take
the SOURCE/FREECOM/SOURCES.ZIP out of the COMMAND.ZIP in
/FDSETUP/PACKAGES/BASE/ to save more than 4 MB again.

*I think it would be better if the USB installer would*
*use a much larger image padded with 96 MB empty space*

It is very hard to find USB sticks smaller than 128 MB
today and it makes life a lot easier if people can add
things to the installer without having to resize it :-)
ZIP download size will still be only 30 MB nevertheless.

In any case, after you install the USB installer image
to your USB stick of any size, it will initially look
as if you have a 32 MB stick and you can delete 4DOS to
make some space for your BIOS update tools and files.

You do not need gparted for that and you do not need
external floppy drives, CD drives or DVD drives either.
Your 32/64 bit issue seems harmless: Your 64 bit Linux
still supports 32 bit apps. You can use either style.

Regards, Eric

PS: Note that USB 1 is horribly slow, so you will need
some patience. Even if you have USB 2 ports, your BIOS
may use USB 1 access mode when you boot from USB stick.
In that case, CD/DVD would be faster, but you need other
tools to change the contents of ISO before burning them.



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

Re: [Freedos-user] FSF

[Eric Auer]

Hi Rugxulo,

> Richard Stallman has not been convicted by a court. He is not in
> prison. Let's not burn his house down over pathetic words.

That is not the point.

> He's not perfect. He doesn't have to be.

To be in a leading position in an organisation which tries
to be a good example in the world, one should contribute to
a good atmosphere. Having a mattress with shirtless people
in your office for example does not contribute to that:

https://selamjie.medium.com/remove-richard-stallman-appendix-a-a7e41e784f88

Just because MIT failed to have sexual harassment policies
which explicitly outlawed bullying people into dating you
does not mean that FSF can welcome a leader who tried that.

> His public or private opinion is irrelevant.
> Nobody is following his example.

He is not just anybody. Having his fame, there is a risk
that people do follow his example. Having him work at a
high-ranking position sends a signal that he has a fine
character and his example should be followed. As said,
FSF could simply hire him as expert consultant instead.

For comparison, think about the years when there was a
man at a very high-ranking position who got away with
"grabbing women by the pussy", firing everybody who did
not agree with him and intimidating yet others to never
hold him accountable. He actually acquired a lot of fans
who hoped to become successful by being more like him,
even in the years before as rich boss guy in a TV show.

So yes, personal opinion does matter for certain jobs.

Regards, Eric



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

Re: [Freedos-user] FSF

[Eric Auer]

Hi all!

Looking at the links provided by TK Chia and in Jim's blog,
Stallman has (and caused) a real problem, so I agree that
he should not be in that new powerful position he now got.

And I do not think that this is cancel culture censoring
unpopular thoughts. He can share his thoughts as much as
he wants *without* being a sexist FSF leader. Sure, none
of his controversial comments were illegal. But reading
the various comments, it was really painful for women to
have him as superior, which makes him unfit for the job
if FSF is as noble as they want to be. Maybe being rude
was good for the fight against MS, but that is unrelated.
He can work for FSF as expert without being board member.

As mentioned, see for example

https://gcc.gnu.org/pipermail/gcc/2021-March/235161.html

https://selamjie.medium.com/remove-richard-stallman-appendix-a-a7e41e784f88

https://homes.cs.washington.edu/~lazowska/mit/

etc.

Now about Michael's off-topic relative to this thread:

Also, why does everybody want a free Windows? You can use
free alternatives such as Linux, optionally with Wine if
you need to keep some Windows compatibility. Or even work
on making ReactOS more useful. None of those involves any
strange arguments about why stealing Windows would be OK.

Why would we want a FreeDOS variant which drops support
for BIOS disks? Floppy, IDE, SATA, USB and other stuff
you mention? If you have no BIOS, install an UEFI CSM
as part of your boot chain to replace it. If you neither
have a CSM nor want to help with creating one, run DOS
in a generic PC emulator of your choice or in DOSEMU2.

Same for possible lack of VGA compatibility in new graphics
cards and their BIOS. People have written TSR to resolve
some of the BIOS issues for DOS, like missing 8x14 fonts.

Also, it is still reasonably easy to get hardware for your
FreeDOS install with a totally normal BIOS, so why would
you want to make a statement by dropping support for it??

What is the problem with GRUB 1 or 2? And what is your EFI
problem? Linux needs almost no help from firmware and is
able to boot from either BIOS or EFI based computers now.

You can use secure boot with Linux, too, as distros make
signed kernels, or you disable it in your BIOS settings
if you want full freedom to boot anything of your choice.
I guess only Blue Ray media players will hate you for it.

There are so many possibilities. Nothing wrong with running
DOS in a virtual PC on your ARM smartphone. Well, I hope you
have an app to connect a real keyboard. But I really see no
reason why you could want a DOS for ARM first, for example.

> ReactOS by the way in VirtualBox on CentOS 8 is stable enough that
> you can play Warcraft II Battle.Net edition all the way through

 :-)

Regards, Eric



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

Re: [Freedos-user] formatting floppies

[Eric Auer]

Hi Bob,

> I need to low level format a bunch of older 1440k floppies that are
> starting to lose their integrity. A low level format often works to
> revitalize them. But, I could not get the FreeDOS formatter to do
> anything but reformat the directory area. Can a full low-level format
> of 1440k floppies actually be done on FreeDOS? What am I missing?

Let me assume you are using a classic floppy drive. USB versions may
lack support for low level format via DOS, or any support DOS at all.

To low level format a floppy, use the /U option. You can combine it
with the /D option for verbose debugging output, for example:

FORMAT A: /u /d

Regards, Eric



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

Re: [Freedos-user] Raspberry Pi ISA card (was: networking/wifi)

[Eric Auer]

Hi! To add some thoughts, rambling and brainstorming here...

interestingly, classic PCI is the sweet spot for DOS networking.
It has better plug n play detection than ISA and is not too new
for DOS drivers to exist.

Fast and easy interfaces include printer (sound: Covox), IDE and
maybe even floppy. I would suggest to connect to those, instead
of the whole ISA bus, where appropriate.

Fast interfaces on Raspberry Pi style computers are usually SPI,
including 2- and 4-bit wide variants and SDIO. Of course you can
do parallel stuff - but it will quickly exhaust your I/O pins.

Actually you can still get 8255 PIO variants, which give you 24
GPIO (not very general purpose, but sufficient) from a single
8-bit bus and 4-5 control lines.

For example in the Unibone mentioned in this thread (connect a
Beable Bone Black to PDP-11 bus) they use 2 parallel buses and 4
address and control lines to control 8+8 read and write registers
connected to retro DS8641 bus drivers for 57 out of 64 GPIO pins.
One bus is used for input data, the other for output data.

You can also use SPI based I/O extenders: At usually max 26 MHz,
you would have to use a few in parallel (maybe via wide SPI, if
you do not have enough fully independent SPI buses) to get enough
I/O speed. I liked the old Asus Tinkerboard with eMMC several SPI.

You mention virtual disks, memory, sound, serial to internet, etc.
For example Covox is not that bad if you DMA samples to the port.

I remember SuSE Linux once shipping with DOS or Win3 X server, but
of course the apps would run on Linux then, not the other way round.

Memory expansion, sound and virtual disk (e.g. SD, USB) cards for
retro computers already are on the market. Bluetooth modules tend
to support modem style serial access. Some also are WiFi modules:

Writing an Arduino program for ESP32 to bridge a serial port to a
telnet in your WiFi network should be reasonably straightforward.

With 8-bit ISA, you have 8 data lines, 20 address lines and almost
30 control lines including many IRQ or DMA signals, but you will
need FAR less depending on your goals. For example I/O ports on PC
normally only look at the low 10 address lines and you need fewer
control signals compared to MMIO or memory extensions. 16-bit DMA
has more data line, some extra address lines and more IRQ/DMA etc.

You could probably get around with a single 8255 and few discrete
logic or latch chips to build a bridge between ISA I/O port space
and Raspberry as long as it is allowed to pull the CHRDY brake.

https://old.pinouts.ru/Slots/ISA_pinout.shtml

I wonder whether super I/O chips exist which can bridge ISA and
LPC: For example the SIO10N268 can be connected to either and it
contains parallel, serial, floppy and other controllers, but of
course it does NOT let you generate ISA from LPC or vice versa,

It just illustrates "how co-existent" both buses were. LPC clocks
at 33.3 MHz and uses around 10 I/O lines to connect the usual ISA
age peripherals to computers which do not really have ISA slots.

Southbridges are probably not the way to go, but how about PCMCIA
or PC Card controllers as a starting point? PC/104 seems less nice
given the prices for PC/104 industrial single board computers now.

Keep me posted :-) Eric



>> ISA ... Pi ... that could emulate a Floppy/HDD/CD-ROM/DVD-ROM
>> ... 1000BaseT Ethernet and/or WiFi would be a super card ...
>> sound cards ... remote desktop ... expanded memory ...(virtual)
>> hard drive ... USB flash drives ... NE2000 network ... debugger
>> ... serial port (over network) ...



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

Re: [Freedos-user] networking/wifi

[Eric Auer]

Thanks for the links, Louis :-)

While the price could be a lot lower, the

https://www.cbmstuff.com/proddetail.php?prod=WiModem232

https://www.cbmstuff.com/proddetail.php?prod=WiModem232&review=all

mentioned on one of the pages is pretty similar to what
I had in mind: some WiFi controller plus a RS232 level
shifter plus good firmware = fake WiFi dial-up modem :-)
AND it has everything pre-installed, with WPS quick setup.

There seem to be several websites about tinkering with
for example a Raspberry Pi and USB serial port adapter,
using the tcpser software. One randome exammple for that:

https://www.insentricity.com/a.cl/215/putting-your-retro-computer-on-the-line

The WiFi232 page http://biosrhythm.com/?page_id=1453 says
it is sold out - the concept seems a lot like WiModem232,
but with a more bulky non-SMD circuit board for WiFi232.

As WiFi232 is ESP8266 based: Arduino-Raspberry-et-al Stores
sell you stuff like Waveshare RS232 (SUBD9, header, SP3232E)
for 5 Euro and ESP8266 or ESP32 modules on boards with pin
headers for 5 to 10 Euro (NodeMCU v2 with Lua, "ESP-01S" or
Olimex MOD-WIFI-ESP8266, Olimex ESP32-DevKit-LiPo, NodeMCU-32S
or similar) you could easily roll your own if you have access
to the right firmware: Some jumper wires or a breadboard can
link both ingredients and the ESP32 or ESP8288 listed above
have micro USB sockets for power and for uploading firmware.

That lets you BUILD a WiFi RS232 modem for less than 20 USD,
not counting cables and case. Without even having to solder!
As long as software is made? Arduino does support ESP chips.

Cheers, Eric




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

Re: [Freedos-user] FreeDOS 1.3 LiveCD hangs with lenovo ryzen 5 3500u

[Eric Auer]

Hi!

> Hello
> 
> I'm having issues with booting FreeDOS 1.3 in live environment in my
> Lenovo Ideapad S145 Laptop. After booting syslinux and isolinux, both
> options, either install or boot into live environment, fail to load. It
> loads memdisk and the fdlive image and hangs.
> 
> I've tested the live environment on a old celeron t3500 with an american
> megatrends bios and it worked, just cant use fdapm, my old laptop has
> heating issues that ACPI control would help to manage as DOS is always
> using the CPU fully. Is it likely some kind of incompatibility from
> lenovo legacy mode? I will contact Lenovo and wait for further
> investigation, but decided to report this. A search on their forum shows
> that other users had issues with freeDOS 1.3 but were able to use
> MS-DOS, so this got me even more confused.
> 
> Regards
> Eduardo Lucas

> It doesn't even starts booting DOS, at least visually. It loads
> memdisk, loads fdlive, and then prints memdisk authorship and
> version message to the screen hanging afterwards and only
> stopping by hard powering off the machine by its button.
> I can't even cold reboot by ctrl alt del.

That sounds like an issue with MEMDISK memory management and I think
there are some boot loader ways to pass options to MEMDISK to switch
it to a more compatible mode, maybe somebody here remembers the right
trick and the details for that? I assume your MEMDISK is loaded via
GRUB, SYSLINUX, ISOLINUX or similar loaders which let you pass some
options to MEMDISK.

https://wiki.syslinux.org/wiki/index.php?title=MEMDISK#Memory_access_method

Default in newer versions is safeint (int 15) while alternatives
include raw and int. Check your loader config to see what you had.

Could also be useful to use stack=2048 if the default 512 is too small.

Regards, Eric



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

Re: [Freedos-user] networking/wifi

[Eric Auer]

Hi! To do some additional name-dropping on the DOS WiFi topic here:

https://www.olimex.com/Products/IoT/ESP32/ESP32-GATEWAY/open-source-hardware

https://www.hackster.io/techbase_group/arduino-esp32-serial-port-to-tcp-converter-via-wifi-66d341

https://github.com/martin-ger/esp_wifi_repeater/blob/master/README.md

In short, you can do interesting things with cheap WiFi (and Bluetooth)
enabled controller modules, including things which involve LAN or RS232,
so there might be some "turn some modules for a total of 10-25 USD into
a connector between WiFi and LAN or serial port" project out there for
those who prefer tinkering over ready to use brand devices :-)

ESP32 are 4 USD 2-core controller modules with WiFi, Bluetooth and more
interfaces, 520 kB RAM, more compute power than your 386 PC. But just
marketed as wireless controller, less as microcontroller. "ESP8266++"
Maybe fast enough to simulate a PC XT, with MDA graphics, in software.

Cheers, Eric



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

Re: [Freedos-user] networking/wifi

[Eric Auer]

Hi!

> Am just wondering if this is the current status, or some old comment:
> 
> "Wireless devices connected via USB can not yet be used with FreeDOS."
> 
> (http://freedos.sourceforge.net/wiki/index.php/WiFi)

This meant "USB dongles which serve as WiFi or Bluetooth modems
have no DOS drivers" and is still the case as far as I know:

In rare cases, DOS drivers for PCMCIA WiFi modems have existed.
For current computers, the recommended workaround would be to
use an external WiFi to LAN converter, as it is much easier to
find LAN style wired network drivers for DOS.

Similarily, I would expect Bluetooth to serial port converter
modules to work reasonably well with DOS: Those tend to have a
modem-style command system to control them and actually serial
interfaces between microcontrollers and Bluetooth modules are
widespread. It is slow enough to be useful even if not connected
by for example a faster SPI bus. Of course you would still need
a converter for RS232 signal levels. Combined products may exist.
Also, DOS users tend to have modem command skills and dialup tools.

Maybe people here could talk about their experiences with specific
brands of WiFi LAN gateways or Bluetooth RS232 adapters in DOS :-)

Regards, Eric



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

Re: [Freedos-user] fdnet.bat

[Eric Auer]

Hi!

> lspci -nn -vvv | grep Ethernet

You can also use PCISLEEP Q02 to get a list of network
devices in DOS, or you could use PCISLEEP L to get a
full list of PCI devices in your system :-) As this
tool is quite small, it will at most tell you the
brand names, not the product names, but you can use
online pci id lists to search those manually.

Note that PCISLEEP Q might have simple enough
text output for automated batch processing ;-)

Regards, Eric



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

Re: [Freedos-user] fdnet.bat

[Eric Auer]

Hi!

If that means that fdnet knows which driver WOULD match
a given PCI ID, could it DISPLAY that info and let the
user dig up the recommended driver manually? What does
the current fdnet version do in such cases, silently
load another driver in the hope that the hardware would
actually be virtual, matching one of a small set of
standard drivers? Even then, it should probably be more
explicit about what is happening :-) And as Dean hints,
if the user already has loaded ODI drivers, fdnet could
detect that and load a WRAPPER, without requiring extra
hardware drivers, as the ODI drivers already are there.

Regards, Eric



> Hi,
> 
> Unfortunately, there are only a few actual drivers that can be
> included in the FDNET package. This greatly limits the usefulness of
> FDNET.
> 
> However, the supplied drivers work well in VirtualBox and VWware.
> Although not tested, it should support some versions of QEMU.
> 
> There was a recent update to FDNET to help a little on machines that
> have a NIC not supported by the supplied drivers. Basically, it added
> a command line option to skip the supplied drivers and only try to
> initialize DHCP. That way the user can provide the correct driver and
> simply start DHCP to prevent running any conflicting supplied
> drivers.
> 
> It would be nice if it could provide support for more NICs. But,
> unfortunately it’s more or less limited to only including the ones it
> already has. If additional open source drivers are known, they might
> get included.
> 
> Jerome




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

Re: [Freedos-user] BIOS weirdness with SATA/IDE adapter (was IDE <-> CF adapters)

[Eric Auer]

Hi Jon,

actually I do not expect "drivers" like OnTrack, Ez Drive etc.
to mess with host protected areas. They just redirect attempts
to access the disk by BIOS to their own code, which modifies
the BIOS call parameters. Which is why OS which access disks
without using the BIOS have to be configured to do suitable
transformations themselves (e.g. Linux offset boot parameter)
or use suitable drivers made for the specific OS in question.

But you make a very important point about the transparency
of the process. In the days when DOS was normal, you could
probably get everything converted during the driver install
process get away with it. But as soon as you have a system
with 2-99 operating systems on disk, it is A LOT easier to
first install the "driver" BEFORE you install any of your
operating systems at all. Because otherwise, even if you
take partition images and everything, you WILL end up with
having to do elaborate tuning to get things to boot again.

Boot managers tend to be RATHER sensitive about where and
on which disk geometry the system that you want to boot is.
So if you install a "driver" which changes that or even
shifts everything to another offset on the disk, you will
have to have some serious explaining to do until the boot
process cooperates with you again.

Then it's a lot easier to start with the "driver" and then
install the OS of your choice later. You may still backup
your files as files or in tarballs, not as disk/partition
images, to add them to the freshly reinstalled OS later.

Regards, Eric



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