Atari v Commodore

[Crazyace]

I think overscan is one area where the 8 bit wins - it takes a lot of effort to open the borders on the C64, on the Atari it's quite easy ( even trivial ) - and if you're using horizontal scrolling there's no real point not using the wide playfield as the data is fetched anyway.

[Thomas Jentzsch]

I think overscan is one area where the 8 bit wins - it takes a lot of effort to open the borders on the C64,

Only the horizonatal borders are really tricky. The vertical ones are very simple to open.

[Crazyace]

they still need more effort that on the 8bit atari.

I never played around with the c64 that much - does scrolling still work with the borders removed?

[Thomas Jentzsch]

I never played around with the c64 that much - does scrolling still work with the borders removed?

I never tried back then, I was happy with soft-scrolling working so smoothly.

 

But I suppse it doesn't work, since the same registers which allow opening the screen are involved in soft-scrolling.

[Fröhn]

But I suppse it doesn't work, since the same registers which allow opening the screen are involved in soft-scrolling.

Not true. Bit 3 is used for opening sideborder and bits 2-0 are used for soft scrolling.

[Thomas Jentzsch]

But I suppse it doesn't work, since the same registers which allow opening the screen are involved in soft-scrolling.

Not true. Bit 3 is used for opening sideborder and bits 2-0 are used for soft scrolling.

Still true. Same register, different bits.

 

IIRC the screens wraps around during soft scrolling, that's why you reduce the screensize then. Right?

 

I suppose that can be overcome by mid screen data manipulation, but that would be like coding for the ancient Atari 2600.

[Crazyace]

Actually I'll show my ignorance of the c64 here - when you open the borders, is there still character data being fetched in the borders?

[emkay]

Actually I'll show my ignorance of the c64 here - when you open the borders, is there still character data being fetched in the borders?

 

Standard modes:

small size 32 bytes

small size + scrolling 40 bytes

standard size 40 bytes

standard size + scrolling 48 bytes

open border 48 bytes

open border + scrolling 48 bytes

 

Or you're talking about the C64 ones?

Edited November 23, 2008 by emkay

[Crazyace]

Yes, the C64..

I had a look around, and most of the comments ( in C= hacking for example ) just talk about the border disappearing and the ability to put sprites there - I guess that it must be possible - as there are games with control panels in the bottom border, but I dont really want to waste too much time researching it

[Fröhn]

Yes, the C64..

I had a look around, and most of the comments ( in C= hacking for example ) just talk about the border disappearing and the ability to put sprites there - I guess that it must be possible - as there are games with control panels in the bottom border, but I dont really want to waste too much time researching it

Then don't. Like most A8 games programmers which don't use the overscan feature too even though its only 1 bit to change.

[Crazyace]

Does that mean it's not possible? I was hoping that you'd be a bit more helpful - I spent more time programming on the 8 bit ( I had a 64 , but the only game I wrote was a graphic adventure - and I wrote it using Mac65, and transferred to the c64 via a joystick to par port cable .. It wasn't something that stretched the technical capabilities of the c64 much )

On the a8 the left/right border is way smaller - and on NTSC it may actually be overscanned already, so it's not so obvious as on the c64.

 

I should finish my pacman demo - it would be so much easier on the C64 because of the amazing sprite capabilities - but the playfield is overscanned fully on the a8

[Fröhn]

Let me be more helpful: There are countless things which are easy to do on A8 which are hard to do on C64. Yet A8 people don't do them but instead prefer to imitate C64 stuff or complain about that its not done. Overscan is one of them. And all those "hard to do on C64" stuff like techtech too.

[TMR]

IIRC the screens wraps around during soft scrolling, that's why you reduce the screensize then. Right?

 

Not wraps around, it just remains 40 bytes wide and 25 bytes high regardless of what the scrolling is doing; the lower three bits of the scroll register move that area by up to seven pixels and when smooth scrolling is enabled the borders are pulled in 8 pixels on either side or four pixels vertically to mask that "dead" column or row. So using the lower three bits to scroll and the fourth for opening the borders works quite happily, the only issue is that because the borders aren't present to mask the edges it has to be done manually. There are examples of games using borders with vertical scrolling, such as Slap Fight (or Alcon for the NTSC territories) and the Shoot 'Em Up Construction Kit game engine where the game uses the entire screen and the status panels are wedged in the borders using sprites.

 

There is even one game called Freak Out (a freeware Breakout clone) that deliberately disables the screen RAM and kicks out the upper and lower borders before running the entire game over that expanded area using the hardware sprites.

[Oswald]

Probably my sight of things comes from the direction of firstly playing Turrican 2 on the AMIGA, where Turrican 2 was an outstanding game in graphics, sound, gameplay...

But sometimes I was wondering, why the enemies were so hard triggered in the levels.... Until I played the C64 Turrican (2)... Well, it does all fit together ...:

They had to keep the gamelogic of the original in the AMIGA Version...

 

Most games on the C64 suffered by the CPU speed when it come to the game logic.

 

forget the amiga, you should compare Turrican 1/2 to.. what on the a8 ? there's nothing comparable...

 

so I am wondering what gives you the "right" to turn it down because of this or that detail? Its better than anything on the a8 whatever you come up with it wont help this simple little fact.

 

edit:

 

"Most games on the C64 suffered by the CPU speed when it come to the game logic."

 

you have no idea what it takes to handle hundreds of enemies even when they're offscreen. impossible task for any 8 bit machine. the A8 never did it, so its stupid to point fingers and blame most c64 games coming short of logic because of this.

Edited November 24, 2008 by Oswald

[Oswald]

Oswald... the pic distorter is exactly for what I would use display list manipulation... but question... is this done by so called "techtech" vic trick? or pure software?

 

tech tech is the name for shifting a picture different amount of pixels horizontally on each rasterline this is well vic trick and software, i can tell the details but that will be a longer post. quite simple actually.

[Oswald]

I think overscan is one area where the 8 bit wins - it takes a lot of effort to open the borders on the C64, on the Atari it's quite easy ( even trivial ) - and if you're using horizontal scrolling there's no real point not using the wide playfield as the data is fetched anyway.

 

the overscan stuff is another not so useful feature like wsync, HW scrolling, DLI, antic. it doesnt do anything truly important that comes really handy when doing 2d games. Give me rather useful sprites, 256 chars, useable colors, etc

[Oswald]

Actually I'll show my ignorance of the c64 here - when you open the borders, is there still character data being fetched in the borders?

 

no. one specific byte of the memory is repeated over and over again each bit=1 black pixel, but even that is only displayed in the top/bottom border area.

[atariksi]

I think overscan is one area where the 8 bit wins - it takes a lot of effort to open the borders on the C64, on the Atari it's quite easy ( even trivial ) - and if you're using horizontal scrolling there's no real point not using the wide playfield as the data is fetched anyway.

 

the overscan stuff is another not so useful feature like wsync, HW scrolling, DLI, antic. it doesnt do anything truly important that comes really handy when doing 2d games. Give me rather useful sprites, 256 chars, useable colors, etc

 

Another biased, one-sides narrow minded selfish answer like others I will prove shortly.

[Rybags]

Overscan not useful?

 

Then why do more than half the C-64 demos out there get the C= owners dribbling with joy over something as trivial (to an Atarian) as sprites in the border?

 

IMO, one of the biggest shortcomings by far of the C-64 was the 320x200 fixed architecture. Using sprites in the border is useful only in the context of things like status displays for games.

[atariksi]

>I have asked if do you think A8 can make better shmups than the best of the c64 (for the ~4th time here again). Do you have an answer? answer to the question please. can you?

 

I don't know what a "speccy" is nor an shmups. It doesn't sound like an English word to me. Overall ANTIC is more powerful-- even if you can show some cartoons with 16 colors.

 

thats sums it up pretty nicely: reality denial. when one starts to act like he is stupid to defend its case, there's nothing left to say.

 

The answer is in post #124 you partly quoted and my other posts if you had taken some time to read and understand. You are not in touch with reality when one year you claim ANTIC is more powerful than another year you claim the opposite all the while the C64 and Atari stay the same. And now you are picking and choosing things and denying reality. ANTIC has a lot more modes than just 160*200 and even the very post you are misquoting I suggested a method to get many colors in that mode. We are not targetting your applications which may be requiring 16 colors horizontally within the first 64 pixels or something like that. The hardware potential of a machine is not what you like. Your mental concoction that higher bus width of the VIC2 means superior chip is not true. The C64 is slower, the graphics are just an extension of its text mode, etc. You claiming Jay Miner did not meant to use tricks is clearly false as well. Just look at the Amiga with its HAM mode. It's 6-bits per pixel at 320*200 and gives a better image output in general than an 8-bit paletted image on the standard VGA 320*200*256 which came out years later. It's called compression. You put in some restrictions to get faster throughput and lower memory usage. You know your DVD movies would not have come out that early on if images had to be sent uncompressed or without color restrictions. I am sure you can find out all the various modes and options available for ANTIC (if you wanted to). Your graphics have to be done in cells whereas ANTIC has both available. You can get higher repaint/refresh rates and lower memory useage for applications that don't need 16 colors per scanline for their applications. And thanks to shades on the Atari, the interlace option works with much less flicker than you C64 palette.

[atariksi]

Now for PAL you need a 4.43 MHz color carrier, but since Atari didn't want to go far away from the 1.79 MHz, they didn't divide 4.43 MHz by 2, but by 2.5 to get 1.77 MHz. This is why you can't do artefacting anymore on PAL Ataris (2.5 color clocks per lores pixel, not exactly 2) and also the scrolling doesnt shift exactly 2 color clocks but 2.5...

Give a link to source of your information.

The source of that information is my brain, I know quite a lot of stuff about TV signals and also 8 bit machines. For example the PAL color carrier frequency is a result of 283.75 color clocks which are desired on a normal PAL rasterline multiplied by the line frequency of 15625 Hz, then added 25 Hz to avoid some interferences:

 

283.75 * 15625 + 25 = 4.43361875 MHz (Link)

 

Usually that frequency is generated from a four times faster clock (where it is easier to get different 90° phase shifts etc): 17.734475 MHz

 

17.734475 MHz / 4 = color carrier

17.734475 MHz / 10 = CPU clock (1.77 MHz) (Link)

17.734475 MHz / 10 * 4 = pixel clock (7.09 MHz)

 

For C64 it's similar:

 

17.734475 MHz / 4 = color carrier

17.734475 MHz / 18 = CPU clock (0.985 MHz)

17.734475 MHz / 18 * 8 = pixel clock (7.88 MHz)

 

I don't accept random searches of internet as all containing correct information or taking Atari/C64 to the limit.

Dude, I searched ONE TIME the bus speed of the SIO, why do you now make up that all I do is use google?

 

You can't have two unique colors on consecutive pixels in NTSC at 3.58Mhz.

No you can't have that, but that doesn't limit scrolling to "color clocks". If you have 4 hires pixels of the same color next to each other, you can still move them by 1 pixel and have no artefacting etc because it's the frequency which counts. The closer you get to those 4.43 MHz the more from the luma signal will get through the filter of the chroma carrier. It's all about frequencies and analog filters, and that's why the pixels themselves do not matter: They can be at any X-position, as long as the color carrier will not phase shift with them. Ofcourse switching from one color to another at a pixel doesn't work perfectly, that's why all those old PAL computers (Atari, C64, VIC20 etc) have fuzzy edges on colors when they meet different chromas.

 

Your source is your brain, my source is from "Mapping the Atari" which claims that on PAL it's still 228 color clocks/scanline.

 

My point was the color is not being retained if you do hscroll by 1/320.

 

Let's get to the guts of the issue here-- can you cause an IRQ on an exact point on the screen on the C64 (I'll avoid using color clock until we verify that Mapping the Atari is correct)? You can do that with the POKEY timer IRQs. Can you do the equivalent of horizontal triggering of hardware registers at exact points in the middle of the scanline using your raster interrupts (like you do with DLI/WSYNC on Atari)? Let's start off with the simple example that I posted before:

 

10 POKE 54286,0

20 POKE 54272,0

30 FOR T=1536 TO 1536+16*5 STEP 5

40 POKE T,169:POKE T+1,T-1536:POKE T+2,141:POKE T+3,26:POKE T+4,208

50 NEXT T

60 POKE T,208:POKE T+1,256-87:D=USR(1536)

 

Can you do the equivalent of the above on C64? Here I did not use WSYNC nor IRQs nor DLIs. And since I know C64 has lower clock speed, let me drop the colors to 8 instead of 17 that I did above.

 

As far as I/O speed goes, I underestimated by stating Atari is >2X. It's a lot faster than 2X since you would have to read nibble at a time and then form a byte before writing to memory. I would probably need to do some look-up or do ROL/RORs.

[Crazyace]

Thanks for the answer - I found about about the $3fff property after reading a bit more. So if the only way to use the borders is with sprites then this is a weakness against the 8bit atari. ( Of course in demos - where the level of coding is heroic, to say the least, the C64 pulls off some amazing effects )

[atariksi]

That is not subjective. More colors is definitely a feature people looked at when buying a machine until now when they all are TRUE color. 256 color palette is a superset of your palette (period).

 

The Commodore 64 has a total set of 16 colors, as compared with the Atari's total set of 256. On the other hand, the Commodore has no difficulty displaying all 16 colors on a line in high-res mode whereas the Atari can't do anything like that.

 

The total number of different colors on the Atari works to a huge advantage in games that use vertical color gradients. The ability to display more colors on a line works to a huge advantage on games whose color layouts aren't amenable to such treatment.

 

Too bad there's no way to retroactively add a 16x8 RAM to the C64 to give it the best of both worlds.

 

I am glad you agree that palette is an objective thing-- the bigger the palette the better. Obviously, if you had a C64 with 256 colors vs. a C64 with 16 colors, you would pick the one with 256 colors even if your application only used 16 colors since at least the hardware potential would be there to use them. As far as that would give you the "best of both worlds", you are greatly underestimating the Atari. You would still need to patch the C64 motherboard with:

 

(1) upgrade the CPU speed

(2) upgrade the CIA to use 1.79Mhz timing frequency or higher

(3) upgrade the graphics chip to allow for better overscanning, scrolling, dlists, graphics modes, text modes, DLIs, WSYNC, etc.

(4) upgrade the sound chip to have more voices

(5) remap the CIA so it can read the joysticks with one LDA and remove the keyboard overload on the joystick data.

(6) improve the ROM to allow for booting

....

 

I think I'll suggest a better solution: why not "finish" the ANTIC/GTIA chip so that the empty PM graphics memory actually contains 8 sprites and the missiles are re-use of the sprites with their own color registers. That would give you best of both worlds.

[TMR]

Overscan not useful?

 

Then why do more than half the C-64 demos out there get the C= owners dribbling with joy over something as trivial (to an Atarian) as sprites in the border?

 

Because the side borders in particular are a total bugger to do; anything that keeps them open is already an evil piece of code to get working and some of the more complex uses are total and utter scumbags. Doesn't mean it's useful as such, just highly impressive from a coding standpoint if you know what's going on.

[emkay]

Well, both were no "complete" computers.

The Atari looks like "filling the trousers before reaching the toilett" and the C64 was intentionally built cheap.

 

Having a closer look at the Atari, the first thing you recognize "there were talented people creating the hardware, back in the 70s" but they were not informed with all the needs about such machines and their knowledge ended at the borders of the USA...

We know that the ATARI got locked hires colours because the developers thought that a TV set cannot display them. Ridiculously GTIA is producing SVIDEO signals to have a separated Luma and Chroma signal... good enough for playing movies on every TV set, but the colours got locked to some alpha tone.

 

Also, when the XL appeared, a small capacitor at pokeys output connected to a not anymore used paddle controller, would have reached miracles...

 

Or GTIA Mode "10" .... 16 colours are possible but only 9 registers are used.... And, since the GTIA is a separated chip with it's own data bus, there really never was a problem to build some extra graphics RAM inside the XL series, that came to the market when RAM got much cheaper than in the 70s.