Forums

Well, they say you never stop learning. I suppose many of you already know this, but it caught me by surprise, I had been properly emulating it by accident in the past. I had finally written a working routine to translate the planar video memory and 'pre-convert' it to a linear tilebay of graphic data so that I could simplify my rasterizing routines. I had a few bugs at first; one of them was that when I changed the sprite rasterizer to use the linear tilebay buffer, I had accidentally broke the part that switched from sprite banks 0-255 and 256-447. The first game I noticed this on was Outrun, and I found a couple others that did it too. So when I fixed it, I tested it with a handful of games that used the high sprite bank, and when I finally got to Outrun, I noticed that it still had some graphics errors. But they weren't in the sprites, they were in the tilemap.

Well, anyhow, the point is, I hadn't thought at first that it was allowed to address tiles 448 through 511. But verily, Outrun at least does this, and I suspect there are a few more commercial games that do as well. I'm not quite sure where it managed to find the extra memory, I suppose you could cram two tiles into the unsused 64 bytes in the sprite table -- er, I guess you could put some more tiles in the part of the name table that doesnt get displayed. Outrun used more than 2 extra tiles though.. It seemed to have at least 5 extra tiles, so it must've found an extra 160 bytes somewhere. Anyhow, looking back at Charles Mac Donald's VDP doc, he DOES specify that the tile n takes vales 0 through 1FF, so I guess that makes sense. Ah well. Just thought that was interesting.

- vecna

In short:
The whole Video Memory can be used to store and display tiles. Since tilemap and sprites map can be movable, there is no reason not to use the upper area.
Of course in the usual case there is not enough room for more than 448 tiles, but they are not always the first 448.

Author	Message
vecna Guest	hehe... Posted: Wed May 10, 2000 6:02 pm
vecna Guest	Well, they say you never stop learning. I suppose many of you already know this, but it caught me by surprise, I had been properly emulating it by accident in the past. I had finally written a working routine to translate the planar video memory and 'pre-convert' it to a linear tilebay of graphic data so that I could simplify my rasterizing routines. I had a few bugs at first; one of them was that when I changed the sprite rasterizer to use the linear tilebay buffer, I had accidentally broke the part that switched from sprite banks 0-255 and 256-447. The first game I noticed this on was Outrun, and I found a couple others that did it too. So when I fixed it, I tested it with a handful of games that used the high sprite bank, and when I finally got to Outrun, I noticed that it still had some graphics errors. But they weren't in the sprites, they were in the tilemap. Well, anyhow, the point is, I hadn't thought at first that it was allowed to address tiles 448 through 511. But verily, Outrun at least does this, and I suspect there are a few more commercial games that do as well. I'm not quite sure where it managed to find the extra memory, I suppose you could cram two tiles into the unsused 64 bytes in the sprite table -- er, I guess you could put some more tiles in the part of the name table that doesnt get displayed. Outrun used more than 2 extra tiles though.. It seemed to have at least 5 extra tiles, so it must've found an extra 160 bytes somewhere. Anyhow, looking back at Charles Mac Donald's VDP doc, he DOES specify that the tile n takes vales 0 through 1FF, so I guess that makes sense. Ah well. Just thought that was interesting. - vecna

Zoop Joined: 24 Jun 1999 Posts: 1732 Location: Paris, France	Posted: Wed May 10, 2000 8:12 pm
	In short: The whole Video Memory can be used to store and display tiles. Since tilemap and sprites map can be movable, there is no reason not to use the upper area. Of course in the usual case there is not enough room for more than 448 tiles, but they are not always the first 448.

Forums

View topic - hehe...