2008-01-17

More Scrollbars; Revenge of DMA

Minor update to the scrollbar - the grip will now follow the stylus correctly even if the stylus isn’t positioned above the scrollbar. Much nicer.

Another DMA fix, too - the SuperBitmap still wasn’t drawing properly. I think there’s probably a good reason for libnds’ DMA functions waiting until DMA has finished before they allow the program to continue. It seems to go against the whole purpose of the DMA hardware (asynchronous memory copying), but in the SuperBitmap code I’ve had to add DMA_Active() checks before and after any calls to DMA_Copy() and DMA_Force() in order for the filled rect functions to work properly. DMA calls elsewhere in the code only have one check, and they probably don’t need that - VRAM is much faster than main memory (the latter being what the SuperBitmap interacts with, hence the problem), so there’s generally no need to hang around for the DMA hardware.

Comments

Jeff on 2008-02-21 at 10:06 said:

Found it.

There are two problems with DMA and I bet you are treading on one or both of them, because I just had exactly the same problem(s) and the symptoms (black lines showing up) seemed to match what you’ve described in the past.

  1. The DMA controller doesn’t see the cached main memory - thus, if you change a location in main memory (perhaps the first byte in line) and then ask the DMA controller to propagate it on, the DMA controller won’t necessarily see the value you just wrote.

This turned up because I was constructing a bitmap in memory before blitting it to the screen with graphicPort::drawBitmap() - which uses DMA internally. The top-left corner of the bitmap would sometimes be black pixels.

The fix?

DC_FlushRange( bitmap, width*height*sizeof(u16) );

prior to calling graphicPort::drawBitmap(). All my DMA access now checks BEFORE the copy, but not AFTER.

  1. The DMA controller isn’t very good at reading from the STACK at all. When I had my buffer allocated with malloc(), or created static, it worked fine. When I had it as an auto array (on the stack frame), I got black rectangles.

Solution to this: don’t try to DMA out of stack variables.

So, things like drawFilledRect() will have problems because it draws the first line by hand, and uses DMA to draw the rest, but doesn’t flush the cached main memory first…

ant on 2008-02-21 at 12:00 said:

Ahh, that all makes sense. Brilliant! I’ll add that in.

There’s another bug that got reported via the PALib forum that I need to fix, too - the Gadget::moveToHiddenList() function (I think it’s that one) uses the wrong index when trying to remove an item from a vector. (Just thought I’d make a note of this here.)

Jeff on 2008-02-21 at 20:51 said:

Just for interest, here’s my most recent app built with Woopsi

http://rapidshare.com/files/93779824/HP16C.zip.html

It doesn’t save yet, because I’m trying to work out the vagaries of writing to SRAM to make its memory persistent. Once I get it neatened up (with the GPL commitments met), I’ll upload it, um, somewhere? Got any suggestions?

ant on 2008-02-21 at 22:52 said:

Bloody hell, that’s good! And that’s Woopsi? Fantastic!

Woopsi’s BSD licenced - unless you’re using other libraries too you can ignore the GPL. As far as Woopsi is concerned, the only reason you’d need to follow the GPL was if you were distributing a build of your app that used the SDL layer, and only then if you statically linked the SDL libs (dynamic linking lets you use the LGPL instead).

I like SourceForge. If you’re just looking for somewhere to host the file, though, I can add it to a “Woopsi Applications” section of this blog if you like.

Jeff on 2008-02-21 at 23:12 said:

Sadly, the nonpareil simulator engine is GPL, so the rest needs to be compatible with that. As far as I’m concerned, I’m going to release the source as freely as possible, though interestingly I think that the GPL actually prevents me from releasing it into the public domain (because that’d be too free)

I admit it doesn’t appear to use much of Woopsi, from a windowing perspective. But its definitely Screen’s and GraphicPort’s and event handlers and such doing all the heavy lifting.

I suspect that getting the ‘save’ aspect going will require me to plug in a bit more window handling to choose filenames, etc, which might mean it takes a while to get out there. But that’ll definitely all be Woopsi gadgets for sure…

Once I have a clean setup, I’ll look into what it takes to do SourceForge…

ant.simianzombie.com » Scrollbars and Greyscale Algorithms on 2009-11-23 at 23:10 said:

[…] have been one of the major banes of Woopsi’s existence for years. No matter what I’ve done, they’ve always been slightly inaccurate. When […]