#9096 - Domovoi - Mon Jul 28, 2003 2:59 pm
Okay, I had just found ease with the way Character Base Blocks are layed out. A 256 color tile is 64 bytes, and a Character Base Block is 16 KB. 16384B/64B = 256 tiles per Character base block, right?
Wrong. Imagine my surprise, when I opened visual boy and looked at the tile data. I see a whole bunch of my tiles... In fact, I see way too much of my tiles. Guess what? When I click on tile 512, it tells me it's memory address is 06004000. That's right, that's where Character Base Block 1 starts. That means I'm somehow saving 512 256-color tiles in Character Base Block 0, i.e. twice as much as should be possible.
Here's a picture of the map viewer: http://baspaap.hypermart.net/odd.jpg
Note that I selected tile 455. Also note that it's a 256 color tile. How can that be, if I can only fit 256 tiles in a CBB?
That does not make sense. What's going on here? A bug in VB? Or do I have mystery powers that shrink the size of a 256-color tile? Anyone have an idea?
Last edited by Domovoi on Mon Jul 28, 2003 3:18 pm; edited 1 time in total
#9098 - niltsair - Mon Jul 28, 2003 3:17 pm
I'm not not I understood you right, but here's a clarification. Screen blocks are just starting address to be used by the map. From that starting point, you can access 1024 tiles forward (but only ScreenBlock 0 has that many tiles accessible in 256colors mode. ) | Code: |
[b] Video Memory [/b]
|------------>------------>------------>-----------|
0 256 512 768 1024 (From ScreenBlock 0)
0 256 512 768 (From ScreenBlock 1)
0 256 512 (From ScreenBlock 2)
0 256 (From ScreenBlock 3)
(Only valide in 256colors mode, in 16colors, those values are differents) |
So, as you can see, char 512 of block0 is the char 256 of block1 and char 0 of block3
Last edited by niltsair on Mon Jul 28, 2003 3:22 pm; edited 2 times in total
#9099 - Domovoi - Mon Jul 28, 2003 3:20 pm
Thanks for the reply!
I understand that. But the odd thing is that when VisualBoy displays the tiles in CBB 0, it's -more- than 256 tiles. It's 512 tiles. What's oddest is that tile nr. 512 is at the -start- of CBB1. So that means tiles 0 to 511 are stored -before- CBB1. How is that posssible?
#9100 - Domovoi - Mon Jul 28, 2003 3:29 pm
Here's another picture: http://baspaap.hypermart.net/tiles.jpg
Now, CBB1 starts at 0600400, right? And only 256 tiles should fit -before- that adress, in CBB0, right?
Note that I have selected tile 511. Note also that it has adress 06003fe0. In other words, just before 0600400. Just before the starting adress of CBB1. So -in- CBB0. But it's tile 511. That means 512 tiles in CBB0. How?
#9101 - niltsair - Mon Jul 28, 2003 3:44 pm
A wild guest, perhaps it's always giving you the tile number of 16colors tiles, since they can fit twice as much, even if you're in 256colors mode.
Try changing the color mode in the tile/map view, and see if it affect the tile number.
#9130 - Domovoi - Tue Jul 29, 2003 12:22 am
Hmmm... nope, still gives 512 tiles. Very odd...
#9146 - RaBBi - Tue Jul 29, 2003 8:34 am
arf...I'm beginning in learning memory and register and all hardware stuff of the gba...
I thought I was ok with tiles and memory but this topic is reversing my mind lol
_________________
Sorry for my poor english, but it would be worst for you to understand me if I speak in my native language, French ^^
#9149 - djei-dot - Tue Jul 29, 2003 11:06 am
I get that too. It seems like vba displays the addresses of 256-color tiles the same way it does with 16-color tiles. The wierd thing about this is that tile 0 in Char Base Block 1 has the address of 06004000, like it should be. However, the same tile viewed in Char Base Block 0 corresponds to the 256th, which is good, but it's address is 06002000, which is not consistent with the address in CBB1. Therefore I guess that tiles addresses are not being counted correctly in vba. But maybe Forgotten had a good reason to do this...
#9179 - sgeos - Wed Jul 30, 2003 12:10 am
I'm not going to worry about VBA. My versions does not tell what address a tile is at. (Maybe I should get the newest one?)
There are four character base blocks. They use the memory from 0x06000000 to 0x0600FFFF. Each is 0x4000 bytes in length. The character base blocks start at 0x06000000, 0x06004000, 0x06008000, and 0x0600C000.
How much space does a tile take up? I use 16 color text tiles. They are 0x20 bytes in length. 0x4000 / 0x20 = 0x200. 0x200 (512) sixteen color tiles can fit in a screen base block. If 256 color tiles take double the space... 0x4000 / 0x40 = 0x100, or 256 tiles.
I think the BG tile format is what is causing this confusion. Let us look at that. In a screen base block, assuming a text BG (not a rotation and scaling BG), the tile used at any given location is represented by a 16 bit integer. If all of the bits == 1, it looks like this: 0xFFFF. I'll mask out portions and explain what the bits do:
| Code: |
0x03FF The tile number
0x0400 H-flip
0x0800 V-flip
0xF000 Palette |
Note how many bits are used for the tile number. Tile 0x03FF is tile 1023 in decimal! That mean that you can select from up to 1024 tiles, offset from the start of the CBB your BG is using.
I'm not sure how all of this works out with 256 color tiles. With any luck, somebody will fill us in on that. (And correct me if I've made any mistakes.)
-Brendan
#9184 - djei-dot - Wed Jul 30, 2003 11:57 am
| sgeos wrote: |
In a screen base block, assuming a text BG (not a rotation and scaling BG), the tile used at any given location is represented by a 16 bit integer. If all of the bits == 1, it looks like this: 0xFFFF. I'll mask out portions and explain what the bits do:
| Code: | 0x03FF The tile number
0x0400 H-flip
0x0800 V-flip
0xF000 Palette |
Note how many bits are used for the tile number. Tile 0x03FF is tile 1023 in decimal! That mean that you can select from up to 1024 tiles, offset from the start of the CBB your BG is using.
|
Those are map entries, not tile entries. I think we're talking about character base blocks and not screen base blocks.
| sgeos wrote: |
How much space does a tile take up? I use 16 color text tiles. They are 0x20 bytes in length. 0x4000 / 0x20 = 0x200. 0x200 (512) sixteen color tiles can fit in a screen base block. If 256 color tiles take double the space... 0x4000 / 0x40 = 0x100, or 256 tiles.
|
That is correct. In fact, a 16-color tile entry takes 4 bits x 64 pixels = 256 bits (32 bytes = 0x20). A 256-color tile entry takes 8 bits x 64 pixels = 512 bits (64 bytes = 0x40). Given that, the address of the second tile in VRAM would be 0x6000020, if it were a 16-color tile, or 0x6000040, if it were a 256-color tile. The thing is, in VBA's tile viewer the address of the second tile is 0x6000020 for both color types!
| sgeos wrote: |
| I'm not going to worry about VBA. My versions does not tell what address a tile is at. (Maybe I should get the newest one?) |
I wouldn't worry much about it also. The point is, there are no extra tiles in memory, they are only incorrectly counted. Maybe Forgotten would like to know about this.
#9229 - sgeos - Thu Jul 31, 2003 1:32 am
| djei-dot wrote: |
| Those are map entries, not tile entries. I think we're talking about character base blocks and not screen base blocks. |
I think the reason that VBA shows so many tiles is because a map entry can select from up to 1024 tiles even though only 512 (or 256 depending) are available to a map entry.
| djei-dot wrote: |
| VBA's tile viewer the address of the second tile is 0x6000020 for both color types! ... The point is, there are no extra tiles in memory, they are only incorrectly counted. Maybe Forgotten would like to know about this. |
Go for it. (Send him an email about it.)
-Brendan
#9318 - Domovoi - Fri Aug 01, 2003 2:06 pm
So has anyone sent him an e-mail pointing him to this thread? I'd do it, but I don't think he'd appreciate redundant bug reports.
#9320 - djei-dot - Fri Aug 01, 2003 3:41 pm
I already did it.