Screen mapping

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

Screen mapping

savage
Dear Forum,

I'm moving on to Fill.asm
On page 70 of the text, in the Screen paragraph, the fourth sentence reads:
"Thus the pixel at row r......".
Firstly, I'm not sure of the meaning of c%16 and
secondly, should the formula for the word location read RAM[16384+r.32+c.16]?

Finally, if you'll excuse, am I correct in my understanding that as long as a key is pressed,
each bit of the current word needs to be sequentially set to  1?

Cheers
John Savage
Reply | Threaded
Open this post in threaded view
|

Re: Screen mapping

cadet1620
Administrator
savage wrote
Dear Forum,

I'm moving on to Fill.asm
On page 70 of the text, in the Screen paragraph, the fourth sentence reads:
"Thus the pixel at row r......".
Firstly, I'm not sure of the meaning of c%16 and
secondly, should the formula for the word location read RAM[16384+r.32+c.16]?

Finally, if you'll excuse, am I correct in my understanding that as long as a key is pressed,
each bit of the current word needs to be sequentially set to  1?

Cheers
John Savage
"%" means modular division (remainder), so c%16 is the remainder from c divided by 16.

RAM[16384 + r·32 + c/16] is correct.  r times 32 gives the address of the first word in row r; c divided by 16 gives the offset to the word containing the bit in column c.

For Fill.asm you do not need to set the pixels one bit at a time; do them a word at a time.

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

Re: Screen mapping

ybakos
In reply to this post by savage
Hi savage,
The point is that the 16-bit word at address 16384 (SCREEN) represents the first 16 pixels in the upper left corner of the screen. So if you wanted just the upper left pixel of SCREEN to be black, then the value at address 16384 would have to be 1000000000000000.

"as long as a key is pressed, each bit of the current word needs to be sequentially set to  1? "

I think you're on the right track, but just to be clear, as long as a key is pressed, Fill.asm should be setting all words between 16384 and 24575 to 1111111111111111. (And what is that in base 10?)
Reply | Threaded
Open this post in threaded view
|

Re: Screen mapping

savage
Hello Mark and Ybakos,
Thank you very much for your comments.
May I summarize please to see if my thinking is correct?

The row number, r, is in the range 0,1,...,255
The column number refers to the pixel element in the row and is in the range 0,1,...,511

If, for example, I wanted to access the 40th pixel in row 1, I'd be looking at the (40mod16) 8th element from the left in word 16384 + 32*1 + ? (should be word 16419)

I put the ? in because the formula looks as though it could have a fractional value for the word location.

If I ignore the notion of accessing individual pixels, I'll press on using your good advice.

Thanks
John Savage

Reply | Threaded
Open this post in threaded view
|

Re: Screen mapping

cadet1620
Administrator
Generally, when working with computers at this low level, division is understood to mean integer division with the fractional part rounded towards zero.

The bad news is that Hack does not have any hardware support for division.  If you continue through chapter 12 you will write system software to do division.
The good news is that you don't need to do any division for Fill.asm.

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

Re: Screen mapping

savage
Thanks Mark,
It's on with the march then....

John Savage
Reply | Threaded
Open this post in threaded view
|

Re: Screen mapping

KitN
In reply to this post by cadet1620
And in the formula for the Screen word, the first row is indexed as 0? I noticed I get the address for KBD if I muliply 32 by 256.

So really the first row for the formula is r=0 and the last is r=255, and the first column is c=1 and the last column is c=512?

It's kind of confusing that the r value should start at 0 but the c at 1.

Reply | Threaded
Open this post in threaded view
|

Re: Screen mapping

cadet1620
Administrator
The "first" column is c = 0, just like the "first" row is r = 0.
Thus the pixel at row r from the top and column c from the left
is mapped on the c % 16 bit (counting from LSB to MSB) of the
word located at RAM[16384 + r · 32 + c / 16].
'%' is the modulus (remainder) operator.

For r = 0, c = 0:
    c % 16 = 0
so the pixel is stored in bit 0 of the word at RAM[16384].

Note that bits in words are numbered from least-significant to most-significant, starting at 0.

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

Re: Screen mapping

Reuben Adams
In reply to this post by ybakos
ybakos wrote
So if you wanted just the upper left pixel of SCREEN to be black, then the value at address 16384 would have to be 1000000000000000.
Do you mean 0000 0000 0000 0001? For example, on page 71, we have


and 1 as a 16-bit binary number is 0000 0000 0000 0001. Also, on page 70 it says "Thus the pixel at row r from the top and column c from the left is mapped on the c%16 bit (counting from LSB to MSB) of the word located at RAM[16384 + r * 32 + c/16]." The c%16 bit would be the 0 bit, and since we're counting from LSB to MSB this would be the right-most bit.

I wanted to make sure I understood this correctly because it seems a little confusing for the top-left pixel to correspond to the rightmost bit of the first word.
Reply | Threaded
Open this post in threaded view
|

Re: Screen mapping

WBahn
Administrator
It is confusing, but just think of the mapping as going in the "natural" direction in both cases.

The column numbers, as we naturally think of them, increase as we move from left to right, while the bit values in a binary number increase as we move from lsb to msb.

The post you quoted has it wrong -- a slip of the fingers.
Reply | Threaded
Open this post in threaded view
|

Re: Screen mapping

Reuben Adams
Ah I see. Glad to know I had it correct even if it does require a bit of extra thought. Thank you for the quick and clear response!