VOGONS


First post, by kas1e

User metadata
Rank Newbie
Rank
Newbie

While some time ago Jmarsh fix issues with 15/16/32 bit modes on big-endian, as well as "vgaonly" driver, I think it worth to create another topic with all remain big-endian issues and will update it from time to time. So what we have now:

1). ctrl+f5 to save screenshots broken for 15/16/32 bit modes
fixed by Dreamer: https://github.com/dreamer/dosbox-staging/com … 4d85000056c485f
Probably can fits into DOSBox main svn repo?

2). ctrl+alt+f5 for video recording record video fine, but audio complete noise

3). and found some new one (or, it can be related to 2) ):

On my big-endian machine, I have libSDL_sound's demo-examples play all .ogg and other files correctly, no noise. But then, the same files when they mounted from some cue file as CD-ROM give me heavy sound distortion when I tried to play them (be it some game using it, or just some simple cd-player)

At first, checked cd_image.cpp, and found that "Sound_AudioInfo desired = {AUDIO_S16, 2, 44100};", while it should be probably AUDIO_S16SYS, so to cover and little and big-endian machines? But even with such a change, I still have distorted sound. Not sure if it related to the same issue which we have when recording a video or it completely different one.

A simple test case is:

1). create file test.cue in which:

FILE "homm2_01.ogg" MP3
TRACK 01 AUDIO
INDEX 01 00:00:00

2). put in the same directory that "homm2_01.ogg".

3). imgmount d test.cue -t iso -fs iso

4). run any cd-player and try to play that single track (as a test can be used DosNavigator's cd-player for example) => noise

Is anyone else can reproduce that 3rd issue on big-endian machines? Thanks!

Last edited by kas1e on 2020-02-03, 05:50. Edited 3 times in total.

Reply 1 of 18, by krcroft

User metadata
Rank Member
Rank
Member
kas1e wrote on 2020-02-01, 17:56:

... But then, the same files when they mounted from some cue file as CD-ROM give me heavy sound distortion when I tried to play them (be it some game using it, or just some simple cd-player)

At first, checked cd_image.cpp, and found that "Sound_AudioInfo desired = {AUDIO_S16, 2, 44100};", while it should be probably AUDIO_S16SYS, so to cover and little and big-endian machines? But even with such a change, I still have distorted sound.

Just curious if dosbox-staging handles compressed audio tracks correctly on your machine? I tested and made accomodations for big-endian to do the right thing for all formats (flac/wav/mp3/opus/vorbis/Sony-Wave64), however I was only able to exercise these on my Linux-based PowerPC-7400.

If it does, then perhaps some aspects on solving this in DOSBox SVN can be garnered there. If not.. then I've got more work to do 😀

Reply 2 of 18, by kas1e

User metadata
Rank Newbie
Rank
Newbie

@krsoft
I tested it via dosbox-staging, and yes, that particular thing works! The sound plays fine!

But then, with DOSBox-staging I have another issue related to imgmount or something, which original DOSBox didn't have: mounting of the ".img" file like "imgmount d mk3.img -t iso", give me on DOSBox-staging:
"MSCDEX: Failure: File is either no ISO/CUE image or contains errors".

While when I mount that in original DOSBox via the same "imgmount d mk3.img -t iso", it gives me:

MSCDEX installed.
Driver D is mounted as c/games/MORTAL3/MK3.img

I checked dosbox-staging part related to that SDL_Sound part, and it seems it needs to replace quite a few files and headers to make it works. Through, it will not fix the issue with non-mounting of .img files (only them? maybe issue is wider?)

Maybe it possible to make a "tiny" change in SDL_Sound part in original dosbox, so endians will be taken in account, but without major rewrite ?

Reply 4 of 18, by krcroft

User metadata
Rank Member
Rank
Member

There were improvements made the CD audio handling code that many folks here helped with testing, offering suggestions, and inspecting the code.

These updates were packaged and provided to DOSBox via its patch-submission page, specifically in the first two posts here: https://sourceforge.net/p/dosbox/patches/284/

Although these haven't been merged as of today, I'm hopeful the authors will be able to review and make use of some or all aspects of them.

Regarding the MK3 img, will PM and see if we can figure it out!

Reply 5 of 18, by kas1e

User metadata
Rank Newbie
Rank
Newbie

@all
Dreamer seems to fix "ctrl+f5" issues on big-endian:
https://github.com/dreamer/dosbox-staging/com … fabd341b105fcc5

Through at the moment I test only 16bit (hugi), and it saves all fine. But with 15 and 32 bit still can't find any application to test with. PCPBench exit once you hit any button, so can't hit ctrl+f5. Maybe anyone remembers any simple app which can be running in 15,16 and 32 bits, so screenshot can be taken?

Thanks!

@krcroft
It seems that with DOSBox-staging I can't mount any ISO, IMG or BIN file at all with pure "imgmount -t xxxxx -t iso".
.CUE or .INS files mount fine. Replied in PM as well.
Maybe on the configuring stage something fail... Is "opus/opusfile" used anyhow in staging for cd-driver or it not related?

Reply 6 of 18, by krcroft

User metadata
Rank Member
Rank
Member

Follow up on Mortal Kombat 3: so although we could mount the CDROM image, install the game files and start the game, it would fail its CDROM copy-protection check.

The issue was in my CDDA code and due to me incorrectly understanding the meaning of the "end track" number in the GetAudioTracks() function. Instead of being the lead-out track number, it should be last playable track number (sounds pretty obvious in retrospect!). This function satisfies the MSCDEX "Audio Disk Info" call, which MK3 uses and checks. A good description is here, https://gist.github.com/abrasive/7a615e6dde0c … mscdex-txt-L651.

A tentative fix is in place and ready for @kas1e to confirm.

Reply 7 of 18, by kas1e

User metadata
Rank Newbie
Rank
Newbie

@jmarsh
I see in r4314 commit also fixes for screenshot saving in the repo as well, cool! Thanks!

So only what issue left for big-endian, it's playing of files from HDD mounted from .cue (that part of code which uses SDL_Sound). In the meantime, krcroft rewrote in DOSBox-staging cd_rom based code, and those .ogg/.mp3/etc files mounted from .cue plays without distortion on PPC. But I add this changed code in some pretty hacky way to my build of r4293 (as is that one to which I can apply your PPC JIt and other patches), and sure will be better to have in original DosBox it fixed too (if those patches from staging will be not considered to be merged into original DOSBox repo). But at least as krcroft rewriting works, and sound plays without distortions, I assume it's an issue in the DosBox and not my SDL_Sound port (i hope:) )

Reply 9 of 18, by kas1e

User metadata
Rank Newbie
Rank
Newbie

It's SDL2 port of SDL_Sound library which I build from ptitSeb: https://github.com/ptitSeb/SDL_sound
I checked it by compiling some test cases if they play .ogg/.mp3 fine on PPC: yep, they are.

But after you say it, I start to fear something maybe be wrong there... Through seeing commits logs there wasn't much changed, but maybe something should be changed in SDL_Sound code for SDL2 in DOSBox instead then...

Reply 11 of 18, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

Yes, the whole SDL_sound lib is a problem because upstream messed it up bad. The SDL1 and SDL2 versions of SDL_sound can't coexist because they are named the same.

Windows 3.1x guide for DOSBox
60 seconds guide to DOSBox
DOSBox SVN snapshot for OS X (10.4-10.14 ppc/intel 32/64bit) codesigned for gatekeeper
DOSBox SVN with SDL2 snapshot for OS X (10.7-10.14 intel 64bit) codesigned for gatekeeper

Reply 12 of 18, by krcroft

User metadata
Rank Member
Rank
Member

Ryan (author of SDL and SDL_Sound) posted a nice retrospective a couple years ago about SDL_Sound here https://www.patreon.com/posts/project-sdl-2-0-20211701, and talks about how, technically it might have succeeded in the code (to abstract away codec-specific details behind common functions), but ultimately became a disservice on those systems that didn't have a package manager to round up all the audio library dependencies (and so on down the line, until all the dependencies are resolved).

It's a great read, and also confirms aspects of the design choice in the audio CDDA code (to bundle single-header decoders and carve down SDL_Sound itself, which is now SDL2-compatible). Perhaps if/when SDL2_Sound does come to life (its code went dormant again in 2018), we could switch over to it.

Reply 13 of 18, by kas1e

User metadata
Rank Newbie
Rank
Newbie

@jmarsh

If it's for SDL2 it's not going to work with an SDL 1.x app.

What I mean is that I use SDL2 version of DOSBox by this patch: An adaptation to SDL 2.0 (Alpha-level Android build attached)

So I had to made that SDL2 port-compile of Ptitseb's SDL_Sound to make it all works as expected. But still seems something going wrong.

On wii all works fine with SDL1 version of SDL_Sound in terms of playing .off files from HDD when mounted as .cue ?

@Dominius

Yes, the whole SDL_sound lib is a problem because upstream messed it up bad. The SDL1 and SDL2 versions of SDL_sound can't coexist because they are named the same.

What worry me most, is if i just use SDL2 version of DosBox + SDL2 port of SDL_Sound, should be done any changes in the SDL_Sound ifdefs of DosBox itself, or, they can be keept as it was.

Reply 14 of 18, by kas1e

User metadata
Rank Newbie
Rank
Newbie

@Jmarsh
Compiled SDL1 version of DosBox with SDL1_Sound, and they're still something wrong with the sound on PPC. I tried some .ogg track mounted from .cue, and it plays slower as expected, and with some distortion as well.

Reply 15 of 18, by kas1e

User metadata
Rank Newbie
Rank
Newbie

@All
Is anybody able to run on PPC (be it normal, or dynamic core with Jmars's patch) RedAlert? For me, "setup.exe" runs well with all installation and co, but when I run the game itself, it just shows me that DOS4/GW output, and then nothing happens. The cursor blinks, but nothing loads/changes/etc.

Also, I have an issue with Mortal Kombat 3, when choosing not "start game", but "start tournament". That what I have then visually:
http://kas1e.mikendezign.com/aos4/dosbox/mk3_ … ament_trash.jpg

Everything operational, just mess on screen.

Both issues happen at least on r4293 build on my PPC machine. The same revision builds on MinGW/win32 does not have those issues.

Can anybody check on their PPC's if those issues present? Thanks!

Reply 17 of 18, by kas1e

User metadata
Rank Newbie
Rank
Newbie

It's something else. I wait for about 5 minutes and more (and with normal, and with dynamic cores). Pure C&C runs in 1-2 seconds with Dynamic and 3-4 seconds with Normal core.

On win32 as I can see, RedAlert may start longer than C&C on just 1-2 seconds, but differences are few seconds only. Not 5 or more minutes. And after I run it, it almost immediately going to a black screen, didn't hold "dos4/gw" output for any time with a blinking cursor. I wait for tests for even 10 minutes: nothing.

Testing almost 100 or 200 dos games of late-era, and none of them take longer than some seconds to start up with dynamic core on me.

Visually I can see that "something" happens: Cpu loading changes a bit, HDD blinks with some the-same-time repeats. Like, it going in some loop mode.

I will try to build today the same revision but without PPC-jit, fat-be and sdl2 patches, maybe it somehow related.

Reply 18 of 18, by kas1e

User metadata
Rank Newbie
Rank
Newbie

Build latest revision without any other patches applied, and tried to run red-alert: no, the same issue on my machine. On win32 the same build, the same red alert works for sure.

I just run it and wait exactly 7 minutes. DOS/4GW output is here, the cursor blinks, CPU loading happens (sometimes 95-98%), and led blinks the same each second or two, but nothing happens.