Atari 8bit is superior to the ST

[atariksi]

I'm sorry but the Photochrome pictures are immeasurably superior to any A8 modes with between 32-48/512 colours PER SCAN LINE in 320x200 mode. For static pics only a blinkered A8 fanboy would claim otherwise

 

I have to agree - I love my 800XL, but I've never seen a picture in any format,

from it, that could touch a Photochrome picture. Or even a well done Spectrum

512 picture.

 

Here is an example:

 

 

I bet some 16 shaded imagery that mixes ANTIC E and Gr.9 would look inferior on ST. Is this Photochrome only for ST or are you talking STe?

 

Attached another gamescreen shot someone sent me.

[atariksi]

Wikipedia has a really interesting pallette comparision here

 

Yep, I've been using those for comparison for a while. (I got that VCS palette immage from the video game color palettes wiki page -all the palette lists use that stock immage) Displays show the entire palette applied at original resolution to the immage and examples of optimized displays the hardware was capable of. (non-dithered in both cases)

Here's the one for 8-bit computers, though the A8 isn't listed.

http://en.wikipedia.org/wiki/List_of_8-bit_computer_hardware_palettes

 

Sometimes I wonder about some articles on Wiki-- if they are biased views of someone or just lack of research. That article should be modified or removed-- shows bias toward certain platforms and other problems.

 

I didn't think the pictures would be more biased or not - I only posted it because they show the pallette well and compare directly - unlike the standard colour grid pictures. They weren't meant to be an indication of actual pictures on the A8 and ST.

 

I was referring to the article being biased. How did you get the A8 version of the image (which software did you use to quantize to A8 128-colors)?

[Crazyace]

You need to look at worst case analysis so blinking power pills, escalators, bombs, etc. And as far as I see it, this is another one of those ANTIC 4 (five color) modes but this time w/DLI on every mode line. What overhead are you computing to mimic an A8 DLI every 8 scanlines?

 

I looked at all of the levels, and I'm pretty certain that there's always more than 50% 'blank' chars - and as I said in most levels the animating chars are a lot less. So 50% is a good number.

For DLI I'd just use a timerB IRQ on the ST - I've used it for colour graduations before, and the cost should be pretty similar to the A8 interupt as it's only going to change a single pallette entry.

 

What about custom screens? And regarding DLIs, I wanted to know what overhead you had computed since for ST, you have to subtract that from total cycles in the frame unlike Boulderdash which didn't require that DLI overhead. It doesn't matter if overhead is same as A8 since A8 repainting chars or sprites is a breeze compared to ST. A8 can repaint the screen even with a kernel running full-screen mimicing the Copper color re-use.

 

Do you mean custom screens in Mr Robot? ( I'm guessing you do as you seem to be looking for a reason why the game can't be reproduced on the ST now )

 

I guess - if I wanted to reproduce the Mr Robot ultimate animated screen ( where each of the 40x20 grid is animating ) I'd switch to a different method , 4 screens. Then I'd only paint a character that changed, and paint it's 4 animation frames - one to each screen. Then to actually animate I'd just change the screenbase - and voila!

The number of 'changing' characters is tiny - either objects hit by you ( a few per frame at most ) or bombs changing to explosions ( again a few per frame at most )

And sprites aren't an issue - as the monsters are software sprites on the A8 the time taken to repaint them is likely to be more than it would be on the ST.

 

Regarding DLI overhead I'd probably have something like this:

 

move.l a0,-(sp)

move.l dliptr,a0

move.w (a0)+,$ffff825c\w

move.w (a0)+,$fffffa20\w

move.l a0,dliptr

move.l (sp)+,a0

rte

 

It's not the fastest routine, but as it's only hit 20 times per frame it wouldn't be a huge priority

 

I guess on the A8 it's something like this

 

pha

tya

pha

ldy index

lda table,y

sta COLUPF1

inc index

pla

tay

pla

rti

[Crazyace]

I bet some 16 shaded imagery that mixes ANTIC E and Gr.9 would look inferior on ST. Is this Photochrome only for ST or are you talking STe?

 

Attached another gamescreen shot someone sent me.

 

I actually preferred the robot to the spaceship

 

Photochrome is for ST and STe ( the picture I showed you was ST only )

[Crazyace]

I was referring to the article being biased. How did you get the A8 version of the image (which software did you use to quantize to A8 128-colors)?

 

I just grabbed it from the site

I'd assume they obtained the image in the usual way - take a 24 bit master, and reduce it to 128 fixed colours ( representing the A8 pallette ) - Any good paint package should have some option like that. ( I've used PaintShop pro before - I guess GIMP and Photoshop also have the same type of option )

[atariksi]

You need to look at worst case analysis so blinking power pills, escalators, bombs, etc. And as far as I see it, this is another one of those ANTIC 4 (five color) modes but this time w/DLI on every mode line. What overhead are you computing to mimic an A8 DLI every 8 scanlines?

 

I looked at all of the levels, and I'm pretty certain that there's always more than 50% 'blank' chars - and as I said in most levels the animating chars are a lot less. So 50% is a good number.

For DLI I'd just use a timerB IRQ on the ST - I've used it for colour graduations before, and the cost should be pretty similar to the A8 interupt as it's only going to change a single pallette entry.

 

What about custom screens? And regarding DLIs, I wanted to know what overhead you had computed since for ST, you have to subtract that from total cycles in the frame unlike Boulderdash which didn't require that DLI overhead. It doesn't matter if overhead is same as A8 since A8 repainting chars or sprites is a breeze compared to ST. A8 can repaint the screen even with a kernel running full-screen mimicing the Copper color re-use.

 

Do you mean custom screens in Mr Robot? ( I'm guessing you do as you seem to be looking for a reason why the game can't be reproduced on the ST now )...

I am not saying game is undoable on ST. Just objecting to the worst case scenario for moving chars. I think you assumed something before too regarding Boulderdash. These games are inferior on ST, but not undoable. They are even doable on Apple II.

[atariksi]

I was referring to the article being biased. How did you get the A8 version of the image (which software did you use to quantize to A8 128-colors)?

 

I just grabbed it from the site

I'd assume they obtained the image in the usual way - take a 24 bit master, and reduce it to 128 fixed colours ( representing the A8 pallette ) - Any good paint package should have some option like that. ( I've used PaintShop pro before - I guess GIMP and Photoshop also have the same type of option )

 

I didn't see the A8 picture on the site Koolkitty gave. I have Photoshop so what option was used; I just want to use same settings to see if the conversion is the best possible. And did you get count of colors on it to be 128?

[andym00]

Yeah, as Heaven stated there's a 5-color mode like the one we were discussing with Boulderdash (ANTIC mode 4). It's 3 bits/pixel where one bit is taken from upper bit of char value but only 5 combinations are used.

 

Careful with those porkies laddy or soon you'll come to believe them yourself..

 

3 Bits Per Pixel ? Ummmm, no..

You're lying again hoping that everyone's sick and tired of correcting your nonsense..

 

It's 2BPP.. Plain and simple..

The 7th bit does nothing more than a poor approximation of the attribute system you've rabidly stated you despise on other architectures..

Edited December 31, 2009 by andym00

[Crazyace]

For Atariski I looked at the Rescue picture on ST.

 

Here is a standard version frat8.jp

And then there's a photochrome format version fratphoto.jpg

 

But a better test would be to use a reference image that not 80 pixels across - BSTAR.jpg

 

Normal ST ( spectrum 512 ) - bstar512.jpg

Normal ST ( photochrome ) - battlepcs.jpg

Atari 8 bit ( GTIA ) - BSTARa8.jpg

 

( Please feel free to upload a better A8 version, I haven't got any tools to make hip or other A8 advanced image formats )

[atariksi]

Yeah, as Heaven stated there's a 5-color mode like the one we were discussing with Boulderdash (ANTIC mode 4). It's 3 bits/pixel where one bit is taken from upper bit of char value but only 5 combinations are used.

 

Careful with those porkies laddy or soon you'll come to believe them yourself..

 

3 Bits Per Pixel ? Ummmm, no..

You're lying again hoping that everyone's sick and tired of correcting your nonsense..

 

It's 2BPP.. Plain and simple..

The 7th bit does nothing more than a poor approximation of the attribute system you've rabidly stated you despise on other architectures..

 

You cannot understand simple English. Get your facts straight. Stop with the lieing crap as much as you like finding fault with me, you're wrong.

[atariksi]

That's an incorrect statement. On ST, C64, modern CPUs, and many others the stability is thrown off by indeterminate signals so they cannot be compared to Copper.

 

 

So firstly..

 

Indeterminate Signals.. You've pulled this old one before, and avoided answering it.. So..

...

I answered this before and the answer is the same now, but it's your LIES that make me want to stop answering. I never avoided answering it thus far.

 

Assuming for the sake of brevity, standard hardware on both and no unknown external devices capable taking over the bus or otherwise upsetting the apple cart of timing..

 

C64:

Sprite(s) on.. Known cycles lost..

Screen on.. Known cycles lost..

Badline.. Known cycles lost..

 

A8:

Memory alive.. Known Cycles lost..

Player(s) on.. Known Cycles lost..

Screen on.. Known cycles lost..

Screen width.. Known cycles lost..

Scroll position.. Known cycles lost..

DLI fetch.. Known cycles lost..

LMS fetch.. Known cycles lost..

Badline.. Known cycles lost..

 

I only pick those 2, because I'm not able to recall all the specifics of the ST & Amiga after all these years.. But they'll do as a nice simple example i guess..

 

So where exactly do these indeterminate signals manifest themselves then ? Because unless I'm mistaken they're all (every single one of them!) entirely deterministic..

 

Yes, even Pentium is deterministic if you know when the CPU throttles, what state cache is in, what speed is the memory, etc. The point is you have to resynch on C64 but not for A8 or Amiga's copper. You don't have uniform DMA on sprites and your bus access signal is indeterminate in regards to color RAM.

[Crazyace]

It does require 3 bpp to reproduce the 5 colour mode - so it's a valid observation by Atariksi. And way back then, it was a plus point to compare against the Apple's 6 colour highres mode, and I guess it didn't require any extra h/w as there were already 5 playfield registers for the other text modes.

[atariksi]

That's an incorrect statement. On ST, C64, modern CPUs, and many others the stability is thrown off by indeterminate signals so they cannot be compared to Copper.

 

 

So firstly..

 

Indeterminate Signals.. You've pulled this old one before, and avoided answering it.. So..

...

I answered this before and the answer is the same now, but it's your LIES that make me want to stop answering. I never avoided answering it thus far.

 

Assuming for the sake of brevity, standard hardware on both and no unknown external devices capable taking over the bus or otherwise upsetting the apple cart of timing..

 

C64:

Sprite(s) on.. Known cycles lost..

Screen on.. Known cycles lost..

Badline.. Known cycles lost..

 

A8:

Memory alive.. Known Cycles lost..

Player(s) on.. Known Cycles lost..

Screen on.. Known cycles lost..

Screen width.. Known cycles lost..

Scroll position.. Known cycles lost..

DLI fetch.. Known cycles lost..

LMS fetch.. Known cycles lost..

Badline.. Known cycles lost..

 

I only pick those 2, because I'm not able to recall all the specifics of the ST & Amiga after all these years.. But they'll do as a nice simple example i guess..

 

So where exactly do these indeterminate signals manifest themselves then ? Because unless I'm mistaken they're all (every single one of them!) entirely deterministic..

 

Yes, even Pentium is deterministic if you know when the CPU throttles, what state cache is in, what speed is the memory, etc. The point is you have to resynch on C64 but not for A8 or Amiga's copper. You don't have uniform DMA on sprites and your bus access signal is indeterminate in regards to color RAM.

 

Answer is already there in the other thread if you still think I never answered it before. Indeterminate signal is due to sprites and the color RAM. As far as 3 bits/pixels goes, it's crystal clear that I wrote one bit comes from the upper bit of the char value and only 5 combinations are used.

[Crazyace]

I am not saying game is undoable on ST. Just objecting to the worst case scenario for moving chars. I think you assumed something before too regarding Boulderdash. These games are inferior on ST, but not undoable. They are even doable on Apple II.

 

As with Boulderdash you state that these games would be inferior on ST - but I contest that, as I can reproduce them 'as is' on the ST ( Boulderdash being the most challenging, but fun to work out ) and then they could easily be redrawn to have superior graphics.

The big point with Boulderdash ( when I was looking at 4 colour scrolling ) was that even though the ST lacks hardware scrolling ( and I wish it were there ) it has enough CPU power to reproduce the actual game scrolling found on the A8 game with plenty of cycles to spare.

I've found with reproducing Pacman on A8 that effectively drawing 5 16x16 4 colour sprite on an screen is pretty much consuming all of the cpu cycles at 60hz anyway .... ( I really should move away from the ST playing, and go back to that code )

[atarian63]

Except it seems there were some who were not in the industry at the time (or even born for that matter) that would like to change things to suit their view. Technical or not being in the industry and running a service center gives a perspective that few if any in the public would have.

As for ice cream..(wouldnt be surprised to see such a forum) many having seen both flavors made a preference. not likely to change after all these years. Just enjoy your preference and that is all fine

 

Well, we should be fair to the young, too. If a younger person takes it upon themselves to get interested in these dinosaur computers, I applaud them for showing a genuine interest in the field. It may help to be born prior to - and live through - the era, but it's also possible that a younger person looking back would have a fresh perspective. I mean, I was just a casual user (still am) but I formed some pretty biased opinions back in the day, and it took a hell of a lot to get me to appreciate other makes. Perhaps a youngster is free of this burden. Alas, you didn't have to be alive during the Civil War to discuss it and form opinions, or have lived through the Pleistocene epoch to meaningfully understand and debate the ice age.

 

Before you think I'm talking about myself: I'm as old as most of you (I imagine), and I freely admit I know considerably less (on this subject) than most (all?) of you, but I sure enjoy reading your techno-babble. I do believe these threads - as lamented as they are by some- can be both entertaining and informative at the same time.

Excellent point! Keeps interest in these old systems alive. I am only refering to those who wish to rewrite history.

[atarian63]

Wow! That A8 version looks great, so does the 2nd ST pic but gotta say wow for good ol A8!

That picture cannot be displayed by an A8. It uses the A8 palette but completely ignores all the limitations on color usage and resolution on the A8.

none the less quite a lovely pallette and not exceeded till Amiga

 

It may be doable on real A8 at least close to it. He's just speculating because most C64 fans think A8 is limited to 160*200*5 whereas in REALITY it's 160*200*128/256.

 

This is pure bollox, show me one GAME from the 80s that uses more than a handfull of colours ANYWHERE on screen ie NOT rubbish limited DLI rasterbar effects on the A8...none then...thought not

 

Even the C64 has demos with complete overscan on horizontal/vertical borders using 16 colours but this isn't possible on a game.

 

The point is on an A8 no matter how good the programmer you will have blocky colour limited smooth scrolling games vs the STs border restricted highly colourful games with not so great scrolling IF the coder is useless and has no talent.

 

The only thing the ST shows up is talentless coders, the A8 just shows it's horribly restricted colour resolution making the excessive palette useless in games production (hence the C64 destroyed it)

cheap price and mismanagement destroyed it. Other than that c64 is crap.However St in it's time was revolutionary. Truly power without the price. (I hate quoting Jack)

[Lazarus]

cheap price and mismanagement destroyed it. Other than that c64 is crap.However St in it's time was revolutionary. Truly power without the price. (I hate quoting Jack)

Let's not forgot the better games on C64 with less coding effort.

[PeteD]

It does require 3 bpp to reproduce the 5 colour mode - so it's a valid observation by Atariksi. And way back then, it was a plus point to compare against the Apple's 6 colour highres mode, and I guess it didn't require any extra h/w as there were already 5 playfield registers for the other text modes.

 

Hmm we are talking about the A8 here? I wouldn't class a 2bpp + msb of char index to be 3bpp at least not in the way it sounds if it isn't fully explained to people.

 

 

Just out of interest here's an APAC Battlestar..

 

 

Pete

[PeteD]

Wow! That A8 version looks great, so does the 2nd ST pic but gotta say wow for good ol A8!

That picture cannot be displayed by an A8. It uses the A8 palette but completely ignores all the limitations on color usage and resolution on the A8.

none the less quite a lovely pallette and not exceeded till Amiga

 

It may be doable on real A8 at least close to it. He's just speculating because most C64 fans think A8 is limited to 160*200*5 whereas in REALITY it's 160*200*128/256.

 

This is pure bollox, show me one GAME from the 80s that uses more than a handfull of colours ANYWHERE on screen ie NOT rubbish limited DLI rasterbar effects on the A8...none then...thought not

 

Even the C64 has demos with complete overscan on horizontal/vertical borders using 16 colours but this isn't possible on a game.

 

The point is on an A8 no matter how good the programmer you will have blocky colour limited smooth scrolling games vs the STs border restricted highly colourful games with not so great scrolling IF the coder is useless and has no talent.

 

The only thing the ST shows up is talentless coders, the A8 just shows it's horribly restricted colour resolution making the excessive palette useless in games production (hence the C64 destroyed it)

cheap price and mismanagement destroyed it. Other than that c64 is crap.However St in it's time was revolutionary. Truly power without the price. (I hate quoting Jack)

 

Hmm. Crap and "angry bees" may be your opinion but do you have to keep repeating it every couple of pages? I think we got the message about how you feel about C64 etc a looong time ago

 

 

Pete

[Crazyace]

Hmm we are talking about the A8 here? I wouldn't class a 2bpp + msb of char index to be 3bpp at least not in the way it sounds if it isn't fully explained to people.

 

 

Just out of interest here's an APAC Battlestar..

 

 

Pete

 

Cheers for that - I think the pictures show a valid comparision between the two machines quite well

 

I find it easier not to argue that point in this case - it just muddies things - and to display 5 colours I have to go up to 3 bitplanes ( Funnily enough it was actually quicker to go directly to 4 planes for the Boulderdash scroll code )

[+DarkLord]

For Atariski I looked at the Rescue picture on ST.

 

Here is a standard version frat8.jp

And then there's a photochrome format version fratphoto.jpg

 

But a better test would be to use a reference image that not 80 pixels across - BSTAR.jpg

 

Normal ST ( spectrum 512 ) - bstar512.jpg

Normal ST ( photochrome ) - battlepcs.jpg

Atari 8 bit ( GTIA ) - BSTARa8.jpg

 

( Please feel free to upload a better A8 version, I haven't got any tools to make hip or other A8 advanced image formats )

 

Just out of curiosity, (and sorry if you said this somewhere else), did you convert the Photochrome version from

a copy that had thousands or millions of colors? (as in an original?). If you converted it from a low-count color

version, you're not gonna see Photochrome's advantages.

 

I mean, if I took picture A, made up of 256k colors and converted it, Photochrome will be doing its best, whereas

if I took picture B, at 128 colors and converted it, the results won't be as good nor it will reflect what the ST

and Photochrome can do.

 

Thanks!

[Crazyace]

Just out of curiosity, (and sorry if you said this somewhere else), did you convert the Photochrome version from

a copy that had thousands or millions of colors? (as in an original?). If you converted it from a low-count color

version, you're not gonna see Photochrome's advantages.

 

I mean, if I took picture A, made up of 256k colors and converted it, Photochrome will be doing its best, whereas

if I took picture B, at 128 colors and converted it, the results won't be as good nor it will reflect what the ST

and Photochrome can do.

 

Thanks!

 

The Rescue picture was just the 16 shade A8 original ( 80x200 ) resized to 320x200 16 shade, and then saved as a 24 bit TGA. So I wasn't expecting anything from it.

The Battlestar picture came from the web somewhere - ( I just google image searched for spaceships , and the Galactica is a bit more interesting than the Enterprise ) , the jpg is the original resized to 320x200 true colour.

[+Stephen]

Hmm we are talking about the A8 here? I wouldn't class a 2bpp + msb of char index to be 3bpp at least not in the way it sounds if it isn't fully explained to people.

 

 

Just out of interest here's an APAC Battlestar..

 

 

Pete

 

Cheers for that - I think the pictures show a valid comparision between the two machines quite well

 

I find it easier not to argue that point in this case - it just muddies things - and to display 5 colours I have to go up to 3 bitplanes ( Funnily enough it was actually quicker to go directly to 4 planes for the Boulderdash scroll code )

It also proves that you can't go by the commonly advertised machine specs for any system.

 

P.S.

No comparisons between these 2 sets of pictures either! No surprise either, except that I'm sure someone will come along to prove the ST images inferior.

 

 

Stephen Anderson

[ANTIQ]

Is there a converter for the A8 which can use all the modes, including kernels and underlays/overlays?

[+wood_jl]

The warning is the same kind of thing I see on any article ( ie - plugging other devices into joystick ports could damage the A8 , but it doesn't in most cases )

 

Yeah, like using Sega Genesis pads on the Atari 400/800/XL/XE or 2600. I have been doing this for years and have never seen a problem. However, I'm extremely afraid to try this with the Commodore 64 (obviously, not the most reliable computer), as I've read much more serious warnings about it blowing out the CIA chip. Dunno about the Vic-20 but afraid to try.