can't understand fillautomatic.cmp

[Vijay99]

please make the attached fillautomatic.cmp file intelligible to me. I can't understand what it means.

There was a comparison failure at line 3.

FillAutomatic.cmp

[WBahn]

Read the comments in the associated test script.

[Vijay99]

Thanks. My compare file is as it should be i.e. first the values are 0, then they become -1 to become 0 again.
Then why is it saying that there was a comparison failure at line 3?

[WBahn]

Post the contents (or a screenshot) of your output file. If we can't figure out from that, I'll have you e-mail me your output file and I'll take a look to see if there are any hidden characters in it.

[Vijay99]

I have already posted the output file in the beginning.
FillAutomatic.cmp

[WBahn]

That's not the output file, that's the comparison file.

The .cmp file is supplied by the authors and contains the expected output.

When you run the test script, it produces an output file with a .out extension.

It then compares the contents of the two files and halts if there's a mismatch.

So we need to see your output file, fillautomatic.out.

[Vijay99]

Here: FillAutomatic.out

My design of fill.asm first turns the screen black then it turns the screen white again. After running these two loops it returns to the first loop that checks for keyboard input. Instructions run into 48 lines. I am sure there's a better way to do it.


PS: I am doing it through Coursera. Over my several interactions in this forum, it has turned out that a few procedurally important details have escaped my attention.

[WBahn]

Vijay99 wrote

Here: FillAutomatic.out

So you can see that your line 3 (the header row counts as line 1) is all zeroes when it should be all -1.

My design of fill.asm first turns the screen black then it turns the screen white again. After running these two loops it returns to the first loop that checks for keyboard input. Instructions run into 48 lines. I am sure there's a better way to do it.

This algorithm doesn't do what the program specification called for.

If the person holds down the key long enough, the screen should eventually become -- and stay -- all black. If the person releases the key long enough, the screen should eventually become -- and stay -- all white.

The test script forces the keyboard input to either be no-key-pressed or some-key-pressed and holds each state long enough for any reasonably written program to have enough time to completely fill or clear the screen before it samples a bunch of widely separated locations to test if it did so.

PS: I am doing it through Coursera. Over my several interactions in this forum, it has turned out that a few procedurally important details have escaped my attention.

That's not too surprising. It's one of the huge drawbacks of self-paced online courses. As humans we will always miss some of the details and without someone to correct us and point out that we've missed them, it can be hard to figure that out on your own.

[Vijay99]

Presently, I think my fill.asm does the following:
        (1)check for KBD input:
                  (i) if Memory[KBD] = 0,
                                run fill screen with 0
                  (ii) else,
                                run fill screen with -1
         return to (1)

In CPU emulator: It turns the screen black if any key is pressed. But doesn't turn it back white when key is not pressed.

In my previous design I had fill.asm do the following:
        (1)check for KBD input:
                  if Memory[KBD] ≠ 0,
                                run fill screen with -1
                                run fill screen with 0
         return to (1)
In CPU emulator, It didn't turn the entire screen black if key was kept pressed for long enough. One could always see flashes of white.

I think you need to take a look at my fill.asm  I am working on it from past 5 days but still can't get it to work. I may not get time to work on it in next few weeks.

[WBahn]

Go ahead and post your code -- we can delete it once the issue is resolved.

Have you tested the code segments that fill the screen with each color and verified that they work as intended?

One thing that can make testing your code a lot faster is to write it as those the screen memory is only a few words long, like four or even two. Then what you are looking for is a black line appearing and disappearing in the upper left of the display. That makes single stepping through the code practical.

[Vijay99]

MOD NOTE: File removed -- no longer needed.

WBahn wrote

Have you tested the code segments that fill the screen with each color and verified that they work as intended?

Yes, you can see that this the 3rd file on which I am working so I have tested the snippets .

[WBahn]

I took a quick look and one possible issue is that you are not staying within the screen bounds.

What happens when i = 8192. You jump back to the check keyboard routing if i - 8192 > 0, which in this case it isn't, so you don't jump back. But what is the value of addr at this point? What happens if you write to that memory location?

I don't have the tool set on this machine, so I can't test it, but at the least it invokes undefined behavior. Assuming the CPU emulator lets you set that memory location, that would probably explain the behavior you are seeing (or at least might) since you are changing the value from what the test script set it to and the test script only sets it a couple of times throughout the entire run and is relying on it staying the same until it changes it.

[Vijay99]

Ha! Its done, changed 8192 to 8191.
I can't express the excitement.

[Vijay99]

Just to confirm, It was happening because I didn't consider that memory addresses start from zero.

[WBahn]

Arguably a better way would be to keep the 8192, as that has meaning being the size of the screen address space, but change the jump conditional from JGT to JGE. Either will work, but this is probably more maintainable.

[WBahn]

Kinda. You were actually inconsistent.

You remembered that it starts at zero because you properly started at an address offset of 0 from the SCREEN address. But you treated the end like it starts at one.