Atari v Commodore

[atariksi]

Artifacting = Chroma Distortion (C-64 terminology).

 

Can happen with singlular width pixels/lines on both machines. It's described in the C-64 Tech manual as well as many Atari ones.

 

Author a DVD with a black background then put up a picture with similar sized lines - you'll be able to generate it there too I'd suspect.

 

Has absolutely nothing to do with the computer - it's a weakness of the way the TV standards work.

 

Is there a picture showing difference in artifacting between PAL/NTSC (same picture)?

[Crazyace]

PMBase and Blanking are not part of the sprite positioning logic - there is no 'start sprite at line Y1 and stop at line Y2' in hardware, so I still say the PM graphics are 1D.

There is no Z-axis - TV is only 2D ... the effect is purely horizontal scaling.

 

What do you mean by VBlanking method - you stated that you could multiplex more sprites horizontally - I tend to disagree, as the cycle counts dont really add up.

( Are you talking about flickering sprites by switching on different frames? )

 

Isn't VDELAY merely a 'disable' for loading grafp registers on odd lines. And how does PMBASE move a player in the Y direction... all it does is point to a different set of graphics.

I used VDELAY on the 2600 , as it's essential for the 6 digit score and other similar routines, but I never had a use for it myself on the 8 bit .. It would be interesting if there is some undocumented functionality.

[potatohead]

Artifacting = Chroma Distortion (C-64 terminology).

 

Can happen with singlular width pixels/lines on both machines. It's described in the C-64 Tech manual as well as many Atari ones.

 

Author a DVD with a black background then put up a picture with similar sized lines - you'll be able to generate it there too I'd suspect.

 

Has absolutely nothing to do with the computer - it's a weakness of the way the TV standards work.

 

hmm, but on the a8 its used to achive some kind of gfx effects ? what kinds? on the c64 it wasnt used to do this.

 

It was used to deliver NTSC colors through artifacting. That, combined with DLI's yields many colors not in the standard palette. It's a lot like the dazzle draw pictures posted above, but with different source color pixels to work with, and intensities too.

 

It's also been used to construct high resolution displays. 640x200x2colors, either character mapped or bit mapped @ 40 byte DMA. Sprites can be used to overlay for additional intensities. This required monochrome display, and could just be a simple B&W TV, or monochrome composite monitor. (I used the Apple ][ screen way back when to to do this)

 

Red / Blue pixels were exploited, alternating scan lines in a fashion similar to how NTSC color interlace is done today.

 

.0.. ---> One color

...0 ---> Other color Frame 0, even scanline

 

...0

.0.. --> Frame 1, odd scanline

 

GR 8 with background set to a low luma value, foreground set to a bright luma value, and something other than black used for the base color for the scanline. Red / Blue worked best as the chroma pixels were nicely separated.

 

An alternative that didn't just hammer the CPU with a lot of DLI's was to just do every other frame. So all even pixels, then all odd pixels on the other frame. No vertical staggering of colors. On the Apple high persistence display, this worked fine, and permitted character mapped displays to make sense. Just have char tables, then switch every other frame. When I did this, I didn't know half of what is known today. There are probably way better methods! (I had the COMPUTE! Atari books at the time, and they documented DLI for scanlines, and interrupts that occur during VBLANK, and that's what I used then.)

 

That whole exercise started with a friendly gaming and programming session. A friend had the Apple ][, with double high-res installed. We were tinkering with higher resolution displays and color, and that's when the idea struck. Apple just took advantage of the fact that it could just display any one of 4 pixels in the 160 pixel sized chroma area, and that artifacting generated lots of color.

 

The fixed color timing on the Atari means 160 pixel full color resolution. However, it also means the sub-pixel used to generate the chroma can be addressed by the programmer, yielding the high resolution display. Pixels interlaced horizontally, 30Hz, NTSC, odd / even scanlines. On the monochrome Apple ][ display, this looked great. The persistence of the phosphers made this work very well. On the B&W tv, interlace was visible. Had to be careful about what gets drawn to keep 30Hz out of viewers attention.

 

Display then consumed two ~8K display pages, depending on DMA used.

 

BTW: This same fixed color timing was present in the CoCo III, for example. It's graphics chip did deliver higher resolution, directly addressable pixels. Two color pixels per 160 pixel sized color clock. On ordinary color TV, that mode delivered very close to 160x192x256. Never did see any games exploiting this however... (I used to plot fractals with that display mode.)

 

There are some clear advantages to having the fixed color timing, as opposed to the C64 timing. That trade-off means better 320 pixel color resolution for the C64 which is a good thing, but also far fewer tricks to do with it, regarding color and display resolution. That may or may not be a good thing, depending on what is intended for the display.

Edited December 6, 2008 by potatohead

[Jetboot Jack]

TMR - regarding Action Biker - I think he is just twiddling sprites in use and priority settings to allow the infront/behind objects appearance - see around 1:40 on this

 

More info here on the C64 and iso...

 

sTeVE

Edited December 6, 2008 by Jetboot Jack

[potatohead]

Artifacting = Chroma Distortion (C-64 terminology).

 

Can happen with singlular width pixels/lines on both machines. It's described in the C-64 Tech manual as well as many Atari ones.

 

Author a DVD with a black background then put up a picture with similar sized lines - you'll be able to generate it there too I'd suspect.

 

Has absolutely nothing to do with the computer - it's a weakness of the way the TV standards work.

 

Is there a picture showing difference in artifacting between PAL/NTSC (same picture)?

 

I would love to see this also. Have been curious about it for years.

[Fröhn]

I calculated that the 256x192 hires bitmap mode on A8 means about 40% more CPU speed compared to C64.

 

I think for the frontmost stuff you could use sprites instead of CPU masking, for example the border graphics may be done that way. That might gain some CPU cycles.

40% have you calculated with the moon or else? It is clearly more.

 

a) DMA is not as time cosuming as you think with the atari, and player overlay cost nothing...

b) The CPU of the C64 is not as fast as you think... Particular when talking about Color RAM and Sprite re-using....

 

A8 cycles for 256x192 hires bitmap mode (no PMs enabled):

 

You have 114 CPU cycles per scanline, and 312 scanlines which gives a theoretic amount of 114*312 CPU cycles per frame.

 

Every rasterline the DRAM has to be refreshed: 9 cycles lost per rasterline. -9*312 cycles.

 

Every visible rasterline 32 bitmap bytes have to be fetched: -32*192 cycles.

 

Result: 26616 free CPU cycles/frame.

 

Effective CPU speed: 1.773 MHz * 26616/(114*312) = ~1.327 MHz

 

 

C64 cycles for 320x200 hires bitmap mode (no sprites enabled):

 

You have 63 cycles on a scanline and 312 scanlines: 63*312 theoretic CPU cycles.

 

Every 8 rasterlines in the display area 41 to 43 cycles are used for fetching color cell information: -43*25

 

No further cycles lost, DRAM refresh and bitmap bytes are fetched on the bus cycles reserved for the VIC.

 

63 per scanline * 312 scanlines - 43 color cell fetch cycles * 25 color cell lines = 18581 cycles / frame.

 

Given the 0.985 MHz clock of the CPU this results in an effective speed of ~0.9314 MHz

 

1.327/0.931 = 1.42 = 42% more speed

 

The 43 cycles per color cell fetch can be shortened to 42 or 41 if write cycles are on those first DMA startup cycles. This reduces the 42% a bit to maybe 41 or 40%, depends on the code.

 

 

No moon involved.

Edited December 6, 2008 by Fröhn

[Crazyace]

Was the 640x2 mode on the A8 NTSC - how well did it work, I never saw any real 80 col displays ( but I have to admit that 80col wasn't high on my list of priorities at the time )

[emkay]

No moon involved.

 

 

But you oversee a small fact. A started command that works inside the CPU can step ahead until the CPU has to write the result back to the RAM. This is caused by the external memory halt of ANTIC. It's depending on the used code, how much speed gets lost.

[emkay]

No further cycles lost, DRAM refresh and bitmap bytes are fetched on the bus cycles reserved for the VIC.

 

And what about the fetches when re-using sprites?

[potatohead]

I had an NTSC machine.

 

It worked very well, if you had a monochrome display. Your average color telly of the time didn't have the sheer pixel resolution to deal with it. Heck, most of them couldn't really even display the nice interlaced color we have today either. That's your smudged 70's color look. No interlaced color back then. Or at least it was not common. I began to see it in the late 80's with sets that had very much improved color resolution, over what I was using before.

 

At that time, I had a color TV, one older B&W tv, with great bandwidth, and an Apple monochrome screen hand down, a C64 and two A8 machines. One 400, which I still have, and later on, one 800 XL, which I don't. (bummer, gotta get one of those here soon)

 

On the color telly, with color turned down, it was a smudged mess. Not worth much. On the monochrome TV's, depending on the persistence of them, pixels were sharp and clear. There was some variation in overall pixel size, depending on the colors used to build the display. Red and blue delivered nice, small, sharp sub-pixels. On a lot of TVs today, you can clearly see them. Just fire up an Atari, enter any 4 color mode, and plot a few pixels and align them vertically. Specifiy the colors, and crank your sharpness and maybe kill your comb filters and such.

 

The little color pixels will be clearly seen, if the luma is bright.

 

I'll have to try this on the newer plasma TV. I've not hooked the Atari up yet. Wondering how the display gets through all the scaling hardware!

 

The graphics mode was memory hungry. I had a 48K machine at the time, so two ~8K pages was rough. I used it for plotting graphs and such. I wrote a little assembly dot plotter that would deal with the addressing, and did some high-res graphs of various things.

 

Char mode was too complex for me to make use of at the time, unless the simple alternative was used. Just every other frame, 30Hz style. That was ok. Two character sets, one containing even pixels, one containing odd, and you got 16 pixel by 8 pixel character mapped displays. Overlay the PM's for other intensities. Or, on a color telly, this could deliver a fair number of colors, but I suspect it wouldn't display well on PAL.

 

The whole thing might be a mess on PAL too. Doesn't the color phase alternate on every scan? If so, it would have to either be the full on ugly, set DLI's for every scan method, or nothing. ---Or maybe it would generate some interesting colors, not seen regularly. Don't know that much about PAL and artifacting!

 

Today, I'm using artifacting on NTSC displays, with the Atari color timing to get >400 color displays from a little micro that normally does about 80 colors. Looks sweet! And that's in my blog, FYI.

 

Always thought a great 80 column display would be nice to see, but I don't think it was possible in char mode because of all the char combinations needed, meaning it's 14K or so to do it on the high-res screen. Never did pursue it, because of that. Today it might make sense because we've generally got a lot more RAM to work with.

 

If somebody did, they could get 8 pixel 80 col displays on the native graphics chip. It's just gonna cost them!

 

On the A8, a real full color pixel is the 160 pixel size we are used to looking at. Jay Miner called this a color clock. To get color, you generated smaller pixels. Anything smaller than the 160 pixel size will do something, as will extreme changes from one pixel to the next. A8 has 16 color shades, so there are 16 positions that like within the full color pixel, with each aligning with some position on the color wheel.

 

00000000000000 --> full pixel 160 pixel size.

---0--------------- ---> some color

------------0------ -----> some other color.

 

I never tried it at the 48 byte DMA either. Used the 32 for a 512 pixel display though, because that consumed less overall RAM.

 

Most PC capture cards I've tried will display the extra colors just fine. If you shove the composite signal into the S-Video luma input, the sub pixels resolve nicely. I'll see if I can post up a screen capture of those. I don't have anything but RF for the 400 right now, so that might have to be from a micro, to illustrate what it looks like.

[Fröhn]

No moon involved.

 

 

But you oversee a small fact. A started command that works inside the CPU can step ahead until the CPU has to write the result back to the RAM. This is caused by the external memory halt of ANTIC. It's depending on the used code, how much speed gets lost.

6502 has no commands that "work inside the CPU". Every cycle it either reads or writes memory.

 

No further cycles lost, DRAM refresh and bitmap bytes are fetched on the bus cycles reserved for the VIC.

And what about the fetches when re-using sprites?

Since Amaurote A8 doesn't use sprites I didn't add them to the calculation. The A8 version would be 40% faster if a 1:1 port to C64 would be done (or other way round: C64 version would run at 70% of the A8 speed), ofcourse there is the option to use sprites for some of the frontmost objects, hard to say how useful that would be.

Edited December 6, 2008 by Fröhn

[potatohead]

hmm, but on the a8 its used to achive some kind of gfx effects ? what kinds?

 

i think that what happens is that there are two high res pixels horizontally to one colour clock and setting only one of them produces a different colour on the screen (which is apparently governed by other factors such as if the machine has a CTIA or GTIA, if it's PAL or NTSC and so forth)... any Atarian want to say if i'm talking rubbish or explain it better?

 

on the c64 it wasnt used to do this.

 

Apparently it comes about from the interaction between the luminance and color signals and the the clock generators on the VIC-II chip are kept apart so that the colour crystal is seperated from the video shift rate to reduce the problem. Or something. Aw stuff it, i'm not going to even pretend i understand! Check page four of this thread (my post, number 86) for a quote from Spectacular Rise And Fall Of Commodore where Bob Yannes explained it properly. =-)

 

On NTSC that is correct. Two pixels per color clock. The difference between CTIA and GTIA was phase, and I think artifacted colors were opposite because of this. Been a long time. Way back when, one friend had a CTIA machine. It was one of the first manufactured 400 machines. It got mem expanded and upgraded over the years. At the time GTIA was released, the discussion was over the new modes, and artifacting differences. Twiddling your tint knob on your telly was the workaround! I got to see this in action with a coupla games back then. A tint tweak was a PITA, so we just went with the other colors and all was good.

 

Also CTIA didn't display all the lumas either. The lower most bit was ignored, leaving the user with 128 colors, not 256.

Edited December 6, 2008 by potatohead

[Crazyace]

Head over heels seems to be running quite nicely as an isometric game on the C64

[Fröhn]

Also CTIA didn't display all the lumas either. The lower most bit was ignored, leaving the user with 128 colors, not 256.

GTIA had a 128 color palette for the color registers too. Only the new GTIA modes had either 16 lumas or 16 chromas -> 16*16 in total.

[Bryan]

I had an NTSC machine.

 

It worked very well, if you had a monochrome display. Your average color telly of the time didn't have the sheer pixel resolution to deal with it. Heck, most of them couldn't really even display the nice interlaced color we have today either.

You mean the line-to-line color mixing used on PAL? That doesn't work at all on NTSC. PAL uses the line mixing to average out any color error between the two phases. NTSC has only one color phase so averaging lines would just reduce the sharpness.

 

BTW, the main problem trying to do PAL artifacting is that the relationship between the pixels and color carrier is always changing. No simple pixel pattern will generate a solid color.

 

Also CTIA didn't display all the lumas either. The lower most bit was ignored, leaving the user with 128 colors, not 256.

Only GTIA mode '01' can generate 16 lumas. All other modes are limited to 8.

[emkay]

Head over heels seems to be running quite nicely as an isometric game on the C64

 

Seems they used a clever trick to compensate the cpu speed. Except of Head and Heels the objects move interleaved (not at the same time).

Have a look at the Knight lore adaption BBC->A8 . The objects move at the same time in there.

[potatohead]

No, I mean interlaced color where the color phase reference is one half of a color clock off.

 

oooooooo--------oooooooo

----oooooooo--------oooooooo

 

Older TV's more or less ignored this, limiting their color resolution to about 160 pixels. Newer ones display this properly, and will do 320 pixels+

 

If you go look at the NTSC standard, there is both vertical interlace and horizontal interlace. On the horizontal, color is interlaced even and odd scanlines, with that flipping every frame, for a 4x4 matrix of color information. (this is why TV graphics are always some color combinations and not others!!)

 

The vertical interlace is scanlines, even and odd.

[thorfdbg]

BTW, the main problem trying to do PAL artifacting is that the relationship between the pixels and color carrier is always changing. No simple pixel pattern will generate a solid color.

 

Not quite correct, you can do artifacting in PAL. The relation is pretty simple, it is 4:5 between color carrier and luminance IIRC. You can check

the crystals inside the PAL A8: There is a main crystal, driving ANTIC and the CPU. Its frequency is divided by four by two 7474 flip-flops, and their output is sync'd with a crystal of 5/4 times the frequency of the main crystal, which is then feed into the GTIA color carrier input.

 

That is, you can generate "sort-of" artifacts on a PAL A8 if you want, just the pattern you need to draw is more complicated. IIRC, you need something like

 

0101010010101001

 

to get a halfway stable color of one kind, and you could phase-shift the pattern to create additional colors. I think you can get something like "smudgy" green and blue this way. Since PAL averages between adjacent lines, you can get additional colors if you offset the pattern between odd and even display lines, which gave you something like yellow and magenta.

 

The effects are not as colorful as for NTSC, but can be observed on a PAL color TV.

 

That said, it should be possible to create artifacts on the C64 as well by carefully studying the relation between the color carrier generation of VIC and the dot-frequency - there is surely some relation, but I don't know which.

 

So long,

 

Thomas

[Fröhn]

BTW, the main problem trying to do PAL artifacting is that the relationship between the pixels and color carrier is always changing. No simple pixel pattern will generate a solid color.

Not quite correct, you can do artifacting in PAL. The relation is pretty simple, it is 4:5 between color carrier and luminance IIRC. You can check

I explained it to Bryan already, but somehow my posts about clock generating seemed to be ignored by him.

 

However we should refer to (hires) pixel clock: 8/5 (pixel clock freq/color carrier freq)

 

Since PAL averages between adjacent lines, you can get additional colors if you offset the pattern between odd and even display lines, which gave you something like yellow and magenta.

Yes, this is how some C64 graphics use other than the original 16 colors (without pattern, just different chroma on odd and even lines):

 

http://noname.c64.org/csdb/release/?id=58480

 

(Try in Vice with PAL emulation on and off to see what colors are mixed)

 

The effects are not as colorful as for NTSC, but can be observed on a PAL color TV.

Because the frequency of the color carrier is higher and less of the luma pixel pattern gets filtered as chroma.

 

That said, it should be possible to create artifacts on the C64 as well by carefully studying the relation between the color carrier generation of VIC and the dot-frequency - there is surely some relation, but I don't know which.

NTSC C64: 16/7

PAL C64: 16/9

 

for comparision:

 

NTSC A8: 16/8

PAL A8: 16/10

Edited December 6, 2008 by Fröhn

[Shawn Jefferson]

...

On the Atari, you have to copy anytime you are moving vertically even... unless you do something strange that compromises reusing the sprites further down the screen, or use up lots of memory (which no one would every do except in a some sort of tech demo.) I don't understand what Atariksi is talking about.

 

You don't know what I'm talking about that's why I am not replying to your points.

 

You're probably right and I apologize, since I didn't read the entire thread, and took a lot of the discussion out of context I think.

[Allas]

Look what Wall-e found on year 3000 :

 

[Heaven/TQA]

Last Ninja is NOT an isometric game in the way the Ultimate Spectrum titles or A8 Amaurote is...

LN uses masks to allow sprites to appear to go behind objects, but they do not - rather than doing proper depth sorted isometric.

 

arent speccy iso games using masks to allow sprites to appear to go behind objects ? I see no difference. and what have depth sorting and moving objects have to do with the definition of isometric projection anyway ?

 

Now before anyone shouts and jumps up an down I would like to point out that I HAVE the C64 source code, I have studied John's code - back in the day I was developing an A8 conversion of LN II for system 3. Discussions of that would make fun thread...

 

wow! would love to hear the whole story about it, and your insights of the c64 engine. care to open a new thread ?

 

Oswald... look here... http://www.jetbootjack.com/JBJ_a8indyindex.html

 

Sorry, Steve... but he might be not familiar... and that you are still in games biz...

[Heaven/TQA]

allas,

 

You searched for:

Releases matching:

Released between: 1 January 2008 and 1 January 2009

 

Found: 779 matches.

 

 

779 screenshots would be a bit too much to include here

 

779 games?

[Bryan]

No, I mean interlaced color where the color phase reference is one half of a color clock off.

 

oooooooo--------oooooooo

----oooooooo--------oooooooo

 

Older TV's more or less ignored this, limiting their color resolution to about 160 pixels. Newer ones display this properly, and will do 320 pixels+

 

If you go look at the NTSC standard, there is both vertical interlace and horizontal interlace. On the horizontal, color is interlaced even and odd scanlines, with that flipping every frame, for a 4x4 matrix of color information. (this is why TV graphics are always some color combinations and not others!!)

 

The vertical interlace is scanlines, even and odd.

The Atari doesn't use horizontal interlace. It must be generated at the source but all A8 lines use the same phase. This makes Atari lines 1/2 color clock longer than the actual NTSC standard.

 

Normal NTSC line: 227.5 CC

Atari NTSC line: 228 CC

 

The half-clock is what normally makes NTSC lines alternate absolute phase and causes 'dot-crawl' and all that.

 

 

Edited for clarity...

Edited December 6, 2008 by Bryan

[Bryan]

I explained it to Bryan already, but somehow my posts about clock generating seemed to be ignored by him.

I know it can be done, it just doesn't work anywhere near as well and I haven't really seen it used by PAL A8 software.