Atari v Commodore

[andym00]

Regards the 64s hardware collision being all but useless, yeah mostly that's true, but it does have some uses, especially when it comes to generating interrupts from sprite to sprite, or sprite to graphics collisions.. A one pixel sprite being used to generate positional interrupts when it 'collides' were handy sometimes, and were useful when people were fathoming out what the VIC-II was up to under it's borders because you can essentially sample the screen output from it..

Granted the positional stuff can be done other ways, but it's just one of the uses for it and something in it's arsenal for a rainy day

 

And no doubt in the very early days, having the collision detection was useful for people writing stuff in basic and learning the machine without having to overtly worry about how things like collision might work.. I for one used it in my earliest things I wrote when learning the C64 way back in the days..

Granted for a modern game it's toss, but in the first generation of C64 games (the really early ones!) I suspect it saw a lot of use, even with it's flaws

[Bryan]

not so flexible then in case of charmode. walking down will waste cpu time.

 

so, charmode instruction will "generate" 8 lines. bitmap mode instructions will make only 1 line? or you can either ask for 8 lines or 1 lines of any mode?

 

if not then how is this possible:

 

QUOTE (Rybags @ Wed Apr 22, 2009 2:47 AM) *

8 pixel boundaries are irrelevant. Atari can have 3 bitmap lines, a character line, 2 bitmap lines, a character line.

 

Normally, each Dlist entry can cause 1 interrupt and the next Dlist entry will not be fetched until a row of the selected mode is complete. That means 1 NMI per character row (on the last line).

 

However, the actual height of character rows (and other multi-line/low res modes) can be adjusted on the fly using VSCROL in your DLI. Usually, if you need changes on closely spaced lines you'll either do things in bitmap mode instead of char mode, or use WSYNC to walk through the lines.

[Heaven/TQA]

f.e. attachted a display list code:

 

.byte $4f,vram lo, vram hi ; Gr. 8 line highres

.byte $0f,$0f ;2x graphics 8 line

.byte $47,textline lo,textline hi ;gr.2 charmode line 16 scanlines hi

.byte $4e,vram2 lo, vram2 hi ; gr.15 line 160x 4 colour mode

.byte $0e ;another line

.byte $42;textline2 lo, textline2 hi ; gr.0 charmode line 8 scanlines hi

.byte $41, dlistplaylist lo, displaylist hi ; wait for VBL and restart displaylist

 

nothing special here...

 

you can multiply scanlines by triggering VSCROL register to duplicate scanlines by using internal ANTIC buffer.

 

 

the simple display list shows few features you can not do or only with trickery on VIC2... mixing modes, several different video ram... (here I am loading 3x times data from different adresses... no VIC bank limits here)

 

Graphics textline 2 has 20 bytes lines while the others have 40 bytes...

 

when I am doing a simple LDA #35 STA $d400 I am in overscanmode so each scanline has 24 bytes visible or 48 bytes visible...

Edited April 22, 2009 by Heaven/TQA

[carmel_andrews]

I think the C128 suffered from the same problems that the atari 130xe did...i.e very few companies were prepared to support the higher ram format (given that the c64 and the atari 800 and xl series were already accepted formats (not that much was specifically released for the XL series anyway)

 

Lovely sexy machine though (especailly the 'D' version) shame that tramiel didn't do likewise for the 130xe

[Wolfram]

f.e. attachted a display list code:

 

.byte $4f,vram lo, vram hi ; Gr. 8 line highres

.byte $0f,$0f ;2x graphics 8 line

.byte $47,textline lo,textline hi ;gr.2 charmode line 16 scanlines hi

.byte $4e,vram2 lo, vram2 hi ; gr.15 line 160x 4 colour mode

.byte $0e ;another line

.byte $42;textline2 lo, textline2 hi ; gr.0 charmode line 8 scanlines hi

.byte $41, dlistplaylist lo, displaylist hi ; wait for VBL and restart displaylist

 

nothing special here...

 

you can multiply scanlines by triggering VSCROL register to duplicate scanlines by using internal ANTIC buffer.

 

 

the simple display list shows few features you can not do or only with trickery on VIC2... mixing modes, several different video ram... (here I am loading 3x times data from different adresses... no VIC bank limits here)

 

Graphics textline 2 has 20 bytes lines while the others have 40 bytes...

 

when I am doing a simple LDA #35 STA $d400 I am in overscanmode so each scanline has 24 bytes visible or 48 bytes visible...

 

 

So, the end of the line says: c64 can trigger raster irq anywhere, a8 can only do it if you adjust the mode lines so that only 1 line of them is visible everywhere. in the "real life" cases a8 does a dli only each 8 pixel. I was far from being wrong.

 

 

"the simple display list shows few features you can not do or only with trickery on VIC2"

 

you just said it. the forbidden word! "trickery" ! A8 users insist that G2F and such modes are not a trickery, and they also insist that there is no difference between "built in" and "cpu driven" modes, everything is built in there's no trickery they say...

 

So now why should I accept that there are things on the VIC2 that can be called trickery ? Everything is built into the VIC2 aswell, just need to make use of it with the cpu

[Wolfram]

I think the C128 suffered from the same problems that the atari 130xe did...i.e very few companies were prepared to support the higher ram format (given that the c64 and the atari 800 and xl series were already accepted formats (not that much was specifically released for the XL series anyway)

 

Lovely sexy machine though (especailly the 'D' version) shame that tramiel didn't do likewise for the 130xe

 

Imho the c128 was simply too compatible, this made it not possible to offer more features. what was there as new features was not enough. It should have been using a VIC3 (least new features: VIC2 modes extended to 640x, the 16 colors selectable from a palette). and the 658c16 at atleast 4 mhz.... and maybe a dma for the icing on the cake. The 1571 drive was o.k. it could have supported such a machine nicely.

[Rybags]

The Atari only does DLIs coinciding with just before mode lines. So what?

 

That's 95% of the application of such interrupts, or more. In the other cases, you might sit there burning a few cycles.

 

C-64, you're burning cycles in many cases since you have no WSync and need to do a double-trigger with the first one executing short instructions, and even then you only land on something like a known 2 or 3 cycle boundary.

[Heaven/TQA]

I used the word trickery before we had a looong discussion with Oswald year ago... and I knew that you will jump on it...

 

you are polemic... I can trigger rasterlines everywhere via IRQs, too... If I am using the DLI feature of ANTIC then it depends on the display list... simple as it is...

[Wolfram]

The Atari only does DLIs coinciding with just before mode lines. So what?

 

That's 95% of the application of such interrupts, or more. In the other cases, you might sit there burning a few cycles.

 

C-64, you're burning cycles in many cases since you have no WSync and need to do a double-trigger with the first one executing short instructions, and even then you only land on something like a known 2 or 3 cycle boundary.

 

 

full ack. I agree

 

nitpicking1: you dont need wsync for a simple gfx mode change (not even for simple raster color bars) just enough nops to push the flickering to the invisible horizontal area

nitpicking2: you can "stablize" an irq within a line, but it needs a lot of effort

[Fröhn]

The Atari only does DLIs coinciding with just before mode lines. So what?

 

That's 95% of the application of such interrupts, or more. In the other cases, you might sit there burning a few cycles.

Sprite multiplexing is a major reason to have IRQs not bound to character lines.

 

C-64, you're burning cycles in many cases since you have no WSync and need to do a double-trigger with the first one executing short instructions, and even then you only land on something like a known 2 or 3 cycle boundary.

WSYNC is not as important as you might think. For most things (sprite mux'ing, rasterbars, screen splitting, sprite stretching, open upper/lower border etc) you don't need it.

Edited April 22, 2009 by Fröhn

[Wolfram]

I used the word trickery before we had a looong discussion with Oswald year ago... and I knew that you will jump on it...

 

you are polemic... I can trigger rasterlines everywhere via IRQs, too... If I am using the DLI feature of ANTIC then it depends on the display list... simple as it is...

 

 

huh? Yeah, I know you havent used here the word trickery, I am basing this on conversations with atariksi/emkay and dont know who else was claiming this.

 

you can use IRQs too. You can thank god I am not atariksi, because I would go on until the end of the world that you can use only DLI's for that, and that would be still more fair than as he wants to force c64 "joystick I/O" be compared with a8 "joystick I/O". because DLI's are ment to do that, but c64 joystick port is not

[frenchman]

I always enjoyed this advert from USA magazine Electronic Games:

[potatohead]

That's a great AD!

 

Setting aside the classic computer discussion, if we only knew how many times computer companies would ship a kludge, then sell the fix!!

[+SpiceWare]

It's a shame they didn't at least pipe the VDC through the composite out, the ST had 640x200 output on the RF/Composite/RGB-A

Wiki has a photo of CGA going thru via composite, it's not pretty though it would have been nice to have it as an option. The VDC does have a monochrome signal, a few of my friends went that route with their older Commodore monitors.

 

I suspect Commodore added the 80 column chip instead of improving the VIC's 40 column abilities as a number of 80 column display adapters were sold for the 64.

[Fröhn]

Composite cannot handle the 640 px resolution. Even 320 is pretty much at the limit what composite can do.

[carmel_andrews]

Was the epyx 'fast cartridge' the originator of all those c64 'turbo' or non standard 'hi speed' disk loaders

 

I seem to remember the popular UK c64 hack carts like Datels Action replay, The expert cartridge etc also came shipped with different warp loaders built in

[+wood_jl]

Composite cannot handle the 640 px resolution. Even 320 is pretty much at the limit what composite can do.

 

 

That's what I always thought, since the 8-bit days. How the modern game consoles manage to look so good over composite is a mystery. Even the Playstation-1 must be doing better than 320 though, right? The old Xbox certainly must be doing a 640 resolution, eh? It looks relatively good over cheap ol' composite although the better connections look a little sharper. How are they doing that, and why couldn't the computers that did 640 resolutions (ST, etc) look as good as an old Xbox over composite?

[Fröhn]

That's what I always thought, since the 8-bit days. How the modern game consoles manage to look so good over composite is a mystery. Even the Playstation-1 must be doing better than 320 though, right? The old Xbox certainly must be doing a 640 resolution, eh? It looks relatively good over cheap ol' composite although the better connections look a little sharper. How are they doing that, and why couldn't the computers that did 640 resolutions (ST, etc) look as good as an old Xbox over composite?

Yes it's doing 640 px but over composite you will only get blurred stuff which has an effective resolution of ~320 (but looks smooth at that). Y/C or RGB is a different matter ofcourse.

[atariksi]

...

Obviously I'm not talking about making a bounding box at a pixel size. Is there something about the word 'approximation' that you fail to understand? And is your thinking truly so limited (binary, even) that you perceive the only options available as being a single large bounding box or pixel perfect collision, with nothing in between. Stop trying to push a false dichotomy to support your position. It's intellectually dishonest.

...

It's NOT obvious. You stated that you can use bouding box and missiles will still be allowed to go under arms. Now you want to approximate it. It's clear.

 

>Again, who said anything about a bounding box the size of a pixel? You're really shameless, aren't you.

...

You can't admit you screwed up.

[atariksi]

Good games do a bounding box based collision detection anyway. It's always a horror when a game lets you die because the out pixel at your shoe touched the topmost hair pixel of a bad guy.

 

Quoted for the truth.

 

Quoted for being a biased sidekick.

If you can't present it in poem-style, then you have no point!

 

No, seriously, what Frohn stated is just how the more advanced C64 shmups do it. And the less frustrating ones use a hitbox that is a _little_ smaller than the sprite for the player and maybe one that is a _little_ larger for the enemies.

 

I don't know though whether the better A8-shmups use hit-boxes or the collision regs, perhaps one of the experienced A8 hackers here can shed a light on this?

 

The point still stands-- Atari has 60-bits of collision registers (in hardware) and to make up for that C64 has to rely on software techniques which hog up CPU time. Of course, C64 games won't use hardware collision registers-- they HAVE to rely on software. I did collision register useage for a menu selection system-- works great and buttons can be any shape.

[atariksi]

Regards the 64s hardware collision being all but useless, yeah mostly that's true, but it does have some uses, especially when it comes to generating interrupts from sprite to sprite, or sprite to graphics collisions.. A one pixel sprite being used to generate positional interrupts when it 'collides' were handy sometimes, and were useful when people were fathoming out what the VIC-II was up to under it's borders because you can essentially sample the screen output from it..

Granted the positional stuff can be done other ways, but it's just one of the uses for it and something in it's arsenal for a rainy day

 

And no doubt in the very early days, having the collision detection was useful for people writing stuff in basic and learning the machine without having to overtly worry about how things like collision might work.. I for one used it in my earliest things I wrote when learning the C64 way back in the days..

Granted for a modern game it's toss, but in the first generation of C64 games (the really early ones!) I suspect it saw a lot of use, even with it's flaws

 

Yeah, the argument starts by the factual statement Atari has 60-bits of collision hardware registers whereas C64 has 8-bits of collision + 8 bits of vague collision. Then the famous Frohn argument that obviously follows-- it's useless since it's easy to do with bounding box. So pixel perfect hardware collision detection is useless since that's an Atari advantage, but bounding box is better although it uses up CPU time. What logic! And on top of that, we know that sprite shapes are generally not boxes.

[potatohead]

I ran CGA over composite back when I built up my first XT class PC. The 80 column was really great on a monochrome display (Apple Type), or with luma only on a TV. Just had to kill, or ignore the color burst and all was pretty good.

 

There are basically two levels of composite NTSC.

 

Fixed color timing (Atari, CoCo, Apple, PC, Others...) This has a base color resolution of about 160 pixels, in the safe area like we've discussed here. One trick is to clamp down on the color signal making a sharp pixel. You still get the 160 pixel color resolution, in that a red pixel will appear in a slightly different position on the screen from where a blue pixel would appear, but by clamping down on the chroma signal, it is possible to limit the smearing. The resolution then ends up being closer to 320, with bigger color wheel changes looking worse than smaller ones are.

 

If that same thing is done with alternating color timing, everything doubles to 640 pixels.

 

Composite really can't do more than 320 in the safe area and see most all of the color changes rendered correctly. Most displays won't even do that. The older they are, or cheaper they are, the worse they are. A good PC capture card, or studio monitor quality display is as good as it gets.

 

From there it's all about the art direction. Because the luma changes can go higher than 320, implied resolution then is higher. Poor on text, but pretty nice on most everything else.

 

Look at an episode of SG-1, or Atlantis sometime. Looks really great on composite right? Now go look at an episode of the older STAR TREK. Looks quite a bit worse. Same standard, different impressions.

 

In the 60's color art direction was all about big, bold and higher contrast. This reflected the display properties and viewer expectations of the time. (displays being fairly lousy, often not even able to differentiate between alternating phase color and static phase color very well, and viewer expectations were low as well, given color TV was essentially new)

 

Now, displays are a lot sharper, meaning the full 320 pixels are possible and expected with the advent of computer monitors, DVD video, HDTV, etc...

 

The art direction changed to reflect that and leverages implied resolution to a much higher degree.

 

On the old STAR TREK, sharp color contrast and transitions are everywhere. And almost no detail on the screen was small enough to pose a problem. Look at SG-1, and everything has a color space that's fairly narrow on the color wheel, but with lots of interesting luma transitions. That is how it is done!

 

Also the difference lies in saturation. Again, older programming used fairly high color saturation for a bolder, low resolution look. The intro credits for SG-1, look a lot sharper and more detailed, and they are, just not in the color space. This is mostly luma, with more of a hint of color at low saturation, suggesting to the eye, more detail than is really there.

 

When I look at modern game consoles, these things are put to good use. High color depth displays means antialising pixels are available to imply resolution, and this combined with sub-pixel motion ends up looking a whole lot better than it really is. If you get up close to the display and watch a slowly moving object, subtle color transitions are a part of the motion, just as much as everything else is. The eye is fooled into "seeing" a lot more resolution than is really there.

 

If, for example, the C64 had more of a palette, the 320 resolution could easily look higher, particularly on moving object, because sub-pixel movement would render as pixel color and luma transitions as much as it would actual movement among pixels.

[atariksi]

...

C-64, you're burning cycles in many cases since you have no WSync and need to do a double-trigger with the first one executing short instructions, and even then you only land on something like a known 2 or 3 cycle boundary.

WSYNC is not as important as you might think. For most things (sprite mux'ing, rasterbars, screen splitting, sprite stretching, open upper/lower border etc) you don't need it.

 

WSYNC is more important than you think. There's the famous Frohn argument-- it's an A8 advantage so it's useless (or not that useful in this case).

For most things, you don't need hardware collision registers (BECAUSE YOU DON'T HAVE THAT MANY).

For most things, you don't need WSYNC (BECAUSE YOU HAVE TO FIND AN ALTERNATIVE).

[atariksi]

...

and to answer your question... yes... you can trigger DLIs via the Display list...so your 8 pixel example only is right when using DLI and 8 line generating display list command... so...when using DLI feature in f.e. charmode then yes...in general only triggered at the beginning... but you can walk "down" by doing STA WSYNCs f.e.

 

or

 

you can use POKEY IRQs to have interrupts on a special scanline or even on a special point on screen...

 

many ways to go...

 

Yep, and the accuracy of the POKEY IRQs is 2 color clocks (higher than C64). And once you sync up with WSYNC writes and then do write to STIMER, you can sync up to frame using base frequency of 1.789790Mhz (29868 cycles/frame on NTSC). And on top of that if you switch base frequency to 15.6999Khz, you get the scanline interrupt which occurs at same point on the scanline if your instructions in the background are aligned.

 

Once again here although the CIA is superior chip, it's timer uses a lower frequency so is less accurate just like it's inferior to PIA in joystick I/O.

[Heaven/TQA]

I always enjoyed this advert from USA magazine Electronic Games:

 

hahaa...