Atari Vs C64 --- 80s Computer scene etc chat...

[supercat]

It's not "random stuff" and has nothing to do with "PAL timing", it has to do with the way the color information is encoded in a PAL signal.

 

Do "venetian blinds" games on the 2600 have any problem with PAL units?

[supercat]

As long as the sprite capability, accurate interrupts, CPU speed, etc. are present in some form or another, the game creation is more dependent on the creativity of the coder. C64 that were originally designed for that machine will be sub-par on Atari when ported and vice-versa. More colors are always a plus for games-- it increases the beauty.

 

Too bad the VIC-2 chip couldn't have squeezed in a 16x8 palette RAM. That would have totally ruled.

 

Still, if I do Toyshop Trouble for the C64, I think I'll be able to have all the toys at high resolution with two colors/scan line each; the player elf will overlap a hires and a multicolor sprite, with per-line coloring on the hires one.

 

The Atari 800 would have a much nicer color palette, but I don't think it could do the player in high resolution at all; the toys would probably get either one color/line high-res or two in low res.

[emkay]

It seems Atari rushed to produce their computers so the 4 players got lumped into 4 missiles instead of 4 more players.

 

The "fact" is that the GTIA was taken mainly from the 2600 system. Similar to POKEY where the TIA sound was simply "doubled" and a bit enhanced by the 16 bit , the GTIA got simply the double of the available moving objects. Even the TIA moving objects are based on Pong. Just to have the two paddles (Player) and the ball(s) (missiles) ....

By all the great effort, the Developers at atari made, they had one big lack in their knowledge: Everything outside the USA seem not worthy to think about (Commodore got international from the first step).

Particular the GTIA Chip was designed for NTSC, as the primary colouscheme was. Not sure what they thought, when making their machines running for the PAL system. But it must be somehow: If NTSC cannot show colours right, others cannot, too...

Despite of the interesting fact that on a PAL TV you can have a resolutions of ~ 1024x768 interlaced with 16Million colours, back in time they chose to have the PAL version of the ATARI still having only on hue in hires....

 

That the A8 has 128(256) colours is done by GTIA, not by ANTIC. You may know that. So a simple upgrade (debugging & removing unnecessary rules) and adding of the 1st colour data line, possibly the A8 reached real arcade looking...

 

As long as the sprite capability, accurate interrupts, CPU speed, etc. are present in some form or another, the game creation is more dependent on the creativity of the coder. C64 that were originally designed for that machine will be sub-par on Atari when ported and vice-versa. More colors are always a plus for games-- it increases the beauty.

 

That's true. It's only in the colours that the C64 can show some nice detailed pictures with some depth in the objects, while the A8 can show fullscreen pictures with a good optical depth of view , but the single details are often "flat".

[Rybags]

The VIC-2 "palette RAM" aka Colour memory is off-chip. Having it 8-bit would have meant needing 16 data lines instead of 12.

That aside, the bitmap modes use 3 nybble sets anyway for attributes.

 

PAL has the set limit of 312/313 scanlines per frame if you adhere to the standards. Computers with TV-out just use digital filtering to reduce the 768 (or however many lines) to that standard.

 

But agreed - Atari seemed to develop hardware for NTSC, with PAL/SECAM as a low-priority afterthought.

[Heaven/TQA]

@atariski

 

aehmmm... maybe I am wrong but how would you move objects vertically or reposition by altering pmbase? esp. in a game like Joust? where all things can cross each other?

[atariksi]

You don't need CIA interrupts for sprite reuse. The C64 raster IRQ generated by VIC is the best way of going about it.

It's not as precise as on the Atari due to lack of a WSYNC function, but wait loops and other tricks make it nearly so.

 

The Atari has a slight advantage and disadvantage re digitized sound. Extra processor speed and a simpler process of setting the amplitude level, vs lower speed and (I guess the most common method) using the pulse wave and varying the Sustain level on the C-64.

 

But the C-64 gains on the front that less DMA means that digi-sound routines don't have their timing so adversely affected.

 

Although, we know these days that on the A8 the best methods of digital sound involve timer IRQs or storing samples based on a VCOUNT wait loop.

I thought they were claiming that they can also re-use sprites like Atari 800 (vertically and horizontally). Atari 800 can re-use sprites on same scanline via DLI+NOPs or IRQ, so I was asking what divisor could you possible use on the CIA to do the same since the CIA clock is out of sync with the NTSC color clock. Amiga electron beam is also out of sync with it's CIA timer but they have the copper list which can also trigger the 68K IRQ#3 via writing to $DFF09C with $8020 and causes a pretty much consistent interrupt at an exact color clock every frame whereas the CIA-based interrupt seems to gradually diverge from the point of interrupt on the screen.

 

What kind of bits/sample equivalent do you get with pulse wave/sustain level mods on C64?

Edited April 22, 2008 by atariksi

[atariksi]

It seems Atari rushed to produce their computers so the 4 players got lumped into 4 missiles instead of 4 more players.

 

The "fact" is that the GTIA was taken mainly from the 2600 system. Similar to POKEY where the TIA sound was simply "doubled" and a bit enhanced by the 16 bit , the GTIA got simply the double of the available moving objects. Even the TIA moving objects are based on Pong. Just to have the two paddles (Player) and the ball(s) (missiles) ....

...

As long as the sprite capability, accurate interrupts, CPU speed, etc. are present in some form or another, the game creation is more dependent on the creativity of the coder. C64 that were originally designed for that machine will be sub-par on Atari when ported and vice-versa. More colors are always a plus for games-- it increases the beauty.

 

That's true. It's only in the colours that the C64 can show some nice detailed pictures with some depth in the objects, while the A8 can show fullscreen pictures with a good optical depth of view , but the single details are often "flat".

 

Some evidence to suggest that they left some work incomplete is that there's exaclty 3-player worth of memory left over when you use the PMBASE register and the way the color indices work in gr.10 seems to be begging for some more color registers.

[Rybags]

The C-64 is too slow for effective sprite reuse horizontally anyway. And using interrupts on either system for anything horizontal is out of the question.

 

Not 100% here, but for digital audio - set the pulse wave with maximum duty cycle. Then, start a sound with 0 Attack.

Alter the sustain level, although I think you can only do it downwards. To go upward you need to initiate another attack sequence.

 

The side-effect is that you get a high-pitched background noise due to the pulse wave going to 0 level. Unsure if you can cancel it out or not using another voice.

 

Another method for digi is to just modify the master volume, but it's not useful if you also want other sounds as well.

[atariksi]

As long as the sprite capability, accurate interrupts, CPU speed, etc. are present in some form or another, the game creation is more dependent on the creativity of the coder. C64 that were originally designed for that machine will be sub-par on Atari when ported and vice-versa. More colors are always a plus for games-- it increases the beauty.

 

Too bad the VIC-2 chip couldn't have squeezed in a 16x8 palette RAM. That would have totally ruled.

 

Still, if I do Toyshop Trouble for the C64, I think I'll be able to have all the toys at high resolution with two colors/scan line each; the player elf will overlap a hires and a multicolor sprite, with per-line coloring on the hires one.

 

The Atari 800 would have a much nicer color palette, but I don't think it could do the player in high resolution at all; the toys would probably get either one color/line high-res or two in low res.

 

The C64 actually needs the wider sprites more than the Atari given lesser variety of graphics modes although a better text mode. If high resolution wasn't important in some application, you would still have to update your high-res graphics mode whereas Atari can switch graphics modes and do a faster update with a faster CPU clock (on a scan-line basis). This is actually true even for modern PCs where 1024*768*32 seems to be the norm but it's getting harder and harder with newer and newer OSes to switch to 320*200.

[TMR]

I thought they were claiming that they can also re-use sprites like Atari 800 (vertically and horizontally).

 

No, just that the C64 can reuse vertically and has more on a scanline horizontally than the Atari gets after recycling.

 

Atari 800 can re-use sprites on same scanline via DLI+NOPs or IRQ, so I was asking what divisor could you possible use on the CIA to do the same since the CIA clock is out of sync with the NTSC color clock.

 

As people have already pointed out, nobody uses CIA timer interrupts for VIC-II hammering - everything is done with raster interrupts instead.

[atariksi]

@atariski

 

aehmmm... maybe I am wrong but how would you move objects vertically or reposition by altering pmbase? esp. in a game like Joust? where all things can cross each other?

I was thinking that you need to share the HPOSes for the 4 players for every player AND modify PMBASE. What do you mean by cross each other-- through or going above or below? I don't think they go through.

[TMR]

The C-64 is too slow for effective sprite reuse horizontally anyway.

 

Actually it's not, the problem is that the VIC-II simply won't let programmers recycle sprites that way.

 

Another method for digi is to just modify the master volume, but it's not useful if you also want other sounds as well.

 

This is how the majority of sample players work on the C64 but it does work over the top of other sounds; have a listen to Mega Apocalypse during play (three SID channels and sampled sounds or speech) or the intro for Outrun Europa for a couple of random examples.

[Heaven/TQA]

PMs suck...

 

again...why should I trigger PMBASE?

 

via DLI I would do the vertical split but I would still need to shift data around and by setting PMBASE on a special raster line it would automaticly affect the other players in that zone?

 

so...look at your Joust example...

 

Player sprite is assigned to player 0. assuming one bird is assigned to 0 as well... so look:

 

........B.........
...................
...P..............
...................
................... 

-->

...................
.......B..........
...P..............
...................
...................

 

so again...now assume P & B overlapping as bird is falling down...now how would you solve your pmbase triggering in that case? as both are overlapping? so engine would assign the lower part of the bird where it overlapps the player to another hardware sprite .f.e. 1... so..now you have sprite gfx data in 0 and in 1 even maybe in another pmbase?

 

no...i guess you can not compare that to the Amiga ones... or did I got something wrong?

[Fröhn]

I don't think that explains the popularity of the C-64. Tramiel simply had better ideas for promoting the product and had the advantage of controlling MOS technologies. Pity he couldn't switch gears and quit thinking like a cutthroat mass marketer when HE got Atari.

Commodore never had any good marketting at all, just like Atari. It was the price (the cut-throat tramial stuff) and the games which sold the C64. Look below to see why this is so.

 

As long as the sprite capability, accurate interrupts, CPU speed, etc. are present in some form or another, the game creation is more dependent on the creativity of the coder. C64 that were originally designed for that machine will be sub-par on Atari when ported and vice-versa. More colors are always a plus for games-- it increases the beauty.

This is not true actually, let's have a look at Crownland for example: It took a very skilled coder and a lot of trickery and a lot of years of experience to get that sprite engine working, it's one of the best uses of the PM's I have seen on A8. But to do the same on C64 you would only need a beginner at programming because all the sprite action you can see there is already part of the VIC2 sprite capabilities. Infact, VIC2 can even do more than that out of the box. For example, due to the way of the multiplexing Crownland limits most sprites to a fixed Y-position. And sometimes it flickers when more than two Crownland sprites are on the same Y-position. You wouldn't have these limitations on a C64, you could have bigger sprites, free Y-positions, up to 8 sprites on a rasterline without flicker, sprite animations cause no CPU-load because every sprite has it's own sprite data pointer... And that's even BEFORE you start to do tricks on C64.

 

Do "venetian blinds" games on the 2600 have any problem with PAL units?

No, since it's the chroma which is mixed but not the luma. Chroma is much more subtile.

 

The VIC-2 "palette RAM" aka Colour memory is off-chip. Having it 8-bit would have meant needing 16 data lines instead of 12.

Turning the C64 color cell system to 8 bits takes 24 data lines. (Or twice the DMA cycles like the C16 is doing)

 

The C-64 is too slow for effective sprite reuse horizontally anyway. And using interrupts on either system for anything horizontal is out of the question.

Huh? In display area, the C64 is actually faster than the A8. The only thing which stops you from reusing sprites is the fact that the sprite shifter is empty after all bits have been pushed through.

[Heaven/TQA]

Fröhn... that's why I am tending to start c64 coding...simply because of the sprites...

[Rybags]

In the display area...

 

Atari = 114 cycles per line. "Badline" = 81 cycles lost, 33 free, other lines = 49 lost, 65 free (50/64 or 52/62 for Dlist fetches)

C64 = 65 cycles per line. "Badline" = 40 lost, 25 free, other lines = 65 free

 

of course, none of that takes into account PMGs or sprites if enabled. Does include memory refresh of 1 or 9 cycles.

 

So, for a basic 40x25 layout, the Atari does have more free cycles in the display region (just).

[Bryan]

Fröhn... that's why I am tending to start c64 coding...simply because of the sprites...

Yeah, but all this debate is meaningless. The A8 is the contemporary of the Vic-20 (which it trounces), not the C64.

 

-Bry

[atariksi]

PMs suck...

 

again...why should I trigger PMBASE?

 

via DLI I would do the vertical split but I would still need to shift data around and by setting PMBASE on a special raster line it would automaticly affect the other players in that zone?

 

so...look at your Joust example...

...

 

no...i guess you can not compare that to the Amiga ones... or did I got something wrong?

"PMs suck..." is hardly a sign that I should put time in replying...

 

It won't affect other players if all 4 HPOSes are being set or zeroed for players not existing in a zone. Anyway, I already have it working with one sprite that I want to use it for; for extending, I already recommended that one can use probability and statistics to drop back to memory moves for those positions not in one of the PMBASE combinations...

[emkay]

The A8 is the contemporary of the Vic-20 (which it trounces), not the C64.

 

And the C64 is the contemporary of the AMIGA.... The hardware development is mainly from the same "age"...

[Oswald]

The C-64 is too slow for effective sprite reuse horizontally anyway

 

 

count the sprites at 1:40.

 

 

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

 

check the screenshot, more than 8 sprites multiplexed over an area where in each rasterline background color is changed 7 times. the sprites are moving, and some of the raster colors aswell.

 

Another method for digi is to just modify the master volume, but it's not useful if you also want other sounds as well.

 

check the video, digis in there does work that way.

http://youtube.com/watch?v=cQNT9Whg4r4

Edited April 22, 2008 by Oswald

[atariksi]

As long as the sprite capability, accurate interrupts, CPU speed, etc. are present in some form or another, the game creation is more dependent on the creativity of the coder. C64 that were originally designed for that machine will be sub-par on Atari when ported and vice-versa. More colors are always a plus for games-- it increases the beauty.

>This is not true actually, let's have a look at Crownland for example: It took a very skilled coder and a lot of trickery and a lot of years of experience to get that sprite engine working, it's one of the best uses of the PM's I have seen on A8...

 

Actually couple of words got left out. C64 optimized games that were originally designed for that machine will be sub-par on Atari when ported and vice-versa. I.e., if you use the hardware resources of the Atari, you will have a hard time porting it to C64. Obviously, if you just write simple BASIC programs or ML programs, they can be easily converted one platform to another.

 

> But to do the same on C64 you would only need a beginner at programming because all the sprite action you can see there is already part of the VIC2 sprite capabilities. Infact, VIC2 can even do more than that out of the box. For example, due to the way of the multiplexing Crownland limits most sprites to a fixed Y-position. And sometimes it flickers when more than two Crownland sprites are on the same Y-position. You wouldn't have these limitations on a C64, you could have bigger sprites, free Y-positions, up to 8 sprites on a rasterline without flicker, sprite animations cause no CPU-load because every sprite has it's own sprite data pointer... And that's even BEFORE you start to do tricks on C64.

 

Once you start doing tricks, the same complaints you just pointed out will happen more so on the C64 due it's slower CPU speed.

I can show 8 sprites without flicker on one scanline and DLIs can split sprites into hundreds vertically without flicker. PMBASE is also like a sprite pointer and sprites being taller on the Atari can be preset with shapes if they are not to be used in vertical motion. So there are advantages and disadvantages on both sides.

[Fröhn]

In the display area...

 

Atari = 114 cycles per line. "Badline" = 81 cycles lost, 33 free, other lines = 49 lost, 65 free (50/64 or 52/62 for Dlist fetches)

C64 = 65 cycles per line. "Badline" = 40 lost, 25 free, other lines = 65 free

This calculation does not matter for two reasons: First, you have to switch the X-position of PMs on a certain X-position on screen which means free cycles in the sideborders do not matter at all. And 2nd, on badlines there are 0 free cycles in the area where you should switch the x-pos.

 

Basically both are equally fast because every 2nd bus cycle is lost for the bitmap DMA there. But A8 also has 9 DRAM refresh cycles per line which sometimes let's the CPU drop another cycle while the C64 DRAM refresh cycles are hidden to the CPU because they are placed into those 2nd "never visible to the CPU" bus cycles too.

[Oswald]

C64 optimized games that were originally designed for that machine will be sub-par on Atari when ported and vice-versa

 

80's type 2d games suits perfectly the c64. its not that they were designed for the c64. actually _most_ of the c64 games are to be found on other systems aswell, many of them coming from arcades or other machines.

 

Once you start doing tricks, the same complaints you just pointed out will happen more so on the C64 due it's slower CPU speed.

 

once you start doing tricks, games like turricans, last ninjas, creatures, mayhem in monsterland emerges on the 64. check them out if you havent already.

[Rybags]

The C-64 is too slow for effective sprite reuse horizontally anyway

 

 

count the sprites at 1:40.

 

 

Nice, but it's in the border region.

That won't work in the display area, and there's also the restriction that it has to reuse the same pixel data.

[frogstar_robot]

Commodore never had any good marketting at all, just like Atari. It was the price (the cut-throat tramial stuff) and the games which sold the C64. Look below to see why this is so.

 

Agreed. It's just that the market was changing when Tramiel came into Atari. When Commodore was a young feisty computer maker, all the "home computers" simply cost too much. This includes our beloved A8s. The C-64 debuted expensive but was cheaper first and was of decent manufacturing standard. So Tramiel created a window of year or so in which to sell an inexpensive computer that could nonetheless play great games. In such a market, that strategy is correct if you can make the economies of scale work for you. That's what made the C-64 the 8-bit king.

 

Fast forward a few years and anyone who wants a home computer or a PC can probably afford one. In this era, you still need a C-64, A8, or an Apple II in a pinch because while they may have been higher-res CGA/Hercules make for some ugly looking barely animated game screens. But PCs get better all time, price floors have been established, and things called NES and Master System start showing up at the local K-Mart. Tramiel gives us the XE line which represents a major drop in build quality from the XL and when the ST comes out, similar materials and methods are used. For awhile, he tries to compete on price alone while the ST changes little until the Megas come out. The Amigas evolved and more than a token effert was made to keep up with the Macs and PCs.

 

That cutthroat IKEA approach is great when there is untapped market to conquer. In a mature market, there is an expectation of quality and an expectation of parity with competitive systems. That is what just he didn't seem to get at all. For a number of years, the most popular upgrade for the ST was a set of keyboard stiffening springs while Amiga owners had all sorts of cool funky stuff to buy. Tramiel just kept selling the same increasingly stale wine in the same bottles with different stickers.

Edited April 22, 2008 by frogstar_robot