Jump to content
IGNORED

Atari v Commodore


stevelanc

Recommended Posts

On PAL Atari you will have different colors even if you shift the pattern 2 hires pixels because of the 16/10 instead of 16/8 color carrier vs pixel ratio.

 

so atari has problem with displaying color in 320x resolutions?

 

It has problems changing colors at 1/320 pixel accuracy. You can have colors as the BASIC program I posted shows.

Link to comment
Share on other sites

You need to check the interval at which they are doing horizontal splitting. Even if you have a stable enough raster and set up your IRQ, your interval for splits will be at a lower resolution. That's what I meant by accuracy. On Atari in most modes (except lines where char data is fetched), you can set up split basically at every other CPU clock

 

just every other? c64 can do it on every cpu clock. what made you think it cant ? there are demoparts which are only changing backgr color, doing scrollers, chessboards, etc.

 

>check any scrolling game with hires pixels ?! how hard is that ? turrican has that fex.

Don't have any to check out. I am doubting that pixels can retain their color at 1/320 pixel accuracy given NTSC standard.

 

given atari standard I'd say.

Link to comment
Share on other sites

Here you go, right from Nolan Bushnell..

 

I know that Joe Decuir says they were developing a game console until Ray Kassar got Atari into computers and I know other Atari employees have insinuated the same thing.

 

I think Nolan is a little bit of a sugar-coater (oh yes, that the idea all along!), but I don't have time to look for the interviews right now. I'll look and post them later.

Link to comment
Share on other sites

Also, from Curt Vendel's www.atarimuseum.com:

 

In 1978 the team that had finished the Atari VCS was at work on a new high-end video game console chipset. Atari was now owned by Warner Communications since its sale in 1976 by its original owner/creator Nolan Bushnell for $28 million. Atari was now run by Raymond Kassar who wanted Atari to compete in the home computer market against Apple and its Apple ][e computer. The new high-end chipset was "frozen" for use only in the newly created Atari Home Computer Division.

 

Atari's new Home Computer Division was so hastily started that office trailers were brought in and set-up behind Atari's offices while work progressed on the new computer designs. Working in these rather cramped quarters Atari's new HCD engineers & designers went to work on designing the worlds first personal computers to use custom IC's to handle graphics, sound and communication.

 

 

Of course, there's a mistake in there as the Apple ][e wasn't available until the '80s.

Link to comment
Share on other sites

On PAL Atari you will have different colors even if you shift the pattern 2 hires pixels because of the 16/10 instead of 16/8 color carrier vs pixel ratio.

so atari has problem with displaying color in 320x resolutions?

It has problems changing colors at 1/320 pixel accuracy. You can have colors as the BASIC program I posted shows.

There is only a problem if you alternate two colors. If you use lower frequencies (like Commodore or Atari fonts) you can use 320x resolution without color artefacting. But this doesn't matter at all, since that's again something entirely different than moving gfx at 320 resolution which on C64 doesn't even imply you are using 320x res, you can do the same in 160x res on C64.

Link to comment
Share on other sites

On PAL Atari you will have different colors even if you shift the pattern 2 hires pixels because of the 16/10 instead of 16/8 color carrier vs pixel ratio.

so atari has problem with displaying color in 320x resolutions?

It has problems changing colors at 1/320 pixel accuracy. You can have colors as the BASIC program I posted shows.

There is only a problem if you alternate two colors. If you use lower frequencies (like Commodore or Atari fonts) you can use 320x resolution without color artefacting. But this doesn't matter at all, since that's again something entirely different than moving gfx at 320 resolution which on C64 doesn't even imply you are using 320x res, you can do the same in 160x res on C64.

 

Yes, that's why I needed to adapt the scrolling routines when porting Venus Express to A8.

Link to comment
Share on other sites

With some C64 bias I guess?

 

DotC is another example where the "unused" benifits of the A8 were...

 

Just 2 conversons. But the title is already not reachable for the C64. With some palette rolling, the screen would look similar to the 16 bit pendants with the metallic shine.

 

A sad thing that they missed to create such games on the A8. They would have been pearls of their time. Even in a "pre C64 time"....

 

 

ammazgin really. a8 can do a better picture than something that was done 20 years ago for the c64 ;)

 

Really amazing that the older hardware can do better in many cases. More amazing is that particular games like Defender of the Crown could have been there as a "Graphics" example deluxe in 1979.

Link to comment
Share on other sites

You need to check the interval at which they are doing horizontal splitting. Even if you have a stable enough raster and set up your IRQ, your interval for splits will be at a lower resolution. That's what I meant by accuracy. On Atari in most modes (except lines where char data is fetched), you can set up split basically at every other CPU clock point and in lower resolution modes, the interval decreases. Memory refreshes occur on left side of display which usually won't require a split and adjustments in HBlanking can be used for the left 30%.

In display area, every 2nd cycle is used for ANTIC DMA. So you end up with an accuracy of 0.887 MHz (and on the left side it's even lower because DRAM refresh cycles are taken from the CPU cycles).

 

On C64 always every 2nd cycle is used for VIC DMA and refresh cycles are hidden to the CPU too. So there is a 0.985 MHz accuracy.

 

According to your "frequency matters" rule that means: C64 has higher split resolution than A8 even without taking the refresh cycles into account. I'd say 8 pixels = 8 pixels but this time I stick to your timer freq rules :D

 

check any scrolling game with hires pixels ?! how hard is that ? turrican has that fex.

Don't have any to check out. I am doubting that pixels can retain their color at 1/320 pixel accuracy given NTSC standard.

Ofcourse it can. Hires outlines do not automatically mean you have to use a chessboard pattern all the time. If you use lower pixel frequencies, there won't be any artefacting.

Link to comment
Share on other sites

You need to check the interval at which they are doing horizontal splitting. Even if you have a stable enough raster and set up your IRQ, your interval for splits will be at a lower resolution. That's what I meant by accuracy. On Atari in most modes (except lines where char data is fetched), you can set up split basically at every other CPU clock

 

just every other? c64 can do it on every cpu clock. what made you think it cant ? there are demoparts which are only changing backgr color, doing scrollers, chessboards, etc.

...

 

If you are going to quote me, quote the whole line. The above quote continues: "and in lower resolution modes, the interval decreases. "

 

You can do it every clock except where DMA occurs which is only 9 cycles of 114 in best case. You can't do it on every CPU clock-- you also have DMA interference which drops your accuracy down to almost 0 for the scanline.

 

>>>check any scrolling game with hires pixels ?! how hard is that ? turrican has that fex.

 

>>Don't have any to check out. I am doubting that pixels can retain their color at 1/320 pixel accuracy given NTSC standard.

 

>given atari standard I'd say.

 

All you have to do is translate that simple BASIC program into C64 and everyone can find it for himself rather than rely on biased data like specific demos.

Link to comment
Share on other sites

Interesting stuff :ponder:

 

You have ten million relatives who argue like you or you misunderstood me or your not using TV hooked up to a C64. Here's a simple piece of code in BASIC that explains what I am talking about as well as showing the GPRIOR/OR color effect in 320 pixel mode:

 

10 GRAPHICS 8

20 POKE 704,16:POKE 705,32:POKE 706,48:POKE 707,64:POKE 623,32

30 COLOR 1:PLOT 256,0:DR. 256,159:PLOT 258,0:DR. 258,159

40 PLOT 265,0:DR. 265,159:PLOT 267,0:DR. 267,159

50 FOR T=53256 TO 53264:POKE T,255:N.T

60 POKE 53248,112:POKE 53249,128:POKE 53250,160:POKE 53251,176

 

On the first blank vertical line, Atari shows correct color but on the next one, it does not show same color although it should. Now show me C64 code that does the above but also shows the same color consistently.

 

That was a simple example. It becomes more interesting when you change the POKE 623,32 to POKE 623,48 and use color register 711 (53273) and put the individual parts of player 5 on top of various parts of merged Player #3 and Player #4 which gives you 4 more colors. So you get the following scenario: Players #1+#2 gives 3 colors. Player #3+#4 gives 3 colors. Playfield conflict with Player #3+4 gives 3 more colors. Playfield #2 color of Gr.8, foreground color of text (luminance only), background color and 4 colors from overlaying Player #5 giving total of 16 colors.

Link to comment
Share on other sites

You need to check the interval at which they are doing horizontal splitting. Even if you have a stable enough raster and set up your IRQ, your interval for splits will be at a lower resolution. That's what I meant by accuracy. On Atari in most modes (except lines where char data is fetched), you can set up split basically at every other CPU clock point and in lower resolution modes, the interval decreases. Memory refreshes occur on left side of display which usually won't require a split and adjustments in HBlanking can be used for the left 30%.

In display area, every 2nd cycle is used for ANTIC DMA. So you end up with an accuracy of 0.887 MHz (and on the left side it's even lower because DRAM refresh cycles are taken from the CPU cycles).

 

On C64 always every 2nd cycle is used for VIC DMA and refresh cycles are hidden to the CPU too. So there is a 0.985 MHz accuracy.

 

According to your "frequency matters" rule that means: C64 has higher split resolution than A8 even without taking the refresh cycles into account. I'd say 8 pixels = 8 pixels but this time I stick to your timer freq rules :D

...

They are not my rules-- they are just bare logical facts. Atari Timing IRQ is at 1.79Mhz regardless of which mode, but DMA pre-empts the interrupt which drops its accuracy so depending on the mode your frequency can vary but best case is 1.79Mhz since you can always time it to avoid refresh cycles. But you are correct regarding the Gr.8 that we were discussing that it would drop it to about half in the display area. However, the DMA is uniform so I can create a multi-line horizontal split window. I haven't coded any horizontal splits on C64, but there's the bad-line DMA and the fact that your frequency does not evenly divide into the calculation of a screen location (based on NTSC rate) that would throw things off.

 

>>Don't have any to check out. I am doubting that pixels can retain their color at 1/320 pixel accuracy given NTSC standard.

 

>Ofcourse it can. Hires outlines do not automatically mean you have to use a chessboard pattern all the time. If you use lower pixel frequencies, there won't be any artefacting.

 

Lower pixel frequencies mean lower resolutions-- but then there's no argument Atari wins since Atari can switch in GTIA modes at specific points horizontally. Original argument is regarding the 320 mode-- how true of a 320 mode it really is. If you go to other (lower) resolutions, Atari has a lot more and lot more combinations to win out easily.

Link to comment
Share on other sites

On PAL Atari you will have different colors even if you shift the pattern 2 hires pixels because of the 16/10 instead of 16/8 color carrier vs pixel ratio.

so atari has problem with displaying color in 320x resolutions?

It has problems changing colors at 1/320 pixel accuracy. You can have colors as the BASIC program I posted shows.

There is only a problem if you alternate two colors. If you use lower frequencies (like Commodore or Atari fonts) you can use 320x resolution without color artefacting. But this doesn't matter at all, since that's again something entirely different than moving gfx at 320 resolution which on C64 doesn't even imply you are using 320x res, you can do the same in 160x res on C64.

 

But scrolling at 320 resolution is related since you want to move the image with its colors in tact by 1/320 of display line.

Link to comment
Share on other sites

>Can the Atari even display this? The sprites are high res. It's no point having 'some commands' to move up and down if you cant reproduce the original.

 

Is it a static image or are the bubbles or something else moving?

 

bubbles and the colors in some of the color splits are moving.

 

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

 

Okay, I did not see anything moving on that link. Also, is this screen shot from an emulator or real C64 since I am not familiar with any emulators and how they deal with artifacting or NTSC-related effects? Hey, even the interlace pictures from C64 would look good if you ran them on a display with higher refresh rate.

Link to comment
Share on other sites

In display area, every 2nd cycle is used for ANTIC DMA. So you end up with an accuracy of 0.887 MHz (and on the left side it's even lower because DRAM refresh cycles are taken from the CPU cycles).

 

On C64 always every 2nd cycle is used for VIC DMA and refresh cycles are hidden to the CPU too. So there is a 0.985 MHz accuracy.

 

According to your "frequency matters" rule that means: C64 has higher split resolution than A8 even without taking the refresh cycles into account. I'd say 8 pixels = 8 pixels but this time I stick to your timer freq rules :D

They are not my rules-- they are just bare logical facts. Atari Timing IRQ is at 1.79Mhz regardless of which mode, but DMA pre-empts the interrupt which drops its accuracy so depending on the mode your frequency can vary but best case is 1.79Mhz since you can always time it to avoid refresh cycles.

The DMA is only one reason why accuracy is far less. Main reason is the fact that the CPU cannot interrupt an opcode and has to wait for it's end, so there is a 0...7 cycle jitter only because of that. Ofcourse 1..2..3... etc cycles DMA also add to that. In the end you are down to an accuracy which is something like 150 kHz or similar, so I don't really see how that 1.77 MHz do actually matter that much.

 

However, the DMA is uniform so I can create a multi-line horizontal split window. I haven't coded any horizontal splits on C64, but there's the bad-line DMA and the fact that your frequency does not evenly divide into the calculation of a screen location (based on NTSC rate) that would throw things off.

Badlines can be removed easily by avoiding badline condition. And why would NTSC throw anything of? Ofcourse the clock cycles can be directly translated to screen locations. It's the same on PAL A8, NTSC A8, PAL C64, NTSC C64: All clocks in the system are generated from 4x color carrier frequency, so everything is perfectly synchronous.

 

Lower pixel frequencies mean lower resolutions--

No they don't. Look at Atari or Commodore font: low pixel frequencies but hires. You don't always have to use chessboard patterns...

 

Original argument is regarding the 320 mode-- how true of a 320 mode it really is.

The original argument is: C64 can scroll 320 res without changing colors. The 320 resolution movement has NOTHING to do with the phase of the color carrier of the colors which get displayed. You can easily scroll gfx at 320x res and don't have those color changes you believe there would be.

 

But scrolling at 320 resolution is related since you want to move the image with its colors in tact by 1/320 of display line.

Again: No. C64 can easily scroll 160x200 mode in 320 resolution steps. Your mistake is that you believe that the color phase depends on the scroll register or something, which it doesn't. On PAL A8 every scroll register value would move the color phase by 450° (90°), but it doesn't.

Edited by Fröhn
Link to comment
Share on other sites

In display area, every 2nd cycle is used for ANTIC DMA. So you end up with an accuracy of 0.887 MHz (and on the left side it's even lower because DRAM refresh cycles are taken from the CPU cycles).

 

On C64 always every 2nd cycle is used for VIC DMA and refresh cycles are hidden to the CPU too. So there is a 0.985 MHz accuracy.

 

According to your "frequency matters" rule that means: C64 has higher split resolution than A8 even without taking the refresh cycles into account. I'd say 8 pixels = 8 pixels but this time I stick to your timer freq rules :D

They are not my rules-- they are just bare logical facts. Atari Timing IRQ is at 1.79Mhz regardless of which mode, but DMA pre-empts the interrupt which drops its accuracy so depending on the mode your frequency can vary but best case is 1.79Mhz since you can always time it to avoid refresh cycles.

The DMA is only one reason why accuracy is far less. Main reason is the fact that the CPU cannot interrupt an opcode and has to wait for it's end, so there is a 0...7 cycle jitter only because of that. Ofcourse 1..2..3... etc cycles DMA also add to that. In the end you are down to an accuracy which is something like 150 kHz or similar, so I don't really see how that 1.77 MHz do actually matter that much.

...

You are generalizing incorrectly. The accuracy is always 1.79Mhz but for placing a horizontally split window on the display area, it's like every other CPU cycle. That's the point. DMA does not affect the 1.79Mhz accuracy. If you know the DMA chart, you can cause an interrupt to occur at the exact cycle (@1.79Mhz accuracy). I already posted the program in this thread that shows it working at 1.79Mhz accuracy in text mode. You just can't have the interrupt occur on top of a DMA cycle which will cause a delayed IRQ and text mode usually has one scanline that's slower than others in the 8-16 scanline block. As far as instruction being in the middle, that can also be avoided.

 

>Badlines can be removed easily by avoiding badline condition. And why would NTSC throw anything of? Ofcourse the clock cycles can be directly translated to screen locations. It's the same on PAL A8, NTSC A8, PAL C64, NTSC C64: All clocks in the system are generated from 4x color carrier frequency, so everything is perfectly synchronous.

 

I thought you have to have badlines for some of your modes. If the ratio is not evenly divisible, you will end of with an unstable point of interrupt on the screen. On the Amiga this happens as well since it's CIA interrupt freq is 7.15909Mhz/10 = 715Khz and it cannot have a divisor that evenly divides into cycles per frame.

 

>>Lower pixel frequencies mean lower resolutions--

 

>No they don't. Look at Atari or Commodore font: low pixel frequencies but hires. You don't always have to use chessboard patterns...

 

You can make them thicker but my original point was to see if you can have color transitions in 1/320 pixel.

 

>The original argument is: C64 can scroll 320 res without changing colors. The 320 resolution movement has NOTHING to do with the phase of the color carrier of the colors which get displayed. You can easily scroll gfx at 320x res and don't have those color changes you believe there would be.

 

I accept there won't be color changes on thick pixels (or regions) but I was talking about 1-pixel thin lines. Also, the edge of a region may be affected.

 

>Again: No. C64 can easily scroll 160x200 mode in 320 resolution steps. Your mistake is that you believe that the color phase depends on the scroll register or something, which it doesn't. On PAL A8 every scroll register value would move the color phase by 450° (90°), but it doesn't.

 

I don't think the color phase setting is that dynamic to adjust.

Link to comment
Share on other sites

I would agree Atari 800 keyboard is superior (and more expensive to make) than Atari 800XL keyboard. I think some people just get used to one keyboard and falsely think the others are inferior. I still haven't found the warm reset key on the C64 keyboard.

 

I thought the 64 had a decent keyboard for low cost machine: full stroke and not mushy. I thought the layout was mildly insane, though. The old Stackpole keyboards on the 800 were nice with gold-plated contacts but prone to breaking which caused the keys to fall out. There was a later version made by Mitsumi which was similar in feel to the 1200XL keyboard.

 

I never had a 1200XL to compare. I just usually write ML code in BASIC to test stuff and when computer freezes up, with Atari I just press WARM reset and can edit the BASIC/ML code, but on C64 I haven't been able to do the WARM reset.

 

Chimes in late on the 8-Bit keyboard discusion...

 

Of my 8-Bit systems here's how I rank the keyboards... at least as far as feel: Apple IIe, Commodore 64, Atari 800XL, Atari XEGS

 

I've never used an Atari 400/800. Is the keyboard more of the "clickety" style like the Apple II and C64?

 

I have both the Atari 800 and 800XL and prefer the Atari 800. It still works after all these years whereas I have had some key failures on 800XL machines due to mylar getting dirty or going bad. I can type faster with Atari 800 keyboard and also has the internal speaker for the key click and a real wire going to the motherboard instead of a thin film strip. You can easily put a palm rest in front of it and make it even easier to use...

 

Okay, I did get my hands on a 800XL computer that has a keyboard without a mylar. The only difference I notice now is that the power switch is slower than the Atari 800. On the Atari 800, I can turn on/off the computer instantly whereas Atari 800XL seems to require some delay like C64. But I also have an 800XL that you can turn on/off instantly.

Link to comment
Share on other sites

You are generalizing incorrectly. The accuracy is always 1.79Mhz but for placing a horizontally split window on the display area, it's like every other CPU cycle. That's the point. DMA does not affect the 1.79Mhz accuracy. If you know the DMA chart, you can cause an interrupt to occur at the exact cycle (@1.79Mhz accuracy).

So you can on C64, and that's why I think this "1.77 mhz timers are better than 0.985 timers" doesn't matter at all: All that matters is that it can hit any CPU cycle. You may complain about slower CPU speed, but the timers can both achieve the very same thing. Also knowing the DMA chart is not enough, because you also need to know exactly what code is running outside the IRQ for knowing the actual delay.

 

I thought you have to have badlines for some of your modes.

You need them for color cells or char matrix row update. If you don't need that, badlines are not needed.

 

If the ratio is not evenly divisible, you will end of with an unstable point of interrupt on the screen. On the Amiga this happens as well since it's CIA interrupt freq is 7.15909Mhz/10 = 715Khz and it cannot have a divisor that evenly divides into cycles per frame.

But since the CIA clocks are equal to CPU clocks on both systems, that doesn't happen.

 

You can make them thicker but my original point was to see if you can have color transitions in 1/320 pixel.

But this was never the issue. I was talking about movement in that resolution, not pixels. All movement of the VIC can be done in 320 resolution, even multicolor sprites or 160x200 gfx. And then you claimed that that is impossible although the C64 is doing that.

 

I accept there won't be color changes on thick pixels (or regions) but I was talking about 1-pixel thin lines. Also, the edge of a region may be affected.

On C64 only slightly since it has an anti artefacting filter which heavily reduces the colors generated by hires pixel patterns. And if you connect the C64 via a S-Video connection it's no issue anyway because then absolutely no chroma effects will appear on switching hires lumas.

 

On PAL A8 every scroll register value would move the color phase by 450° (90°), but it doesn't.

I don't think the color phase setting is that dynamic to adjust.

That's how PAL/NTSC encoding works: color carrier phase shift is the color tone, color carrier amplitude is the saturation.

 

The carrier is generated like this: C = U*sin(x) + V*cos(x) -> It can have any phase shift from 0...360°.

Link to comment
Share on other sites

You miscounted. GPRIOR and OR produced colors are features not on the C64 whereas color RAM is not on the Atari. Sprite overlays and interrupts are there on the C64 although not as accurate to do horizontal split windows.

There is countless examples of cycle-accurate sync of video + CPU. It's most often used to open the sideborder or to change colors mid line. There are a few examples of actual mode switch, but on C64 that usually isn't too useful because if you want to mix 320 and 160 resolution, you can simply use the C64 character mode which already supports mixing of resolutions.

...

Claim was that 320 mode has advantage of more colors so you do need to use a mode that has a bad line which prevents the horizontal split.

 

>That's artefacting due to simulated color carrier. If you use lower frequencies (160 res or multiple hires pixels of same color next to each other) there won't be any. Please keep in mind that C64 can scroll anything in 320 res accuracy, even 160x200 resolution.

 

I'll have to see if that retains the color (especially on edge of region).

Link to comment
Share on other sites

Actually, I used it for my curtains demo I mentioned a few times in this thread which is a moving scene not a static one. Once I remove its dependence on joystick input for real-time audio playback, I'll post it as an image disk. It uses > 4-bit color depth total (7-shaded overscanned curtain on top of a GTIA 16-color image). It can also work for some games like joust (if someone wanted to re-write it). Your code above is sub-optimal. Algorithm is that you want to set the Hpos0..3 in HBLank and also set up the A,X,Y registers to the xpos of 3 additional sprites which are closest to HPOSn already used. You want to avoid doing LDAs in the middle of the scanline during visible area. I still had cycles left over for setting the colors for right side of curtain if I wanted to but curtain wouldn't look as good.

 

My code snippet was just for cycle counting - you're right that loading A+X+Y is much better in real code. Were you reloading the graphics for the curtain as well as changing the hpos?

...

 

Even in cycle counting if you were in a DLI kernel (or IRQ-based kernel), the X,Y at least can be factored out to beginning of kernel since the HPOS you are replicating will be constant throughout the kernel. I am actually using zero bytes of RAM for the curtain since it's just shading produced by GPRIOR settings of colored bars.

 

 

True, the X,Y load cost can be eliminated - saving 2 constands and 4 cycles :) - however your curtain isn't a true multiplexed sprite, just a graphics overlay effect - I would expect to reuse the graphics as well for a game situation.

...

In the example, if you replicate 4 sprites horizontally @60Hz, you are restricted in the y-position and shape since there's not enough time to update Grafn AND HPOSes.

 

>It would be an interesting challenge to write a 'real' sprite routine to allow 8 completely indepentant sprites on a horizontal line ( even with only 4 visible ) as it takes 12 cycles to change the 3 sprite attributes ( 24 pixels in 160 mode ) at least - so if the 8 sprites were at X positions $40 , $50, ... ,$a0,$b0 hex they would cause problems

 

VBlanking method would have to be used if you want to change shape and Y-axis and have 8 sprites on a scanline.

 

>My original point was that the c64 was much more geared to 320 pixel modes - the Atari has a limited support , but everything is based on 160. All of the underlay tricks are very usefull to 'extend' the 320 support - but they dont match the builtin colour ram.

 

I would state that they are not the same method to coloring stuff in 320 pixel mode not that Atari's tricks are more limiting. After all for certain cases, Atari approaches the 8-bit color depth whereas C64 hits the ceiling at 4 bit color depth.

 

>>On Atari you can disable/enable any of the GTIA modes at mid-scanline and put in higher color content in 320*200 mode and selecting a GTIA mode (one STA) automatically switches in/out a 16-color or 16-shade or custom 9-color palette...

 

>Extended background colour uses the top 2 bits of the character code to select one of 4 background pallette registers for the 8x8 character ( the foreground colour is set by the colour ram ) - it reduces the charset size to 64 ( it's very similar to the atari charmodes in some ways ) but still in 320 pixel mode

 

>Switching GTIA mode on/off is ok - but I really would prefer switching between normal 4 colour mode with no sideeffects ... On the C64 each character can be 8x8 (320) or 8x4(160) with no restrictions, and no need for timing

 

There's no side-effect in switching between Gr.9 <->Gr. 8 <->Gr. 11. Gr. 10 would cause one color clock delay. And sprite overlays can be replicated easily just like 53275 for switching priorities.

Link to comment
Share on other sites

In the example, if you replicate 4 sprites horizontally @60Hz, you are restricted in the y-position and shape since there's not enough time to update Grafn AND HPOSes.

 

Which is a limitation compared to the C64 , as I originally stated.

 

>It would be an interesting challenge to write a 'real' sprite routine to allow 8 completely indepentant sprites on a horizontal line ( even with only 4 visible ) as it takes 12 cycles to change the 3 sprite attributes ( 24 pixels in 160 mode ) at least - so if the 8 sprites were at X positions $40 , $50, ... ,$a0,$b0 hex they would cause problems

 

VBlanking method would have to be used if you want to change shape and Y-axis and have 8 sprites on a scanline.

 

Are you talking about multplexing sprites - I was thinking of 8 per line from a far greater number ( 30 or 40 ) , which is what you would need for a 'busy' sprite game

 

 

>My original point was that the c64 was much more geared to 320 pixel modes - the Atari has a limited support , but everything is based on 160. All of the underlay tricks are very usefull to 'extend' the 320 support - but they dont match the builtin colour ram.

 

I would state that they are not the same method to coloring stuff in 320 pixel mode not that Atari's tricks are more limiting. After all for certain cases, Atari approaches the 8-bit color depth whereas C64 hits the ceiling at 4 bit color depth.

 

The Atari method is still inherently 160 pixel based - again you claim a shading advantage, which I agree with, while ignoring the resolution advantage.

 

 

>Switching GTIA mode on/off is ok - but I really would prefer switching between normal 4 colour mode with no sideeffects ... On the C64 each character can be 8x8 (320) or 8x4(160) with no restrictions, and no need for timing

 

There's no side-effect in switching between Gr.9 <->Gr. 8 <->Gr. 11. Gr. 10 would cause one color clock delay. And sprite overlays can be replicated easily just like 53275 for switching priorities.

 

This isn't as easy as just setting a bit in colour ram to select between 320 and 160 mode for each of the 40 characters. Can you switch gr.8 -> gr.15 , and switch back 4 colour clocks later?

 

 

This is a very simple example of something you can never replicate on an A8, purely because of the 320 pixel resolution.

 

There are A8 images that would be impossible for the c64 to replicate , and that's why the A8 is so cool... seeing as it can still hold up with the newer machine.

post-4839-1229159663_thumb.png

Link to comment
Share on other sites

There are A8 images that would be impossible for the c64 to replicate , and that's why the A8 is so cool... seeing as it can still hold up with the newer machine.

 

 

For example pictures like this below. And when G2F works better, the results will even be better aswell.

post-2756-1229172120_thumb.png

Link to comment
Share on other sites

Frogger is one game that fits on Atari Antic capabilities. Many colors and scrolls on both sides. I think this version is better than arcade.

 

Although I like the ATARI more than C64 I believe that there are more conversions on C64 that are better than their ATARI counterparts than vice versa.

 

Just two examples:

 

Ghost Busters

Beach Head II

 

Apart from that there are unfortunately a lot of games missing from C64 (Cybergoth mentioned a few but forgot Space Taxi ;))

 

I guess that had a lot of reasons:

 

- There were more C64 sold than ATARIs so it was commercially more attractive

- There had been more skilled coders on C64 than on ATARI

- If you are designing a game on C64 it is more creative because you don't have to think in advance about the limitations of the machine. If you are designing a game on ATARI you already have to know what you want to achieve so you can use all the necessary tricks (Display Lists and interrupts, PM overlays for more than five colours, POKEY waveform playback, soft sprites etc.)

 

But that was the past, currently the situation has changed. Current productions attract me more to the ATARI (Yoomp!, Mule Wars, Nibbly and even Venus Express (it's better than the original)) than to the C64.

 

There are even unfinished productions that look promising: Space Harrier, Tempest Xtreme etc.

 

Haven't seen good game productions (either unfinished or finished) for the C64 during the last few months.

 

Just my 2 cents,

 

Patjomki

Edited by patjomki
Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
  • Recently Browsing   0 members

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