Atari v Commodore

[TMR]

Because you keep repeating the same mistake. Atari only has 2 multicolor sprites (8-10 X 256).

 

This is more a matter of semantics than anything; since what you're describing as a multicolour sprite istill isn't a single entity and has two X registers for the seperate parts, it's still two sprites as far as the hardware is concerned.

 

All I have to show is that two of the C64 colors can be formed by four other colors and keep them fixed in a palette to show it's better than C64 palette. Yeah, if you look at it from Atari palette's point of view, you have more combinations that can be formed without using OR.

 

No, you've got to show that, in order to match the totally arbitary selection of colours the C64 has, you can do the same thing; otherwise the claim about three unique colours per multicolour sprite has a huge "but".

 

All I stated as restriction was that when you have *MULTIPLE* multicolor sprites, you can get a scenario where two sprites in the same zone which would be slower than other zones since the combinations of the multiple sprites in the same zone would not be a PMBase value.

 

At which point block copying kicks in yes? So in these worst cases, how much faster than my suggestion does your method go if you include the bounds checking to see when things need copying?

 

If you wanted to animate sprites, you can still have a better method than the one you suggested. My method was to defeat the idea that setting Y-position is 11X slower.

 

That's the thing... we weren't just moving things in Y, it was about matching facilities; yes, your method works ten times faster than mine but it apparently doesn't replicate the other features.

[emkay]

archon is obviously designed around the atari limits, only a few moving objects at a time, primitive sound, etc. on the c64 it has already better gfx just to take one example.

 

Archon is just using simple features of the A8. Nothing special don here.

there's zilion c64 games playing music&sfx during gameplay, picking one which doesnt proove anything. I can just as pick the lamest a8 game ever and point out how lame a8 is...

 

Hm. So you call Turrican a lame game? I thought it was one of your favorites.

T3 ingame has filtered 3 channel 16 bit freq sounds with 4 waveforms and >>>>50hz adsr, which pokey is not able to do. not even with 100% cpu usage.

 

I thought so. But where is the benefit of all that "technical facts". Surely not in the music you hear in the levels of the game...

Look, the AMIGA's PAULA has no ADSR, no fixed 4 waveforms, and no filters.... And the music is lightyears better. POKEY also needs no ADSR and the 16 bit os only good for doing some slide-FX. for the notes you only need the fixed frequencies. And, please, don't talk about waveforms. The independend filters of POKEY gives much more possibilies than 4 waveforms....

[Oswald]

incorrect. on the c64 gfx-dma and cpu bus cycles are interleaved. the bus is esentially 2mhz, so displaying gfx and running the cpu doesnt slows down the cpu.

 

Good Lord.... Ofcourse the graphics does not slow down the cpu of the C64. But every change takes full CPU speed. This doesn't happen on the A8, because Antic handles the changes without the help of the cpu.

 

except when it happens and you need DLI to do it.

 

 

the exceptions are badlines (-40 cycles*25 charlines) where color & charpointers are read and sprites (3-4 cycles / sprite / rasterline). displaying Mood's screen takes only 1000 cycles away from the cpu compared to the available 19656. but this happens in every default gfx mode. mood does use on of them.

 

The DMA read is doubled with this "mood-charmode-trick" compared to the standard 40x25 mode, and you need software routines to handle this, which cost additional cpu time.

That Mood still looks ugly and plays rather low is another point of thread

 

even if the bad line dma read would be doubled even if it would be done with the cpu the cpu wouldnt be slowed down to "5-600mhz" as you put it. mood uses a gfxmode which needs no cpu intervention, no tricks, its a default built in stock gfx mode.

 

I'm coding the c64 since 22 years. since 17 years in assembly. almost non stop. You cant even code on the a8. give me break telling me how mood works. instead read what I've written about it.

[Oswald]

archon is obviously designed around the atari limits, only a few moving objects at a time, primitive sound, etc. on the c64 it has already better gfx just to take one example.

 

Archon is just using simple features of the A8. Nothing special don here.

there's zilion c64 games playing music&sfx during gameplay, picking one which doesnt proove anything. I can just as pick the lamest a8 game ever and point out how lame a8 is...

 

Hm. So you call Turrican a lame game? I thought it was one of your favorites.

T3 ingame has filtered 3 channel 16 bit freq sounds with 4 waveforms and >>>>50hz adsr, which pokey is not able to do. not even with 100% cpu usage.

 

I thought so. But where is the benefit of all that "technical facts". Surely not in the music you hear in the levels of the game...

Look, the AMIGA's PAULA has no ADSR, no fixed 4 waveforms, and no filters.... And the music is lightyears better. POKEY also needs no ADSR and the 16 bit os only good for doing some slide-FX. for the notes you only need the fixed frequencies. And, please, don't talk about waveforms. The independend filters of POKEY gives much more possibilies than 4 waveforms....

 

no I havent called turrican a lame game. learn to read, or go see a doc.. I will go te see another one. arguing with such a dumbfuck as you is not good for my health. bye.

[Alison DeMeyer]

. You cant even code on the a8.

 

 

If you are not good enough coding on the Atari 8 -bit computer, surely that is entirely your fault.

Edited November 29, 2008 by Alison DeMeyer

[emkay]

incorrect. on the c64 gfx-dma and cpu bus cycles are interleaved. the bus is esentially 2mhz, so displaying gfx and running the cpu doesnt slows down the cpu.

 

Good Lord.... Ofcourse the graphics does not slow down the cpu of the C64. But every change takes full CPU speed. This doesn't happen on the A8, because Antic handles the changes without the help of the cpu.

 

except when it happens and you need DLI to do it.

 

 

No DLI needed for the graphics itself.

 

the exceptions are badlines (-40 cycles*25 charlines) where color & charpointers are read and sprites (3-4 cycles / sprite / rasterline). displaying Mood's screen takes only 1000 cycles away from the cpu compared to the available 19656. but this happens in every default gfx mode. mood does use on of them.

 

The DMA read is doubled with this "mood-charmode-trick" compared to the standard 40x25 mode, and you need software routines to handle this, which cost additional cpu time.

That Mood still looks ugly and plays rather low is another point of thread

 

even if the bad line dma read would be doubled even if it would be done with the cpu the cpu wouldnt be slowed down to "5-600mhz" as you put it. mood uses a gfxmode which needs no cpu intervention, no tricks, its a default built in stock gfx mode.

 

I'm coding the c64 since 22 years. since 17 years in assembly. almost non stop. You cant even code on the a8. give me break telling me how mood works. instead read what I've written about it.

 

 

Ok, let's say, someone told me shit about the used mode that is used in Mood?

If it is not a "50" Line charmode that is using "50" badlines... how is it done?

Is it using some charset filter, calculating the upper and lower half of a character for the shown graphics? What kind of sorting routine was used here, because the movent clearly shows a 40x50 resolution.

[emkay]

. You cant even code on the a8.

 

 

If you are not good enough coding on the Atari 8 -bit computer, surely that is entirely your fault.

 

Seems he don't know that I was coding the A8 back in the 80/90s

[TMR]

...but some people just seem incapable of enjoying the Atari unless it's at the expense of other machines.

Because it is an Atari site...

 

And i don't see why, for some people at least, loyalty to the Atari seems to automatically mean you can't countenance even discussing anything else; this thread sort of reflects that in the way it limits discussion to only the games where the Atari is superior (and i disagree with a couple of the titles listed, but that's opinion for you isn't it) whilst a far more interesting discussion would be comparing all of the games that exist on both. It's quite sad really that nobody feels confident enough in the Atari to go there...

[emkay]

OK. I was talking about Turrican and mentioned the missing soundtrack during the levels before...

 

there's zilion c64 games playing music&sfx during gameplay, picking one which doesnt proove anything. I can just as pick the lamest a8 game ever and point out how lame a8 is...

 

So, please english people, please tell me what you unterstand in this sentence. Thanks.

[TMR]

OK. I was talking about Turrican and mentioned the missing soundtrack during the levels before...

 

there's zilion c64 games playing music&sfx during gameplay, picking one which doesnt proove anything. I can just as pick the lamest a8 game ever and point out how lame a8 is...

 

So, please english people, please tell me what you unterstand in this sentence. Thanks.

 

Well, it comes in two sentences; the first bit says that, unlike the C64 version of Turrican, there are a lot of games that have both sound effects and music playing during the game so it's not impossible to do, just not done in that specific example - that's perfectly sound (if you'll excuse the pun) because there are, even Turrican plays music during the fixed speed scrolling parts so it's not as though it runs out of CPU power, they just seem to have chosen not to for some reason. The second sentence, to me at least, says that he could select a single Atari 8-bit game that doesn't do something in particular and use that as a basis for a false argument about the Atari's capabilities, similar to where you said "What are the capabilites of a soundchip worth, if the computer isn't "good" enough for handling it during gameplay....<sneaking at the fabulous C64 game: Turrican>" and implied that the lack of music during play in Turrican was limited by the hardware in some way.

[dwhyte]

EDIT: POST DELETED. I will no longer be feeding the trolls...

Edited November 29, 2008 by dwhyte

[Heaven/TQA]

the interesting thing is...

 

emkay did not code on A8 since for ages and has not touched c64, too...

Oswald does a lot of high level stuff on c64 but will not touch A8, too...

 

but both fight each other regarding technical stuff... so...why not put your energy and actually make something out of it???

 

I have a demo screen of one Oxyron member at home done on A8 last year... So Oswald... you are next?

[emkay]

Back to pokey and the aimed "possible" from my side. The following tune might show how wide the spread is between the emulation and the real thing.

Because I'm not a professional musician, I'm restricted to use RMT. But listen to yourselves. There is a big timing difference, the volume is not optimized together and so on. Hearing those differences, how to make full finetuning in RMT?

 

Well, the biggest problem of POKEY is NOT the 8 bit resolution for the pitches. The biggest problem is the volume. SID friends call it ADSR... In the tune you might recognize volume tuning. This is done by the independent filter and needs the correct timing.

So you can compare the recording from the real thing and in the emulation. The funny thing... This volume manipulation works over interferences that happen also when not active manipulating them. This means: They change also between the commands of VBI 50Hz.... it also allows corrections on higher notes as you might recognize.

 

 

http://www.speedshare.org/download.php?id=8BCE416211

[Crazyace]

Ok, let's say, someone told me shit about the used mode that is used in Mood?

If it is not a "50" Line charmode that is using "50" badlines... how is it done?

Is it using some charset filter, calculating the upper and lower half of a character for the shown graphics? What kind of sorting routine was used here, because the movent clearly shows a 40x50 resolution.

 

If I was trying to implement a 3D game I'd probally set up a hires multicolour screen with alternating 4 pixel high lines of colour 2 and colour 3. This would effectively give me a 40x50 grid of colours programable by the low nibble of the character ram and the colour ram. - So all the 3d stuff could act on the screen as a byte per pixel.

 

That way, I wouldn't need any interupt hacks... but it would cost a 'dummy' high res screen

[+skr]

http://www.speedshare.org/download.php?id=8BCE416211

 

I don´t understand much of your technical notes, but that tune sounds great. Just copied it to a Floppy Disk to make sure it really is Pokey-Sound. It is. :-)

[emkay]

Ok, let's say, someone told me shit about the used mode that is used in Mood?

If it is not a "50" Line charmode that is using "50" badlines... how is it done?

Is it using some charset filter, calculating the upper and lower half of a character for the shown graphics? What kind of sorting routine was used here, because the movent clearly shows a 40x50 resolution.

 

If I was trying to implement a 3D game I'd probally set up a hires multicolour screen with alternating 4 pixel high lines of colour 2 and colour 3. This would effectively give me a 40x50 grid of colours programable by the low nibble of the character ram and the colour ram. - So all the 3d stuff could act on the screen as a byte per pixel.

 

That way, I wouldn't need any interupt hacks... but it would cost a 'dummy' high res screen

 

I was reading about Mood that it does force a refresh of the colour Ram every 4 scanlines to have the independend colours. This would result in 50 Badlines, not only 25. Even if a "standard" mode is used.

[Crazyace]

Ok, let's say, someone told me shit about the used mode that is used in Mood?

If it is not a "50" Line charmode that is using "50" badlines... how is it done?

Is it using some charset filter, calculating the upper and lower half of a character for the shown graphics? What kind of sorting routine was used here, because the movent clearly shows a 40x50 resolution.

 

If I was trying to implement a 3D game I'd probally set up a hires multicolour screen with alternating 4 pixel high lines of colour 2 and colour 3. This would effectively give me a 40x50 grid of colours programable by the low nibble of the character ram and the colour ram. - So all the 3d stuff could act on the screen as a byte per pixel.

 

That way, I wouldn't need any interupt hacks... but it would cost a 'dummy' high res screen

 

I was reading about Mood that it does force a refresh of the colour Ram every 4 scanlines to have the independend colours. This would result in 50 Badlines, not only 25. Even if a "standard" mode is used.

 

ok - you're probally right.. but this way would involve only the normal 25 'badlines' - and probally save a lot of processor cycles as no interupts would be needed ( I assume the refresh is via vscroll hacks to get more badlines ) and the cpu speed would be maximised

[emkay]

ok - you're probally right.. but this way would involve only the normal 25 'badlines' - and probally save a lot of processor cycles as no interupts would be needed ( I assume the refresh is via vscroll hacks to get more badlines ) and the cpu speed would be maximised

 

The essential here is that this mode on the C64 cost cpu time, alike what is done to reach this40x50 resolution.

On the A8 such mode gives CPU time back and Antic removes any "copy" command combinations for every 2nd line. That's why Space Harrier is "fast as hell". It is a real co work of three Chips:

-6502 handles the game

-Antic fills the display

-GTIA overlays via the PM Graphics.

 

So, while the C64 is the "perfect" Scroller with Sprites, caused by the VIC2 , the ATARI starts warming up when using fullscreen fast acting scenes. At least it is proven with Space Harrier...

[Tezz]

MK, I agree that such a game could potentially show the strengths of the Atari, moreso than sprite based games perhaps but def something worthwhile in any case. The problem being is that when this has been discussed in the past with the Numan engine for example nobody was that interested in it.

Edited November 29, 2008 by Tezz

[Crazyace]

ok - you're probally right.. but this way would involve only the normal 25 'badlines' - and probally save a lot of processor cycles as no interupts would be needed ( I assume the refresh is via vscroll hacks to get more badlines ) and the cpu speed would be maximised

 

The essential here is that this mode on the C64 cost cpu time, alike what is done to reach this40x50 resolution.

 

Actually - if you implemented it the way I've just described, rather than the way you said, there is no cpu time cost at all

 

On the A8 such mode gives CPU time back and Antic removes any "copy" command combinations for every 2nd line. That's why Space Harrier is "fast as hell". It is a real co work of three Chips:

-6502 handles the game

-Antic fills the display

-GTIA overlays via the PM Graphics.

 

So, while the C64 is the "perfect" Scroller with Sprites, caused by the VIC2 , the ATARI starts warming up when using fullscreen fast acting scenes. At least it is proven with Space Harrier...

Yes - the bitmap modes have a lot of flexibility for 3D - I'm not a big fan of the flickering in Space Harrier though - maybe it looks worse on the emulator

[emkay]

Actually - if you implemented it the way I've just described, rather than the way you said, there is no cpu time cost at all

 

At least it cost the initialization "routine" and the DMA Cycles for reading the colour RAM data.

[emkay]

MK, I agree that such a game could potentially show the strengths of the Atari, moreso than sprite based games perhaps but def something worthwhile in any case. The problem being is that when this has been discussed in the past with the Numan engine for example nobody was that interested in it.

 

That's why threads like this one always run out of fuel.

[Crazyace]

Actually - if you implemented it the way I've just described, rather than the way you said, there is no cpu time cost at all

 

At least it cost the initialization "routine" and the DMA Cycles for reading the colour RAM data.

 

Not quite sure what you mean about initialisation - the only costs that matter really are per frame costs.

I dont think it actually costs any extra cycles to read colour ram on the C64 because of the 12 bit bus to Vic.

[atarian63]

archon is obviously designed around the atari limits, only a few moving objects at a time, primitive sound, etc. on the c64 it has already better gfx just to take one example.

 

Archon is just using simple features of the A8. Nothing special don here.

there's zilion c64 games playing music&sfx during gameplay, picking one which doesnt proove anything. I can just as pick the lamest a8 game ever and point out how lame a8 is...

 

Hm. So you call Turrican a lame game? I thought it was one of your favorites.

T3 ingame has filtered 3 channel 16 bit freq sounds with 4 waveforms and >>>>50hz adsr, which pokey is not able to do. not even with 100% cpu usage.

 

I thought so. But where is the benefit of all that "technical facts". Surely not in the music you hear in the levels of the game...

Look, the AMIGA's PAULA has no ADSR, no fixed 4 waveforms, and no filters.... And the music is lightyears better. POKEY also needs no ADSR and the 16 bit os only good for doing some slide-FX. for the notes you only need the fixed frequencies. And, please, don't talk about waveforms. The independend filters of POKEY gives much more possibilies than 4 waveforms....

 

no I havent called turrican a lame game. learn to read, or go see a doc.. I will go te see another one. arguing with such a dumbfuck as you is not good for my health. bye.

Same old oswald, losing an argument then curses

[Crazyace]

MK, I agree that such a game could potentially show the strengths of the Atari, moreso than sprite based games perhaps but def something worthwhile in any case. The problem being is that when this has been discussed in the past with the Numan engine for example nobody was that interested in it.

 

That's why threads like this one always run out of fuel.

 

Running 3D is nice - but games have already shown off some of the extra 'power' of the A8 ... look at Wayout , or Mercenary.

The Numen engine is cool for a demo - but the Framerate is really low for a 'doom' game.. Although it would be quite cool for a Dungeon master style game.