GR.10 and Priors

[José Pereira]

In this mode if we set prior0 woudn't I get oring if p0 and p1 overlap pf0 and pf1 but also p2 and p3 overlap pf2 and pf3?

 

And if we enable 5th player 4missiles they over any of the 9colour registers? And it takes the normal as usual pf3 colour and no oring/interaction with the 4players?

[José Pereira]

G2F only supports what Tebe call prior1 and it seems that all players always go over all colour registers.

[José Pereira]

Please try to paint simple 9colours=9colour registers gr10 on g2f.

Then run it on real machines or emulators. Try different possibilities and see the mess you get on emulators.

Is it emulators or is it g2f? G2F seems to display like it was supposed. Is gr.10 working good in emulators?

 

On g2f by now other priors apart also missing pmg multicolour.

 

 

Please help.

Tebe are you here?

 

Also where's a complete explanation about gr.10 with all possible priors, pmgs put over gfxs, pmgs can be in multicolour mode or not,...?

[José Pereira]

Start to discouver some things:

-> on g2f on 'edit colours':

pm0 it's indeed background register

pm1 it's pf0

pm2 it's pf1

pm3 it's pf2

pf0 it's pf3

pf1 it's pm0

pf2 it's pm1

pf3 it's pm2

background it's pm3.

 

 

If you this way all work fine, even multicolour pmgs.

But it still doesn't show right on emulators.

pf

[José Pereira]

I finally get it, just need some hours to write a complete and understandable explanation with the proofs and the corrections needed to be done on g2f.

I'll put them here and I'll send them to Tebe.

 

Emulators works fine and problems are in g2f:

-> on 'edit colours' it's wrong. To fix do exactly like I said on the previous message

-> when entering in 'zoom mode' the top cells with colours numbers doesn't show the colours but are in the correct sequence (like colour0 it's 704 and it's pm0 but also background register for the borders and all the next ones untill 711).

But you choose colour0/704 but paint background register colour(712), c2/705 paint pf0, c3/706 paint pf1, c4/707 paint pf2, c5/708 but paint pf3, c6/709 but paint pm0 and so on untill colour8 that instead of what it should be (711) paint as pm3

-> on 'edit bitmap' the 9 coloured cells show, from left to right, backgr,pf0->pf3,pm0->pm3 and it paint like this but indeed you're painting (and can only see that when you run the files on an emulator or a computer) that in reality you were painting pm0->pm3,pf0->pf3,backgr (real gr10 colour registers sequence)

- on 'edit pmgs' it works correct (including multicolour and enable 5th player) but on 'zoom mode' you can only build/erase pmgs in 4x1 ratio and not single pmgs if normal wide 2x1 ratio

-> g2f only supports priority1 when priority0 we would get more colours because of the different oring possibilities.

[José Pereira]

Hope you all understand this and someone with a better English can post here the explanations clearly explained.

[+Stephen]

Nice find and that's a detailed explanation. Bug reports like those are very helpful.

[phaeron]

Emulators works fine and problems are in g2f

 

...Almost.

 

From a priority standpoint, Gr. 10 gives you the same that you would get with just a regular playfield and players. Wherever you have player colors in the playfield, they're treated the same for priority as the players. This means that there are no surprises that are specific to Gr. 10.

 

Attached is a test program that checks all combinations of players, missiles, and playfields with priority 0, multicolor, and fifth player color enabled in Gr. 10. Altirra 2.1, Atari800WinPLus 4.0, and Atari800 2.2.0 appear to match the real Atari. Here you can see the P0+P1+PF0+PF1 and P2+P3+PF2+PF3/P5 blending:

 

 

Atari++ 1.60, unfortunately, has some errors in this mode. It is not blending the playfields with the players and is also allowing the fifth player to override the playfield when it is covered by players 0 or 1.

 

gr10prior0.zip

[José Pereira]

We also didn't have prior0 in hi-resolution and I sent a PM to Tebe and he answered me with a prior0 in just a few days.

I'll send him a message with all this today. Just need to finish some screens/tables with all explanations the simpliest way possible that I would also post in here.

[José Pereira]

I think this with even my 'always, always Bad English' self explain:

GR10 Bug g2f and xex Files.zip

Sent also to Tebe...

[Synthpopalooza]

...Almost.

 

From a priority standpoint, Gr. 10 gives you the same that you would get with just a regular playfield and players. Wherever you have player colors in the playfield, they're treated the same for priority as the players. This means that there are no surprises that are specific to Gr. 10.

 

Attached is a test program that checks all combinations of players, missiles, and playfields with priority 0, multicolor, and fifth player color enabled in Gr. 10. Altirra 2.1, Atari800WinPLus 4.0, and Atari800 2.2.0 appear to match the real Atari. Here you can see the P0+P1+PF0+PF1 and P2+P3+PF2+PF3/P5 blending:

 

 

Atari++ 1.60, unfortunately, has some errors in this mode. It is not blending the playfields with the players and is also allowing the fifth player to override the playfield when it is covered by players 0 or 1.

 

 

I wonder if it's related to a bug I found once ... it had to do with when you use color pattern #1000 with the GTIA enabled to mode 10 while using an Antic lo-res mode (Antic 4/5, Antic 6/7 or Antic E) ... on a real Atari this produces COLBAK (712) but in most emulators this incorrectly returns PF0 (708) ... I noticed this bug in about every emulator, although this did get fixed with Altirra 2.0

Edited September 26, 2012 by Synthpopalooza

[phaeron]

It's what you get when you say, "I'll take obscure Atari Hardware Quirks for $400, Alex." None of this stuff is documented in Atari's official documentation or even largely elsewhere, and you'd only know about it by either exhaustive testing of the real hardware or by squinting at the low-quality scans of the GTIA schematics that are floating around. Even the 6502, which has been scrutinized so far that it has been decapped and simulated at netlist level, is still causing problems because we're now uncovering strange behavior related to analog effects on the chip. What's amusing is that (1) emulators have gotten to 99.99% compatibility with existing software without these quirks and (2) we are still managing to find or inadvertently write new stuff that does trip up on it.

[+JAC!]

>these quirks and (2) we are still managing to find or inadvertently write new stuff that does trip up on it.

I'm currently writing something with also includes GR.10 & players - will test on real iron this weekend to see if it falls into this category :-)

Edited September 27, 2012 by JAC!

[José Pereira]

Hi.

As I've been and will be without computer, just Mobile for the next days, anyone tried the new version of G2F to see if Gr.10 bugs were fixed?

Thanks.

Jose Pereira.

Edited November 2, 2012 by José Pereira

[thorfdbg]

Atari++ 1.60, unfortunately, has some errors in this mode. It is not blending the playfields with the players and is also allowing the fifth player to override the playfield when it is covered by players 0 or 1.

 

Thanks for digging this up - sorry that I haven't had the time to look into this earlier, but it is fixed now (hopefully with all the undocumented modes where priority conflicts generate black).Greetings and Merry Christmas!Thomas

[thorfdbg]

I wonder if it's related to a bug I found once ... it had to do with when you use color pattern #1000 with the GTIA enabled to mode 10 while using an Antic lo-res mode (Antic 4/5, Antic 6/7 or Antic E) ... on a real Atari this produces COLBAK (712) but in most emulators this incorrectly returns PF0 (708) ... I noticed this bug in about every emulator, although this did get fixed with Altirra 2.0

 

Sorry, could you please be more specific?Thanks,Thomas

[Synthpopalooza]

Well, try this from BASIC to see what I mean:

 

GRAPHICS 15:POKE 623,128:POKE 87,10:POKE 712,14:COLOR 8:PLOT 0,0:DRAWTO 159,0

 

On a real Atari and Altirra 2.0 this produces a white line. On other emulators this is wrongly interpreted as PF0 and produces an orange line. There was a technical explanation for why the color settings are different with Graphics 10 as opposed to 9 or 11, but it escapes me at the moment.

 

More info is in this thread: http://www.atariage....-vs-real-atari/

Edited December 25, 2012 by Synthpopalooza

[thorfdbg]

Well, try this from BASIC to see what I mean:

 

GRAPHICS 15:POKE 623,128:POKE 87,10:POKE 712,14:COLOR 8:PLOT 0,0:DRAWTO 159,0

 

On a real Atari and Altirra 2.0 this produces a white line. On other emulators this is wrongly interpreted as PF0 and produces an orange line. There was a technical explanation for why the color settings are different with Graphics 10 as opposed to 9 or 11, but it escapes me at the moment.

 

And fixed!

Merry Christmas.