0xC000 VRAM stuff, and efficiency question.

For anything related to VDP (plane, color, sprite, tiles)

Moderators: BigEvilCorporation, Mask of Destiny

Post Reply
Count SymphoniC
Very interested
Posts: 149
Joined: Sat Nov 17, 2012 3:58 am

0xC000 VRAM stuff, and efficiency question.

Post by Count SymphoniC » Mon Sep 22, 2014 11:40 pm

Well I finally managed to get the first layout for the YMDJ tracker interface loaded and to display correctly... but it took some work on my part.

Here was the problem. I would load my 40x30 cell layout, and it would skew beyond the boundaries of the x coords... It looked bad. After spending all day trying to figure it out, I decided to dump the VRAM using Regen and open it up in a hex editor. I found the table used to define which font characters go where on the layout.


So I played with the 0x40000003 VDP data write instruction, changing the upper word of it to 0x4800, just to see what would happen and I noticed that this would move my entire layout halfway down the screen. At this point, the solution to my problem was obvious. I wrote some code using a counter to branch from the Plane writing loop whenever the counter dropped from 40 to 0. Then I added 0x0??? random numbers to my PLANEWRITEA global, fed that to the VDP, jumped back to the Plane writing loop. Now the loop was set to branch off whenever the last tile on the far right of the screen was drawn, but I still got a skewed result. So I fine tuned 0x0??? until all the tiles were correctly aligned.

The magic value was 0x0080.

I now understand that 0xC000 is the beginning of the area in VRAM where things are directly drawn on screen. I now understand how to place things on specific parts of the screen. And now for my question on efficiency.

Would it have been better to use the auto increment functionality of the VDP instead of adding to the PLANEWRITEA value that was stored in d0?

Also is there any inaccuracies in anything I said? I think I understand it, but I don't want to be wrong later.


[/img]

Chilly Willy
Very interested
Posts: 2984
Joined: Fri Aug 17, 2007 9:33 pm

Post by Chilly Willy » Tue Sep 23, 2014 1:22 am

If you look at the source, VDP_init() sets PLANE A to $C000, PLANE B to $E000, and the map mode to 64x64. That's why the "magic" number is 128 - each entry in the map is a word, so 64x2 = 128.

When in doubt, look at the source code. :D

Count SymphoniC
Very interested
Posts: 149
Joined: Sat Nov 17, 2012 3:58 am

Post by Count SymphoniC » Tue Sep 23, 2014 4:40 am

Chilly Willy wrote:If you look at the source, VDP_init() sets PLANE A to $C000, PLANE B to $E000, and the map mode to 64x64. That's why the "magic" number is 128 - each entry in the map is a word, so 64x2 = 128.

When in doubt, look at the source code. :D
WHAT!?!?!?!?!?! I've been figuring all this out in pure assembly and all I had to do was look at the source for the C dev kit. WHY?!??!?! I feel so stupid now. Well no sense in reinventing the wheel I guess, that source will definitely come in handy. Haha, I can't believe this.

powerofrecall
Very interested
Posts: 237
Joined: Fri Apr 17, 2009 7:35 pm
Location: USA

Post by powerofrecall » Tue Sep 23, 2014 4:42 am

If you can read C the SGDK source is excellent documentation!

Chilly Willy
Very interested
Posts: 2984
Joined: Fri Aug 17, 2007 9:33 pm

Post by Chilly Willy » Tue Sep 23, 2014 5:47 pm

powerofrecall wrote:If you can read C the SGDK source is excellent documentation!
It's its own documentation. :lol:

All the vdp register settings are commented on what the values set by VDP_int() do, so it's pretty easy to read that part.

Post Reply