#7085 - bitshifter - Mon Jun 09, 2003 5:50 am
Hi all, I know C, albeit not very well... I've been reading tutorials and messing around, I understand pretty much everything except this:
u16* testingMem = (u16*)0x5000000; (ripped from dovoto's tutorial!)
Why exactly are we typecasting the memory address into an unsigned short? And what does this afford us? I've scoured google for tutorials on using memory addresses and what we can do with them and found very little... Obviously we can't just fiddle with a memory address as it is, but I still dont understand how this works...
If this is explained elsewhere throw me a link! Thanks!!
#7088 - tom - Mon Jun 09, 2003 10:24 am
| bitshifter wrote: |
u16* testingMem = (u16*)0x5000000; (ripped from dovoto's tutorial!)
Why exactly are we typecasting the memory address into an unsigned short? And what does this afford us? |
you're not casting the address in an unsigned short, you're casting it into a *pointer to unsigned short*.
for the compiler, your address (the number you marked red) is simply an integer. if you were doing something like this:
u16* testingMem = 0x5000000;
gcc would spit out a warning message:
"warning: initialization makes pointer from integer without a cast"
with the cast you tell the compiler to shut up because you think you know what you're doing =)
now that testingMem holds the address of the video ram, you can access vram like this:
*testingMem = 0x7fff;
this will plot a white pixel in the upper left corner on the screen (assuming you're in mode 3)
#7094 - niltsair - Mon Jun 09, 2003 2:11 pm
Abd by casting it in a certain type, that tells the compiler how we want to access the memory. u16 means that when we read/write to this location, we read 16bits(unsigned short).
If we were to do this : testingMem[10]
then the compiler would know it's location 0x5000000 + (10*2) since a u16 takes 2 bytes. Same if we did a : testingMem++;
The pointer would get increased by 2 (0x5000000 + 2)
If we had casted it to a u32, then we woudl read/write 4bytes at a time, and the address woudl increase by 4 bytes.
Last detail, why 16bits and not 8? In mode 3 it makes sens (since 1 pixel = 16bits, but in other mode it make less, when a pixel takes 8bits, but the hardware limit us to 16bits access when reading/writing video memory.
#7110 - bitshifter - Mon Jun 09, 2003 8:36 pm
Well that certainly clears up a lot. Thank you very much niltsair and tom!
But I am still fuzzy on understanding memory addresses. I know that the 0x5000000 is in hex, and each 5 or 0 or whatever it happens to be represents a byte (four bits, 1 or 0), correct?
So the 0x5000000 is actually 0101 0000 0000 0000 0000 0000 0000, right? What is actually going on when we place a pixel value in videoBuffer? And how does altering a value for the videoBuffer at 0x5000000 differ from using the palette at 0x4000000 (or whatever it is :)) where only one bit has changed? I understand hex-binary conversions easily, but how it all corresponds to memory values is difficult to understand at first....
Thanks again fellas, you've been a great help!
#7113 - niltsair - Mon Jun 09, 2003 9:12 pm
0x123456
1,2,3,4,5,6 are half Byte(4bits)
12,34,56 are 1Byte(8bits)
0x01 = 1(decimal)
0x10 = 16(decimal)
0x100 = 256(decimal)
0x1000 = 4096(decimal)
...
So 0x5000000 means that you're accessing address :
0x05*(16777216) + 0x00*(65536) + 0x00*(256) + 0x00*(1) = 83,886,080
0x4000000 means that you're accessing address :
67,108,864
So, when you're doing this : ((u16*)0x5000000) = RGB(15,15,22); you're saying that you want to store a value at the memory address 0x5000000 or 83,886,080 in decimal.
#7114 - bitshifter - Mon Jun 09, 2003 9:32 pm
thank you very very very much, I searched the internet for hours looking for that, and it was summed up so easily by you. I really appreciate it!!! Thanks again!!!