Atari v Commodore

[Gorf]

It's that river in Egypt again.

 

What, just because xxl said it didn't use any 6502 power you mean? =-)

 

 

No comparing the register write trick on the C64 with the DLI's. You wont achive

the same thing. You dont have the graphic modes in the C64 and I dont think you

can change grphics modes per scan line of the fly with the C64.

[Fröhn]

No comparing the register write trick on the C64 with the DLI's. You wont achive

the same thing. You dont have the graphic modes in the C64 and I dont think you

can change grphics modes per scan line of the fly with the C64.

You can not even change gfx mode every scan line, but also in the middle of scan lines. Also as mentioned before: You can use the sprites as a totally independent gfx layer (independent in movement + mode).

Edited April 1, 2009 by Fröhn

[TMR]

No comparing the register write trick on the C64 with the DLI's. You wont achive

the same thing.

 

No, but that was a display list rather than a DLI and i believe (since i don't recognise the macro format and the smiley in the middle certainly didn't help) it was generating 192 DMA pulls at 40 cycles a piece; the claim that there was "no 6502 usage" when there are over 7,000 cycles taken by that display list is rather bogus, isn't it.

 

You dont have the graphic modes in the C64 and I dont think you can change grphics modes per scan line of the fly with the C64.

 

Raster interrupts are far more flexible than you're giving them credit for, they can split between bitmap and character on a scanline by scanline basis, wait a few cycles and change modes halfway across a scanline and toggle from character mode to bitmap or vice versa can happen halfway down a character line to get four scanlines in character mode and the other four in bitmap (is there a way to truncate a character line or start it late in a display list that i'm not aware of?)

[emkay]

It's that river in Egypt again.

 

What, just because xxl said it didn't use any 6502 power you mean? =-)

 

 

No comparing the register write trick on the C64 with the DLI's. You wont achive

the same thing. You dont have the graphic modes in the C64 and I dont think you

can change grphics modes per scan line of the fly with the C64.

 

 

Picture comparision:

 

168x240 resolution with up to 256 colours FX here....

 

[Rybags]

(is there a way to truncate a character line or start it late in a display list that i'm not aware of?)

 

Yes. VScrol tricks.

 

Like the low-DMA GTIA modes as used in Numen. You can stretch what normally would be a 1 pixel high bitmap mode into anything from 2 to 16 high.

 

With character modes, you can truncate the normal 8x8 down to 8x6, 8x4 or even 8x1 if you wanted to.

 

You can also make character modes larger, although the CPU expenditure of having to change characterset pointer halfway down makes it kinda pointless - much cheaper to just use a LMS+DLI to repeat the current row.

Edited April 1, 2009 by Rybags

[TMR]

With character modes, you can truncate the normal 8x8 down to 8x6, 8x4 or even 8x1 if you wanted to.

 

Do you ge arbitary choice of start and end positions as well?

[Rybags]

Kind of.

 

Start of a "scrolling region" can be any row in the char, although you're then committed to showing the remainder in it's entirety unless you halt DMA (and therefore get background).

 

Last character in the scrolling region you start at row 0 and can end at any position.

 

I'm going to try a special interlaced mode - probably use 6 pixel high characters with a character set per field = 12 pixels high. Have a Mode F line in between each row of characters to provide spacing, plus it gives a cheap way of getting around the start/end limitations, ie use it as the start of your scrolling region which allows the character lines to all have the same start/end pixel rows.

[xxl]

> It's that river in Egypt again.

 

it is kind of idiom? i dont know what it mean.

 

> (since i don't recognise the macro format and the smiley in the middle certainly didn't help)

 

:192 dta LMS + GR8, a ( apple_ekr + ( ( # % 8 ) * $400 ) + ( ( # % $40 ) / 8 ) * $80 + ( # / $40 ) * $28 )

 

this DL (Display List - not DLI) display Apple2 screen in 50fps (antic, no 6502), on c64 you should copy (cpu) 192*40 bytes every frame, doable?

 

ok, maybe this one:

 

:64 dta LMS + GR8 , a ( zx_ekr + ( # / 8 ) * 32 + ( # & 7 ) * $100 )

:64 dta LMS + GR8 , a ( zx_ekr1 + ( # / 8 ) * 32 + ( # & 7 ) * $100 )

:64 dta LMS + GR8 , a ( zx_ekr2 + ( # / 8 ) * 32 + ( # & 7 ) * $100 )

 

the same but with zx spectrum screen (50fps . point is that on atari you can do it on coprocessor (antic) so cpu is free (even with dma is on a8 is faster)

 

what is better a8 or c64? i dont know... in some tasks zx spectrum is far more better.

 

ach, someone told that 1 dac can do the same as 4 dac... i dont think so. i check something today, 3 channel music where one channel is playing on two dac and even i hear difference.

[TMR]

> It's that river in Egypt again.

 

it is kind of idiom? i dont know what it mean.

 

The river in Egypt is "the Nile", which rhymes with "denial".

 

this DL (Display List - not DLI) display Apple2 screen in 50fps (antic, no 6502), on c64 you should copy (cpu) 192*40 bytes every frame, doable?

 

No, but as i said throwing over 7,000 cycles at the job when you're converting a game seems overkill. Personally, i'd go into the game and rewrite the draw routines for the A8's screen layout because the odds are they could well be optimised in the process.

 

the same but with zx spectrum screen (50fps . point is that on atari you can do it on coprocessor (antic) so cpu is free (even with dma is on a8 is faster)

 

Oh come on, you know as well as i do that these display lists are taking cycles away from the CPU, the 7,000 plus lost through the Apple 2 system is dropping a considerable amount of time each frame.

[TMR]

Kind of.

 

Start of a "scrolling region" can be any row in the char, although you're then committed to showing the remainder in it's entirety unless you halt DMA (and therefore get background).

 

So not as flexible as the C64 then, every scanline can toggle in and out of bitmap mode pretty much as the programmer sees fit and if memory serves the transitions can happen halfway across the scanline so the left half will be bitmap and the right character or whatever.

[Bryan]

Kind of.

 

Start of a "scrolling region" can be any row in the char, although you're then committed to showing the remainder in it's entirety unless you halt DMA (and therefore get background).

 

So not as flexible as the C64 then, every scanline can toggle in and out of bitmap mode pretty much as the programmer sees fit and if memory serves the transitions can happen halfway across the scanline so the left half will be bitmap and the right character or whatever.

 

Actually, you can fool Antic by playing with VSCROL. Castle Crisis generates characters that are 7 lines tall by setting VSCROL just before and after the start of the first character line.

 

Edit: Or are you talking about changing mode mid-line? It would have been cool if the mode register was memory mapped, although this feature would be more useful in GTIA than Antic.

Edited April 1, 2009 by Bryan

[emkay]

The river in Egypt is "the Nile", which rhymes with "denial".

 

 

Only in english pronouncing. Orginal pronounce is "Neel" which rhymes with "appeal"

It seems people still have to learn that their opinion is just one of 6 Billion people. Just as their knowledge and their learning in a lifetime.

But, the truth ist, every day a new human is born that has to learn everything. So If one has teached 6 Billion people the same, he has to start right from scratch then.

 

That's why the Atari vs. Commodore Thread never will end...

[Crazyace]

Isn't it best to concentrate on the way the Atari is competitive with ( and better in some areas ) than the c64 - which is a 3 year newer design, rather than blindly denying the things that the C64 is actually better at!

( It's a bit like comparing C64 with Amiga the gap there is 3 years as well )

[atariksi]

Isn't it best to concentrate on the way the Atari is competitive with ( and better in some areas ) than the c64 - which is a 3 year newer design, rather than blindly denying the things that the C64 is actually better at!

( It's a bit like comparing C64 with Amiga the gap there is 3 years as well )

 

Isn't it better not to assume Atari is only "better in some areas"?

[atariksi]

You are changing the subject. Pacman Atari is better than Pacman C64 (perioed). NO excuses. Remember we're comparing games as one of the topics here.

...

If i were more of a cynic i'd assume that since the conversion was done by Atarisoft there's always that chance that whoever wrote it was under pressure to not produce a superior version to their own Atari code... but i'm not. =-)

 

...

Well, earlier in the thread you were claiming Atari came and told you there's no multicolor player stuff so that argument would go against that one.

 

>But it's not biased because that wasn't the question; it was about smoothness and for games with multi-speed scrolling or fixed speed games that require half pixel movement that extra resolution means the C64 will always be either as smooth or in many cases smoother.

 

For TV-based machines, half-pixel movement in color modes like 160*200 isn't that useful as luminance modes where it's doable on Atari. And even if you find some use for it, that's one part of the scrolling hardware. It's better to have pointers to memory areas when scrolling than have to to use LDA/STAs every time you scroll a byte.

 

>Unless i missed something, that doesn't work on 160 pixel resolution graphics because they can't be shifted half a pixel over the two buffers.

 

See above. However, you do have a choice to mix the 320*200 mode with 160*200 mode at any scanline with one cycle DMA of DL.

 

>It's only vague if you remove it from the original context where it was a direct reply to your saying "So if you are enhancing an image with sprite overlays, expect every 20 or so lines to see no enhancements (glitch depending on image)". As a response to that it's quite specifically saying that there are several existing examples that disprove what you've said, which there are.

 

Okay, so you were being vague about the resolution of your overlay.

 

>>You need to change to new shape ptrs every 21 scanlines (200/21 = 10 times per frame) so you need 10 screen RAM areas

 

>No, you only need two and simply alternate back and forth, changing the one that isn't in use when the sprite Y positions are adjusted.

 

So now you got the CPU involved even more by copying data to sprite pointer areas.

[atariksi]

hmmm.... been quite awhile away from Atari due to personal things and getting Mac OS x on my Samsung NC10 for the iphone SDK.... (working now btw... )

 

I can not see how you would get the highres pixel resolution of c64 (320x hpos for sprites & scrolling) on A8? ok. you can do the speccy way in Antic F but I can not see a way to go 1/2 color clock resolution in Antic 4/E without heavy colour glitches?

 

Yeah, I was only talking graphics/text screens. I thought C64 sprites were 0..159 unless you make them monochrome than you get 0..319 but then you have to start writing to two registers to set the xpos.

[Heaven/TQA]

I can not see how you would get the highres pixel resolution of c64 (320x hpos for sprites & scrolling) on A8? ok. you can do the speccy way in Antic F but I can not see a way to go 1/2 color clock resolution in Antic 4/E without heavy colour glitches?

 

Antic F can be done with two buffers offset by a pixel to pick up the difference, display buffer 1, display buffer 2 which is offset one pixel to the left, flip back and move the hardware scroll. i was pondering about doing a tech-tech that way when i last thought about demo code, but i wouldn't use it for a game personally.

 

sure...but read carefully... I was talking about antic 4/e.... with speccy method I was describing the "ROL" method... not the double buffer thing.

[Heaven/TQA]

unfortunatly not... c64 has 320x pixel resolution for scrolling/sprites neverless the gfx mode you are using... (mono/multicolour)

 

I was not aware of this little nice feature before I was porting Venus Express from C64 to A8... but well...

 

 

hmmm.... been quite awhile away from Atari due to personal things and getting Mac OS x on my Samsung NC10 for the iphone SDK.... (working now btw... )

 

I can not see how you would get the highres pixel resolution of c64 (320x hpos for sprites & scrolling) on A8? ok. you can do the speccy way in Antic F but I can not see a way to go 1/2 color clock resolution in Antic 4/E without heavy colour glitches?

 

Yeah, I was only talking graphics/text screens. I thought C64 sprites were 0..159 unless you make them monochrome than you get 0..319 but then you have to start writing to two registers to set the xpos.

[atariksi]

No comparing the register write trick on the C64 with the DLI's. You wont achive

the same thing. You dont have the graphic modes in the C64 and I dont think you

can change grphics modes per scan line of the fly with the C64.

You can not even change gfx mode every scan line, but also in the middle of scan lines. Also as mentioned before: You can use the sprites as a totally independent gfx layer (independent in movement + mode).

 

It's better to have a DL do the mode changes since it's only 1 cycle of DMA; and there are more options to change to on Atari. Atari also has GTIA modes which have to be changed by changing a register; those also would have been better if they were doable with a DL instruction. As far as sprite overlays go, on Atari you can go from simply filling up the screen with sprite data (using 0 cycles/0 ram) to 192*240 multicolored coverage using >80% of CPU time, 12K of RAM.

[atariksi]

I can not see how you would get the highres pixel resolution of c64 (320x hpos for sprites & scrolling) on A8? ok. you can do the speccy way in Antic F but I can not see a way to go 1/2 color clock resolution in Antic 4/E without heavy colour glitches?

 

Antic F can be done with two buffers offset by a pixel to pick up the difference, display buffer 1, display buffer 2 which is offset one pixel to the left, flip back and move the hardware scroll. i was pondering about doing a tech-tech that way when i last thought about demo code, but i wouldn't use it for a game personally.

 

sure...but read carefully... I was talking about antic 4/e.... with speccy method I was describing the "ROL" method... not the double buffer thing.

 

But if scrolling hardware is in color clocks, then rolling would slow things down as compared to just toggling to second buffer prepared a priori.

[atariksi]

The river in Egypt is "the Nile", which rhymes with "denial".

 

 

Only in english pronouncing. Orginal pronounce is "Neel" which rhymes with "appeal"

It seems people still have to learn that their opinion is just one of 6 Billion people. Just as their knowledge and their learning in a lifetime.

But, the truth ist, every day a new human is born that has to learn everything. So If one has teached 6 Billion people the same, he has to start right from scratch then.

 

That's why the Atari vs. Commodore Thread never will end...

 

As long as the truth is present and not just denials from both sides, it has achieved something whether thread dies or not. I mean we just had one guy arguing that Atari only has 160*200*4 because he was misinformed and thought there was no GTIA paletted mode (what to speak of interrupt driven/GPRIOR/sprite overlayed modes). Actually, when I bought my Atari 800, it was also advertised as 160*192*4 and 320*192*2 from palette of 128 although the GTIA chip was in there.

[Fröhn]

It's better to have a DL do the mode changes since it's only 1 cycle of DMA; and there are more options to change to on Atari.

1 cycle assuming you change the gfx mode all the time. But look at the average game: Most only change the mode 2 times per frame (playfield + scores), many others do not change the mode a single time. So it's ALL display list cycles of a frame vs ~2 mode changes via CPU.

[miker]

OK, regarding Atari and those DACs...

 

Here's "little" experiment which Xxl has just sent me.

 

 

Please listen to this one (real stuff is strongly recommended, alternatively Atari800WinPLus 4.0 final but expect partial lack of quality) and you may start to wonder how is it done.

digi6502.zip

[emkay]

OK, regarding Atari and those DACs...

 

Here's "little" experiment which Xxl has just sent me.

 

 

Please listen to this one (real stuff is strongly recommended, alternatively Atari800WinPLus 4.0 final but expect partial lack of quality) and you may start to wonder how is it done.

 

It sounds impressive in the emulation already. Could someone post a recording ?

[TMR]

Well, earlier in the thread you were claiming Atari came and told you there's no multicolor player stuff so that argument would go against that one.

 

That's not what i said at all, the point i made was that you were using two hardware sprites (two as defined by Atari's own documentation and the hardware itself having a set of registers for each sprite regardless of what mode it's in) to generate a single multicolour object which you were then comparing to one hardware sprite on the C64. i'm surprised that anybody can see that as a fair comparison.

 

For TV-based machines, half-pixel movement in color modes like 160*200 isn't that useful as luminance modes where it's doable on Atari.

 

It's the reason that Last V8 or Red Max are less "wobbly" on the C64 when accellerating horizontally for a start. Have a look at Humanoid on the A8 and the game it "borrows" it's graphics from on the C64, Subterranea - one scrolls a colour clock every other frame, the other at half a clock every frame and the latter is always going to be smoother because if it's higher frame rate. Any game using multi-speed scrolling will similarly have smoother transitions when it can move half a clock, a clock, clock and a half and then two clocks whilst accellerating rather than jumping from zero to one to two clocks, so again smoother.

 

There are literally thousands of C64 games that use half clock scrolling speeds, hell i've written four of 'em myself and have a fifth (and indeed a sixth, as well as contributing technical support for a seventh) under way! One of the reasons the scrolling shoot 'em up i'm writing for the A8 has stalled is because working at that resolution is going to make for a much faster game than i'd usually write and i'm not keen on dropping every other frame to slow things down, i haven't decided which route is better.

 

However, you do have a choice to mix the 320*200 mode with 160*200 mode at any scanline with one cycle DMA of DL.

 

And the C64 can have both modes on the same scanline with no extra DMA overhead at all.

 

Okay, so you were being vague about the resolution of your overlay.

 

No, you jumped in with both feet and incorrectly declared something impossible without actually knowing what it would be. My overlay could have been 160x100, 80x200 or 80x100 but the techniques discussed are still perfectly sound and will work regardless despite your claim, the lower vertical resolutions merely require less raster splits and sprite definitions.

 

Yeah, I was only talking graphics/text screens. I thought C64 sprites were 0..159 unless you make them monochrome than you get 0..319 but then you have to start writing to two registers to set the xpos.

 

Horizontal sprite positions are always nine bit numbers, the extra bits stored in a byte after the X and Y registers; the result is that they have twice the precision regardless of the mode they're working in.