Did you have problem on real console?

[youki]

Hi,

 

Do you already have some "surprise" when you try your game on a real console instead of an emulator?

 

I tried my game (under developpment) on a real console (thanks to the 128 in 1 Flash multicart cartrige of AtariMax). And the result is very strange... seems there is some sprite problems... in certan case they are duplicated, in other showed partially when they move at a certain position on screen (even if they are alone on the row) , and sometimes i have a little part of the sprite elsewhere....

 

Of course under the emulators, none of these problems occurs.

 

I suspected my console to have a problem... but if i try othe games (like donkey kong, popeye, gyruss ) i don't have these kind of effects.

 

Tomorrow, i will try on another console, juste to be sure it is not the console.

 

I develop with the SDCC kit from NewColeco. Daniel did you already try project done with sdcc kit on real console?

 

Thanks

Edited April 30, 2009 by youki

[Nukey Shay]

Welcome to the wonderful world of bugtesting. Emulators only get you so far before a program must be tested on the real deal (emulation is not perfect).

[youki]

Welcome to the wonderful world of bugtesting. Emulators only get you so far before a program must be tested on the real deal (emulation is not perfect).

 

I don't think i'm doing tricky things or pushing the hardware. That's my first coleco project , so what i'm doing is more or less "standard". , i guess. I would expect a better behavior.

 

But as i said, it could be a problem with the console. I will try on another one tomorrow.

[gdement]

I don't know anything about the CV, but are you sure there aren't any initialization steps that you've missed? Emulators are likely to be more forgiving about that stuff. For example, any registers in the graphics chip that need to be set, etc?

[PkK]

Hi,

 

Do you already have some "surprise" when you try your game on a real console instead of an emulator?

 

I often encountered such problems when I started programming. With time and experience they became less and less common. Now they are very rare.

 

Philipp

[PkK]

seems there is some sprite problems... in certan case they are duplicated, in other showed partially when they move at a certain position on screen (even if they are alone on the row) , and sometimes i have a little part of the sprite elsewhere....

 

This sound like you're using thegraphic's chip's undocumented bitmask functionality of the color and pattern tables. It has such a side effect on sprites, which emulators don't show.

 

Here's the description I posted to the colecoprogramming mailing list when I encountered it in 2006:

I have a strange problem with sprites:

I tested on two CBS Colecovisions, the symptoms are slightly different,

but it seems to be the same problem:

All sprites with entries > n in the sprite attribute table are affected

 

On the first ColecoVision n varies from 7 to 10. An affected sprite will

not display when in the lower third of the screen.

When in the upper third of the screen it will display both in the upper

third and in the lower third of the screen (that is it's visible twice:

where it should be and 2/3 of the screen height lower).

 

On the second ColecoVision n seems to be fixed at 7. An affected sprite

will not display when in the middle or lower third of the screen.

When in the upper third of the screen it will display where it should

be, in the lower third of the screen and in the middle third in the

screen (that is it's visible at three places: where it should be, 1/3

below and 2/3 below).

 

Has anyone else seens this problem? It is perfectly reproduceable (I

only tested using my game "Search for the Stolen Crown Jewels") except

for the varying n on the first ColecoVision (which causes flickering of

sprites at numbers 7 to 10).

 

Of course in the emulators everything works perfectly.

Philipp

 

And this after having a closer look:

As we know there are some undocumented features in the TMS9918.

Two of them are well known: The undocumented screen modes and the effect

on characters of the lower bits of registers 3 and 4 in bitmap mode.

By accident I found out a bit more: the lower bits of registers 3 and 4

seem to affect the sprites, too!

I have not done a careful investigation, but it seems that you can make

the sprites show multiple times on screen.

I had acidentally reset the second most significant bit of register 4.

All sprites except the first 8 ones where shown twice when in the upper

third of the screen: At their normal position and two thirds below.

Googling I saw that someone had already noticed this on the MSX-1, which

uses the TMS9918, too:

http://www.msx.org/forumtopic5579.html

I have not seen this undocumented bahaviour implemented in any emulator.

 

For me the most important effect is that I can now finally fix the last

bug in "Search for the stolen Crown Jewels"!

 

Philipp

[youki]

Hi PkK,

 

Thanks for your answer. Effectivly i think you found the problem here.

It seems i have the same behavior as described.

 

I 'm using SDCC kit from Daniel so i do not manipulate directly register , for now, i'm just using provided API. So may be there is a "bug" in the API or somewhere in the way i use it.

 

But now, i have a good track , thanks to you. I will dig into that issue and i hope find the issue.

 

Somebody knows if it exists an emulator that implement this behavior?

 

Thanks

 

 

seems there is some sprite problems... in certan case they are duplicated, in other showed partially when they move at a certain position on screen (even if they are alone on the row) , and sometimes i have a little part of the sprite elsewhere....

 

This sound like you're using thegraphic's chip's undocumented bitmask functionality of the color and pattern tables. It has such a side effect on sprites, which emulators don't show.

 

Here's the description I posted to the colecoprogramming mailing list when I encountered it in 2006:

I have a strange problem with sprites:

I tested on two CBS Colecovisions, the symptoms are slightly different,

but it seems to be the same problem:

All sprites with entries > n in the sprite attribute table are affected

 

On the first ColecoVision n varies from 7 to 10. An affected sprite will

not display when in the lower third of the screen.

When in the upper third of the screen it will display both in the upper

third and in the lower third of the screen (that is it's visible twice:

where it should be and 2/3 of the screen height lower).

 

On the second ColecoVision n seems to be fixed at 7. An affected sprite

will not display when in the middle or lower third of the screen.

When in the upper third of the screen it will display where it should

be, in the lower third of the screen and in the middle third in the

screen (that is it's visible at three places: where it should be, 1/3

below and 2/3 below).

 

Has anyone else seens this problem? It is perfectly reproduceable (I

only tested using my game "Search for the Stolen Crown Jewels") except

for the varying n on the first ColecoVision (which causes flickering of

sprites at numbers 7 to 10).

 

Of course in the emulators everything works perfectly.

Philipp

 

And this after having a closer look:

As we know there are some undocumented features in the TMS9918.

Two of them are well known: The undocumented screen modes and the effect

on characters of the lower bits of registers 3 and 4 in bitmap mode.

By accident I found out a bit more: the lower bits of registers 3 and 4

seem to affect the sprites, too!

I have not done a careful investigation, but it seems that you can make

the sprites show multiple times on screen.

I had acidentally reset the second most significant bit of register 4.

All sprites except the first 8 ones where shown twice when in the upper

third of the screen: At their normal position and two thirds below.

Googling I saw that someone had already noticed this on the MSX-1, which

uses the TMS9918, too:

http://www.msx.org/forumtopic5579.html

I have not seen this undocumented bahaviour implemented in any emulator.

 

For me the most important effect is that I can now finally fix the last

bug in "Search for the stolen Crown Jewels"!

 

Philipp

[newcoleco]

The first time I've heard of this problem of sprites duplication was from PKK using his own kit under SDCC when I was still using Hi-Tech C without a problem.

 

I assume that the simple fact of using another compiler cannot explain the phenomena, or can be? Porting to SDCC by changing a couple of pop and push instructions should not gives another result because it seems that the problem is only about the way of setting the video registers. At this point, I just want to say : "why I've never experimented this issue before with all my games during all these years?" The only sprites issue I did experiment was because I was trying to update them at a bad time making the sprites appearing randomly on screen... a situation solved by updating into the nmi() section.

 

I didn't try all the binaries I'm getting with the new kit, this is something I will do eventually. I was assuming they all work the same as if it was compiled with Hi-Tech C. Also, please note again that the new kit is still under development, still in beta version.

 

I've so much things to do with this kit and now my coleco web site will be down shortly... an happy 10 years celebration was my only wish for this year.

[newcoleco]

BlueMSX v2.7 is the only emulator that was trying to fake the sprites duplication issue. Unfortunately, it did that too well, and all my games running under it was getting the sprites duplication issue when we can clearly see them working normally with the real Coleco game system.

[youki]

BlueMSX v2.7 is the only emulator that was trying to fake the sprites duplication issue. Unfortunately, it did that too well, and all my games running under it was getting the sprites duplication issue when we can clearly see them working normally with the real Coleco game system.

 

I use BlueMSX v2.8 for my dev.

[youki]

The first time I've heard of this problem of sprites duplication was from PKK using his own kit under SDCC when I was still using Hi-Tech C without a problem.

 

I assume that the simple fact of using another compiler cannot explain the phenomena, or can be? Porting to SDCC by changing a couple of pop and push instructions should not gives another result because it seems that the problem is only about the way of setting the video registers. At this point, I just want to say : "why I've never experimented this issue before with all my games during all these years?" The only sprites issue I did experiment was because I was trying to update them at a bad time making the sprites appearing randomly on screen... a situation solved by updating into the nmi() section.

 

I didn't try all the binaries I'm getting with the new kit, this is something I will do eventually. I was assuming they all work the same as if it was compiled with Hi-Tech C. Also, please note again that the new kit is still under development, still in beta version.

 

I've so much things to do with this kit and now my coleco web site will be down shortly... an happy 10 years celebration was my only wish for this year.

 

No worries with the kit, i know it is under development. By using it , i test it! You did a really great job with it!. If i can find potential bug it is good to improve it.

 

May be a good test, would be that i recompile my game using Hi-Tech to see if there is difference...

 

Anyway i will keep you inform if i find something.

[youki]

So , some progress on that.

 

I tried on different (better) console , and the problems weres still the same.

 

I did various test.

 

And i discover that by replacing the code i used to update my sprite that was :

 

put_vram (0x1b00,sprites,....);

 

by

 

updatesprites(0,...);

 

Most of problems disapeared. Mainly 2 big problems :

 

One where some sprite was not totally drawn if its y coordonate was between a value range

and One where one line (and only one!!) of the sprite was drawn elsewhere on the screen....

 

So now on the 14 screens that my game has for now , 12 works correctly.

Therefore for the 2 last screens ,i still have the sprite duplication problem. But strangly not on all sprites.

 

I have 3 Bats flying in row , and depending of their y coordonnates sometimes i can see 9 Bats!

 

Curiously i use already that 3 sprites in another screen (but with a different pattern) and here no duplication.

 

I continue my test... i wonder if it not also related to the number of sprites on screen.

 

On the 1st screen where it does not work i have : 9 visibles sprites , and on the second : 12 visibles sprites.

 

All other screens where it works have less...

[youki]

I solved my problem!!

 

So as PKk (billions thanks to him) pointed to me , it was well the problem of sprite cloning.

 

The problem occurs with sprites above number 8.

 

The problem is linked with mode 2 initializations.

 

Reading MSX forums ,the sprite cloning occurs when bit 0 and 1 of VDR reg 4 are set both to 0.

 

My code was the following :

 

screen_mode_2_text();

disable_nmi();

rle2vram(PATTERNRLE,0x0000);

 

where the PATTERNRLE has been generated by daniel's tool : ICVGM303 .

 

Looking in the code of screen_mode_2_text , i saw that the code that initialize reg3 and reg4 is :

 

ld bc,#0x039F ; vdp_out(3,9fh)

call 0x1FD9

ld bc,#0x0400 ; vdp_out(4,0)

call 0x1FD9

 

So, the 2 first bit of reg 4 are set to 0 . The problem comes from here.

 

To solve my problem , after lot of experimenting and TMS 9918 documentation reading, i have simply replaced my code by that one :

 

screen_mode_2_text();

vdp_out(3,0x9f);

vdp_out(4,0x3);

disable_nmi();

rle2vram(PATTERNRLE,0x0000);

rle2vram(PATTERNRLE,0x0800);

rle2vram(PATTERNRLE,0x1000);

 

Doing that now it works! no more cloning!!

[newcoleco]

Please try this :

 

Replace screen_mode_2_text by screen_mode_2_bitmap, instead of changing the video control registers manually.

 

My bet is that you will get the same result... and if you don't use NAMERLE, do a cls() to clear up the screen.

[newcoleco]

Well, I'm taking a note about your solution and will certainly try it to fix this sprites issue in the library.

[youki]

Please try this :

 

Replace screen_mode_2_text by screen_mode_2_bitmap, instead of changing the video control registers manually.

 

My bet is that you will get the same result... and if you don't use NAMERLE, do a cls() to clear up the screen.

 

I have tested=> no sprite cloning in screen_mode_2_bitmap . Seems coherent as reg 4 is set to 3 in that mode too.

 

of course, i have to load 3 times the color table to make my game works as it was in screen_mode_2_text.

 

 

screen_mode_2_bitmap();

disable_nmi();

rle2vram(PATTERNRLE,0x0000);

rle2vram(PATTERNRLE,0x0800);

rle2vram(PATTERNRLE,0x1000);

rle2vram(COLORRLE,0x2000);

rle2vram(COLORRLE,0x2800);

rle2vram(COLORRLE,0x3000);

[newcoleco]

So, if I change the upload_patternrle (or whatever was the name of the function) to duplicate automatically the pattern data in vram and change the screen_mode_2_text to use the 3 charsets instead of only one, everything will be fine. Good to know!

[youki]

So, if I change the upload_patternrle (or whatever was the name of the function) to duplicate automatically the pattern data in vram and change the screen_mode_2_text to use the 3 charsets instead of only one, everything will be fine. Good to know!

 

Yes, i think!

[newcoleco]

So, if I change the upload_patternrle (or whatever was the name of the function) to duplicate automatically the pattern data in vram and change the screen_mode_2_text to use the 3 charsets instead of only one, everything will be fine. Good to know!

 

Yes, i think!

The solution add extra bytes because of duplicating the pattern... can be a problem to stay under 4K for minigames.

 

There is a problem with the default functions to upload the ascii charset to VRAM. The pattern is not duplicated automatically, so we need an extra step to duplicate the pattern which is not convenient for newbies. Adding a function that duplicate the top pattern in vram to the other two vram spaces should be nice, but making it safe to be used by anyone seems difficult. A strategy can be to save a portion of RAM to a supposed not used vram space and use this ram to act like a buffer and restore the ram data after the treatment. Another strategy is using the 32 bytes buffer I did setup in crtcv file to be used by a few graphic functions from the bios... but it's a very very tiny buffer.

[youki]

So, if I change the upload_patternrle (or whatever was the name of the function) to duplicate automatically the pattern data in vram and change the screen_mode_2_text to use the 3 charsets instead of only one, everything will be fine. Good to know!

 

Yes, i think!

The solution add extra bytes because of duplicating the pattern... can be a problem to stay under 4K for minigames.

 

There is a problem with the default functions to upload the ascii charset to VRAM. The pattern is not duplicated automatically, so we need an extra step to duplicate the pattern which is not convenient for newbies. Adding a function that duplicate the top pattern in vram to the other two vram spaces should be nice, but making it safe to be used by anyone seems difficult. A strategy can be to save a portion of RAM to a supposed not used vram space and use this ram to act like a buffer and restore the ram data after the treatment. Another strategy is using the 32 bytes buffer I did setup in crtcv file to be used by a few graphic functions from the bios... but it's a very very tiny buffer.

 

The other solution , could be to simply document to no use more than 8 sprites in screen_2_mode_text .

[newcoleco]

Well, the duplicating pattern function is done and seems to work, at least under emulation programs.

 

I don't understand why 8 sprites is the limit... why this glitch even exist... and why I'm torturing myself with questions I can't answer?

[GOTHCLAWZ]

Turn your ROM into RAM : )

[youki]

Well, the duplicating pattern function is done and seems to work, at least under emulation programs.

 

I don't understand why 8 sprites is the limit... why this glitch even exist... and why I'm torturing myself with questions I can't answer?

 

In fact the limit is not only 8 sprites , the real limit is to not use sprite above sprite number 8 . If you use only 8 sprites but starting from sprite number 9 , the problem occurs.

 

I think i read on a msx forums, that if the 8 first sprites are not affected by the problem , it is simply because due to some internal timing when the glitch occurs the first sprites are not yet displayed (the scan line is not in the visible area). So the problem exists for the 8 first sprite, but it is not visible.