Hi Eric,
I have accidentally responded only to Jerome before, saying that I've
found the cause. Let's take care of your message first.
>Do things work better with no JEMM... loaded?
Yes! Much better! I would have to record those tests, but I can tell you
that:
Redneck Rampage will glitch out, make my ears bleed and return to DOS,
and while it's still in DOS, the sound card will continue to play a
half-buffered sample and continue to destroy my ears
GTA1 will refuse to run in every graphic mode. 8bit palette mode and
24bit palette mode will just print a stack and some kind of exception.
3dfx mode will complain it can't allocate 215KB of memory, despite at
least 500KB being free
This is the state of affair with JEMM386 loaded, so when I run my system
with Yamaha or AWE, it's with HIMEMX and nothing more on top of that.
The only game so far that actually prefers there be JEMM386 running is
"The Lost Vikings" which is unable to count the free memory correctly.
Probably because my FreeDOS machine has 2GB RAM.
I have figured out that the games are okay. I used Metasoma's "Mirror of
life" album in Quake 1 which is a pressed CD and it worked wonders. So
the problem is the CD copies I made for GTA1 and Redneck Rampage. I have
analyzed my images and software stack and I have a little clue. It seems
the culprit is CDRDAO, and this is what I found when successfully
running toc2cue:
toc2cue version 1.2.4 - (C) Andreas Mueller <andr...@daneb.de>
Converted toc-file 'Quake2.toc' to cue file 'Quake2.cue'.
Please note that the resulting cue file is only valid if the
toc-file was created with cdrdao using the commands 'read-toc'
or 'read-cd'. For manually created or edited toc-files the
cue file may not be correct. This program just checks for
the most obvious toc-file features that cannot be converted to
a cue file.
*Furthermore, if the toc-file contains audio tracks the byte**
**order of the image file will be wrong which results in static**
**noise when the resulting cue file is used for recording**
**(even with cdrdao itself).*
So, the images I make with CDRDAO might be all wrong.
So, FreeDOS is fine. Sorry for alarming anyone.
Best regards,
Michał
W dniu 22.01.2022 o 23:45, Eric Auer pisze:
Hi!
I used this version of OAK
https://www.hiren.info/download/dos-files/oakcdrom.sys
and the problem persists. I even tried 3 different sound cards with
the CDROM in UDMA and PIO modes:
- SoundBlaster AWE64 Gold
- SoundBlaster Vibra 128
- Yamaha YMF724
...
In all 6 tests, the CD input would produce static noise, except with
Vibra 128. Don't even get me started on this card, it's always been
an unstable mess in DOS, courtesy of JEMM386.
Do things work better with no JEMM... loaded?
Have you tried using XMGR instead of HIMEM?
Regarding the sound question in general, do
the games use the audio PLAY function of the
drive? If yes, is the wiring okay and are the
games able to properly configure the soundcard
volumen control and mixer to the correct input?
If the games use the function to read the raw
audio sectors instead and then play them as a
part of the game sound itself, the whole flow
of data and sound would be different and the
question would change into whether the games
can properly READ the sound data, while using
the normal game sound driver to then play it.
Any more ideas? It used to work flawlessly in FreeDOS 1.2 with
SHSUCDX backported from 1.3 RC that was newest like, at least a year
ago. It turned out back then that SHSUCDX from FD 1.2 does not
support CD playback at all.
I suggest that you compare the UDVD2 versions
and SHSUCDX versions of FreeDOS 1.2 and 1.3 to
find out whether you need the FD1.2 version of
one (which?) or both drivers for your games.
If you were using a different driver, such as
ATAPICDD or OAKCDROM or AHCICD instead of UDVD2,
or MSCDEX instead of SHSUCDX, you can of course
also compare the effects of those differences.
However, as far as I understand, 1.2 worked
out of the box with old SHSUCDX and old UDVD2
and your OAKCDROM experiment is just to check
whether that works better with new SHSUCDX
than new UDVD2 does, also possibly related
to changed command line options in the new
FreeDOS 1.3 style default boot config files?
Thanks for testing!
Regards, Eric
PS: As usual, the memory drivers can also be
part of the problem. HIMEM (try XMGR), JEMMEX
(try JEMM386 or no JEMM... at all) etc.
_______________________________________________
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user
_______________________________________________
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user
