Graphics 9 one color clock scroll

[Divya16]

Has anyone managed to use a scroll register to scroll one color clock in Graphics 9 mode? I know you can use Graphics 10 to get the one color clock shift and mix the modes but there are 8 less shades in that mode. I tried to scroll by one color clock but the colors just go bonkers.

 

If this topic was already discussed, let me know URL to the topic.

[Rybags]

It can't be done. And, you're stuck with the one CC shift in Gr. 10.

 

My theory on the difference in Gr. 10 is that it's a delay due to GTIA having to do a palette lookup (change colours mid scan-line and you get the same "delay" in other graphics modes).

 

GTIA renders it's extra modes by combining successive pairs of AN0-AN1 bus data on two half-cycles. Scrolling only has the effect of delaying the arrival of data, so causing either full pixel shifts or skewing the data such that a pixel uses the bottom half of one piece of data followed by the top of the next piece.

 

e.g. you have a screen with pixels set to 0101 1010 1111 0000 - with HSCROL value 1 that would change onscreen to 0001 0110 1011 1100

 

Gr. 10 is also different in that there are only 9 colours available - values from 1001 thru 1111 just reuse earlier combinations.

[atariksi]

It can't be done. And, you're stuck with the one CC shift in Gr. 10.

 

My theory on the difference in Gr. 10 is that it's a delay due to GTIA having to do a palette lookup (change colours mid scan-line and you get the same "delay" in other graphics modes).

 

GTIA renders it's extra modes by combining successive pairs of AN0-AN1 bus data on two half-cycles. Scrolling only has the effect of delaying the arrival of data, so causing either full pixel shifts or skewing the data such that a pixel uses the bottom half of one piece of data followed by the top of the next piece.

 

e.g. you have a screen with pixels set to 0101 1010 1111 0000 - with HSCROL value 1 that would change onscreen to 0001 0110 1011 1100

 

Gr. 10 is also different in that there are only 9 colours available - values from 1001 thru 1111 just reuse earlier combinations.

 

You mean change the color register like 53274 mid-screen and it causes a delay by one color clock in Graphics 9 and if you change a GTIA mode in register 53275 (say from 64 to 192), it won't cause that same delay?

[Rybags]

I was taking a guess at why Gr. 10 pixels are shifted to the right, relative to other modes.

 

With changing GPRIOR ($D01B) mid-scanline, the effects are already known.

 

You can start with normal graphics, then change to a GTIA mode (as a few programs and demos already do). The pixels of the GTIA mode will be positioned with the shifting as per normal.

e.g. interleave GR. 11 and GR. 10 on a horizontally windowed screen - you'll have a comb-like effect where the pixels are alternately shifted or not.

 

But, if you change from a GTIA mode to anything else, you don't get what you want. You end up in a GR. 15 -like mode except PF0-PF3 controls the colours.

[Bryan]

I was taking a guess at why Gr. 10 pixels are shifted to the right, relative to other modes.

 

With changing GPRIOR ($D01B) mid-scanline, the effects are already known.

 

You can start with normal graphics, then change to a GTIA mode (as a few programs and demos already do). The pixels of the GTIA mode will be positioned with the shifting as per normal.

e.g. interleave GR. 11 and GR. 10 on a horizontally windowed screen - you'll have a comb-like effect where the pixels are alternately shifted or not.

 

But, if you change from a GTIA mode to anything else, you don't get what you want. You end up in a GR. 15 -like mode except PF0-PF3 controls the colours.

It's actually a timing bug that wasn't caught or wasn't worth fixing.

 

I was using a machine once where the GTIA's would show the Gr.10 pixels with the proper alignment if I went out of Gr.10 and back in during the HBLANK, so I wrote a graphics demo to utilize that effect but it didn't work on any other machines. Then I noticed it worked on some machines if I heated the chip. GTIA simply has some on-the-edge timing that led to this bug.

 

-Bry

[atariksi]

I was taking a guess at why Gr. 10 pixels are shifted to the right, relative to other modes.

 

With changing GPRIOR ($D01B) mid-scanline, the effects are already known.

 

You can start with normal graphics, then change to a GTIA mode (as a few programs and demos already do). The pixels of the GTIA mode will be positioned with the shifting as per normal.

e.g. interleave GR. 11 and GR. 10 on a horizontally windowed screen - you'll have a comb-like effect where the pixels are alternately shifted or not.

 

But, if you change from a GTIA mode to anything else, you don't get what you want. You end up in a GR. 15 -like mode except PF0-PF3 controls the colours.

It's actually a timing bug that wasn't caught or wasn't worth fixing.

 

I was using a machine once where the GTIA's would show the Gr.10 pixels with the proper alignment if I went out of Gr.10 and back in during the HBLANK, so I wrote a graphics demo to utilize that effect but it didn't work on any other machines. Then I noticed it worked on some machines if I heated the chip. GTIA simply has some on-the-edge timing that led to this bug.

 

-Bry

 

Perhaps who has the capability can remake the GTIA chip so it's consistently off by 1 color clock in graphics 10 since it's a nice feature to have and put in a Half-bright mode in Graphics 10 so that the colors 8..15 are half-bright of 0..7 so the extra values are not going to waste and the 4th luminance bit gets used as it does in Graphics 9. Similar to half-bright mode on the Amiga's upgraded Agnus chip (which was also added later on as a chip upgrade).

[atariksi]

I was taking a guess at why Gr. 10 pixels are shifted to the right, relative to other modes.

 

With changing GPRIOR ($D01B) mid-scanline, the effects are already known.

 

You can start with normal graphics, then change to a GTIA mode (as a few programs and demos already do). The pixels of the GTIA mode will be positioned with the shifting as per normal.

e.g. interleave GR. 11 and GR. 10 on a horizontally windowed screen - you'll have a comb-like effect where the pixels are alternately shifted or not.

 

But, if you change from a GTIA mode to anything else, you don't get what you want. You end up in a GR. 15 -like mode except PF0-PF3 controls the colours.

It's actually a timing bug that wasn't caught or wasn't worth fixing.

 

I was using a machine once where the GTIA's would show the Gr.10 pixels with the proper alignment if I went out of Gr.10 and back in during the HBLANK, so I wrote a graphics demo to utilize that effect but it didn't work on any other machines. Then I noticed it worked on some machines if I heated the chip. GTIA simply has some on-the-edge timing that led to this bug.

 

-Bry

 

Perhaps one who has the capability can remake the GTIA chip so it's consistently off by 1 color clock in graphics 10 since it's a nice feature to have and put in a Half-bright mode in Graphics 10 so that the colors 8..15 are half-bright of 0..7 so the extra values are not going to waste and the 4th luminance bit gets used as it does in Graphics 9. Similar to half-bright mode on the Amiga's upgraded Agnus chip (which was also added later on as a chip upgrade).

[Rybags]

Half-bright would have been a good idea in the first place. Too bad they didn't think of it at the time.

[Heaven/TQA]

ehm...maybe i am wrong but could'nt be an 8-shade-pic scroller simply made by

 

- 1st frame mode9

- 2nd frame mode10 (same pic)

- 3rd frame mode9 shifted 1 colour clock (maybe by hand or maybe by hscrol?)

- 4th frame mode10 (same pic) shifted 1 colour clock (maybe by hand or maybe by hscrol?)

- 5th frame mode9 shifted by one byte...

 

? why not...

[Rybags]

That would work - only problem being that Gr. 10 screen data isn't really compatible with Gr. 9 data - odd lum values of course can't be duplicated. Pixel values 8, A, and C give background colour in mode 10.

 

Of course, the shift value would be 2 colour clocks between occurrences of the same mode - it's quite fine to scroll by that amount.

 

I checked my theory on colour change mid-line in Gr. 10 last night - if you change a colour register it happens on an exact pixel boundary.

[eru]

As a side note, the fact that Gr.10 is shifted differently than Gr.9 allows gfx modes like HIP/RIP/TIP.

Of course, it sux that we can't scroll Gr.9 by 2 hi-res pixels.

But then, it sux just as much we can't scroll Gr.15 by 1 hi-res pixel

[atariksi]

Half-bright would have been a good idea in the first place. Too bad they didn't think of it at the time.

 

So I guess no one who owns the IP saw the need to upgrade it down the road or had the capability of doing it. Some people may accept the upgrade even now.

[Rybags]

I don't see much point - a lot of effort for a limited feature upgrade which would only be owned by a few people.

 

Videoboard XE is such an enhancement, but if it properly gets off the ground could have a much bigger market due to the massive improvements it has on offer.

[atariksi]

ehm...maybe i am wrong but could'nt be an 8-shade-pic scroller simply made by

 

- 1st frame mode9

- 2nd frame mode10 (same pic)

- 3rd frame mode9 shifted 1 colour clock (maybe by hand or maybe by hscrol?)

- 4th frame mode10 (same pic) shifted 1 colour clock (maybe by hand or maybe by hscrol?)

- 5th frame mode9 shifted by one byte...

 

? why not...

 

If you only use the 8 even shades of Gr.9 that would work. I guess in 3rd and 4th frame, you mean 1 pixel not 1 color clock (otherwise you would not need Gr.10). But it seems Divya16 was looking for 16-shade scrolling screen at 1 color clock resolution scroll.

[atariksi]

I don't see much point - a lot of effort for a limited feature upgrade which would only be owned by a few people.

 

Videoboard XE is such an enhancement, but if it properly gets off the ground could have a much bigger market due to the massive improvements it has on offer.

 

I was thinking that a person familiar with the GTIA architecture would be quickly do the modification going from modulo colors to just shift right the color and allow 16-color paletted mode in Gr. 10. It would also be easier and more affordable to just replace GTIA chip like some did from CTIA to GTIA. I guess people working on bigger and more feature video boards can also do the GTIA modification so that some people can just get the GTIA chip that can't afford the board or don't need the board.

[eru]

- 1st frame mode9

- 2nd frame mode10 (same pic)

- 3rd frame mode9 shifted 1 colour clock (maybe by hand or maybe by hscrol?)

- 4th frame mode10 (same pic) shifted 1 colour clock (maybe by hand or maybe by hscrol?)

- 5th frame mode9 shifted by one byte...

This has been presented for 8-color scroll in Jac's VISDOM demo a long time ago. This gave a basis for HIP/RIP/TIP modes.

[Heaven/TQA]

Eru... ah... yes...you are right... wasn't aware of Visdom... need to have a look.

[eru]

Eru... ah... yes...you are right... wasn't aware of Visdom... need to have a look.

Sorry, I think it was first in HalleProject93 demo.. In JAC's Wiggle-Plasma part, if you wait long enough, you will see the precursor of HIP...

[Heaven/TQA]

yes. i remember the fx when you mentioned Jacomo...