Divya16 Posted January 21, 2008 Share Posted January 21, 2008 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. Quote Link to comment Share on other sites More sharing options...
Rybags Posted January 21, 2008 Share Posted January 21, 2008 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. Quote Link to comment Share on other sites More sharing options...
atariksi Posted January 22, 2008 Share Posted January 22, 2008 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? Quote Link to comment Share on other sites More sharing options...
Rybags Posted January 22, 2008 Share Posted January 22, 2008 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. Quote Link to comment Share on other sites More sharing options...
Bryan Posted January 22, 2008 Share Posted January 22, 2008 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 Quote Link to comment Share on other sites More sharing options...
atariksi Posted January 22, 2008 Share Posted January 22, 2008 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). Quote Link to comment Share on other sites More sharing options...
atariksi Posted January 22, 2008 Share Posted January 22, 2008 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). Quote Link to comment Share on other sites More sharing options...
Rybags Posted January 22, 2008 Share Posted January 22, 2008 Half-bright would have been a good idea in the first place. Too bad they didn't think of it at the time. Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted January 22, 2008 Share Posted January 22, 2008 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... Quote Link to comment Share on other sites More sharing options...
Rybags Posted January 22, 2008 Share Posted January 22, 2008 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. Quote Link to comment Share on other sites More sharing options...
eru Posted January 22, 2008 Share Posted January 22, 2008 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 Quote Link to comment Share on other sites More sharing options...
atariksi Posted January 23, 2008 Share Posted January 23, 2008 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. Quote Link to comment Share on other sites More sharing options...
Rybags Posted January 23, 2008 Share Posted January 23, 2008 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. Quote Link to comment Share on other sites More sharing options...
atariksi Posted January 24, 2008 Share Posted January 24, 2008 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. Quote Link to comment Share on other sites More sharing options...
atariksi Posted January 24, 2008 Share Posted January 24, 2008 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. Quote Link to comment Share on other sites More sharing options...
eru Posted January 24, 2008 Share Posted January 24, 2008 - 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. Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted January 24, 2008 Share Posted January 24, 2008 Eru... ah... yes...you are right... wasn't aware of Visdom... need to have a look. Quote Link to comment Share on other sites More sharing options...
eru Posted January 28, 2008 Share Posted January 28, 2008 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... Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted January 28, 2008 Share Posted January 28, 2008 yes. i remember the fx when you mentioned Jacomo... Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.