VGA.spin Dissection
tdeyle
Posts: 85
I have been hacking away at the video driver, trying to learn how the prop generates the video for VGA monitors. Specifically, the VGA.spin driver found in the library.
I have been reading A. Lamothe's book about programming the Hydra console and gained alot of insight into how the video generator works, the way the memory is setup for colour, pixels, etc.
But when I arrived to the actual pixel generating area of the code, I was a tad confused.
To make this example easier to explain, I have made a few considerations when figuring out this code:
This is the first run of the code, the Propeller was just turned on.
Also, the Bitmap Memory Address is located @ $0000_0000.
The way it looks to me, the line that states
reads the WORD sized pointer from the screen variable to tile. This pointer points to the starting address of the tile in the bitmap memory and the colourset used to determine the four colors used in that tile. Here is how I understand it:
Bits 0..1 are included for boundary purposes,
bits 2..5 is the address of the LONG within the individual tile address,
bits 6..15 are the address of each 64 byte tile within the Bitmap Memory.
Now on to the confusing part. The next two lines:
Okay, the first line adds %0000_0000_0000_0110_0000_0000_0000_0000 into the tile variable. Since the tile variable is WORD length, that would change the resulting tile variable into a LONG, correct?
For example, let's say that the tile variable equals %0100_0000_0000_0000 before it gets to the ADD command. After the ADD occurs, the tile variable equals %0000_0000_0000_0110_0100_0000_0000_0000, correct?
Continuing, the ROL command rotates the tile variable 6 places to the left:
With my example: %0000_0001_1001_0000_0000_0000_0000_0000
Now this is where the issue is for me. In the next line:
Considering that this is the first execution of this code, the tile variable should point to the address of the first row, of the first tile, yes? If the tile variable equals %0000_0001_1001_0000_0000_0000_0000_0000, wouldn't that point to the incorrect location in the memory?
But if the address was the first 16 bits of this LONG, then I could understand it: In other words, if the address was %0000_0000_0000_0000.
My question is, how does this work? What does the RDLONG command read? Bits 0..15, or the entire LONG? How does it only access bits 0..15 to get the address?
Any help would be greatly appreciated.
Theo
I have been reading A. Lamothe's book about programming the Hydra console and gained alot of insight into how the video generator works, the way the memory is setup for colour, pixels, etc.
But when I arrived to the actual pixel generating area of the code, I was a tad confused.
To make this example easier to explain, I have made a few considerations when figuring out this code:
This is the first run of the code, the Propeller was just turned on.
Also, the Bitmap Memory Address is located @ $0000_0000.
The way it looks to me, the line that states
:tile rdword tile,screen
reads the WORD sized pointer from the screen variable to tile. This pointer points to the starting address of the tile in the bitmap memory and the colourset used to determine the four colors used in that tile. Here is how I understand it:
Bits 0..1 are included for boundary purposes,
bits 2..5 is the address of the LONG within the individual tile address,
bits 6..15 are the address of each 64 byte tile within the Bitmap Memory.
Now on to the confusing part. The next two lines:
add tile,line 'ADD line=$0006_0000 to tile, rol tile,#6 'ROtate tile Left by 6
Okay, the first line adds %0000_0000_0000_0110_0000_0000_0000_0000 into the tile variable. Since the tile variable is WORD length, that would change the resulting tile variable into a LONG, correct?
For example, let's say that the tile variable equals %0100_0000_0000_0000 before it gets to the ADD command. After the ADD occurs, the tile variable equals %0000_0000_0000_0110_0100_0000_0000_0000, correct?
Continuing, the ROL command rotates the tile variable 6 places to the left:
With my example: %0000_0001_1001_0000_0000_0000_0000_0000
Now this is where the issue is for me. In the next line:
rdlong pixels,tile
Considering that this is the first execution of this code, the tile variable should point to the address of the first row, of the first tile, yes? If the tile variable equals %0000_0001_1001_0000_0000_0000_0000_0000, wouldn't that point to the incorrect location in the memory?
But if the address was the first 16 bits of this LONG, then I could understand it: In other words, if the address was %0000_0000_0000_0000.
My question is, how does this work? What does the RDLONG command read? Bits 0..15, or the entire LONG? How does it only access bits 0..15 to get the address?
Any help would be greatly appreciated.
Theo
Comments
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm
Can I get some clarification on the "ignoring" aspect of the RDLONG instruction? Whether or not it actually dies this and if it does, how?
Important bits here are the used source bit ranges (S[noparse][[/noparse]31..16] is ignored).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm
Slight correction: the hub address space is 64k (32k RAM, 32k ROM). 64k implies 16-bit addressing.
I'm sure that's what Rayman meant to say.