Atari v Commodore

[Oswald]

If I'd had to choose if I want a colorful (well sort of... a few colors more than on c64) ping pong table or turrican.. guess which one would I choose

You just desperately refuse to admit that the Atari version of the table looks better; there's no other explanation why would you use Turrican as argument. I never said that this Ping Pong game on atari would look better than any other game on the C64.

 

I admit that the atari version of a gfx 20 years later and using pc tools looks better than the 20 year older c64 counterpart tho it would have been a 4 color table if it were ported at the same year, speaking of a fair comparison...

Edited December 4, 2008 by Oswald

[maximebeauvais]

40 pages in 14 days WOW I have to say something here:

 

I like Commodore but I love atari

[Rybags]

The Atari table could have been done just as easily before the XPD tools came along.

 

It could be improved even further without a huge effort.

 

The C-64 simply can't do it, full stop. It would have to compromise with luma transitions which entails using totally wrong colour combinations.

[Crazyace]

I did not understand your diagram, but you have the multicolor sprites at position 0, 16, 32, 48, ... in PMBase 0. You have the same sprites at position 1, 17, 33, 49... in PMBase 1, and so on until PMBase 15. So it's sort of a warped memory look-up table. The lower nibble of Y position is goes into PMBase (+Starting addr in memory of all PMBases). The higher nibble of Y determines the scanline where to cause interrupt.

 

But this system doesn't work for more than one object.

 

Also there must be quite a large over head in setting up the interupts to handle this - I guess you are using timers, as DLI's may only be occuring on character boundaries? How many cycles are taken up by the overhead of your two interupt routines per frame?

[Fröhn]

The Atari table could have been done just as easily before the XPD tools came along.

I'd like to disagree. Especially with graphics and sound things that are done have a very strong correllation to the tools available to make them. Ofcourse theoretically somebody could have typed those gfx in a hex editor in 1979, but that's VERY theoretic, isn't it?

 

It could be improved even further without a huge effort.

Ofcourse, same is true for the C64 version btw.

 

The C-64 simply can't do it, full stop. It would have to compromise with luma transitions which entails using totally wrong colour combinations.

Or use dithering... or enhance the surrounding area too etc etc.

[Heaven/TQA]

I have to admit... the C64 Ping Pong could be patched to use sprite overlays to get some nicer gfx, too?

[Oswald]

The C-64 simply can't do it, full stop. It would have to compromise with luma transitions which entails using totally wrong colour combinations.

 

 

omg, c64 pictures use totally wrong colour combinations !!!!!!1111 totally right color combinations has no compromise!!!!111 its the very same colour!!!!!1111

[Oswald]

I have to admit... the C64 Ping Pong could be patched to use sprite overlays to get some nicer gfx, too?

 

no it cant because that would be totally wrong color combinations!!!!!1111

[Bryan]

C64 don't even have normal red color.

The Atari doesn't have a very good red either. You have to keep the brightness down to avoid getting pink.

[Heaven/TQA]

Bryan... Yes... --> International Karate.

[Bryan]

Sorry my PC does not have any sprites nor can Amiga sprites do 24 pixel width.

You do realize that things like sprites are workarounds for systems with limited CPU power. If you've got a 2GHz processor and a little bit of RAM, you can have all the sprites you want.

 

The lower resolution timers can be done in software using higher resolution timers. We are talking timer accuracy at max on each system: Atari is 1.78979Mhz w/16-bit divisor, Amiga CIA is 7.14Khz but you can combine with Audio Intr as timer IRQs, PC timer freq is 1.19318Mhz (standard PCs-- new nonstandard HPET doesn't qualify as most PCs don't have it nor can access it directly via applications), C64 is 1Mhz CIA frequency.

99% of programs don't need more than VBLANK and occasional HBLANK timing. I don't know if this is really a big issue.

 

No, Gameport is for games-- you know Mov DX,201h; IN AL,DX that interface is standard on all PCs with gameport. Atari standard is LDA 54016. C64 is LDA $DC01. Amiga is Move.b $DFF0nn,D0 followed by some XOR algorithm. Not comparing CPU speed but more instructions/processing on PC than all other platforms. It takes about 1 ms to read joystick on PC and stick is analog (less control than other three systems).

The old PC gameport was an absolutely horrible design. Most games used the keyboard. I don't think it's really an issue today, though.

 

You can take over amiga with simple Move.w $7FFF,$DFF09E, Move.w $7FFF,$DFF09a.

Similar on Atari/C64. But on PC, you can't tell physical addresses from linear or virtual; you can't do I/O w/o OS intervention, etc. H/W is nonstandard so even if you do IN AL,61h to read PC keyboard, it won't run on system w/USB keyboard. VGA card is nonstandard nowadays as well so you can't tell where it's physically mapped unlike older cards where it's always at $A000:0000. You can't call API calls in real-time programming unless you know worst case timing of the API call.

The PC is a totally different animal, but it doesn't really matter. It's so fast that your code executes very quickly and you simply meter the speed at certain points (fps control and whatnot). You'll never have that "real" control over the system, but PC games seem to do just fine without it.

[Rybags]

PCs do have sprites and they are used.

 

Games like Far Cry and Crysis render up close vegetation in 3D. Further away stuff is just sprites in 2D.

 

The Windoze mouse cursor is also a sprite.

[Bryan]

On PAL the color clock resolution is 200.

 

Also, there is no "sampling" of the color carrier going on. It's a simple analog circuitry which converts average amplitude + phase shift to color offsets. For example, on PAL the color carrier is delayed in the delay loop for exactly 1 rasterline, so every line the math is like this:

 

U = C(prev_line) + C(current_line)

V = C(prev_line) - C(current_line)

 

(expecting that in a normal TV picture the chroma doesn't change too much from one rasterline to another)

 

That's why those 256 color modes works, and that's also why they don't work on NTSC because NTSC decodes colors differently.

I wasn't talking about how GTIA generates color. I was talking about how it generates pixel data.

 

The Atari can change the color at the 160 rate. It can change the luminance at the 320 rate and does so by expressing sequences of PF1 of PF2 lum bits on opposite phases of the pixel clock. He asked if the color could change at that rate and I said no, because it can't. Internally, GTIA clocks pixels at the 160 rate.

[emkay]

I have to admit... the C64 Ping Pong could be patched to use sprite overlays to get some nicer gfx, too?

 

no it cant because that would be totally wrong color combinations!!!!!1111

 

Those weird colour combinations of the C64 seem to make some people crazy.

[Bryan]

If anything, Atari could probably lay more claim to Plug & Play than it could ever hope to for USB (SIO devices downloading drivers, XL/XE PBI protocols etc).

It's cool how forward-thinking the A8 engineers were in this regard. Atari didn't invent these things, but they did consider how to eliminate problems for the user. Ever try to connect two 1541's to the C64?

[Bryan]

indeed, it does have more important things than 128/256 colors.

I doubt that.

Also, A8 has even more important things than that.

 

I can't really agree here. The A8 has a large palette, but limited bit depth. The 64 has greater bit depth bit limited colors.

 

The result is A8 games generally have less coloring, and 64 games have certain sameness from the lack of color choices.

 

C64 programmers see a program and go, "there's color 7, color 2, etc..." Most 8-bit systems don't offer a palette as good as the 64's, though.

[TMR]

It's cool how forward-thinking the A8 engineers were in this regard. Atari didn't invent these things, but they did consider how to eliminate problems for the user. Ever try to connect two 1541's to the C64?

 

[Looks at two 1541s and a 1581 connected to his C64] Erm yeah, easy enough...?

[Oswald]

If anything, Atari could probably lay more claim to Plug & Play than it could ever hope to for USB (SIO devices downloading drivers, XL/XE PBI protocols etc).

It's cool how forward-thinking the A8 engineers were in this regard. Atari didn't invent these things, but they did consider how to eliminate problems for the user. Ever try to connect two 1541's to the C64?

 

yeah, they can copy a whole disk without any c64 interaction. great stuff

[Bryan]

i'd argue the toss over that because the interrupts may make juggling the sprites easier but they take CPU power in the process; looking at my own DLI code there's stashing and unstashing of registers to do at each end (pha / txa / pha / tya / pha, that bit alone is thirteen cycles per iteration and it's reversing that as well) and then the actual handling code between them and that adds up if you're kicking in an interrupt several times a frame.

 

I rarely push all the regs in a DLI unless it's going to run for many lines. Also, it's faster to set aside some P0 space for the DLI since nothing else can run anyway:

 

pha

stx $10

sty $11

 

pla

ldx $10

ldx $11

[Bryan]

CPU jitter? WTF is that?

I think he means the indeterminate interval between instructions when interrupts can happen.

[Bryan]

What do you A8 people have with these "color clocks"? They don't matter to the CPU or timer clock at all anyway since there are different divider for PAL and NTSC. The timers run with CPU clock speed on both systems. And on both systems you can accurately target ANY CPU cycle on screen (if the CPU can react on that cycle is another question).

NTSC programmers use the term "color clock" to represent a Mode E pixel since they're the same size. It avoids confusion unless you're talking to PAL programmers who have separate pixel and color clocks.

 

So, you can usually substitute '160-pixel' for 'color clock'.

[Bryan]

The whole purpose of the IRQ was to factor out the WSYNC (which can cause some cpu cycles to be lost). It's stable w/o WSYNC.

IRQs are NOT stable without WSYNC. They may APPEAR to be stable because you use a JMP-eternal loop as main program, but that is only stable if the rastertime outside IRQs is exactly dividable by 3 (the amount of cycles the JMP takes).

Fröhn is correct. Make a DLI that only changes the background color and watch it wiggle.

[Bryan]

As I stated, "If you know your code." Another way to put it is that code must be aligned on boundaries so when IRQ hits, it's not in the middle of the instruction.

Spoken like a true 2600 programmer.

[Bryan]

PCs do have sprites and they are used.

 

Games like Far Cry and Crysis render up close vegetation in 3D. Further away stuff is just sprites in 2D.

 

The Windoze mouse cursor is also a sprite.

The PC itself has nothing. Your graphics card may have sprites...

[Garak]

[Looks at two 1541s and a 1581 connected to his C64]

 

I have a 1541C, 1541-II, and a FD-2000 connected to mine.

 

Erm yeah, easy enough...?

 

I thought so. No problems here either.

 

Garak