Overlay support on the SAM?

Hi,

Am I right in thinking there's no working overlay (PIP) support for the SAM440? My TV program just fell over trying to grab the frame buffer or something (not sure as I'm away from home right now). I noticed people saying DVPlayer needed the overlay support disabled too...?

Thanks!

@Spirantho

Quote:

Cobra quote:

"again the Sam actually does a very nice job at it, especially with the not-yet-released planar overlay stuff."

(March 5, 2009)

#6

@number6

the overlay is not yet implemented in the video drivers?

@Spirantho

Overlay always worked for me on the Sam without issues, and I haven't noticed any differences between Overlay on the Sam and overlay on other systems (A1, Pegasos2). Perhaps if you could give us some more detailed info about how you're trying to set it up, I can help you figure out what's wrong.

@number6

Quote:

That refers to planar overlay formats (e.g. YUV420P and YUV410P) which allow for faster operation because less data needs to be transferred to video memory, and also for a faster copy loop (because Y, U and V data is in separate 8-bit planes, rather than in a packed format.

@Spirantho

Did you get this problem sorted?

@COBRA

Yup, it wasn't the overlay that was failing, it was the DMA.

Got it working in the end, though, so AmiTV 0.13 and later (0.14 is the current) support the SAM... but you can't use the direct overlay mode for some reason, I think the latency is too high like on the A1. It works, but then stops working soon after. I'll look at it again at some point, but even now you can have full screen video using buffered overlay.

@Spirantho

Good to hear, what do you mean by direct overlay? Doing a DMA directly into the video memory of the Radeon into the overlay buffer?

@COBRA

What I'd like to know is if there is any way of ensuring that the system doesn't pull the overlay buffer out from under the TV-card's nose while it's DMA'ing something into the overlay window. Spirantho can't exactly just keep the overlay bitmap locked.

Hans

@Hans

Normally you can only access BitMaps while you hold a lock on them, that also ensures that the correct memory mode is set for the Radeon (because sometimes it needs to do byte-swapping, depending on the colour format used). Why is it a problem to lock the bitmap, do a DMA transfer and then unlock it afterwards?

@COBRA

For AmiTV I have two forms of overlay:

Direct Overlay: The TV card (which is a busmastering card) DMAs directly into the overlay memory of the graphics card.
Buffered Overlay: The TV card DMAs into the main memory of the machine. Then the OS does a memcpy after every frame from the target buffer into the overlay memory.

With buffered overlay, every tick I can LockBitmap(), memcpy(), and UnlockBitmap(). Hence I get a clean output.

With direct overlay, however, there is no OS control of when the DMAing into the overlay memory is going to be written to. Hence I can't lock it. TV cards actually have a very RISC processor (about 14 instructions) which does the DMAing, but it's engineered towards memory copying, and has no way of knowing about locking and unlocking bitmaps.

What I need is a way to lock the overlay bitmap such that it will never change and there will be no bus contention onto that memory space.

I actually once got a completely smooth and clean direct overlay picture on my Sam. How did I do it? My program happened to crash solid while the card was running well... so AmigaOS stopped doing anything, allowing the TV card full access to the overlay bitmap. So I can probably make it a full screen display as long as you don't mind me locking the OS solid. :) The amount of corruption I get in the direct overlay mode is directly proportional to how much Intuition is doing. I can see this because if I hold the right mouse button down the picture gets a lot cleaner....

@Spirantho

Thanks for the explanation. This is really strange, because P96 allocates Overlay bitmaps so that they generally do not move (e.g. they should be the last thing P96 would move, just like screens). You could do a test though in your buffered overlay mode, where you do a lock/unlock, could you output the base address of the YUV bitmap and see if it changes as you do things in intuition? That would confirm whether it's really an issue of the overlay bitmap's location changing.

@Spirantho

On second thoughts, bitmaps are only moved when low graphics memory requires things to be paged out/moved. It shouldn't cause continuous corruption.

Is there any way of getting an interrupt when a DMA transfer starts? Maybe an interrupt when the vblanking occurs? Locking/unlocking the bitmap when appropriate seems to be the only way to fix the problem.

Hans

@Hans

One frame takes approximately 1/50th of a second, 1/60th in NTSC. That means you'd have to lock the overlay buffer (which, incidentally, does indeed stay still in memory all the time) for nearly a full 50th of a second. That's a verrry long time to hold a lock, and would leave very little time for anything else.

I do have interrupts on the Bt8x8, but I've never trapped any on the Cx2388x....

I wonder... could P96 be changing endianness of some things it's doing while the overlay is being updated? That'd make the graphics go the wrong colour at those points in time.

@Hans

I think it might be a memory mode issue rather than changing bitmap address issue. Basically, Radeons store bitmaps internally in little-endian format, and under OS4 we use big-endian modes. The Radeons can automatically perform byte-swapping on read/write accesses to the video memory so that to the CPU or other peripherals transferring BitMap data, it appears as big-endian, but which bytes have to be swapepd by the Radeon depends on the colour format so the memory mode has to be set correctly, according to the bitmap's colour format before accessing it. This is done by LockBitMap().

You can't have some PCI device transfer data into a bitmap in video memory while the CPU is transferring data to/from another bitmap, because if the colour format of that other bitmap is different, a different memory mode may be required, so you'll have some strange effects on the transferred bitmap (such as false colours, or groups of 2-4 pixels reversed).

There must be some kind of signalling mechanism on those TV cards, which allow an interrupt to be called to perform some pre-DMA initialization/setup before the DMA operation takes place.