27 replies to this topic

[Schmutzpuppe]

Hi,

I attached a little prg. that shows 3 colors in 320b mode.
It works with prosystem and mess emulator (haven't tried emu7800 yet) on a real (pal) device I can only see 2 colors and I really don't know why.
There is no overlapping and "Kangaroo" is off.
With Kangaroo on I can see 3 colors.
Any idea?

Attached Files

•  320btest.zip   857bytes   136 downloads

[Bruce Tomlin]

Schmutzpuppe, on Sun Apr 24, 2005 6:21 PM, said:

I attached a little prg. that shows 3 colors in 320b mode.
It works with prosystem and mess emulator (haven't tried emu7800 yet) on a real (pal) device I can only see 2 colors and I really don't know why.
There is no overlapping and "Kangaroo" is off.
With Kangaroo on I can see 3 colors.

I don't remember why, but I turned on Kangaroo mode on when I used 320B. I guess that must have been why. Since I use Macs, I didn't even have an emulator which would do 320B at the time and had to use the real hardware. This could easily be a bug in the emulator (displaying 3 colors without Kangaroo mode) since 320B didn't work right at all back in the MESS 0.70 days.

[Schmutzpuppe]

Bruce Tomlin, on Sun Apr 24, 2005 7:23 PM, said:

Schmutzpuppe, on Sun Apr 24, 2005 6:21 PM, said:

I attached a little prg. that shows 3 colors in 320b mode.
It works with prosystem and mess emulator (haven't tried emu7800 yet) on a real (pal) device I can only see 2 colors and I really don't know why.
There is no overlapping and "Kangaroo" is off.
With Kangaroo on I can see 3 colors.

I don't remember why, but I turned on Kangaroo mode on when I used 320B. I guess that must have been why. Since I use Macs, I didn't even have an emulator which would do 320B at the time and had to use the real hardware. This could easily be a bug in the emulator (displaying 3 colors without Kangaroo mode) since 320B didn't work right at all back in the MESS 0.70 days.

I am sure that this is an emulator bug for me the question is why the 7800 doesn't display 3 colors. According to the Software guide 3 colors (from 1 palette) should be possible without kangaroo (or did it wrap something?).

[Eckhard Stolberg]

I haven't tried your demo, but depending on how your graphics look, this is normal in mode 320B. As the programmer's guide says, in mode 320B transparency doesn't work as expected when Kangaroo mode is turned on.

The two pixels that would make up one pixel in 160 pixel modes are seen as a unit here. Only if both of theses pixels are turned on, they will show their selected colours. If both are turned off, they will be transparent. But if one is on and the other is off, then both pixels will show the background colour.

When Kangaroo mode is turned on, then pixel colouring will work as normal. So if your graphics are designed in such a way that the third colour is only used for the pixels that are supposed to have a transparent pixel next to them, then they will not show in mode 320B with Kangaroo mode turned on.


Ciao, Eckhard Stolberg

[Schmutzpuppe]

Eckhard Stolberg, on Mon Apr 25, 2005 7:36 AM, said:

The two pixels that would make up one pixel in 160 pixel modes are seen as a unit here. Only if both of theses pixels are turned on, they will show their selected colours. If both are turned off, they will be transparent. But if one is on and the other is off, then both pixels will show the background colour.

Hm, maybe that's the problem, I have to think about it after work.
The picture itself is very simple as you can see here.

Thanks
Matthias

Attached Images

• 

[Schmutzpuppe]

I have to admit that I don't understand it.
The hex value of the red stripe you can see in the picture is $0f, white is $f0 and blue $ff.
Only $f0 and $ff are visible on real device.

Eckhard Stolberg, on Mon Apr 25, 2005 7:36 AM, said:

The two pixels that would make up one pixel in 160 pixel modes are seen as a unit here. Only if both of theses pixels are turned on, they will show their selected colours. If both are turned off, they will be transparent. But if one is on and the other is off, then both pixels will show the background colour.

Maybe I don't get it right but shouldn't $0f also be visible according the definition?

[Eckhard Stolberg]

Yes, all colours should be visible in this example. This can't be the problem then. Did you already try different colours, just to make sure that your red isn't simply too dark on your TV?

Also it might be good, if you could post your source code. That would make it easier to look for other potential proplems. Looking at the binary, it seems that you have your DLL set to select palette 1. The manual says that in mode 320B only the most significant palette bit is read, and that you therefore can only choose between palette 0 and palette 4. Maybe setting a different palette can cause problems on a real 7800. Maybe that's why colour 1 doesn't get displayed?


Ciao, Eckhard Stolberg

[Schmutzpuppe]

[quote name='Eckhard Stolberg]Yes' date=' all colours should be visible in this example. This can't be the problem then. Did you already try different colours, just to make sure that your red isn't simply too dark on your TV?[/quote']
Impossible because I also made a version that increment the concerning color every vb.

[quote name='Eckhard Stolberg]Also it might be good' date=' if you could post your source code. That would make it easier to look for other potential proplems.[/quote']
The code is very simple and doesn't do much, I can post it tonight.[/quote]

[quote name='Eckhard Stolberg]Looking at the binary' date=' it seems that you have your DLL set to select palette 1. The manual says that in mode 320B only the most significant palette bit is read, and that you therefore can only choose between palette 0 and palette 4. Maybe setting a different palette can cause problems on a real 7800. Maybe that's why colour 1 doesn't get displayed?[/quote']
Good Idea, I don't thought this could cause trouble but who knows...!?

Edited by Schmutzpuppe, Tue Apr 26, 2005 7:45 AM.

[Schmutzpuppe]

Ok, the palette (unfortunately) makes no difference
Beside Kangaroo I didn't managed to get more then 2 (4) colors on screen.
I modified the code so that you can see 8 sprite using p0-p7, the file is attached.
One "funny" thing I found out was that if you use an “inc” on a color register the color get black (0)!?
No emulator seems to handle that correct.

Attached Files

•  320btest_source.zip   1.66K   118 downloads

[Bruce Tomlin]

Schmutzpuppe, on Tue Apr 26, 2005 2:54 PM, said:

One "funny" thing I found out was that if you use an “inc” on a color register the color get black (0)!?

That's because the palette registers are read-only. If an emulator is making them readable, that is a bug.

[DanBoris]

Bruce Tomlin, on Tue Apr 26, 2005 9:00 PM, said:

That's because the palette registers are read-only.  If an emulator is making them readable, that is a bug.

I am assuming there is a typo in the comment, or am I missing something...

According to the 7800 Software Guide the palette registers are Read/Write, and this is how MESS emulates it. Are they really write-only?

Dan

[kenfused]

DanBoris, on Tue Apr 26, 2005 10:30 PM, said:

Bruce Tomlin, on Tue Apr 26, 2005 9:00 PM, said:

That's because the palette registers are read-only.  If an emulator is making them readable, that is a bug.

I am assuming there is a typo in the comment, or am I missing something...

According to the 7800 Software Guide the palette registers are Read/Write, and this is how MESS emulates it. Are they really write-only?

Dan

The 7800 Software guide says they are read/write but must be read with absolute,x addressing mode.

[Schmutzpuppe]

kenfused, on Tue Apr 26, 2005 9:58 PM, said:

DanBoris, on Tue Apr 26, 2005 10:30 PM, said:

Bruce Tomlin, on Tue Apr 26, 2005 9:00 PM, said:

That's because the palette registers are read-only.  If an emulator is making them readable, that is a bug.

I am assuming there is a typo in the comment, or am I missing something...

According to the 7800 Software Guide the palette registers are Read/Write, and this is how MESS emulates it. Are they really write-only?

Dan

The 7800 Software guide says they are read/write but must be read with absolute,x addressing mode.

Ah, you are right I remember reading that (but forgot about it).

[EricBall]

I've had a quick look at the code and I don't see anything weird. I haven't had a chance to give it a whirl on my CC2 though. A couple of thoughts:

The 320 modes are subject to color aliasing, artifacts & blending. Changes in luminance will be decoded by the TV as color shifts. (At one point I started to work out how to model this, but never finished it.) So you may not be able to see certain color changes.

Kangaroo mode causes color 0 to be background instead of transparent. However, in 320 modes transparency only works if both the even & odd half pixels are are zero.

Unfortunately, I can't understand how setting Kangaroo mode would impact non-overlapping sprites. Perhaps our understanding of 7800 graphics (which is almost entirely documentation based) is flawed.

[Eckhard Stolberg]

OK, I have a new theory:

Could you change your graphics in such a way that the two pixels in 320 mode, that make up one pixel in 160 mode, don't both have colour 1? I think the problem might be that mode 320B uses the same write mode as mode 160B.

In mode 160B the low nibble of the graphics data bytes selects the palettes for the pixels, while the high nibble selects the individual colours in those palettes. So if bits D7 and D6 are both zero, the left pixel will be transparent. And if bits D5 and D4 are both zero, the right pixel will be transparent.

In your demo the graphic bytes, that contain the colour 1 pixels, have bits D7, D6, D5 and D4 all be zero. So if mode 320B uses the same write mode as mode 160B, it might be possible that your colour 1 pixels all are transparent, because they would be, if you used the same graphics data in mode 160B.

Could that be possible?


Ciao, Eckhard Stolberg

[Schmutzpuppe]

Eckhard Stolberg, on Wed Apr 27, 2005 1:45 PM, said:

OK, I have a new theory:

Could you change your graphics in such a way that the two pixels in 320 mode, that make up one pixel in 160 mode, don't both have colour 1? I think the problem might be that mode 320B uses the same write mode as mode 160B.

In mode 160B the low nibble of the graphics data bytes selects the palettes for the pixels, while the high nibble selects the individual colours in those palettes. So if bits D7 and D6 are both zero, the left pixel will be transparent. And if bits D5 and D4 are both zero, the right pixel will be transparent.

In your demo the graphic bytes, that contain the colour 1 pixels, have bits D7, D6, D5 and D4 all be zero. So if mode 320B uses the same write mode as mode 160B, it might be possible that your colour 1 pixels all are transparent, because they would be, if you used the same graphics data in mode 160B.

Could that be possible?


Ciao, Eckhard Stolberg

I am not sure if I am get you right (maybe one caipirinha to much tonight) but I changed a bit in the high nibble of the c1 gfx data et voilà c1 becomes visible.
I will wait until tomorow trying to understand this but however guess you deserve a caipirinha.
Call me if you are in hamburg next time

[Bruce Tomlin]

Eckhard Stolberg, on Wed Apr 27, 2005 1:45 PM, said:

In your demo the graphic bytes, that contain the colour 1 pixels, have bits D7, D6, D5 and D4 all be zero. So if mode 320B uses the same write mode as mode 160B, it might be possible that your colour 1 pixels all are transparent, because they would be, if you used the same graphics data in mode 160B.

It sure seems possible to me. This would be a sort of bug in 320B mode which is an artifact of how it relates to 160B mode. Kangaroo mode fixes it by turning off transparency. It's surely got something to do with half-pixel stuff, and if it's just D4-D7, then that's one bit from each 320B pixel.

[Schmutzpuppe]

Ok guys, another day another test.
Just came home read Eckhard's mail again and start some testing.
It looks as if he had the right theory about this issue.
Setting bit d7 or d6 make the left c1 pixel visible and d5/d4 the right one.
That's a pity if you ask me using the 320 modes are more limited than everyone would have expected I guess.
Anyway, maybe it's possible with clever color settings to mix c1 and c2/c3 pixel so that you still can use c1.
The 7800er picture in this mode is really a bit blurred so the pixel pattern wouldn't catch someone's eyes too much.
But things don't getting easier...
Thanks for your effort guys.

[Bruce Tomlin]

I guess the trick is to use color 1 as your third color so as to increase your chances that an adjacent pixel will be 2 or 3. Then you have to design your sprites so that the transparency is based on pairs of pixels. If a tool was being written to convert graphics for 320B mode, having it be able to warn about this would be useful.

Clearly the 7800 is hard to emulate in a bug-compatible way, both in this transparency problem and in the DMA cycle stealing. The good news is that this doesn't affect existing games because the emulators are more forgiving than the real hardware. The bugs only affect new programmers by tricking them into thinking they can do things that don't work on the real hardware.

Now the question I have is whether a similar "half pixel transparency" problem affects any other 320 modes.

[Schmutzpuppe]

Bruce Tomlin, on Fri Apr 29, 2005 8:33 AM, said:

I guess the trick is to use color 1 as your third color so as to increase your chances that an adjacent pixel will be 2 or 3.  Then you have to design your sprites so that the transparency is based on pairs of pixels.  If a tool was being written to convert graphics for 320B mode, having it be able to warn about this would be useful.

Had the same idea, I allready added this warnig function to my converter tool (it writes the x/y position of all invisible pixel to a textfile).

Bruce Tomlin, on Fri Apr 29, 2005 8:33 AM, said:

The bugs only affect new programmers by tricking them into thinking they can do things that don't work on the real hardware.

Right

Bruce Tomlin, on Fri Apr 29, 2005 8:33 AM, said:

Now the question I have is whether a similar "half pixel transparency" problem affects any other 320 modes.

Good question, we will see...

[EricBall]

See http://www.atariage.com/forums/index.php?a...=blog&blogid=7&, where I've posted a test program. There definitely is something strange going on with 320B & 320D which Kangaroo Mode affects.

[Schmutzpuppe]

I haven't had a chance to check it out yet but I'll take a look at it during this week.
Anybody else took a look at the test programm on a real device?

[EricBall]

I have a CC2, although it's via a standard RF connection. Might be clearer with an A/V or S-Video connection.

[Allan]

Schmutzpuppe, on Sun May 8, 2005 6:27 PM, said:

I haven't had a chance to check it out yet but I'll take a look at it during this week.
Anybody else took a look at the test programm on a real device?

I tried the first program on a real 7800 with s-video and all I see are two colors. I tried the second program and all I see is a black screen. I used 8K .BNK file. I'm not sure if that was the problem but since the screen didn't roll at all I think it might just be your program. What is the second program suppose to show?

Allan

[Schmutzpuppe]

Allan, on Mon May 9, 2005 5:15 AM, said:

Schmutzpuppe, on Sun May 8, 2005 6:27 PM, said:

I haven't had a chance to check it out yet but I'll take a look at it during this week.
Anybody else took a look at the test programm on a real device?

I tried the first program on a real 7800 with s-video and all I see are two colors. I tried the second program and all I see is a black screen. I used 8K .BNK file. I'm not sure if that was the problem but since the screen didn't roll at all I think it might just be your program. What is the second program suppose to show?

Allan

I meant the test program from Eric
The problem that I want to demonstrate with my little "demo" was solved by Eckhard but Eric's prg. seems to display more riddles about the 320 mode.