Re: [Freedos-devel] Contemplations, Considerations and some Conclusions

2022-01-22 Thread Eric Auer



Hi Jerome, to answer some specific parts of your mail:

Yes, it is useful to have two different boot style CD
images and not only the more compatible variant plus
a boot floppy image. Because the latter would mean
that people which could boot CD only in the less
common style would need a floppy drive to boot some
special floppy which in turn boots the common style
CD "manually", but not everybody with an old CD boot
BIOS automatically has a floppy drive to boot this
workaround :-)

And no, to answer the other question, it does not
sound very useful to me that you can install floppy
edition style from the CD, even when it only is an
easter egg.

So: LiveCD yes, LegacyCD yes, additional boot floppy
images beyond those on the CD itself used by the BIOS
to boot no? And as you know, I suggest having a nice
BASE plus some extras set of things pre-installed on
the LiveCD, without first having to unpack them to a
RAMDISK. Most BASE apps do not need to be copied to
a writeable drive to work, so precious RAMDISK space
can be saved by running directly from the CD.

Also, regarding some earlier question on this list,
I think it would be nice to have the bootable USB
"live stick" pre-installed in similar ways. This
lets users start to enjoy DOS immediately without
needing this "use a partition manager to create a
second FAT partition on the stick in remaining space
and push the installer to install to D:" trick :-)

I agree that USB boot support may not always let
you write to the stick, but then again it helps
to have more pre-installed DOS apps on the stick,
so people have to install less into some RAMDISK.

We should expect DOS users to be able to realize
whether or not writing to USB fails on their PC.

There should be a warning about which drive is RAMDISK,
so people are not disappointed to lose data THERE.

Last but not least, some mails mentioned FDISK
problems which do not happen with 512 MB or larger
virtual computer drives, but with smaller ones,
such as 500 MB so I wonder whether this actually
some FDISK automatic LBA decision gone wrong?
The limits for various CHS schemes are in the
500 to 530 MB range and around 8 to 8.5 GB.

It would be nice to have a tool for popular OS
which extends the boot partition to the size of
the stick when using a DOS USB boot image, but
that takes effort, so I think a flat diskimage
which requires a stick of at least 150% of the
space actually filled with installer data will
be most universal: People can use any diskimage
writer of their choice to "install" it, which
avoids questions like whether RUFUS etc. would
understand contents well enough to tune them?

Regards, Eric

PS: I agree that CoreBoot or SeaBIOS as base of
a CSM (or whatever the acronym was) to get BIOS
style services on UEFI systems would be cool :-)
Regarding a pre-configured Linux which simply
boots into DOSEMU2 or similar, those exist. But
you could even use DOS in DOSBOX-X in HX in DOS.



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


Re: [Freedos-devel] Testing FreeDOS 1.3 RC5 (Games)

2022-01-22 Thread Eric Auer



Hi! Bumping this thread from Jim. I think if the majority of
the games has palette issues, it could be VirtualBox or QEMU
just not properly emulating VGA, VESA, VBE etc., possibly also
depending on the color depth of the host operating system GUI.

Which versions and settings were used? Which variations tried?
Also, about the frequent crash/hang/etc. problems, did it make
a difference which memory managers and/or DOS extenders such
as a pre-loaded DPMIONE, DOS32A, CWSDPMI etc. were used, and
which virtual computer settings were used? Have you tried HIMEM
versus XMGR, with and without JEMM386, optionally JEMMEX instead?

Floppybird seems to be one of a few games with stable colors?
And maybe PakuPaku and Tetris, minus the art licensing issue
with the latter? I have omitted the license discussion below,
because the virtual graphics card and crash issues seem to be
more "hardware" specific and your mail sort of focuses on how
well the two emulators can run DOS games. Senet, Zimy and Smiley
also work for you, so the question is which graphics modes have
which problems. My guess would be MCGA working, but VBE not?

Regards, Eric

...


I am testing on both VirtualBox ("VB") and QEMU. (I don't seem to have
sound set up properly on VirtualBox, but it works fine on QEMU. If
someone else uses VirtualBox and has sound working, please share your
config info.)


...


Bolitaire (Freecell-like game)
VB: Plays fine, but the screen just goes to black after I exit, never
goes to the command prompt
QEMU: Doesn't even start, just reboots my virtual machine

Boom (Doom-like game)
VB: Plays fine, but I don't have my sound set up so I don't get sound
QEMU: Doesn't start, just aborts with "Illegal instruction"


...


Dosdef (Defender-like game)
VB: Doesn't start, I get a Jemm386 exception. If I reboot without
Jemm386, I get "Interrupt divide by zero."
QEMU: Doesn't run, just a blank screen.


...


Empong (Pong-like game)
VB: Plays fine, but my VB isn't set up for sound
QEMU: Completely unplayable; I get a beep, then the game seems to
freeze, then my turn is over.

Ev4de (space flight game)
VB: Plays fine. Feels a bit sluggish...
QEMU: Doesn't run, I get "Fatal error! Error code 5"

Ewsnake (snake game)
VB: Plays fine, but I think the colors are messed up (hard to tell
because it doesn't use much of a palette)
QEMU: Plays fine, and the graphics palette seems correct here


...


Fmines (minesweeper game)
VB: Plays fine, but really slooow to load, probably because
it's loading a huge image
QEMU: Plays fine, but takes a long time to do anything, so
long that I thought my virtual machine had stopped


How about using UHDD or similar, possibly with the BIOS mode
option in case your virtual computers have broken UDMA? It
would of course be even better if they emulate UDMA properly!
Also, have you tried whether a ramdisk made the game faster?


Freedoom/SMMU (Doom-like game)
VB: Plays fine, but I don't have my sound set up (see Boom)
QEMU: Doesn't start, I just get "Illegal instruction" (see Boom)

GNU Chess (chess game)
VB: Plays okay, but you need to load NANSI to play this one
QEMU: Same; plays okay, but you need to load NANSI first
**But this doesn't really seem like a good chess game. Is there a
better open source chess game for DOS out there?


Do you mean in terms of strength in playing or in terms of
looks? I think the GNU Chess and Go games are primarily just
engines, which you can combine with nicer looking GUIs. Of
course, computer opponents have grown a lot stronger now,
but that probably requires multi core, multi GB RAM, GPGPU?


Hangman (hangman game)
VB: Plays okay
QEMU: Starts up, but I can't start a game. I get "Illegal function
call in module HANGMAN at address 02dd:0745" when I start any game.
**This seems like a primitive Hangman game. Is there a better open
source version out there?

Ivan (Rogue-style game)
VB: Plays ok
QEMU: Starts up okay, but really slow to load. I'm also
getting some "double keypress" problems on this game.

Kraptor (Raptor-like game)
VB: The graphics palette is messed up. I tried to quit, but then
nothing happened. I think it froze up trying to quit.
QEMU: Plays fine. Keyboard is faster than the mouse.

Liquiwar (unique multiplayer strategy game)
VB: The graphics palette is messed up. I tried to quit, but then
nothing happened. I think it froze up trying to quit.
QEMU: Starts up okay, but really slw to start.

Mirror Magic (puzzle game)
VB: The graphics palette is messed up. I tried to quit, but then
nothing happened. I think it froze up trying to quit.
QEMU: Plays fine, and I get sound

Mistral (turn-based spy RPG game)
VB: Plays okay
QEMU: Starts up okay, and I get sound, but I get the "double keypress"
problem and can't select Quit.

Nethack (text explorer game)
VB: Plays okay.
QEMU: Plays okay, but I get the "double keypress" problem so I keep
skipping over things

NGE Nibbles (snake game)
VB: The text fade in/out is really slow,