Atari 8bit is superior to the ST

[atariksi]

This thread is too long to keep track of. Let's "boil it down" to an easy-to-memorize chart of thread participants. Then you can zero in on the chart and know where a user stands.

 

A "RULES! or SUCKS!" form should be filled out by each user, for A8, C64, ST, Amiga. Then, one won't have to read all of the thread to jump in.

 

See if I'm keeping score correctly:

 

atariksi:

Atari 400/800/XL/XE: RULES!

...

Atari ST: SUCKS!

Amiga: RULES!

...

I would say "SUCKS!" is strong word. I am basically choosing A8 over ST if I had to choose one for good reasons. In reality, I have a few STs. I still hold onto the ST (not for it's CPU or high resolution) but for cycle-exact stuff like Spectrum 512 and some crack-tros (love those tightly coded, perfectly timed stuff lacking in modern PCs).

 

kool kitty89: all over the map

We need a supercat to get this kool kitty to get more focused and drop all this NES/TRS-80/Z-80/etc. crap.

[atariksi]

DLIs are have bugger all to do with the copper..

One more think I forgot to mention is that WSYNC is also optional on Atari if you get every cycle computed in the frame for each procedure used in the frame. Then you can have stable DLIs and WSYNC won't be needed. In high resolution on a 7.16Mhz Amiga, Copper has very few cycles per scanline and becomes like a horizontal blanking interrupt (x position becomes useless). And in 5/6 bitplane modes, bitplane DMA steals cycles meant for Copper/68K so again the x doesn't isn't that resolute.

[PeteD]

More corner cases that don't happen in the real world... "every cycle computed in the frame for each procedure used in the frame"? Maybe in a demo routine where you know exactly what you're doing you can make sure you have stable CPU timing so interrupts don't start at different scan positions, but anything "real" you have no clue as even something like a branch taken or not changes the outcome and that's just 1 instruction. Working out every case for when that happens or not for an app or a game is nigh on impossible. Add to that scrolling and your DMA stealing changes as well depending on the X offset, more problems to deal with.

 

 

Pete

[andym00]

One more think I forgot to mention is that WSYNC is also optional on Atari if you get every cycle computed in the frame for each procedure used in the frame. Then you can have stable DLIs and WSYNC won't be needed.

 

 

So in other words, nothing that every single other processor on the planet can't do anyway..

 

In high resolution on a 7.16Mhz Amiga, Copper has very few cycles per scanline and becomes like a horizontal blanking interrupt (x position becomes useless). And in 5/6 bitplane modes, bitplane DMA steals cycles meant for Copper/68K so again the x doesn't isn't that resolute.

 

 

Fine, but in normal resolutions and depths that's not the case at all, you just want to make it sound like that's the only way it can be.. Anyway, as pointed out the Amiga has bugger all to do with this thread apart from you dragging it in to confuse things..

[Crazyace]

It depends on the image. I have seen images that have close to zero flicker. And logically speaking, toggling between shades closer together should give less flicker as is true for Gr.9.

I wonder if there are any good galleries - I've looked at some images on various AA topics , but if you've got any better examples? ( Maybe it's worth posting the best looking images on each platform , and then deciding )

 

 

 

That's pretty good that they got all those software sprites and animations done at 60Hz on A8; I thought they would use more sprites since I never saw more than two monsters in a horizontal zone. Nonetheless, it's repaint job for ST.

Yes, I was quite surprised - but it makes sense, as you could easily have 4 monsters on the same line in the designer. ( See picture )

But it's only 4 real colours for everything except Mr Robot - so I could easily repaint the entire screen, 4 enemies , and Mr Robot in a NTSC frame. ( and if I used 4 screens, I wouldn't actually take any real time for any of the actual repeating animations )

[atariksi]

One more think I forgot to mention is that WSYNC is also optional on Atari if you get every cycle computed in the frame for each procedure used in the frame. Then you can have stable DLIs and WSYNC won't be needed.

 

 

So in other words, nothing that every single other processor on the planet can't do anyway..

...

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. On A8, the reset trapping code and VBI trapping code shows that without WSYNC you can do cycle exact coding and sprites, DLIs, VBIs, keyboard, etc. will not affect the cycle-exactness. On pentium chips, you get power management, cpu throttling, caching, I/O wait states, etc. to throw things off.

 

In high resolution on a 7.16Mhz Amiga, Copper has very few cycles per scanline and becomes like a horizontal blanking interrupt (x position becomes useless). And in 5/6 bitplane modes, bitplane DMA steals cycles meant for Copper/68K so again the x doesn't isn't that resolute.

 

 

Fine, but in normal resolutions and depths that's not the case at all, you just want to make it sound like that's the only way it can be.. Anyway, as pointed out the Amiga has bugger all to do with this thread apart from you dragging it in to confuse things..

 

Perhaps you're the only one confused. A8 is doing in a DLI exactly what the Copper does on Amiga but just has less CPU power to do as many register modifications per scanline. Copper has 113 cycles per scanline and that goes down depending on graphics mode. A8 has 105 cycles per scanline and that goes down depending on graphics mode.

 

And the point was that 4-color mode is not really 4-color mode once you take the DLI effects into account. Nothing confusing about it.

[PeteD]

Surely sprites (PMGs) do effect the timing in the same way as C64 sprites because the C64 ones only steal cycles when they're there and the same happens with PMGs. If you want to save some cycles on A8 you'd turn off DMA or at least the DMA refresh for the PMGs. No difference then apart from as a standard setting PMGs are full screen height an C64 sprites aren't. No doubt you'll find some way of twisting that logic too..

 

As for DLI's being the same as copper, they have extra overheads of the interrupt entry/exit, interrupt handling (such as other interrupts triggering) etc that Copper doesn't have. DLIs are nothing more than interrupts, the DL itself is closer to what copper is but is severely limited in its functionality.

 

Pete

Edited December 30, 2009 by PeteD

[+rdemming]

I am not talking about unreliable means like SYNC scrolling or VSP which put the system in an unreliable state by screwing monitor frequencies or garbling up memory.

Do you actually have any evidence for this for Sync scrolling? - as none of the sync scrolling techniques I've seen change monitor frequencies or garble memory ( no memory seems to be changed at all - the shifter doesn't write after all )

 

Yes. I combined both of those unreliable hacks into one sentence. One uses frequency toggling the other causes memory issues. I have read about both and thus avoided both.

 

Read these articles about ST overscan:

http://alive.atari.org/alive9/ovrscn1.php

http://alive.atari.org/alive11/oscan2a.php

 

Then you will see that the quick toggling of the frequency (as used with overscan or sync scroll) during the display of a line won't change the output frequency. The very short change of the frequency registers only makes that the display enable signal to the shifter is starting earlier or stopping later. The VSYNC and HSYNC output signals are not changed.

 

Robert

[+poobah]

They tried to hide their embarassing situation of having the most inferior joystick ports ever built for Atari machines-- 781 bytes/second protocol which requires multibyte packets to read joysticks w/keyboard and mouse overloaded on the same bandwidth. If you could port over a video digitizer to Atari ST, it would capture less thanb 1/30 frame per second (compared to 30 frames/second live video).

 

There were several ST video digitizers. They used the cart port.

[+poobah]

 

Herein lies the problem with certain people's attitudes to what other people say in threads like this. I'm not pro or con any of them, I'm pro facts when it comes to talking about their capabilities. As of now I've owned them all, worked professionally on 3/4 of them and am now in the middle of working on at least game ideas for 3 of them (ditching the Amiga because there's no point doing what I want to on ST on the miggy and going full out on A8). I don't think any of them "suck" but I think some people do need a reality check when it comes to what each machine is or isn't capable of in a real world situation (which is why I'll argue with people), not take 1 point and argue about it removing parts of what's been claimed until it boils down to a spec of actual truth then banging on about it like it actually matters, not guessing at what one machine can do and presuming (due to lack of actual knowledge no doubt) that other's can't and refusing to admit they can when proof is handed to them..

 

 

Pete

 

Amen!

[andym00]

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..

 

 

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..

[+poobah]

One more think I forgot to mention is that WSYNC is also optional on Atari if you get every cycle computed in the frame for each procedure used in the frame. Then you can have stable DLIs and WSYNC won't be needed.

 

 

So in other words, nothing that every single other processor on the planet can't do anyway..

...

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. On A8, the reset trapping code and VBI trapping code shows that without WSYNC you can do cycle exact coding and sprites, DLIs, VBIs, keyboard, etc. will not affect the cycle-exactness. On pentium chips, you get power management, cpu throttling, caching, I/O wait states, etc. to throw things off.

 

 

As much as it pains me to say so, in this specific instance, atariksi is indeed (mostly) correct.

 

Modern CPU's do not deterministically execute code. You can't be sure exactly how many cycles is will take for a given code sequence to execute. Multiple cores, multiple levels of cache, out of order execution, etc. etc.

 

No way you can count cycles and say "this code will definitively execute in 29 cycles". The A8, ST and friends rely on that for many video effects

 

You can mask interrupts on the ST if you need cycle exact-ness.

[oky2000]

They tried to hide their embarassing situation of having the most inferior joystick ports ever built for Atari machines-- 781 bytes/second protocol which requires multibyte packets to read joysticks w/keyboard and mouse overloaded on the same bandwidth. If you could port over a video digitizer to Atari ST, it would capture less thanb 1/30 frame per second (compared to 30 frames/second live video).

 

There were several ST video digitizers. They used the cart port.

 

You don't need

 

To turn this on it's head ALL 64kb+ A8 machines were limited to two joystick ports, on the ST you could have 4 joystick ports with a Parallel Port adaptor

 

And to be honest, the stuff you are trying to do on the joystick port on the A8 there is 10s of other superior ports more suitable for the job anyway...so it is an exercise in futility. The truth is the ST's joystick ports did what they were supposed to do, not some frankenstein project you had to make on an A8 because it had LESS output/input ports.

[Heaven/TQA]

just a stupid question... I found my limited edition of Dragonflight game (yes, sometimes looking in the attic is quite interesting...) but looking on the webshrine of Thalion I can not find any ST image? does anybody have one?

[Heaven/TQA]

http://www.lysator.liu.se/~celeborn/sync/page3.html

 

just in case some of you want to go deep into tech talk... (I don't )

 

btw... just remember someone saying here some valid point for the SID... (Oky2k)... Yes, I agree, on the sid each composer had some different style and you really could have some different style in terms of sounding while yamaha sounds most of the time like the YM chip...

[atarian63]

Umm, judging by these: http://www.youtube.com/watch?v=PhqrfB7UbPY (1:15)

(0:45)

I'd have to say I prefer the A8's sound most definitely, if any C64 stuff fits Atarian's "angry bees" argument, that game is a prime example. (I mean it's OK, but I much prefer the clean sound of the A8, which apears to be using POKEY's viriable pulse-wave to good effect -kind of NES sounding) Not a bad looking game by comparison either. (though there isn't much A8 stuff on youtube for that game, so it's not as easy to compare for someone who doeasn't actually own it)

 

The A8 stuff sounds like a demented Colecovision to me. ho hum.

 

The "angry bees" thing is a subjective opinion on my part though back in the day it was shared by many. It's a love it or hate it sound I guess. The sound drove me right up a wall. I always made the employees turn in down a bit, though I was always game for the user group guys coming in and running demos.

 

Yeah many blinkered atari fanboys that is*

take off the commode a dore blinders dude.

 

He keeps making off-topic already-refuted remarks. He is drawing conclusions about machines just from Salamander and a few games which haven't yet appeared on A8. And he can't understand that DLIs are equivalent of what Amiga does with the Copper. It's a feature like his crappy C64 does with Color RAM to make the screen appear to have more color depth although C64 has more restrictions in graphics modes, text modes, colors, etc. And even their color RAM makes DAC-based music sound like crap and causes instability in timing things. A8 has real linear 16-color modes that don't rely on color RAM and its consequent disadvantages. Yeah, he should take off his commodore blinders and re-read the 19 items I listed against his C64. I bet all those returns of failed C64s adds to the crappiness already substantiated by failing 6526s, PLAs, etc.

In a simple sense it's like ice cream..

For a non specific example.

You like choclate lets say.I don't like chocolate

I like Vanilla. You don't like vanilla.

Throw in a smidge of brand loyalty (hard to to since the brands changed sides or mixed).

There you have it.

Flame on, but in reality if it's good for you, then fine.Just don't try to convince me that mine sucks and yours is great.

 

Go like your chocolate, I'll stay with my Vanilla. They are both classics so enjoy.

[Heaven/TQA]

the interesting part for me are the 2 sync scroll examples... basic idea is the same but execution different... and have not seen 68000 code for ages... but looks familiar...

[Crazyace]

It depends on the image. I have seen images that have close to zero flicker. And logically speaking, toggling between shades closer together should give less flicker as is true for Gr.9.

 

... I found this as an example for the standard ST ( not STe ) - in my eyes it looks pretty good

PICS.zip

[PeteD]

Umm, judging by these: http://www.youtube.com/watch?v=PhqrfB7UbPY (1:15)

(0:45)

I'd have to say I prefer the A8's sound most definitely, if any C64 stuff fits Atarian's "angry bees" argument, that game is a prime example. (I mean it's OK, but I much prefer the clean sound of the A8, which apears to be using POKEY's viriable pulse-wave to good effect -kind of NES sounding) Not a bad looking game by comparison either. (though there isn't much A8 stuff on youtube for that game, so it's not as easy to compare for someone who doeasn't actually own it)

 

The A8 stuff sounds like a demented Colecovision to me. ho hum.

 

The "angry bees" thing is a subjective opinion on my part though back in the day it was shared by many. It's a love it or hate it sound I guess. The sound drove me right up a wall. I always made the employees turn in down a bit, though I was always game for the user group guys coming in and running demos.

 

Yeah many blinkered atari fanboys that is*

take off the commode a dore blinders dude.

 

He keeps making off-topic already-refuted remarks. He is drawing conclusions about machines just from Salamander and a few games which haven't yet appeared on A8. And he can't understand that DLIs are equivalent of what Amiga does with the Copper. It's a feature like his crappy C64 does with Color RAM to make the screen appear to have more color depth although C64 has more restrictions in graphics modes, text modes, colors, etc. And even their color RAM makes DAC-based music sound like crap and causes instability in timing things. A8 has real linear 16-color modes that don't rely on color RAM and its consequent disadvantages. Yeah, he should take off his commodore blinders and re-read the 19 items I listed against his C64. I bet all those returns of failed C64s adds to the crappiness already substantiated by failing 6526s, PLAs, etc.

In a simple sense it's like ice cream..

For a non specific example.

You like choclate lets say.I don't like chocolate

I like Vanilla. You don't like vanilla.

Throw in a smidge of brand loyalty (hard to to since the brands changed sides or mixed).

There you have it.

Flame on, but in reality if it's good for you, then fine.Just don't try to convince me that mine sucks and yours is great.

 

Go like your chocolate, I'll stay with my Vanilla. They are both classics so enjoy.

 

But if you were on an icecream forum (I'm sure there are such things lol) and looking to find a nice vanilla icecream and someone was shouting about Raita vanilla icecream is the best because it has less ice crystals compared to all the others and you had no way of knowing if that was true and just believed it.....

 

I don't think at this or any point really (apart from some weird folk) anyone is trying to get the other people to change their minds about their affiliations. It tends to be (especially now some more knowledgeable folk have appeared) separating the wheat from the chaff as it were in the hope some people won't be blinded by technical babble.

 

 

 

Pete

[Crazyace]

Also, for MrRobot - painting the screen could run quite quickly, even with a 8x8 charset.

 

Something like this per character:

 

move.w (a4)+,a3 [8]

beq.s skip [8] or [12 if skip taken]

add.l a5,a3 [8]

movem.w (a3),d0-d7 [12+4*8]

movep.w d0,0(a6)

movep.w d1,160(a6)

...

movep.w d7,1120(a6) [16*8]

skip:

 

It's a total of 196 cycles/char on a grid of 40x20 ( as used by MrRobot ) thats 156800 cycles, which is too slow for 60Hz.

However most of the Mr Robot screens have massive amounts of blank space - so in practice less than 50% of the characters will need to be painted.

The cost of skipping 50% is just 20*40*(8+12)/2 = 8000 cycles, and the painting then costs 78400 - so the total is way less than a frame.

And really, only the characters that actually animate will nead to be repainted, and in practise less than 20% of the characters would qualify in any one level, which is a further saving.

[atariksi]

Also, for MrRobot - painting the screen could run quite quickly, even with a 8x8 charset.

 

Something like this per character:

 

move.w (a4)+,a3 [8]

beq.s skip [8] or [12 if skip taken]

add.l a5,a3 [8]

movem.w (a3),d0-d7 [12+4*8]

movep.w d0,0(a6)

movep.w d1,160(a6)

...

movep.w d7,1120(a6) [16*8]

skip:

 

It's a total of 196 cycles/char on a grid of 40x20 ( as used by MrRobot ) thats 156800 cycles, which is too slow for 60Hz.

However most of the Mr Robot screens have massive amounts of blank space - so in practice less than 50% of the characters will need to be painted.

The cost of skipping 50% is just 20*40*(8+12)/2 = 8000 cycles, and the painting then costs 78400 - so the total is way less than a frame.

And really, only the characters that actually animate will nead to be repainted, and in practise less than 20% of the characters would qualify in any one level, which is a further saving.

 

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?

[atariksi]

Also, for MrRobot - painting the screen could run quite quickly, even with a 8x8 charset.

 

Something like this per character:

 

move.w (a4)+,a3 [8]

beq.s skip [8] or [12 if skip taken]

add.l a5,a3 [8]

movem.w (a3),d0-d7 [12+4*8]

movep.w d0,0(a6)

movep.w d1,160(a6)

...

movep.w d7,1120(a6) [16*8]

skip:

 

It's a total of 196 cycles/char on a grid of 40x20 ( as used by MrRobot ) thats 156800 cycles, which is too slow for 60Hz.

However most of the Mr Robot screens have massive amounts of blank space - so in practice less than 50% of the characters will need to be painted.

The cost of skipping 50% is just 20*40*(8+12)/2 = 8000 cycles, and the painting then costs 78400 - so the total is way less than a frame.

And really, only the characters that actually animate will nead to be repainted, and in practise less than 20% of the characters would qualify in any one level, which is a further saving.

 

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?

[atariksi]

It depends on the image. I have seen images that have close to zero flicker. And logically speaking, toggling between shades closer together should give less flicker as is true for Gr.9.

 

... I found this as an example for the standard ST ( not STe ) - in my eyes it looks pretty good

 

That looks pretty good. Same Nrsima (half man/half lion) image I used in my A8 demo posted earlier in the thread.

 

This looks like more than 16 colors though...

[atariksi]

They tried to hide their embarassing situation of having the most inferior joystick ports ever built for Atari machines-- 781 bytes/second protocol which requires multibyte packets to read joysticks w/keyboard and mouse overloaded on the same bandwidth. If you could port over a video digitizer to Atari ST, it would capture less thanb 1/30 frame per second (compared to 30 frames/second live video).

 

There were several ST video digitizers. They used the cart port.

 

You don't need

 

To turn this on it's head ALL 64kb+ A8 machines were limited to two joystick ports, on the ST you could have 4 joystick ports with a Parallel Port adaptor

 

And to be honest, the stuff you are trying to do on the joystick port on the A8 there is 10s of other superior ports more suitable for the job anyway...so it is an exercise in futility. The truth is the ST's joystick ports did what they were supposed to do, not some frankenstein project you had to make on an A8 because it had LESS output/input ports.

 

No, parallel port is also 8-bit just like two A8 joystick ports combined. You can do BYTE i/o on A8 using LDA 54016 or STA 54016 so it's the fastest port on A8 and equivalent to having a parallel port on A8. But both parallel ports and joystick ports can use simple software to communicate rather than build some circuit and specialized connectors like you would need to use cartridge port on either machine. And both parallel port and joystick ports were standards in their time. But both ST and PC lack a +5V signal for devices on parallel ports but cable transfer stuff like laplink or my software works fine.

 

By the way, C64 doesn't allow BYTE mode on it's joystick ports in addition to being slower.

[atariksi]

Umm, judging by these: http://www.youtube.com/watch?v=PhqrfB7UbPY (1:15)

(0:45)

I'd have to say I prefer the A8's sound most definitely, if any C64 stuff fits Atarian's "angry bees" argument, that game is a prime example. (I mean it's OK, but I much prefer the clean sound of the A8, which apears to be using POKEY's viriable pulse-wave to good effect -kind of NES sounding) Not a bad looking game by comparison either. (though there isn't much A8 stuff on youtube for that game, so it's not as easy to compare for someone who doeasn't actually own it)

 

The A8 stuff sounds like a demented Colecovision to me. ho hum.

 

The "angry bees" thing is a subjective opinion on my part though back in the day it was shared by many. It's a love it or hate it sound I guess. The sound drove me right up a wall. I always made the employees turn in down a bit, though I was always game for the user group guys coming in and running demos.

 

Yeah many blinkered atari fanboys that is*

take off the commode a dore blinders dude.

 

He keeps making off-topic already-refuted remarks. He is drawing conclusions about machines just from Salamander and a few games which haven't yet appeared on A8. And he can't understand that DLIs are equivalent of what Amiga does with the Copper. It's a feature like his crappy C64 does with Color RAM to make the screen appear to have more color depth although C64 has more restrictions in graphics modes, text modes, colors, etc. And even their color RAM makes DAC-based music sound like crap and causes instability in timing things. A8 has real linear 16-color modes that don't rely on color RAM and its consequent disadvantages. Yeah, he should take off his commodore blinders and re-read the 19 items I listed against his C64. I bet all those returns of failed C64s adds to the crappiness already substantiated by failing 6526s, PLAs, etc.

In a simple sense it's like ice cream..

For a non specific example.

You like choclate lets say.I don't like chocolate

I like Vanilla. You don't like vanilla.

Throw in a smidge of brand loyalty (hard to to since the brands changed sides or mixed).

There you have it.

Flame on, but in reality if it's good for you, then fine.Just don't try to convince me that mine sucks and yours is great.

 

Go like your chocolate, I'll stay with my Vanilla. They are both classics so enjoy.

 

Well, it's not that simple and subjective. You can have vanilla from Breyers that used superior ingredients and is more expensive than some non-brand ice-cream that uses inferior ingredients to make the product cheaper. Now regardless of which one sells more, one can argue objectively which is the superior product.