0xC000 VRAM stuff, and efficiency question.
Posted: 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]
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]