pvr_wait_ready: timed out
-
- DC Developer
- Posts: 453
- https://www.artistsworkshop.eu/meble-kuchenne-na-wymiar-warszawa-gdzie-zamowic/
- Joined: Thu May 16, 2002 8:29 am
- Location: ice88's house
- Has thanked: 0
- Been thanked: 0
- Contact:
pvr_wait_ready: timed out
I'm getting 'pvr_wait_ready: timed out' on a regular basis in KOS-1.2.0 - anyone got experience of why? and how to fix it? I don't get this in KOS-1.1.8 which I was using previously.
Read my blog: http://unrational.blogspot.com
-
- bleemcast! Creator
- Posts: 882
- Joined: Wed Oct 17, 2001 7:44 pm
- Location: Los Angeles, CA
- Has thanked: 0
- Been thanked: 0
- Contact:
-
- Soul Sold for DCEmu
- Posts: 4865
- Joined: Fri Jul 11, 2003 9:56 pm
- Has thanked: 2 times
- Been thanked: 4 times
-
- DC Developer
- Posts: 9951
- Joined: Sun Dec 30, 2001 9:02 am
- Has thanked: 0
- Been thanked: 1 time
Got it working again. It seems to have some slightly different issues to last time. And I have no idea what I did differently, but it now works.
The pvr_wait_ready timeout could be caused by a bug in the PVR - if it's not firing the end of frame interrupt, pvr_wait_ready will just wait a while for it to happen, then abort.
ice88 - Is that happening all the time, or only under certain circumstances?
The pvr_wait_ready timeout could be caused by a bug in the PVR - if it's not firing the end of frame interrupt, pvr_wait_ready will just wait a while for it to happen, then abort.
ice88 - Is that happening all the time, or only under certain circumstances?
-
- DC Developer
- Posts: 453
- Joined: Thu May 16, 2002 8:29 am
- Location: ice88's house
- Has thanked: 0
- Been thanked: 0
- Contact:
Interestingly it only happens at a point after the main emulation engine has ended and I've returned control to my GUI - but as far as the PVR is concerned, nothing has changed... (I haven't re-initialised or anything)
It is odd - you get one good run of the emulation engine then *poof* timeouts.
I could try experimenting with it some more - interesting to hear about possible PVR bugs, but I'm more inclined to believe it's KOS or something I'm doing.
It is odd - you get one good run of the emulation engine then *poof* timeouts.
I could try experimenting with it some more - interesting to hear about possible PVR bugs, but I'm more inclined to believe it's KOS or something I'm doing.
Read my blog: http://unrational.blogspot.com
-
- bleemcast! Creator
- Posts: 882
- Joined: Wed Oct 17, 2001 7:44 pm
- Location: Los Angeles, CA
- Has thanked: 0
- Been thanked: 0
- Contact:
I mentioned the PVR bug only because it's good to know that sometimes the issue isn't of your doing.
The major one that bit me hard is quite complicated to set up, and only occurs rarely -- but if you're not doing anything with general polygons per se, you'll not see it.
If you get a good run once and then subsequently it causes problems, I'd suspect something on your end.
Easiest thing to do is to record your input, and ensure that you play back everything *precisely* as you recorded it. Then you can easily reproduce the situation that causes the bug and track it down rapidly.
If you want a quick fix, though, you could always just reset the PVR and see if that solves it -- that would likely remove HW from the equation and leave you with whatever software setup you are/aren't doing correctly. Don't forget to clear interrupts, etc. etc. back to their reset state as well (otherwise, obviously, you'll end up servicing an interrupt that was from the *previous* frame and not the current one).
Best,
Rand.
The major one that bit me hard is quite complicated to set up, and only occurs rarely -- but if you're not doing anything with general polygons per se, you'll not see it.
If you get a good run once and then subsequently it causes problems, I'd suspect something on your end.
Easiest thing to do is to record your input, and ensure that you play back everything *precisely* as you recorded it. Then you can easily reproduce the situation that causes the bug and track it down rapidly.
If you want a quick fix, though, you could always just reset the PVR and see if that solves it -- that would likely remove HW from the equation and leave you with whatever software setup you are/aren't doing correctly. Don't forget to clear interrupts, etc. etc. back to their reset state as well (otherwise, obviously, you'll end up servicing an interrupt that was from the *previous* frame and not the current one).
Best,
Rand.
-
- DC Developer
- Posts: 9951
- Joined: Sun Dec 30, 2001 9:02 am
- Has thanked: 0
- Been thanked: 1 time
Well, there's three things that could be going wrong - the hardware, the PVR drivers in KOS, or the code that's using it. The KOS PVR drivers are fairly stable (probably not as good as Sega's, of course), but I think they still go a little weird from time to time. It's probably the code that's using it that's going wrong.
ice88 - It could be that you've not finished a frame at the end of the emulation, and pvr_wait_ready is waiting for the running frame to finish. I think that'd cause an assertion failure though (debug output appears, DC resets). Shutting down the PVR might actually help, but it's probably overkill. Is that bug present in the MAME 0.71 source you released, or is it in something else?
ice88 - It could be that you've not finished a frame at the end of the emulation, and pvr_wait_ready is waiting for the running frame to finish. I think that'd cause an assertion failure though (debug output appears, DC resets). Shutting down the PVR might actually help, but it's probably overkill. Is that bug present in the MAME 0.71 source you released, or is it in something else?
-
- DC Developer
- Posts: 2285
- Joined: Fri Feb 21, 2003 7:37 am
- Location: Chicago, IL
- Has thanked: 0
- Been thanked: 1 time
- Contact:
I get the same pvr timeout right at the begining of things too. It doesn't seem to have any ill effects so I've never worried.
KOS is able to figure out if you are using dc-load and pipes printf and the like to the console. When you release this on a CD, KOS will just throw any any stdout data and you will lose very little performance. But to be on the safe side, you might want to use a macro that calls printf for debugging, and when you are ready to release, define that macro to be empty.Artchi wrote:Did somebody knows how I can disable the console output? Because if I release an end user version I don't want performance losts because of console outputs.