ripsaw8080 wrote on 2024-05-06, 21:09:

Which thread(s) are you locking? FYI, SDL has its own thread for audio, and SB sound generation might be using DMA, but you can probably use SDL_mutex locks to avoid collisions there.

I have a separate thread to handle Rendition DMA transfer within dosbox. SDL_mutex? I'll check it out thanks.

Have you looked at the DMA callback in sblaster.cpp as an example for handling the transfer data?

ripsaw8080 wrote on 2024-05-07, 03:14:

Have you looked at the DMA callback in sblaster.cpp as an example for handling the transfer data?

I'll check it out. Had a few other things to sort out. It never went even occurred to me check out the sound blaster code.

That worked fabulously well. Thanks!!! I get a bit of audio stutter now every once in a while.

Does dosbox have delayed memory writes to addresses sometimes? As part of core=dynamic?

I don't think it does from what I've seen.

@ripsaw-8080.

The SDL_Delay in increaseticks() when using anything other than a fixed number of cycles seems to cause Indy Car Racing 2 to suffer a slowdown with high poly custom car models. Setting

1cycles=400000

Allows it to run perfectly, with occasional audio stutter during replays.

is there any way to eliminate the SDL_Delay?

@ripsaw-8080, sorry to trouble you again but

is there anyway to count the number of cycles that have elapsed since the start of dosbox, as in emulated CPU cycles? I need virtual Rendition board to idle for a number of cycles.

It depends on what needs to happen during the idle time. To just consume cycles where nothing needs to happen except the usual event handling, see the I/O delay functions in iohandler.cpp for an example. If the machine needs to run (IRQs need to fire) during the idling, then something like the idle loop for the "beep" in int10_char.cpp could be an example. Look at current SVN source for either one.

ripsaw8080 wrote on 2024-08-01, 11:43:

It depends on what needs to happen during the idle time. To just consume cycles where nothing needs to happen except the usual event handling, see the I/O delay functions in iohandler.cpp for an example. If the machine needs to run (IRQs need to fire) during the idling, then something like the idle loop for the "beep" in int10_char.cpp could be an example. Look at current SVN source for either one.

No, no. What I mean is if the virtual rendition's receives a command (via a port) and needs to idle for a number of cycles while the CPU runs.

I need the CPU to carry on for a certain number of cycles before the video card does something.

I just named two relevant examples. I doubt you've really looked at them in the few moments since I posted.

ripsaw8080 wrote on 2024-08-01, 11:52:

I just named two relevant examples. I doubt you've really looked at them in the few moments since I posted.

Reading comprehension isn't my strong suit.

Sorry, the delay in beep sounds like what I need.

I've already seen the delay code for port io., which stopped me from comprehending the rest of your post.

If you need the idle time to be based on cycles, you'll probably have to calculate the amount of time based on current cycles (CPU_CycleMax) as in the I/O delay example.

ripsaw8080 wrote on 2024-08-01, 12:12:

If you need the idle time to be based on cycles, you'll probably have to calculate the amount of time based on current cycles (CPU_CycleMax) as in the I/O delay example.

Thanks. I think saw existing code for that.

@ripsaw8080, I've open sourced the DOS part of my wrapper:

https://sourceforge.net/projects/rready-speedy3d-for-dosbox/

So it *might* appear in a future release of dosbox-staging.

My modifications to Dosbox (regular) are available here:
https://sourceforge.net/projects/dosbox-rendition/

@ripsaw, is it possible to get a list of addresses which've been remapped through DOS API calls in Dosbox?

I ask because RReady exposes physical address 0xE1000000-E1FFFFFF as the Rendition address range, but some games seem to address it through different ranges such as 0xFE000000.

I seem to be getting "Corrupt MCB chain" in Dos_CompressMemory while running CGL apps (Creative Graphics Library).

I can't tell if this is a problem with Dosbox running CGL apps or a problem with the wrapper. Every single CGL app I've tried seems to be producing this.

[Merry Christmas, if applicable].

i never seen this type of error, on real hw.
to determine its needed to split dosbox and wrapper and see on which side it happens , somehow, as idea.
my guessing's:
1. need to patch/hack/modify some app or game so it can run on v1000 non creative card.
2. same but for v2100 and v2200, those two steps can answer it can work or no.
3. try patching to just run at any video card, try understand me correctly , it should just not check cgl present, and try to run directly which may got other errors, or hung up, to see what it wants, maybe it will produce this Corrupt error.
4. possible to patch vlb cgl vs pci cgl, to see how they close to be compatible.
Merry Christmas , wish all the best to you all, this is great year (closing eyes to rest troubles and life difficulties).

RaVeN-05 wrote on 2024-12-25, 12:25:

i never seen this type of error, on real hw. to determine its needed to split dosbox and wrapper and see on which side it happen […]
Show full quote

i never seen this type of error, on real hw.
to determine its needed to split dosbox and wrapper and see on which side it happens , somehow, as idea.
my guessing's:
1. need to patch/hack/modify some app or game so it can run on v1000 non creative card.
2. same but for v2100 and v2200, those two steps can answer it can work or no.
3. try patching to just run at any video card, try understand me correctly , it should just not check cgl present, and try to run directly which may got other errors, or hung up, to see what it wants, maybe it will produce this Corrupt error.
4. possible to patch vlb cgl vs pci cgl, to see how they close to be compatible.
Merry Christmas , wish all the best to you all, this is great year (closing eyes to rest troubles and life difficulties).

Hey RaVeN-05, nice to see you around.

I'll try all of those things over the next few weeks.

Wish you all the best for the coming year.

RaVeN-05 wrote on 2024-12-25, 12:25:

i never seen this type of error, on real hw. to determine its needed to split dosbox and wrapper and see on which side it happen […]
Show full quote

i never seen this type of error, on real hw.
to determine its needed to split dosbox and wrapper and see on which side it happens , somehow, as idea.
my guessing's:
1. need to patch/hack/modify some app or game so it can run on v1000 non creative card.
2. same but for v2100 and v2200, those two steps can answer it can work or no.
3. try patching to just run at any video card, try understand me correctly , it should just not check cgl present, and try to run directly which may got other errors, or hung up, to see what it wants, maybe it will produce this Corrupt error.
4. possible to patch vlb cgl vs pci cgl, to see how they close to be compatible.
Merry Christmas , wish all the best to you all, this is great year (closing eyes to rest troubles and life difficulties).

The wrapper is initialised, but not active. Cgl apps start writing to unknown memory ranges and then dosbox crashes. This is at the start of the 3d sequences.

i guess those might be different VRAM memory ranges? probably every video card bios can assign its own memory range, (own range resources) , and probably CGL have here stupid hardcoded range. idk, guessing.