VDP-related bugs

[Tom Maneiro]

While making CrazyBus, i noticed some bugs/issues while loading tiles into VDP:

1)Sometimes when i load a 1120 tile pic (320*224) in VDP starting at offset 256, screen scrolls to the left, and sometimes not. Why?
More details on CB sources (CrazyBus.bex,line 610), i have commented the bug there.
2)What stores BasiEgaXorz starting at VDP offset 1376? If i overwrite that "garbage", and try to create a sprite, i get the error "SPRITE LIMIT REACHED (START:reset)". Maybe some undocumented "important info"?
3)That portion of code give me some headaches:
print "loading tiles"
loadtiles cosa,8,256
loadtiles rc1,1,219

if busID=1 then
 loadtiles bus1_pic,108,264
endif
if busID=2 then
 loadtiles bus2_pic,108,264
endif
if busID=3 then
 loadtiles bus3_pic,108,264
endif
loadtiles vbLO,792,372
sleep 10
'for avoid weird screen corruptions, load these two
'tiles at finish
'weird BEX bug?
loadtiles rc2,1,220
loadtiles rc3,1,221
print "tiles loaded"

It works OK, but when if i change it to this:
print "loading tiles"
loadtiles cosa,8,256
loadtiles rc1,1,219
loadtiles rc2,1,220
loadtiles rc3,1,221
if busID=1 then
 loadtiles bus1_pic,108,264
endif
if busID=2 then
 loadtiles bus2_pic,108,264
endif
if busID=3 then
 loadtiles bus3_pic,108,264
endif
loadtiles vbLO,792,372
sleep 10
print "tiles loaded"
screen gets corrupted after executing "loadtilles rc2,1,221". Weird.....

These bugs are present in v0.12 and v0.19.

[oompa loompa]

1)Sometimes when i load a 1120 tile pic (320*224) in VDP starting at offset 256, screen scrolls to the left, and sometimes not. Why?

here's the layout of the default vram map for basiegaxorz

Low-Level Video Setup
Default VRAM Map
Scroll B = $E000 - $FFFF [8192 Bytes]
Scroll A = $C000 - $DFFF [8192 Bytes]
Patterns (Tiles 1520-1535) = $BE00 - $BFFF [1856 Bytes]
Window = $B000 - $BDFF [2240 Bytes]
Patterns (Tiles 1396-1407) = $AE80 - $AFFF [384 Bytes]
Sprites = $AC00 - $AE7F [640 Bytes]
H Scroll = $A800 - $ABFF [1024 Bytes]
Patterns (Tiles 0-1343) = $0000 - $A7FF [43008 Bytes]

Any tiles stores after tile 1343 will overwrite the mappings for the tiles. loadtiles should never overwrite this data. The genesis has a limit of 64 kilobytes of vram. 34% of the memory holds the mapping of tiles for the appropriate planes, also the sprite properties too

2)What stores BasiEgaXorz starting at VDP offset 1376? If i overwrite that "garbage", and try to create a sprite, i get the error "SPRITE LIMIT REACHED

Like #1, you've actualy overwritten over the sprite data. When all the sprites are written, basiegaxorz routines check this before writing another sprite, and will warn you that there's not enough memory to write more sprites.

3)That portion of code give me some headaches:

probably a bug in basiegaxzorz routines, not certain though

EDIT: fock, another clr d1 bug
yep its a bug within the compiler
will be fixed in v0.2

[Tom Maneiro]

#2 and 3 are a relief, but.... why the heck, in #1, the entire screen (maybe the active layer) scrolls to left?

Sometimes i load those 1120 tiles at offset 256, with no prob, but sometimes, i load THE SAME 1120 TILES IN THE SAME OFFSET, and screen scrolls! I am sure that i am not overwriting any important zone!

[oompa loompa]

Tom said:

#2 and 3 are a relief, but.... why the heck, in #1, the entire screen (maybe the active layer) scrolls to left?

Sometimes i load those 1120 tiles at offset 256, with no prob, but sometimes, i load THE SAME 1120 TILES IN THE SAME OFFSET, and screen scrolls! I am sure that i am not overwriting any important zone!

The long detailed, technical answer:

Uhm, its because when you go writing to vdp tile offsets 1344 and above, you overwrite the hscroll data, sprites, background planes, etc. With 1120+256 tiles, luckily you don't overwrite anything above sprites, but you do overwrite the horizontal scroll data. By default, horizontal scrolling is by overall, scrolling the entire screen. The value that determines how much to scroll is in adress 0xA800. If a word value of 0 is written to this address, the screen is not scrolled, as in basiegaxorz's deafult startup. If its any other value, the screen will scroll. The reason why you get intermittent results is because you sometimes write a value of 0 to it, which should show no problems, and sometimes you write some other value, which will definitely scroll the screen. You can test this out yourself. Load a tile at tile offset 1344. The first word value in the tile will determine how much the screen is scrolled. One unit of this data equals one pixel scrolled to the left.

[Tom Maneiro]

Now I understand. You mean that i need to do some editing to my tiles?

First word... first 4 bits

So:

DATALONG $11111111
DATALONG $11111111
DATALONG $11111111
DATALONG $11111111
DATALONG $11111111
DATALONG $11111111
DATALONG $11111111
DATALONG $11111111

i should edit it to get something like this:

DATALONG $00001111
DATALONG $11111111
DATALONG $11111111
DATALONG $11111111
DATALONG $11111111
DATALONG $11111111
DATALONG $11111111
DATALONG $11111111

for avoid scrolling. Is this correct?

[oompa loompa]

no my point to you is to not overwrite over that data.
for upward compatability reasons, etc etc

my test picture program loaded 1120 tiles to make up a full 320x224 screen too. it did this by writing tiles starting at 128, not 256

[Fonzie]

Yeah, 1120+256 tiles = (1120+256)*8*4= 0xAC00
and A800 is hscroll (so there is a overwrite).

These are my VDP registers with 1536 tiles free + 128 tiles free (optimal for what i need). I don't know if its possible for you to edit them but:
   uchar *pb,i;
   volatile ushort *pw;
   uint *pl;

   pl = (uint *) GFXCNTL;

   /*Set the vdp (Video(not visual lol) Display Processor)
*/
   pw = (ushort *) GFXCNTL;
   *pw = 0x8016;   /* reg. 00 - Enable HBL */
   *pw = 0x8174;   /* reg. 01 - Enable VBL */
   *pw = 0x8230;   /* reg. 02 - PlnA $30*$400=$C000 ok C000 - D000 */
   *pw = 0x8340;   /* reg. 03 - Win $40*$400=$10000 offset FFFFF - XXX */
   *pw = 0x8407;   /* reg. 04 - PlnB $7*$2000=$E000 ok E000 - F000 */
   *pw = 0x856A;   /* reg. 05 - Sprt $6A*$200=$D400 ok D400 - E000 */
   *pw = 0x8600;   /* reg. 06 */
   *pw = 0x8700;   /* reg. 07 - BGc */
   *pw = 0x8801;   /* reg. 08 */
   *pw = 0x8901;   /* reg. 09 */
   *pw = 0x8a01;   /* reg. 10 */
   *pw = 0x8b00;   /* reg. 11 - Full screen-vscroll and screen h-scroll precision */
   *pw = 0x8c89;   /* reg. 12 - Screen width set to 320 */
   *pw = 0x8d34;   /* reg. 13 - Hscrlt $34*400=$D000 ok D000 - D400 */
   *pw = 0x8E00;   /* reg. 14 */
   *pw = 0x8f02;    /* reg. 15 */
   *pw = 0x9001;   /* reg. 16 - Planes set to 512*256 */
   *pw = 0x9100;   /* reg. 17 */
   *pw = 0x9200;   /* reg. 18 */
   *pw = 0x9300;   /* reg. 19 */
   *pw = 0x9400;   /* reg. 20 */
   *pw = 0x9500;   /* reg. 21 */
   *pw = 0x9600;   /* reg. 22 */

[oompa loompa]

you could probably squeeze in a few more bytes by not using the window plane and writing tiles to there. in basiegaxorz you can't currently do this. maybe later i'll try to make it so the user can modify the addresses while still being able to use the disaply functions