Need some help with loops for fill program -- Solved

[Magerman]

So I'm pretty sure I have everything right in my fill program except for the specifics of the loop. That is to say, if I hold down a key it will indeed blacken the whole simulated screen before erroring out, so I at least have the "turn all pixels black" code (and, by extension, the "turn all pixels white" code) correct.

I keep getting an error saying that I'm trying to write to a memory address that doesn't exist (specifically 24577). What am I doing wrong?

Here is the code I've done; I've eliminated the parts that seem to be working adding in a description of what they do instead for brevity and to limit the amount of code I post here:

Edit: snipped code, issue solved

[WBahn]

If you walk through your loop by hand, keep track of the values in your screenpointer variable you should see your problem pretty quickly.

Set screenpointer (either in the emulator or on paper) equal to the last value that you expect to write to the screen memory with and see what happens.

Remember, it's important to execute the code that you have actually written and not the code that you thought you wrote.

[Magerman]

Ah yeah, I see the problem =x. I was pretty tired when I made this code, so I guess I just brain farted on exactly what was going on with the pointer.

I've got the program working now, though I did so by having the loop ending test check the screenpointer variable against the highest number that it should be (rather than the highest actual memory location it should be writing to), which was 8192, a constant I defined at the start of the program. I'm curious: is there a better way to do it than that, or was that solution perfectly valid? It just felt like I was sort of forcing it, I want to make sure I'm not missing anything important for later chapters.

Thanks for the help, at any rate!

[WBahn]

Since I can't see your code anymore (and I understand why you removed it, so I'm not asking you to repost it) I'm going from memory.

Your loop can be condensed considerably. Consider making your screenpointer variable actually be a variable that points to the memory address you want to change next.

Also, when programming in assembly, never forget the power of bit banging.

If I want a value to cycle start at 0010000, go up to 0010111 and then go back and start over, I can do this with a simply masking operations at the end of each step and an unconditional jump back to the beginning.

I just need to recognize that after I increment it from 0010111 I get 0011000 and what I want to get is 0010000, so all I need to do is force bit 3 to always be 0 after each iteration. Doing so has no affect on any other times through the loop.

[WBahn]

Magerman wrote

I'm curious: is there a better way to do it than that, or was that solution perfectly valid?

These are two different questions. They way you did it was perfectly valid -- ANY solution that meets the requirements is perfectly valid.

Whether or not there a "better way to do it" depends on the metric by which "better" is determined.

Fewer instructions?

Faster execution (which can be, but often is not, related to fewer instructions)?

More readable/maintainable (which is usually inversely related to fewer instructions)?

Less time to develop, implement, and test?

Any of these -- and probably several others -- are reasonable metrics by which to compare one solution to another and decide which of them is better.

 It just felt like I was sort of forcing it, I want to make sure I'm not missing anything important for later chapters.

For what it's worth, the solution I came up with has nineteen instructions (not counting labels, which are pseudoinstructions since they don't generate any code) and uses one variable, one conditional jump, and one unconditional jump. Eight of the nineteen instructions are A-instructions. Four of the instructions are before the loop and fifteen are in the loop.

I suspect that it can be condensed by perhaps one or two more instructions, but if so I haven't figured it out. It just seems like it should be possible since I access the variable three times and it seems like there should be a clever way to eliminate at least one of them.