Chapter 4

[JustinM]

Whew, is it just me, or is chapter 4 tougher than the chapters that came before it? I'm re-reading it now and actually taking notes this time.

I've never seen low language programming before... I would say it's what I expected, but it sure is different!

I'm having fun though... it's pretty neat to see how higher level constructs are assembled (heh heh, assembled) from their lower level counterparts. It still seems cryptic to me, but I'll get there.

[bizobo]

I agree, I think it's tougher as well!

Fill right now is giving me some trouble, I'm not sure I understand page 70 when they say RAM[16384 + r*32 + c/16]. How can you have a fractional RAM address? For example if it's Row 0 and Column 1, that's
16384 + 0 + 1/16. That doesn't make sense to me!

[cadet1620]

bizobo wrote

I agree, I think it's tougher as well!

Fill right now is giving me some trouble, I'm not sure I understand page 70 when they say RAM[16384 + r*32 + c/16]. How can you have a fractional RAM address? For example if it's Row 0 and Column 1, that's
16384 + 0 + 1/16. That doesn't make sense to me!

This is integer division, which means ignore the remainder. So 1/16 = 0, 15/16 = 0, 16/16 = 1, etc.
Note that in "c%16" the "%" is the remainder operator.

--Mark

[bizobo]

hey mark,

i realized after a while i had messed that one up.

how do i load a 16-bit value into an M in Hack?

I want to force M to hold 16-bit 1 or 16-bit 0 for Fill.asm but I can't figure out how to assign to do that. I can't seem to get it to work.

I try doing

M=M|1

And it gives me an "Expression expected" error.

I can't do M=M|D and set D to 1, because I'm already using D (in combination with A) to give me the correct Memory value by adding my counter to 16384 (the beginning of the Screen's memory space).

I don't know how to do this and I'm beginning to hate Assembly with a passion.

[bizobo]

Got it to work (solution is at the end of this post - spoiler alert!), but I'm unsure why what worked worked. Is it because in 2's-radix for signed numbers the binary equivalent of the base 10 number I was entering was 16 bit's of 1's? I assume that must be the reason why.

Regardless, got it working now!



















































Set M to -1.

[cadet1620]

bizobo wrote

Got it to work (solution is at the end of this post - spoiler alert!), but I'm unsure why what worked worked. Is it because in 2's-radix for signed numbers the binary equivalent of the base 10 number I was entering was 16 bit's of 1's? I assume that must be the reason why.

Regardless, got it working now!

Set M to -1.

This is shown in figure 2.1 in the section about 2's complement numbers, albeit for 4-bit numbers instead of 16-bit. This is one of those facts that should become automatic; when you see -1 think all bits set.

Another thing that might help you see how 2's complement works is to think about counting.

0111 1111 1111 1111 is the largest 16-bit positive number -- in effect positive infinity. When you add 1 you get 1000 0000 0000 0000 which is a negative number since it has the sign bit set. It makes sense that this should be negative infinity -- the negative number with greatest magnitude.

When you add 1 again you get another negative number that should be closer to 0. Keep adding 1 and you eventually get to 1111 1111 1111 1111 which is -1. Add 1 again and you get back to 0.

--Mark

[bizobo]

That counting exercise actually does make a lot of sense. And the reason why 1111 1111 1111 1111 is -1 and that is the closest number to 0 is because these bits are storing integers, not fractional numbers.

Cool, thanks!

Also, does anyone else have the problem where their Fill.asm fills the whole screen except for a tiny little bit at the top left? When I was writing this program and just testing the screen memory space I was setting M=!M and that actually worked and filled that top left portion as well. With the new solution, the one that actually works with listening for keyboard input, I can't get that top left corner to fill.

I think it's a CPUEmulator problem, not a code problem. Can anyone else confirm?

[cadet1620]

It's not a known emulator bug.

If you want to mail me your code, I'll take a look at it.

--Mark

[bizobo]

Sent!