robfinch wrote:
Whenever I encounter an intractable problem I try and work on something else for a while. So now it's flood filling.
Sounds like a good move. Often a solution to one problem can suddenly pop into mind while working on a totally different problem.
Quote:
Added flood filling to the core, it uses a recursive flood fill for simplicity. The flood fill stack is 4096 entries, so if there are more than 4094 pixels in a row to be filled without returning the stack will overflow and the operation will be aborted. It could happen since the bitmap may be up to 65536x65536. Practically it shouldn’t happen because there is only 1MB of graphics memory. The target bitmap is <= 800x600.
As a test the entire screen is to be flood filled. But when run, only two pixels in the middle of the screen are set. This has me baffled. I wasn’t expecting it to fail in that manner. I figured it would scan at least to the end of the scan-line. The only thing I can think of right now is that it’s reading the wrong pixel from the screen and it thinks it’s finished because it’s reading a pixel that’s set already.
I put an additional delay in from the time the pixel coordinate is calculated to the generation of memory address and that helped a bit. Now there are about sixteen scanlines of fill happening instead of just two pixels. This should not have made a difference but it did, as there were no timing errors reported.
Might be time for another video debug hack.
If you disable writes and run the fill in a loop, you'll be able to flag the result of your 'read test for set pixel' function and feed it directly into the video out section of the design to see what's going on.
If you also set a flag based on then the 'disabled' writes would have been occurring, use a different colour and see if it lines up with the detected edge pixels.
Quote:
Another problem with the system is that the cursor loses it’s shape. I observed that cursoring around on the screen changes the cursor shape. It looks like the cursor image address register is updated whenever the cursors vertical position changes. There’s got to be a bad logic bit somewhere. I tried to fix this with software by re-writing the cursor image address register after a change in position but it didn’t work.
Anyways I’ve re-written the flood fill because it just might be failing at a 4096 stack overflow due to a programming problem. The system is building at this very moment.
A fix might be as simple as only updating the cursor position during the vertical blanking interval.