Atari v Commodore

[frenchman]

can we all agree on not having this childish discussions and flaming in terms of personal attacks?

 

even I don't like sometimes Atariski and some others going over the edge but Rockford & frenchman...sorry... we are 30+ and not 5+...

Respect!

 

But Rockford falls into this trap so easy....I could string him along for pages and pages. (Wish I was 30 though, you lucky guys (and girls)).

[oky2000]

4x speed...my arse! It wouldn't even be as fast as the Spectrum or Amstrad versions haha hardly all conquering.

 

You still have to learn very much, don't you?

 

I see very clearly, Rescue on Fractulus...a much more complex 3D algorithm runs maybe 1/3 faster on a 50% lower screen resolution as the C64....and this speed advantage is less on The Eidolon due to optimisation of code and a higher resolution.

 

This is not roundy-rounds at the fairground emkay, plenty of people have proved technically speaking the A8 CPU is maybe 20-25% faster in real terms with some solid indisputable technical explanations even in this thread. 25% faster CPU <> screen update of 4x faster than the C64 version whatever A8 wet dreams you may have for your Antic/GTIA matey. The Spectrum version of the Freescape engine would still run rings round an A8 version as would Starglider if you ever tried programming it for A8.

 

You just have to accept that whilst the Spectrum may well be 99% a horrible piece of crap of a micro it does one thing better than any other 8bit this side of a Memotech MTX512....and that is raw 3D calculations for either wireframe, hidden line or solid vertex calculations. There is no cheat available for rendering solid 3D, no silicon to help with that existed until 2 decades after the A8 was even prototyped I know that much. Geometry setup/vertex calculation is in no way going to be impacted with a teeny tiny faster draw routine that may or may not exist my friend....it's 99% pure calculation 1% rendering on an 8bit system.

 

Even the mighty Amiga hardware line draw and fill operations do nothing for solid 3D games like Freescape let alone some mythical feature exploited from within the A8 XL/XE chipset. I have learnt enough in my time so I'm OK thanks Feel free to code it up in your spare time and prove me wrong though

 

For the record the only machine which could even attempt to do 2-3x speed of a colour version of Freescape on 8bit is the 4mhz Memotech MTX machines, now that is one powerhouse of an 8bit that would do any kind of 3D better than C64/A8/Amstrad/Spectrum/Apple II due to sheer CPU grunt and one hell of a clean system design. Only as good as an MSX 1 for 2D traditional games sure...but 3D...forget it nothing can touch the MTX for that in the 8bit world.

[Rockford]

can we all agree on not having this childish discussions and flaming in terms of personal attacks?

 

even I don't like sometimes Atariski and some others going over the edge but Rockford & frenchman...sorry... we are 30+ and not 5+...

Respect!

 

But Rockford falls into this trap so easy....I could string him along for pages and pages. (Wish I was 30 though, you lucky guys (and girls)).

Yeaaaaaah frenchman set a trap and then he just fell into it by posting his "smart and logical" comments. MEGA LOL !!!!! :D In general, some of Atarians here are unbelievably "smart" (so far we have 2), when caught saying something stupid or illogical, want to deflect the criticism by saying it was just a trap. Oh, and frenchman is an unequalled master of that. Another MEGA LOL Hey frenchman keep setting traps and we certainly will be laughing a lot !!!! Oh my dear, I haven't laughed so much since forever !!!! it's not enough, so there are some more LOLs :D

Edited September 8, 2009 by Rockford

[Lazarus]

Technically, it's not "2 pixel positioning" but one color clock positioning as these machines are targetted towards TVs w/3.57Mhz color clock. So in many cases, it's sufficient given TV resolution and the way our mind looks at fast scrolling images.

2 pixels = "one color clock" is not true on any C64 model.

 

Regardless, it was more to do with reducing overhead and optimizing for 8-bit accesses. Heck, I prefer VCOUNT as 8-bit value since there's also the option of using a PADDLE counter in case you need a scanline counter.

VCount on C64 is fine as it is, in 99% of the cases you only need bits 0...7 anyway since that covers the entire visible area and a lot of upper/lower border area aswell.

[peteym5]

Oh my god, its the thread that never ends!!!

 

Can you give this Atari vs Commodore thing a rest????

[emkay]

I see very clearly, Rescue on Fractulus...a much more complex 3D algorithm runs maybe 1/3 faster on a 50% lower screen resolution as the C64....and this speed advantage is less on The Eidolon due to optimisation of code and a higher resolution.

 

It was discussed in this thread before, too...

 

The Atari versions were the 1st builts. After creating them , they may have learned how to optimise things for speeding up other machines.

Particular Rescue on Fractalus runs on the ATARI with VBLANK syncing, while on the C64 it runs "free" on the CPU. You can prove it by switching the emulators between 50 and 60hz. The Atari version gets slower when using 50Hz, which is nuts, because the PAL Ataris have more cycles free per second for faster 3D calculations.

[emkay]

Even the mighty Amiga hardware line draw and fill operations do nothing for solid 3D games like Freescape let alone some mythical feature exploited from within the A8 XL/XE chipset.

 

Ofcourse it does.

Using the blitter, you could calculate the 3D stuff and draw pixel blocks, resulting in a "Driller" with textures.

Same on the A8. Using ANTIC as a "line Blitter" results in the resolution of 80x60 with 16 colours, and almost the full speed of the CPU, because the DMA Reads and RAM Refresh Cycles get less. But, otherwise than the AMIGA, where the CPU has to wait for the Blitter Operations to be finished, ANTIC draws the PIXEL WHILE the CPU is calculating.

So, instead of a virtual resolution of 80x60 with the usage of colour transitions on the C64, the ATARI simply has the right mode for this to offer, where the graphics controller and CPU can work at the same time.

[jeremysart]

Woohoo, i'll belooking through the 300+ pages of this thread when choosing a new game

[emkay]

 

Ofcourse it does.

Using the blitter, you could calculate the 3D stuff and draw pixel blocks, resulting in a "Driller" with textures.

 

Forgot to mention the light source

 

It's an ECS demo!

 

Normally on the AMIGA they use AGA for 3D....

Edited September 9, 2009 by emkay

[frenchman]

can we all agree on not having this childish discussions and flaming in terms of personal attacks?

 

even I don't like sometimes Atariski and some others going over the edge but Rockford & frenchman...sorry... we are 30+ and not 5+...

Respect!

 

But Rockford falls into this trap so easy....I could string him along for pages and pages. (Wish I was 30 though, you lucky guys (and girls)).

In general, some of Atarians here are unbelievably "smart" (so far we have 2)

 

Thanks for the compliment, that's already two more than there are 'smart' C64 users.

 

BTW, aren't you dead yet?

Edited September 9, 2009 by frenchman

[andym00]

First of all, you have to write two registers even if you scroll every color clock and secondly I don't see that big of a difference extracting LSB or MSB (algorithm differs).

 

You said before it would have been more optimal to use a packed LSBs versus packed MSBs, now you're saying there's not much difference.. That difference between the two methods is as best as I can figure something to the tune of 2-3 cycles per sprite assuming an entities x-position is accessed at least once per frame by logic.. In a 64 sprite multiplexer that's 3 or 4 scanlines in C64 slowland, which is pretty far from optimal, and is actually a big difference..

[andym00]

Antic stores the last - via DMA read scanline - in its own memory.

You can force ANTIC to reuse the memory for 1 to 16 scanlines ... So you don't get black/blank lines. It cost around 5 cycles and saves 40 cycles per scanline of DMA reads and additional 3 cycles of RAM refresh per scanline.

 

Oh, well it's a good job "line blitter" was written in quotes otherwise it it could have been considered misleading..

So in otherwords exactly the same effect as can be achieved with VIC..

Edited September 9, 2009 by andym00

[andym00]

Even the mighty Amiga hardware line draw and fill operations do nothing for solid 3D games like Freescape let alone some mythical feature exploited from within the A8 XL/XE chipset.

 

Ofcourse it does.

Using the blitter, you could calculate the 3D stuff and draw pixel blocks, resulting in a "Driller" with textures.

Same on the A8. Using ANTIC as a "line Blitter" results in the resolution of 80x60 with 16 colours, and almost the full speed of the CPU, because the DMA Reads and RAM Refresh Cycles get less. But, otherwise than the AMIGA, where the CPU has to wait for the Blitter Operations to be finished, ANTIC draws the PIXEL WHILE the CPU is calculating.

So, instead of a virtual resolution of 80x60 with the usage of colour transitions on the C64, the ATARI simply has the right mode for this to offer, where the graphics controller and CPU can work at the same time.

 

You are completely certifiable emkay

Edited September 9, 2009 by andym00

[andym00]

 

Ofcourse it does.

Using the blitter, you could calculate the 3D stuff and draw pixel blocks, resulting in a "Driller" with textures.

 

Forgot to mention the light source

 

It's an ECS demo!

 

Normally on the AMIGA they use AGA for 3D....

 

Maybe they should stick to using AGA then.. I guess the reason it came 3rd (or maybe there were only 3 entries) is that it looks like something the dog threw up, then ate again, and then brought back up again..

 

edit: Just checked.. lol, there were only 4 entries that year

Edited September 9, 2009 by andym00

[Gury]

 

Now factor into that that the Atari code is running 50% lower resolution and you get the real figure of 20-25 faster in real terms processing power than a 1mhz 6510 C64.

 

4x speed...my arse! It wouldn't even be as fast as the Spectrum or Amstrad versions haha hardly all conquering.

 

A8 can go easily par with Spectrum. Amstrad has no power to do faster as it does, because its graphics subsystem and other things take so many cycles. The other 8-bit micro which surpass others in speed is BBC B+, which has MOS 6502 processor with 2 Mhz. Its Elite is still the best.

[Gury]

It offers some redemption I guess

These were the days... I enjoyed playing Super Cobra, it is one of my favourites.

[analmux]

Antic stores the last - via DMA read scanline - in its own memory.

You can force ANTIC to reuse the memory for 1 to 16 scanlines ... So you don't get black/blank lines. It cost around 5 cycles and saves 40 cycles per scanline of DMA reads and additional 3 cycles of RAM refresh per scanline.

 

Oh, well it's a good job "line blitter" was written in quotes otherwise it it could have been considered misleading..

So in otherwords exactly the same effect as can be achieved with VIC..

I doubt that. I don't know whether VIC2 also stores the last line in its own memory, but there aren't situations (comparable to these) VIC2 will give cycles back to the CPU. The CPU can't run faster than 1mhz. On A8 the CPU DOES get back cycles from Antic. On PAL systems we go down from 1.77mhz to around 1.53mhz.

[Lazarus]

Using the blitter, you could calculate the 3D stuff and draw pixel blocks, resulting in a "Driller" with textures.

The blitter cannot do such things since it cannot clip against other polygons. And it would be dead slow too since all those blitter initializations would be slower than doing everything just with the CPU.

[popmilo]

... Same on the A8. Using ANTIC as a "line Blitter" results in the resolution of 80x60 with 16 colours

Existing Driller 3d part runs in 128x128 and pixels have 2x1 ratio.

How would it look in 80x60 with square pixels ?

 

What do you mean with "line Blitter" ?

[Lazarus]

What do you mean with "line Blitter" ?

I think he is talking about rasterline repeating. Ofcourse that has nothing to do with blitting.

[oky2000]

 

Now factor into that that the Atari code is running 50% lower resolution and you get the real figure of 20-25 faster in real terms processing power than a 1mhz 6510 C64.

 

4x speed...my arse! It wouldn't even be as fast as the Spectrum or Amstrad versions haha hardly all conquering.

 

A8 can go easily par with Spectrum. Amstrad has no power to do faster as it does, because its graphics subsystem and other things take so many cycles. The other 8-bit micro which surpass others in speed is BBC B+, which has MOS 6502 processor with 2 Mhz. Its Elite is still the best.

 

The BBC B+ and BBC B and BBC A all use a 2mhz 6502. You must be thinking of Elite+ the game not the machine, which was an optimised version of the original code. But then you would have to find an optimized hack of all the other 8bit versions of Elite to compare as the Amstrad/Spectrum/C64 code is not optimised in such a way and there is quite a lot of room for improvement.

 

Also the closest version of Elite to the A8 would be the Commodore C16/+4 version which uses pretty much the same CPU at the same speed, but again there are various hacks to optimise this version also so it is hard to tell without running all optimised versions next to each other side by side. Technically it would not be any noticably faster on A8 given the CPU does 99% of the work.

 

The problem with 3/4 of Amstrad games is they are simple Spectrum ports with no attempt at optimisation to account for different screen layouts. Writting to the screen on the Amstrad is not that bad, their Shadow of the Beast homebrew demo is impressive for a machine that is doing all that horizontal scrolling via software. look here....

 

 

Also another good video to see would be MSX version of Elite but there isn't one only useless screenshots.

[oky2000]

Using the blitter, you could calculate the 3D stuff and draw pixel blocks, resulting in a "Driller" with textures.

The blitter cannot do such things since it cannot clip against other polygons. And it would be dead slow too since all those blitter initializations would be slower than doing everything just with the CPU.

 

Exactly, even the most feature rich implementations of a Blitter can NOT do anything of the sort. 3D maths can only be done on either a CPU or DSP nothing else.

 

Blitter stands for Block Image Transfer, all it does is move data from A to B running logical operations like AND OR XOR etc with an optional source of data C. It has no ability to do any calculations for 3D geometry maths at all...which is also why Doom type FPS games are horrendously bad compared to a 66mhz 486 PC (which has trouble doing smooth scrolling 2D games like an Amiga or SNES or Megadrive etc).

 

It's true that on the Amiga you do actually have line draw and fill functions built into the Blitter BUT the set up time is so wasteful you couldn't gain any real advantage using these functions for something like Carrier Command solid 3D or Starglider hidden line wireframe 3D.....hence the ST versions are 10% faster

 

Also....notice that the Freescape engine on Driller uses cross hatching patterns to do the inbetween shades even on the ST/Amiga versions which there is no possible way to use any kind of line draw/fill hardware routines to fill with those bespoke bitpatterns

[andym00]

I doubt that. I don't know whether VIC2 also stores the last line in its own memory, but there aren't situations (comparable to these) VIC2 will give cycles back to the CPU. The CPU can't run faster than 1mhz. On A8 the CPU DOES get back cycles from Antic. On PAL systems we go down from 1.77mhz to around 1.53mhz.

 

On the 64 you can abort the badline, VIC will use the character and colour data last fetched, fetching only new graphics data, which doesn't interfere with the CPU anyway.. It's using this technique that it's possible to create a 4 colour bitmap screen[1] that doesn't use steal any cycles from the CPU because the colour RAM, and character RAM fetches (used for colours) are being aborted as they begin.. Of course you end up with more cycles anyway on the A8 anyway, that's taken for granted.

 

[1] Well more than 4 because the colour memory can be different across the line being repeated.. You let one line fetch occur then no more..

[oky2000]

Antic stores the last - via DMA read scanline - in its own memory.

You can force ANTIC to reuse the memory for 1 to 16 scanlines ... So you don't get black/blank lines. It cost around 5 cycles and saves 40 cycles per scanline of DMA reads and additional 3 cycles of RAM refresh per scanline.

 

Oh, well it's a good job "line blitter" was written in quotes otherwise it it could have been considered misleading..

So in otherwords exactly the same effect as can be achieved with VIC..

I doubt that. I don't know whether VIC2 also stores the last line in its own memory, but there aren't situations (comparable to these) VIC2 will give cycles back to the CPU. The CPU can't run faster than 1mhz. On A8 the CPU DOES get back cycles from Antic. On PAL systems we go down from 1.77mhz to around 1.53mhz.

 

This is nothing more than a feature which minimises a quirk of how the A8 displays screens, we don't use that kind of system on other 8bits so there is no cycles to lose or be gained by having this feature. What emkay is talking about is probably just optimising an Atari specific display which is already less suitable than the Spectrum or BBC screen generating hardware for this kind of display I guess.

 

I can categorically state that there is no 3D calculating co-processor capability in any 8bit micro, CPU speed and efficiency is all you can rely on as well as optimising your code down to the last fetch/execute cycle in Assembler. There is no mythical custom chip and wouldn't be until DSPs were introduced in the Falcon or SuperFX chip by Argonaut software etc.

[sack-c0s]

 

 

It's true that on the Amiga you do actually have line draw and fill functions built into the Blitter BUT the set up time is so wasteful you couldn't gain any real advantage using these functions for something like Carrier Command solid 3D or Starglider hidden line wireframe 3D.....hence the ST versions are 10% faster

 

 

I've written some simple code on the ST and ported it to the Amiga and haven't even touched the blitter yet and the screen management (being able to repoint the video addresses on a line by line basis and the screen buffer format) actually removes a lot of overhead that I had on the ST from working around its video memory format. What I've gained from having linear planes has wiped out any advantage of having a faster CPU.

 

But more experienced 68k coders might prove me wrong on this one - it's just my experience.