Forums

Hello Guys.

This week, i finally finished the 1st stage of VDP Optimization on SayaRX. Now it "pre-decodes" all pattern data from bitplanes to linear format when the pattern bitplane byte is changed in VRAM.

One detail caught my attention. Lots of documents (except Charles Doc) says that games uses the area $0000-$37FF to store VDP pattern data. Actually, you guys know that it's possible to store 512 patterns and fill all the 16Kb VRAM.

Emulators like ChaSMS also shows only the first 448 Patterns.
WIth that in hand, i implemented my VDP conversion routine to do it's job only when data is written to the range $0000-$37FF.
After that, i started to get strange BG errors in Phantasy Star.

This game uses more than 448 patterns to display menu borders and that small arrow in all menus. So i had to change my function to check the VDP registers and see when the pattern VRAM ends.

Quote

> This game uses more than 448 patterns to display menu borders and that small arrow in all menus. So i had to change my function to check the VDP registers and see when the pattern VRAM ends.

Yeah, at the moment I'd say that, while the other docs like Richard Talbot Watkin's docs are useful because they cover the whole SMS and are, on the whole, a little easier to understand, Charles' VDP docs should be taken as the authorative VDP reference, especially when implementing a VDP in an emulator. You can get by with a less complete doc if you are interested in writing SMS software. You can get quite far without worrying about moving the sprite and map table locations are vram, for instance.

So, yes, any part of VDP ram can be displayed on the screen as a tile, including the block after the end of the map table, the two tile's worth between the x/attribute and y parts of the sprite table, and even the map and sprite tables themselves (Although there's no reason I could think of to do that). Easier to just maintain a pretranslated version of all of VRAM. As with SayaRX, Smeg maintains a pretranslated version of the VDP Ram to reduce redundant decoding of the planar pixel data when rendering the background and sprite layers. I initially considered not pretranslating when a byte was written to an address that was used by the map or sprite tables. That might have been a small speed boost, but it would have required that I work out ways to handle the tables being moved in memory (such as the title screen in quartet), and it didn't seem to be worth the trouble.

Quote

> Emulators like ChaSMS also shows only the first 448 Patterns.
> WIth that in hand, i implemented my VDP conversion routine to do it's job only when data is written to the range $0000-$37FF.
> After that, i started to get strange BG errors in Phantasy Star.

> This game uses more than 448 patterns to display menu borders and that small arrow in all menus. So i had to change my function to check the VDP registers and see when the pattern VRAM ends.

PS uses all possible VRAM space, including the space between the sprite Y and X attributes, the bottom 4 rows of the name table (in non-scrolling areas), and some unused parts of the sprite table for tiles. eSMS is good for checking that out since its tile display is the full 512 tiles. It is also a pain for people hoping to squeeze some extra tiles in for a retranslation :/

Maxim

Detect the table movement is not so hard. You can use VDP Registers to determine the start of each table.

The problem is:
It is not possible to know how many bytes of the table(s) are in use. So, if the game uses only two sprites, the other 62Bytes of the Y-SAT can be used to display patterns.

Author	Message
Rene Dare Joined: 28 Mar 2002 Posts: 180 Location: Toronto, Canada	Pattern behaviour Posted: Fri Aug 01, 2003 12:04 pm
	Hello Guys. This week, i finally finished the 1st stage of VDP Optimization on SayaRX. Now it "pre-decodes" all pattern data from bitplanes to linear format when the pattern bitplane byte is changed in VRAM. One detail caught my attention. Lots of documents (except Charles Doc) says that games uses the area $0000-$37FF to store VDP pattern data. Actually, you guys know that it's possible to store 512 patterns and fill all the 16Kb VRAM. Emulators like ChaSMS also shows only the first 448 Patterns. WIth that in hand, i implemented my VDP conversion routine to do it's job only when data is written to the range $0000-$37FF. After that, i started to get strange BG errors in Phantasy Star. This game uses more than 448 patterns to display menu borders and that small arrow in all menus. So i had to change my function to check the VDP registers and see when the pattern VRAM ends.

Heliophobe Site Admin Joined: 25 Oct 1999 Posts: 2029 Location: Monterey, California	Posted: Fri Aug 01, 2003 4:59 pm
	Quote > This game uses more than 448 patterns to display menu borders and that small arrow in all menus. So i had to change my function to check the VDP registers and see when the pattern VRAM ends. Yeah, at the moment I'd say that, while the other docs like Richard Talbot Watkin's docs are useful because they cover the whole SMS and are, on the whole, a little easier to understand, Charles' VDP docs should be taken as the authorative VDP reference, especially when implementing a VDP in an emulator. You can get by with a less complete doc if you are interested in writing SMS software. You can get quite far without worrying about moving the sprite and map table locations are vram, for instance. So, yes, any part of VDP ram can be displayed on the screen as a tile, including the block after the end of the map table, the two tile's worth between the x/attribute and y parts of the sprite table, and even the map and sprite tables themselves (Although there's no reason I could think of to do that). Easier to just maintain a pretranslated version of all of VRAM. As with SayaRX, Smeg maintains a pretranslated version of the VDP Ram to reduce redundant decoding of the planar pixel data when rendering the background and sprite layers. I initially considered not pretranslating when a byte was written to an address that was used by the map or sprite tables. That might have been a small speed boost, but it would have required that I work out ways to handle the tables being moved in memory (such as the title screen in quartet), and it didn't seem to be worth the trouble.

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14769 Location: London	PS VRAM usage Posted: Fri Aug 01, 2003 5:28 pm
	Quote > Emulators like ChaSMS also shows only the first 448 Patterns. > WIth that in hand, i implemented my VDP conversion routine to do it's job only when data is written to the range $0000-$37FF. > After that, i started to get strange BG errors in Phantasy Star. > This game uses more than 448 patterns to display menu borders and that small arrow in all menus. So i had to change my function to check the VDP registers and see when the pattern VRAM ends. PS uses all possible VRAM space, including the space between the sprite Y and X attributes, the bottom 4 rows of the name table (in non-scrolling areas), and some unused parts of the sprite table for tiles. eSMS is good for checking that out since its tile display is the full 512 tiles. It is also a pain for people hoping to squeeze some extra tiles in for a retranslation :/ Maxim

Rene Dare Joined: 28 Mar 2002 Posts: 180 Location: Toronto, Canada	Posted: Mon Aug 04, 2003 3:08 pm
	Detect the table movement is not so hard. You can use VDP Registers to determine the start of each table. The problem is: It is not possible to know how many bytes of the table(s) are in use. So, if the game uses only two sprites, the other 62Bytes of the Y-SAT can be used to display patterns.

Forums

View topic - Pattern behaviour