Oswald

Maybe that's why their rasters are not stable. Which reminds me, the three timer IRQs can do better than their raster irq. They can be set to 15.6999Khz frequency via bit 0 of 53768 and each count causes EXACTLY one scan line to go by. And even if set the IRQ in the middle of the scanline, it will occur at the end of the scanline. And you can set each of the three IRQs at arbitrary scanlines. the a8 rasters/irqs etc are not stable either. which reminds me, 4 timer IRQs can do better job than 3.

I doubt you can do that without wsync, or the corresponding c64 techniques. 6510 will finish the current instruction before serving an irq so you will have a jitter. no matter whats the irq source.

funny how amiga needs xor to check the bits, while the atari can do it with one lda. ammazing! timing blabbla: just as the sprites the pc does not need that. it can do better without it. and yes, its a scientific wonder, but the c64's cpu is in synch with its gfx chip. halleluja! Go check out the Amiga Hardware Reference manual if you have a problem. Hope you know that 68000 MOVEs generally take more cycles than LDA. And if you can't make a rational argument, don't reply-- let someone who knows about the subject reply. PC cannot do better w/o sprites. you have a problem: you neglect the code to check the bits when it comes to atari, but counting it when it comes to amiga. now THATS an irrational argument. furthermore you stated you are not comparing cpu speed but instruction count, thats another irrational statement as you TRIED to compare joystick ports to start with. and where do you end when comparing joyports? -> checking cpu instruction cycles and shit. what does it have to do with joystick state checking ? nothing my dear. pc: yes it can do better sprites with cpu/gpu. how couldnt it? go and see doom for example. This is the last time I'll reply to you if you keep up with your cursing. No, it's rational. I'm writing code to read the joystick status into a register. I'm not comparing CPU speed, but I/O speed. On PC I/O speed is MUCH slower than CPU speed. You can time it yourself using IN AL,DX where DX is set to 201h. Instruction count comes into play because Amiga has faster speed I/O than Atari but requires more instructions. a) where do I curse? b) how comes the atari doesnt need "some XOR algorithm" to check the bits, while the amiga has to ? and what does this has to do with joy I/O speed? b2) define joyport I/O speed c) who cares if its 25 or 30 zilionth of a second to check joystate ?gee a 0.01% performance difference? so what?

funny how amiga needs xor to check the bits, while the atari can do it with one lda. ammazing! timing blabbla: just as the sprites the pc does not need that. it can do better without it. and yes, its a scientific wonder, but the c64's cpu is in synch with its gfx chip. halleluja! Go check out the Amiga Hardware Reference manual if you have a problem. Hope you know that 68000 MOVEs generally take more cycles than LDA. And if you can't make a rational argument, don't reply-- let someone who knows about the subject reply. PC cannot do better w/o sprites. you have a problem: you neglect the code to check the bits when it comes to atari, but counting it when it comes to amiga. now THATS an irrational argument. furthermore you stated you are not comparing cpu speed but instruction count, thats another irrational statement as you TRIED to compare joystick ports to start with. and where do you end when comparing joyports? -> checking cpu instruction cycles and shit. what does it have to do with joystick state checking ? nothing my dear. pc: yes it can do better sprites with cpu/gpu. how couldnt it? go and see doom for example.

buhahaha c= pet had a serial bus before a8, and there was an industry standard for that before the c= pet. Yes, but the Atari serial is the grandfather of USB, not the PET. Who cares about the PET serial, not one person. And the MSDOS floppies is based on Atari DOS, read Retro Gamer, schoolboy. grandfather my ass. its just the same design philosophy. msdos floppies claim is probably similer: they are also circle shaped and spinning, right? :D

funny how amiga needs xor to check the bits, while the atari can do it with one lda. ammazing! timing blabbla: just as the sprites the pc does not need that. it can do better without it. and yes, its a scientific wonder, but the c64's cpu is in synch with its gfx chip. halleluja!

The point is the A8 Ping Pong example shows good use of "rainbow" colors, making picture more real with more color depth. C64 can't come close to this. indeed, it does have more important things than 128/256 colors. I doubt that. Also, A8 has even more important things than that. you doubt that? hell, c64 should have been 4096 colors with a screen able to display only one pixel. that would fulfill your list of important things alone you should see that 16 colors is (amongst others) the key to the high color density on the c64. it allows 2 independent colors in one byte. also it spares silicon space for sprites for example. 128 colors does little when you can only display them in very special circumstances (rainbow&static screen) and have to do softsprites, etc.

another entry on the unimportant feature list the a8 has and the c64 doesnt. keep it growing

buhahaha c= pet had a serial bus before a8, and there was an industry standard for that before the c= pet.

The point is the A8 Ping Pong example shows good use of "rainbow" colors, making picture more real with more color depth. C64 can't come close to this. indeed, it does have more important things than 128/256 colors.

not a typical scenario, one is playing a game but the keyboard interference has to be take care of because he might have wanting typign something while playing

HW sprites are simply outdated on the PC, there's no need for them and that doesnt means its not as good. it can do better with the CPU/GPU, just like the amiga can do better sprites with the blitter/cpu. who gives a shit if its 20 or 30 zillionth of a second is to check joy state? doesnt affects performance at all. wow atari is the best in that! it doesnt even needs some xor algorithm like the amiga! who give a shit again how does it happen. the pc owns all the rest of the 3 anyway.

Nice pictures, rich colors. That clearly shows how A8's various colors can be used to make scene more alive. yeah, luckily its the rainbow scene, even a 2600 would cope with it better then a c64 I don't see a problem with this, as far as the scene looks overall better. Compared to it, the C64 screen looks like a poor relative. Of course the colour attributes add quite some nice possibilities to colouring an image (and I really wish atari had this feature), but you're still heavily restricted by the limited palette, while Atari is not. that c64 screen is ~20 years old. I could similarly pick a 20 year old a8 screen and compare to something done today on the c64... whats the use of a palette you can not display in regular modes. its a bad engineering compromise not an advantage.

if you would think rationally and objectively you would realise that for the average game scenario 8x24x21 multicolor/hires sprites with hires X coordinates are better than 4x8 pixel wide stripes without hires/multicolor abilty (yes you can combine them to have even less vertical stripes for multicolor..). and if I look at the whole thing horizontally which represents the true throughput the system (vertically you kindof just multiplex the system) the atari lags behind heavily. And if you do the ORed mode horizontally at 4X sprite expansion, you'll see the ORing is at every pixel and so the throughput is similar horizontally as well. I was comparing both equally at 160*200 which is more used mode. I don't know where you get 4*8 from. throughputwise horizontally a8 sprites are less then half of c64 ones.

whats the definition of a normal red color ?

Nice pictures, rich colors. That clearly shows how A8's various colors can be used to make scene more alive. yeah, luckily its the rainbow scene, even a 2600 would cope with it better then a c64 Oswald, I don't know what is bothering you all the time. The fact is there are more color possibilities with A8 than C64. C64 colors don't even show all colors correctly, so many demonstration images are more like comics than true images. but atari colors show all colors correctly ? give a check to g2f gallery, images are more like comics than true images, and sub quality to (non cpu aided) c64 ones.

you should finish berzek, or beyond evil instead this ping pong game is really pointless, on the c64 it was unplayable. give it a go to see..

hello? and what that has to do with what I have said ? some consistency please ? was I talking about games shouldnt be made without hw sprites or anything ?! I haven talked about this either but: what you call a problem or a challenge is subjective matter again. give me a break. keep telling this to emkay please. its not me blabbling about virtual possibilities all the time.

Nice pictures, rich colors. That clearly shows how A8's various colors can be used to make scene more alive. While on the A8 you gain more and more colours by (quoting Oswald) "juggling around", the C64 can juggle as long as till it breaks: It never will show more than 16 "real" colours on the screen. Seeing the 21 colours of the ping pong game at the 4 colour ( ) resolution, and every of them are a part of a screen enhancement, tells all more colors doesnt helps. see previous post .) btw waiting for your pinball table mockup with 256 colors... you know, it only takes a decision of the coder as you said, lets decide so and show me

Nice pictures, rich colors. That clearly shows how A8's various colors can be used to make scene more alive. yeah, luckily its the rainbow scene, even a 2600 would cope with it better then a c64

pc>amiga>c64>atari agree pc>amiga>c64>atari c64 has 4 16bit timer interrupts, the timers can count the other timers underflow, be one shot, or continous. ok. it makes no sense to compare a nonstandard solution of the a8 amongst systems. should be IO: pc>amiga>atari>c64. you are comparing here cpu speed. tho I'm not sure a parallel drive-c64 is not faster then atari, as you can beef up the c64's drive while on atari it says constant speed. cpu speed again. nothing differentiates here amiga/c64/atari, all of them allow direct chip access.

if you would think rationally and objectively you would realise that for the average game scenario 8x24x21 multicolor/hires sprites with hires X coordinates are better than 4x8 pixel wide stripes without hires/multicolor abilty (yes you can combine them to have even less vertical stripes for multicolor..). and if I look at the whole thing horizontally which represents the true throughput the system (vertically you kindof just multiplex the system) the atari lags behind heavily.

I've tried the ones from http://www.interstyles.nl/pinball/ and http://noname.c64.org/csdb/release/?id=32484 Both of which are the same. Searching turns up no other versions. So if there is a newer one, I don't think it's actually been released? the csdb one has working bumpers and lights. check again. tho the lights are only wired in for the top "bonus multiplier" stuff.

"so arguing that we can't have this or that is not a really supportable position" sure it is. what is not supportable is to try to turn down objective arguments based on how many ppl like a platform on a given forum. you dontt have 24*8 hires pixel wide hw sprites. this is a fact regardless of what you like. "The fact that to do G2F pictures means lots of tricks are used to achieve the results - is rather irrelevant to the user/viewer, they appear to be colorful pictures, however achieved." it becomes suddenly revelant, when emkay starts to blabble that 256 colors is possible in a pinball game. in case of g2f pix 20-30 is used in best cases, but usually less then 16. now start to think how would you move a software ball sprite with pm underlays and cpu color changes all over the place, how would you move all table, it becomes very complex and about impossible.

Blablabla... Graph2font really does not support all GTIA features. It also does not support correct cpu timing when using a graphics kernel. And, you know what? Pictures never show the action during gameplay. As I wrote before. It is no problem to move the "standalone pictures up and down with only some commands, leaving enough cpu time for game handling, flipper and ball movement. the only "worse" would be the ball's resolution. And there is again a failure in your sentence "reach C64 quality". We don't need C64 quality, if coders decide to use the Atari quality instead. I dont give a crap how much GTIA features g2f doesnt supports yet, it wont get much better than that. sprite&cpu coloring <<< color memory to begin with. thats why it wont reach c64 quality. come on do a table mock up to proove me wrong.