Jump to content
IGNORED

mode f finescroll


twh/f2

Recommended Posts

hey *,

 

in mode F when I do this for a hscrol-enabled antic line:

 

lda #$f
sta hscrol

and in the next frame

 

lda #$e
sta hscrol

 

it seems that the antic fine-scrolls two gr.8 pixels instead of one. Or am I missing something? what's the meaning of a "1/2 Farbtakt" (geman guys? Farbtakt= color cycle?) for mode F?

 

Can I get it somehow smooth? I mean it works smooth for gr.0 on text mode?!

 

grtx,

\twh::taos

Link to comment
Share on other sites

no... hscroll does scroll per one colour clock... so in gr.8 (and gr.0) 1 pixel is 1/2 colour clock... so you can only scroll by 2 pixel. that's again one difference to C64 f.e.

 

so...if you want to scroll 1 pixel...you must do the hardway and do it by yourself by shifting bits.

 

and gr.0 might fool you as the font is using 2 pixels... ;)

Link to comment
Share on other sites

heaven,

 

thanks for your comments.

 

and gr.0 might fool you as the font is using 2 pixels... ;)

 

But I don't understand this part. Why is gr.0 font using 2px? It has 8 pixels per character...

 

or do you mean, that also gr.0 is scrolling 2px per "dec hscrol"?

 

doing it the "hard way" would basically mean to left-shift a 40 bytes array bit by bit... mhm. sounds like a lot of work for the 6502 :(

 

grtx,

\twh

Link to comment
Share on other sites

"The font uses 2 pixels"

 

Most 8-bit computers have characters with the vertical lines at least 2 pixels wide. It looks better and ensures you don't get chroma artifacting (as you do if you draw single pixel width lines).

 

"Doing it the hard way" - scrolling by rotating character set data. Costly in CPU time since you have to manipulate a whole heap of data to get the single pixel movement.

 

But, you can fine-scroll single pixel width a slightly easier way. Have a second character set with all the characters shifted a single pixel left. Then, you just have HSCROL=15, std charset; HSCROL=15, shifted charset; HSCROL=14,std charset; HSCROL=14, shifted charset; etc...

 

Of course, that means you can't have most of the special graphics characters since they use all 8x8 of the grid, but most alpha characters fit in a 6x6 matrix.

Edited by Rybags
Link to comment
Share on other sites

twh...i ment with 2 pixels that the standard atari font is using nearly 100% always 2 pixel beneath... check it by your own... and in gr.0 you might not realise that when doing soft scrolling... but compare a "gr.0"-scroller on C64 and on A8... the A8 one should be 100% faster even both use 50hz scrolling.

Link to comment
Share on other sites

ok thanks guys!

 

again something learned... :)

 

rybags,

 

the second-font trick is very nice, but I'm afraid it does not help me in mode F :-) but it would be cool to see an actual 1px gr.0 scroller. When I find some spare time I would like to compare it...

 

good night

\twh

Link to comment
Share on other sites

I did a single-pixel H-Scroll in the NYE demo I whipped up a month ago.

 

It works the "long and painful" way - also it's aligned horizontally with static graphics, so HSCROL wasn't an option.

 

What is it that you want to scroll? If it's only a small screen area, then rotating the data around is a definate option. You probably wouldn't bother if it was > 1,000 bytes or so worth, since it would be too slow.

Link to comment
Share on other sites

no... hscroll does scroll per one colour clock... so in gr.8 (and gr.0) 1 pixel is 1/2 colour clock... so you can only scroll by 2 pixel. that's again one difference to C64 f.e.

Gnah this will never end in the Atari scene. On PAL Ataris 1 color clock = 2.5 hires pixels, NOT exactly 2 like on NTSC. So it's wrong to count in "color clocks" when talking about the scroll register.

Link to comment
Share on other sites

no... hscroll does scroll per one colour clock... so in gr.8 (and gr.0) 1 pixel is 1/2 colour clock... so you can only scroll by 2 pixel. that's again one difference to C64 f.e.

Gnah this will never end in the Atari scene. On PAL Ataris 1 color clock = 2.5 hires pixels, NOT exactly 2 like on NTSC. So it's wrong to count in "color clocks" when talking about the scroll register.

 

 

Can you tell me more about this? I'm not technician guy and maybe I wrongly understand to some technical words. I thought that hi-res graphics have only one color in two lumas beacuse the pixel is only half of "color clock" and thus cant get whole new color information, only luma change. Doesn't it mean that in 160 pixel wide graphics mode the "color clock" is then 1.25x (if 2.5x in 320) gr. pixel so again it should not be possible to completly change color of next pixel, but of course it's not that case as you can "freely" change pixel colors in these modes? I'm just curious...

Edited by MaPa
Link to comment
Share on other sites

Gnah this will never end in the Atari scene. On PAL Ataris 1 color clock = 2.5 hires pixels, NOT exactly 2 like on NTSC. So it's wrong to count in "color clocks" when talking about the scroll register.

 

Can you tell me more about this? I'm not technician guy and maybe I wrongly understand to some technical words. I thought that hi-res graphics have only one color in two lumas beacuse the pixel is only half of "color clock" and thus cant get whole new color information, only luma change.

On NTSC the color carrier has 3.58 MHz and the pixel clock is exactly twice of that (7.16 MHz). So on NTSC two hires pixels are exactly one color clock period which makes it possible to do color artefacting.

 

On PAL it's a bit different. The color carrier is 4.43 MHz while the pixel clock is 7.09 MHz which means that one color clock period is 1.6 hires pixels long (ok my 2.5 was wrong too :D ). This means that color artefacting does not work and only produces an ugly looking "color wave pattern" instead of a solid new color.

 

Doesn't it mean that in 160 pixel wide graphics mode the "color clock" is then 1.25x (if 2.5x in 320) gr. pixel so again it should not be possible to completly change color of next pixel, but of course it's not that case as you can "freely" change pixel colors in these modes? I'm just curious...

Completely changing the color from one pixel to another isn't possible anyway. Depending on the decoding circuitry, it can take easily 4-6 hires pixels to fully switch from one color to another. This only applies to the chroma signal, luma changes are much quicker.

Link to comment
Share on other sites

And, isn't NTSC actually closer to 227.5 of Atari's "colour clocks" ?

A8 NTSC:

 

color clock = 3.58 MHz

system clock = color clock / 2 = 1.79 MHz

pixel clock = system clock * 4 = 7.16 MHz

 

A8 PAL:

 

color clock = 4.43 MHz

system clock = color clock * 2 / 5 = 1.77 MHz

pixel clock = system clock * 4 = 7.09 MHz

 

So on NTSC two hires pixels = one color clock period while on PAL two hires pixels = 1.25 color clock periods.

Link to comment
Share on other sites

Right, it was called "Laser Demo", not "Lasermania Demo". I remembered that scroll, because, after I saw it, I was able to reproduce the effect using just the same method Rybaqs mentioned, i.e. with two fonts shifted one bit off one to another.

Edited by drac030
Link to comment
Share on other sites

Right, it was called "Laser Demo", not "Lasermania Demo". I remembered that scroll, because, after I saw it, I was able to reproduce the effect using just the same method Rybaqs mentioned, i.e. with two fonts shifted one bit off one to another.

 

yes. this is really good stuff. i just posted some comments at http://www.pouet.net/prod.php?which=10104

 

funny. I never really noticed that nice little aspect about atari finescrolling. That's so typical for the tech-people. I mean once you know about the technical limitations and still see it working somehow, you are shocked / impressed and say "How did that guy code this?!"

 

and that way one old demo is still something where people are speaking about 19 years later...

 

grtx,

\twh::taos

Link to comment
Share on other sites

ah true. I now understand how he did it... he repeated the larger portions (like the "complex stars gfx") and spread around the small pixel stars. mhm smart !! *g

 

grtx,

\twh

 

twh... read my comment at pouet... ;) it's only the upper part covered with PMGs... so not the whole screen and the stars can easily spread via DLIs... ;)
Link to comment
Share on other sites

Like a lot of demos, it seems to use cunning tricks to create the illusion that something more is happening. Like magic I guess. :)

 

The main spot is that those"cunning tricks" are only the correct/clever usage of the given hardware abilities of the machine, that have been discovered.

 

 

Well, I didn't know that demo, but we created something similar...(nazgul02)

 

http://www.atariage.com/forums/index.php?s...st&p=518779

 

A hires scroll over a G2F picture ;-)

 

 

People always say.... using this mode or this mode.... charset or graphics.... etc...

 

Actually.... "Graphics modes" are a definition by the implemented Basic. Antic has lines to handle... not Graphics modes.

So, with a absolutely clever software design we may have some hires/colour mode game with 256 colours on screen... and no one detects the limits of the A8.

Lucasfilm Games did already a very good Job with Koronis Rift. But the Hardware usage was "obvious" and not really highly achieved.

Link to comment
Share on other sites

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...