Fill.asm

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Fill.asm

matiancai74
Looking for help with Fill.asm please - if I submit my code could someone take a look if that's allowed? The weird thing is that if I run it with a value > 0 in Memory 24576 to simulate a key press, then it starts to blacken the screen. If I run it with no animation and press a key, nothing happens! It's driving me nuts so any help would be appreciated.
Reply | Threaded
Open this post in threaded view
|

Re: Fill.asm

cadet1620
Administrator
You may mail your code directly to me and I'll take a look at it for you.

--Mark
Reply | Threaded
Open this post in threaded view
|

Re: Fill.asm

matiancai74
Have sent my code to you - thanks for taking a look. Very odd - when running with 'Program Flow' animation it seems to behave as expected - if the Keyboard word has a value > 0 it starts to draw black lines in the screen as it fills each memory word for the screen with -the value -1. However, running without animation nothing happens at all if I press a key. Any help appreciated.
Reply | Threaded
Open this post in threaded view
|

Re: Fill.asm

matiancai74
In reply to this post by cadet1620
I have actually got it to work now - I changed my JGTs to JEQs when looking at register D and it works - just have to work out why now!
Reply | Threaded
Open this post in threaded view
|

Re: Fill.asm

matiancai74
In reply to this post by cadet1620
I think that there was some kind of conflict going on in the program where I was writing to the SCREEN + 8192 th word, which is actually 24576, the Keyboard word. I also think that that I wasn't terminating the loops that 'painted' white/black pixels on the screen correctly by looking at the variable that counted the screen words.
Reply | Threaded
Open this post in threaded view
|

Re: Fill.asm

cadet1620
Administrator
matiancai74 wrote
I think that there was some kind of conflict going on in the program where I was writing to the SCREEN + 8192 th word, which is actually 24576, the Keyboard word. I also think that that I wasn't terminating the loops that 'painted' white/black pixels on the screen correctly by looking at the variable that counted the screen words.
You are correct. Excellent job analyzing the bug. I was just about to send you mail that said exactly that when I noticed your latest post.

There appears to be a bug in the Hardware Simulator. Writing to the Keyboard address corrupts the value that will be returned. The value remains bad until the next time a key is pressed or released.

So, by having the off-by-one bug that writes -1 to 24576 at the end of the black loop, the Keyboard read at the top of the program reads -1 even though the key has been released, and the program enters the black loop again.

Side note: Unless special circumstances require that you end a loop with an = or != comparison, it is safer to use <, <=, > or >= so that if something goes wrong with the loop index, to loop will still exit. The program may not do what it is supposed to, but at least it doesn't hang.

--Mark
Reply | Threaded
Open this post in threaded view
|

Re: Fill.asm

matiancai74
Thanks for getting back to me - on with chapter 5!