DFB1 BadMooD issues

[exxos]

Note that in VGA mode ACE Tracker has display glitches now and again on a stock machine, which is a known issue that New Beat has said he'd look at sometime.

Is that where it seems to judder vertically ? Though that could be my crap TV anyway.

[stephen_usher]

I think I showed iit in a video. Every now and again the display seems to glitch where it desyncs for a frame or two and then returns to normal. It happens more often if playing music. It's probably no more than once or twice a minute.

Here's the video...

[exxos]

I think I showed iit in a video. Every now and again the display seems to glitch where it desyncs for a frame or two and then returns to normal. It happens more often if playing music. It's probably no more than once or twice a minute.

Odd not seen that. Do you have one of my clock patches installed ?

[stephen_usher]

I think I showed iit in a video. Every now and again the display seems to glitch where it desyncs for a frame or two and then returns to normal. It happens more often if playing music. It's probably no more than once or twice a minute.

Odd not seen that. Do you have one of my clock patches installed ?

No, but it's a known and recognised bug in the software.

Oh, and no crackles or any other clock problem symptoms at all, even with DSP playback on ACE Tracker pushed to the limit.

[exxos]

No, but it's a known and recognised bug in the software.

Not heard of that bug.Where's the info on it ? But why don't I see it ? I am using RGB scart, not sure if its only relating to some other video mode ?

[dml]

Not heard of that bug.Where's the info on it ? But why don't I see it ? I am using RGB scart, not sure if its only relating to some other video mode ?

I think ACE is perhaps just setting the screen address - especially the low byte - slightly late on each vblank, which can cause the screen to 'jump' occasionally if an interrupt or something delays it enough. It is much more likely to happen on VGA because the available time to set the address is less.

There is another, related problem with VGA on some Falcons (or induced by some monitors connected to the Falcon) where a noisy signal bug or echo from the VGA port causes multiple vblank interrupts to trigger close together. This can cause the software to misbehave when setting the screen registers and the screen can jump or interlacing effects can strobe/skip as a result. It's a known thing on the falcon and some software detects/avoids it by confirming real vblanks off a late raster (first vblank after the last raster is real, any subsequent ones are not until the raster recurs).

It could be something else but I've seen both effects myself and while its is annoying its not serious - especially the first one, which doesn't affect the software at all.

[exxos]

Will see if I can hookup my VGA monitor when I get back home. On my TV the video jumps about 1 pixel vertically. Maybe noise on vsync, no idea.

[stephen_usher]

It's a bug when using VGA. It doesn't appear when using RGB. It's in the changelog.

[Badwolf]

OK, so just done a half hour soak on DMA2DSP in 50MHz mode and no failures reported*.

However it gets interesting if I start playing with the TT-RAM flags. It runs absolutely fine if I allow malloc'ing from TT-RAM, but hangs and/or crashes and burns if the program is loaded to TT-RAM.

Oh teh noes! I thought. I've broken the firmware! This may be still be true, but then I considered the second half of the program name and it occurred to me perhaps the DMA part of that program means it doesn't like to be loaded into TT-RAM.

So I need a better test kit.

Gone looking...

BW


* I have to run DMA2DSP without NVDI as the bars are not visible if NVDI is loaded. Default palette problem? Makes it hard with TT-RAM enabled, though.

[exxos]

OK, so just done a half hour soak on DMA2DSP in 50MHz mode and no failures reported*.

Can't remember, but can you run it in other video modes like true-colour for example ?