Atari v Commodore

[atariksi]

Personally I think it's a real shame that the Amigas Workbench didn't end up as the dominant OS

 

yucko

Care to elaborate? I'm betting neither of you used anything other then the 1.x releases, and they were still much more feature rich then the TOS 1.x, Windows 1.x or any version of Apples system prior to 7.

 

Yes I know this is an Atari board, I'm a fan of the Atari consoles and a big fan of JMs work, but that doesn't mean I can't prefer other computer operating systems that weren't designed to run on Atari hardware

Oh I am with you there. Anything but Windows. We used to sell Amiga back in the day. All the way to the end. The hardware was great(jay miner) but I always hated that comic o/s. powerful yes, but just didn't care for it. just my personal opinion. I much preferred the Falcon/ST o/s.

To each his own.

 

I have more problems with the floppy system on Amiga and how the OS uses it rather than the OS. I mean multitasking floppy reads should never be allowed-- it just slows things down so much with the floppy drive grinding back and forth between various files. Also too many files lost on the floppy disk due to "cannot validate disk" or other such messages. PC floppy drives are definitely more robust than any other that I know (so I rely more on floppy drive simulation on Amiga these days). Atari disk drives, however, are more robust than Amiga-- haven't lost a floppy disk yet.

[TMR]

The link I gave agrees with me that you enable bit 5 to enable multicolor sprite otherwise it's two monochrome sprites.

 

And when it's enabled, it's two sprites as a pair to produce what the page you linked calls a "multicolor object" but not a multicolour sprite - a multicolour object can be built (again, as the page says) from any number of hardware sprites. You keep accusing me of using the Chewbacca defence but i'm not the one who linked to a page and yet insists on contradicting other parts of the same text with his own definitions of terms, that's a deliberate attempt to confuse the argument on your part and not mine.

 

Colors distort as you move-- try a one pixel color red and then start scrolling it by half a color clock.

 

Ah, now you're being vague again... we were talking about scrolling multicolour graphics previously, so presumably it's a multicolour pixel (unless you're trying to change things again) and in that case no it won't - if it did distort, any fixed speed scrolling game would alternate from undistorted to distorted and back again as it moved.

 

You misunderstood again. It's about both. You can put up sprites full height and use them for enhancement.

 

[sigh] Make your mind up... okay, so what can be done is that a sprite layer can be about 160x273 pixels (seven by thirteen hardware sprites) and during the 200 pixels of the screen itself can be used to enhance the picture and for the rest the sprites are on their own but present. That can be done and what i said about two sets of pointers holds.

[Crazyace]

320pixel screen is supported; I guess you meant simulate the half color clock scroll. It's quite easy to have a graphic in 320 pixel mode say at the bottom and have it scroll at half a color clock using double buffered lines (not screens). You can move/scroll the graphic at the bottom at 1/320 width accuracy whereas the top half of the screen can be GTIA or 160*200*4+.

 

The positioning of sprites and scrolling, are only 160 pixel accurate on the Atari, and they are both 320 pixel accurate on the C64. It is possible to do software tricks with a mono screen ( to get scrolling ) - and you can use PM graphics to underlay extra colours in static screens, but they wouldn't help with dynamic ones.

Emkay's mockup screen could work to give the more colourfull highres scrolling background ( as the 'main' front scroll is probally 1/160 per frame anyway ) - but a lot of the sprites might end up being monochrome. Also the level 2 stuff shows really nice mixing of 320pixel mode and 160pixel mode graphics on the C64 - which wouldn't be possible with scrolling on the Atari.

[emkay]

Err... regardless of the CPU speed, you can still only talk to Antic, GTIA and Pokey at the "slow mode" speed of 1.79 MHz.

 

But still, a quicker CPU opens up all sorts of ideas.

 

A full-screen Kernal can change colours, add extra PMGs etc, without impacting performance compared to a normal 6502.

Of course that also means you have a game that has virtually no hope of running on standard hardware.

 

 

Ofcourse you have the "1.79MHz" limits, but, if the CPU is fast enough, you could change all (colours, players, missiles,GTIA modes, priority, mixing...) registers of the GTIA within two bytes on the screen.

With the VICII, you cannot even add more sprites or generate more colours with a 1GHZ CPU ...

 

The only cause for my posting of the mockup picture: C64 really should stop saying "The A8 cannot do this/not possible on the A8". It's all possible... even if slower.

[emkay]

Drawing pictures is easy but I KNOW enough about the A8 that you picture doesn't prove much sorry mate

 

You don't know nothing about the A8...

[Gorf]

My opinion, is though any windows OS is the worst of the worst, Im not so sure the Amiga OS would be the best.

I still would love to see Linux with XWindows(or whatever GUI) be the dominating OS of choice someday. I'm

not holding my breath though.

Wouldn't that be great! Have some hope, linux is coming along nicely on pc's and already has made great inroads in the server area.

 

Y'know... we may be at odds over 8-bits but it's nice to have something to agree on. =-)

 

 

Indeed!

[FastRobPlus]

My opinion, is though any windows OS is the worst of the worst, Im not so sure the Amiga OS would be the best.

I still would love to see Linux with XWindows(or whatever GUI) be the dominating OS of choice someday. I'm

not holding my breath though.

Wouldn't that be great! Have some hope, linux is coming along nicely on pc's and already has made great inroads in the server area.

 

Y'know... we may be at odds over 8-bits but it's nice to have something to agree on. =-)

 

 

Indeed!

 

I disagree.

[atariksi]

You are once again making straw man arguments AND emplying Chewbacca defense and not addressing the point.

 

The link I gave agrees with me that you enable bit 5 to enable multicolor sprite otherwise it's two monochrome sprites.

 

And when it's enabled, it's two sprites as a pair to produce what the page you linked calls a "multicolor object" but not a multicolour sprite - a multicolour object can be built (again, as the page says) from any number of hardware sprites. You keep accusing me of using the Chewbacca defence but i'm not the one who linked to a page and yet insists on contradicting other parts of the same text with his own definitions of terms, that's a deliberate attempt to confuse the argument on your part and not mine.

...

It's two MONOCHROME sprites together to make a multicolored sprite. Two monochrome sprites can also NOT make a multicolored sprite. The link I gave is talking about combining two MONOCHROME sprites like the Amiga bitplane example which you have yet to reply to. According to your logic, Atari ST has more colors in 640*200*4 since Amiga would be using 2 bitplanes to get the same number of colors.

 

>>Colors distort as you move-- try a one pixel color red and then start scrolling it by half a color clock.

 

>Ah, now you're being vague again... we were talking about scrolling multicolour graphics previously, so presumably it's a multicolour pixel (unless you're trying to change things again) and in that case no it won't - if it did distort, any fixed speed scrolling game would alternate from undistorted to distorted and back again as it moved.

 

Straw-man argument. It's not vague. The word "AGAIN" you put there to confuse people as you have previously not stated where I was vague. I only stated that the color is not retained and I stated the same thing again. Think before you reply. It's a colored pixel scrolling half a color clock. That's well defined-- no vagueness about it.

 

>>You misunderstood again. It's about both. You can put up sprites full height and use them for enhancement.

 

>[sigh] Make your mind up... okay, so what can be done is that a sprite layer can be about 160x273 pixels (seven by thirteen hardware sprites) and during the 200 pixels of the screen itself can be used to enhance the picture and for the rest the sprites are on their own but present. That can be done and what i said about two sets of pointers holds.

 

I told you 3 times to read msg #3013-- it's there. Even if I changed my mind, it doesn't change msg #3013.

That's chewbacca defense-- claiming I'm not making up my mind when the problem is stated in black & white.

[atariksi]

320pixel screen is supported; I guess you meant simulate the half color clock scroll. It's quite easy to have a graphic in 320 pixel mode say at the bottom and have it scroll at half a color clock using double buffered lines (not screens). You can move/scroll the graphic at the bottom at 1/320 width accuracy whereas the top half of the screen can be GTIA or 160*200*4+.

 

The positioning of sprites and scrolling, are only 160 pixel accurate on the Atari, and they are both 320 pixel accurate on the C64. It is possible to do software tricks with a mono screen ( to get scrolling ) - and you can use PM graphics to underlay extra colours in static screens, but they wouldn't help with dynamic ones.

Emkay's mockup screen could work to give the more colourfull highres scrolling background ( as the 'main' front scroll is probally 1/160 per frame anyway ) - but a lot of the sprites might end up being monochrome. Also the level 2 stuff shows really nice mixing of 320pixel mode and 160pixel mode graphics on the C64 - which wouldn't be possible with scrolling on the Atari.

 

We were talking about bitmap graphics scrolling at 320 pixel resolution; okay so Atari has to use double line buffering or double screen buffering but it has the time to do that and you forget that after you scroll a byte, C64 will spending more software time doing copying of data whereas Atari has LMS instruction. And to hide new-coming data, C64 has to use up sprite channels. Atari can also stretch hi-res to 384*240 (NTSC) w/o using sprite channels.

[atariksi]

Err... regardless of the CPU speed, you can still only talk to Antic, GTIA and Pokey at the "slow mode" speed of 1.79 MHz.

 

But still, a quicker CPU opens up all sorts of ideas.

 

A full-screen Kernal can change colours, add extra PMGs etc, without impacting performance compared to a normal 6502.

Of course that also means you have a game that has virtually no hope of running on standard hardware.

 

 

Ofcourse you have the "1.79MHz" limits, but, if the CPU is fast enough, you could change all (colours, players, missiles,GTIA modes, priority, mixing...) registers of the GTIA within two bytes on the screen.

With the VICII, you cannot even add more sprites or generate more colours with a 1GHZ CPU ...

 

The only cause for my posting of the mockup picture: C64 really should stop saying "The A8 cannot do this/not possible on the A8". It's all possible... even if slower.

 

I guess you mean two scanlines right not "two bytes".

[Barnacle boy]

It's just a lame excuse to keep repeating 320 scroll mode-- their games also mainly use 160 mode.

 

What do you mean by '320 scroll mode'. Are you talking about scrolling in single (hires) pixel increments?

 

This isn't a 'mode'. This is just how scrolling on the c64 works, regardless of whether the graphics are hires or multicolour. If you wanted to make the scrolling shift in a whole multicolour pixel step you would would literally have to increment the scrolling by two pixels per frame, as the scrolling is always conducted in hires pixel increments.

 

And you'll find that plenty of horizontally scrolling games on the c64 move in single (hires) pixel increments, because stepping more than 1 pixel per frame at 50fps results in a scrolling speed that is too fast for many games.

[atariksi]

It's just a lame excuse to keep repeating 320 scroll mode-- their games also mainly use 160 mode.

 

What do you mean by '320 scroll mode'. Are you talking about scrolling in single (hires) pixel increments?

 

This isn't a 'mode'. This is just how scrolling on the c64 works, regardless of whether the graphics are hires or multicolour. If you wanted to make the scrolling shift in a whole multicolour pixel step you would would literally have to increment the scrolling by two pixels per frame, as the scrolling is always conducted in hires pixel increments.

 

And you'll find that plenty of horizontally scrolling games on the c64 move in single (hires) pixel increments, because stepping more than 1 pixel per frame at 50fps results in a scrolling speed that is too fast for many games.

 

Yeah, I was talking about both 320 resolution scrolling and 320 mode. Both machines have a way of doing 320*200 resolution but neither machine uses it in most of their games. To keep stressing it is lame since I can also find advantages on Atari side to do more colors in 320 mode using GPRIOR mode 0 and to stretch its resolution. And 1/320 width accurate scrolling is easily done on Atari in 320*200 mode using double buffered lines/frames.

 

If you're talking about speed of scrolling (not 1/320 width accuracy), you can keep say 8 fractional bits in zero page register and then when a carry is generated you add it to the scroll register value.

[emkay]

I guess you mean two scanlines right not "two bytes".

 

Two scanlines is the restriction when using the original 1.7xMHz CPU. A ten times faster CPU can change ten registers where the "standard" only changes one register. You only have to take care about the clear multiply of the CPU and RAM clocking, so that the "old" chips can use their reads at standard clockings. GTIA will act on every register then, on all positions on the screen where it gets access to the RAM.

[Crazyace]

320pixel screen is supported; I guess you meant simulate the half color clock scroll. It's quite easy to have a graphic in 320 pixel mode say at the bottom and have it scroll at half a color clock using double buffered lines (not screens). You can move/scroll the graphic at the bottom at 1/320 width accuracy whereas the top half of the screen can be GTIA or 160*200*4+.

 

The positioning of sprites and scrolling, are only 160 pixel accurate on the Atari, and they are both 320 pixel accurate on the C64. It is possible to do software tricks with a mono screen ( to get scrolling ) - and you can use PM graphics to underlay extra colours in static screens, but they wouldn't help with dynamic ones.

Emkay's mockup screen could work to give the more colourfull highres scrolling background ( as the 'main' front scroll is probally 1/160 per frame anyway ) - but a lot of the sprites might end up being monochrome. Also the level 2 stuff shows really nice mixing of 320pixel mode and 160pixel mode graphics on the C64 - which wouldn't be possible with scrolling on the Atari.

 

We were talking about bitmap graphics scrolling at 320 pixel resolution; okay so Atari has to use double line buffering or double screen buffering but it has the time to do that and you forget that after you scroll a byte, C64 will spending more software time doing copying of data whereas Atari has LMS instruction. And to hide new-coming data, C64 has to use up sprite channels. Atari can also stretch hi-res to 384*240 (NTSC) w/o using sprite channels.

 

For bitmap graphics at 320 pixel resolution the Atari can only scroll monochrome ( 2 shades of one colour ) , and that does require 2 buffers. The c64 can scroll a 16 colour screen ( colour per cell ) at that resolution. If you use PM underlays they wont scroll at the 320 pixel resolution - only 160 pixel.

You are correct about the extra software time taken to support the h/w scroll on the c64 - but the c64 doesn't use sprite channels to hide new-coming data.

 

I've never seen 384 pixels visible on an NTSC screen with the Atari ever - Has anyone else? I always assumed 352 to be a workable maximum.

[Crazyace]

I guess you mean two scanlines right not "two bytes".

 

Two scanlines is the restriction when using the original 1.7xMHz CPU. A ten times faster CPU can change ten registers where the "standard" only changes one register. You only have to take care about the clear multiply of the CPU and RAM clocking, so that the "old" chips can use their reads at standard clockings. GTIA will act on every register then, on all positions on the screen where it gets access to the RAM.

 

If Antic/GTIA are still running on the same bus then GTIA will only have the slots that aren't taken by Antic - It would be possible to place a PM underlay under a ModeF bitmap and change the colour every 8 highres pixels I guess - but not in mode 2 as the charfetches will take up the memory slots every 8th line

Or you could have a 128 colour mode by hammering the background colour 80 times during the line

[Rybags]

The problem with colour changes is you get a half-cycle delay. Of course you could workaround that by scrolling everything 1 cc to the right.

 

352 visible "changable" pixels is the norm for wide mode, although you also get the bus noise for 1/2 a character space at the extreme right. You can kind of get rid of it with scrolling, and you can display PMGs in the border area to give an effective visible width of 374 hires pixels.

Edited April 5, 2009 by Rybags

[TMR]

It's two MONOCHROME sprites together to make a multicolored sprite.

 

Multicolour object according to your own reference material, not sprite. Throughout it refers to two sprites being used and yet you feel that's not "allowed" for the C64 as well. Since nobody describes three bitplanes working together as a "multicolour bitplane", two sprites working together isn't a multicolour sprite.

 

Two monochrome sprites can also NOT make a multicolored sprite. The link I gave is talking about combining two MONOCHROME sprites like the Amiga bitplane example which you have yet to reply to.

 

i have replied to it several times, for example pointing out that the reference refers to multicolour objects being constructed from multiple sprites and it doesn't use the term "multicolour sprite" for two sprites working together at any point - i've obviously read it far more closely than you have since you're insisting that it's wrong when you disagree with me repeating what the book says.

 

Straw-man argument. It's not vague. The word "AGAIN" you put there to confuse people as you have previously not stated where I was vague.

 

So what? You're being vague regardless of my previously being too polite to point it out...

 

I only stated that the color is not retained and I stated the same thing again. Think before you reply. It's a colored pixel scrolling half a color clock. That's well defined-- no vagueness about it.

 

It's a coloured pixel yes but you didn't specify the resolution so you were being vague. A lone high res pixels will distort a bit (less than on the A8, however) if moved half a clock but lone multicolour pixels won't be affected and, as i've said, there are thousands of games doing it to prove you wrong.

 

I told you 3 times to read msg #3013-- it's there. Even if I changed my mind, it doesn't change msg #3013.

That's chewbacca defense-- claiming I'm not making up my mind when the problem is stated in black & white.

 

In "black and white" you said "if you are enhancing an image with sprite overlays, expect every 20 or so lines to see no enhancements" and, since you specifically said "enhancing an image" that's a 160x200 pixel overlay (images can't be bigger than the screen on the C64, something i'm sure you're aware of) and was what i was going to code.

 

Then you remembered where you'd dragged overscan in, but that doesn't make a difference either (at least not for vertical, but when you reintroduced it you were vague once more about which direction the overscan was too, expecting me to remember verbatim what you'd said previously) since it's just a matter of a couple of extra sprite rows and a couple of prods at the vertical scroll register to knock the upper and lower borders out. In both cases your comment about "expect every 20 or so lines to see no enhancements" is wrong as was pointed out to you back then and my comment about using two sets of pointers is perfectly valid for both.

[TMR]

Yeah, I was talking about both 320 resolution scrolling and 320 mode. Both machines have a way of doing 320*200 resolution but neither machine uses it in most of their games.

 

You're being vague again... do you mean 320x200 resolution or 320x200 with scrolling?

Edited April 5, 2009 by TMR

[Heaven/TQA]

It's just a lame excuse to keep repeating 320 scroll mode-- their games also mainly use 160 mode.

 

What do you mean by '320 scroll mode'. Are you talking about scrolling in single (hires) pixel increments?

 

This isn't a 'mode'. This is just how scrolling on the c64 works, regardless of whether the graphics are hires or multicolour. If you wanted to make the scrolling shift in a whole multicolour pixel step you would would literally have to increment the scrolling by two pixels per frame, as the scrolling is always conducted in hires pixel increments.

 

And you'll find that plenty of horizontally scrolling games on the c64 move in single (hires) pixel increments, because stepping more than 1 pixel per frame at 50fps results in a scrolling speed that is too fast for many games.

 

Yeah, I was talking about both 320 resolution scrolling and 320 mode. Both machines have a way of doing 320*200 resolution but neither machine uses it in most of their games. To keep stressing it is lame since I can also find advantages on Atari side to do more colors in 320 mode using GPRIOR mode 0 and to stretch its resolution. And 1/320 width accurate scrolling is easily done on Atari in 320*200 mode using double buffered lines/frames.

 

If you're talking about speed of scrolling (not 1/320 width accuracy), you can keep say 8 fractional bits in zero page register and then when a carry is generated you add it to the scroll register value.

 

sure you can use 8 fractional bits for scrolling but you have to admit that having 8 possible values in the VIC scrolling register even for multicolour gfx is not bad at all... so you can scroll "half colour clocks" without any tricks... and this is not possible on A8 as hscroll works in colour clocks resolution. in multicolour mode you definitly can not avoid that...

 

your fractional method is good to have dynamic scrolling speed but when it cames down to scrolling resolution in slow scrolling situation you would recognise the "jumps"... you could not even simulate that with PM overlays as the PMs are in colour clocks, too...

 

for non coders... imagine we want to scroll gfx horizontal every 2nd frame one pixel to the left... on A8 we would skip every 2nd frame the scrolling to achieve that. On c64 we could simply do scrolling as normal because the scrolling speed is the same...so after several frames both A8 and c64 reach the same point in the gfx but definitly the c64 has scrolled "smooth" while A8 not.

[potatohead]

Why argue about this?

 

C= has 320 pixel positioning. It's cool, and the 320 pixel color resolution, with the sprites is the best C= feature!

 

Atari has a ton of features, that's just not one of them.

[Heaven/TQA]

Why argue about this?

 

C= has 320 pixel positioning. It's cool, and the 320 pixel color resolution, with the sprites is the best C= feature!

 

Atari has a ton of features, that's just not one of them.

 

because we are sometimes discussion very little details... but this feature is one of the not well known for the average c64 user... or non-c64 coder...

[potatohead]

Fair enough, but it's clear now.

 

And heck, I knew about it

 

No sense in marginalizing it, details or no.

[atariksi]

320pixel screen is supported; I guess you meant simulate the half color clock scroll. It's quite easy to have a graphic in 320 pixel mode say at the bottom and have it scroll at half a color clock using double buffered lines (not screens). You can move/scroll the graphic at the bottom at 1/320 width accuracy whereas the top half of the screen can be GTIA or 160*200*4+.

 

The positioning of sprites and scrolling, are only 160 pixel accurate on the Atari, and they are both 320 pixel accurate on the C64. It is possible to do software tricks with a mono screen ( to get scrolling ) - and you can use PM graphics to underlay extra colours in static screens, but they wouldn't help with dynamic ones.

Emkay's mockup screen could work to give the more colourfull highres scrolling background ( as the 'main' front scroll is probally 1/160 per frame anyway ) - but a lot of the sprites might end up being monochrome. Also the level 2 stuff shows really nice mixing of 320pixel mode and 160pixel mode graphics on the C64 - which wouldn't be possible with scrolling on the Atari.

 

We were talking about bitmap graphics scrolling at 320 pixel resolution; okay so Atari has to use double line buffering or double screen buffering but it has the time to do that and you forget that after you scroll a byte, C64 will spending more software time doing copying of data whereas Atari has LMS instruction. And to hide new-coming data, C64 has to use up sprite channels. Atari can also stretch hi-res to 384*240 (NTSC) w/o using sprite channels.

 

For bitmap graphics at 320 pixel resolution the Atari can only scroll monochrome ( 2 shades of one colour ) , and that does require 2 buffers. The c64 can scroll a 16 colour screen ( colour per cell ) at that resolution. If you use PM underlays they wont scroll at the 320 pixel resolution - only 160 pixel.

You are correct about the extra software time taken to support the h/w scroll on the c64 - but the c64 doesn't use sprite channels to hide new-coming data.

 

I've never seen 384 pixels visible on an NTSC screen with the Atari ever - Has anyone else? I always assumed 352 to be a workable maximum.

 

Different screens show a different amount but memory addressing is supported up to 384 pixels without involving any scrolling. On LCDs you get the most visible output, but even 360*240 is superior. You are ready to point out that Atari has to use software to do half color clock but then C64 is also using software after every 4 color clocks. So they both are using a hardware/software combination but then Atari has hardware to do scroll on a per scanline basis as well as do it wide screen mode.

[atariksi]

It's two MONOCHROME sprites together to make a multicolored sprite.

 

Multicolour object according to your own reference material, not sprite. Throughout it refers to two sprites being used and yet you feel that's not "allowed" for the C64 as well. Since nobody describes three bitplanes working together as a "multicolour bitplane", two sprites working together isn't a multicolour sprite.

 

Two monochrome sprites can also NOT make a multicolored sprite. The link I gave is talking about combining two MONOCHROME sprites like the Amiga bitplane example which you have yet to reply to.

 

i have replied to it several times, for example pointing out that the reference refers to multicolour objects being constructed from multiple sprites and it doesn't use the term "multicolour sprite" for two sprites working together at any point - i've obviously read it far more closely than you have since you're insisting that it's wrong when you disagree with me repeating what the book says.

 

...

What's in a name. A rose by any other name would smell just as sweet. Now you are showing your shallow understanding of bitplane method vs. chunky method. If the essence is the samething that a bitplane mode does, that's what it is. I never stated anything about 3 bitplanes. You never replied to the bitplane method before and you avoided getting to the guts of it here as well. You can have 2 bitplanes on Amiga generate 2 colors (+bak) and you can have 2 bitplanes on Amiga generate 3 colors (+bak).

 

>>Straw-man argument. It's not vague. The word "AGAIN" you put there to confuse people as you have previously not stated where I was vague.

 

>So what? You're being vague regardless of my previously being too polite to point it out...

 

Just blaming someone for being vague won't cut it. I specifically stated half a color clock which is 1/7.16Mhz = 140ns. QED. Regardless of whether you are in 160*200 or 320*200, you keep scrolling by half a color clock, the color cannot be retained. Nothing vague but your understanding of it (see msg #3065).

 

>>In "black and white" you said "if you are enhancing an image with sprite overlays, expect every 20 or so lines to see no enhancements" and, since you specifically said "enhancing an image" that's a 160x200 pixel overlay (images can't be bigger than the screen on the C64, something i'm sure you're aware of) and was what i was going to code.

 

>>Then you remembered where you'd dragged overscan in, but that doesn't make a difference either (at least not for vertical, but when you reintroduced it you were vague once more about which direction the overscan was too, ...

 

 

Do you have a problem reading a simple reply (msg #3013) or are just too biased to admit you misunderstood the point? Frohn mentioned that he can do full screen height sprites (which implies overscan) and he can use for image enhancement. So I stated explicitly the word OVERSCAN not drag it in now; I also stated what was involved for image enhancement so it's both.

 

>about "expect every 20 or so lines to see no enhancements" is wrong as was pointed out to you back then and my comment about using two sets of pointers is perfectly valid for both.

 

My point was there's not enough cycles (every 20 or so lines) once you have overscan and sprite multiplexing to cover the screen. You method of having only two screen rams also I don't accept.

[atariksi]

Yeah, I was talking about both 320 resolution scrolling and 320 mode. Both machines have a way of doing 320*200 resolution but neither machine uses it in most of their games.

 

You're being vague again... do you mean 320x200 resolution or 320x200 with scrolling?

 

First finish your other debate with me before answering for other people. Re-READ what I wrote: I was talking about both and you are asking which I am talking about. Do you just like replying to people without reading what I wrote. You were being vague by claiming you can do overlays for image enhancement without mentioning the resolutions. Don't mix up your point with someone else's point.

 

Seems like you are DAZED and CONFUSED and want to make it seem like others are.