Atari v Commodore

[atariksi]

You don't need exceptional coders-- it requires a different approach. To me programming C64 color RAM in cell-based graphics mode seems quirky and problematic. But if your company is based on making money, you have to learn C64 stuff and then port it over to A8.

If you think it's difficult to deal with color cells just don't use them. You get 4 color background gfx then, just like A8.

 

I meant with no bad lines now since that would affect the audio quality.

[emkay]

 

 

The C64 version has better graphics, sprites and more colours. The Atari version works in low-res graphics with ugly sprites and also doesn't have the animated end sequence. An easy win by C64

 

Hm...

This time I have to stand on the point that ingame draconus on the A8 looks better. The color usage of the C64 version turns the neck of a frog 360°

 

Title of the C64 is clearly better.

[Rockford]

 

 

Note he is blaming people for "double morality". He thinks its fine to go into any topic and try to show the "other" side. However, there are many topics talking about Atari games so perhaps he's going to invade those topics to and try to even those out as well despite what the discussion is or what the original poster wants.

 

Wow, "he thinks", "perhaps he's going to invade"... we truly can see reading people's mind in reality I am afraid to go to sleep tonight

[Lazarus]

If you think it's difficult to deal with color cells just don't use them. You get 4 color background gfx then, just like A8.

I would like some code to set up that mode-- 320*200*2 and 160*200*4. Perhaps, then I can port some of my A8 stuff to C64.

 

320x200x2:

 

setup_hires:
   LDA #$08
   STA $D016

   LDA #back_color
   STA $D021

   LDA #front_color
   LDX #$00
loop
   STA $D800,X
   STA $D900,X
   STA $DA00,X
   STA $DB00,X
   INX
   BNE loop

 

160x200x4:

 

setup_lores:
   LDA #$18
   STA $D016

   LDA #back_color
   STA $D021

   LDA #mc_color_1
   STA $D022

   LDA #mc_color_2
   STA $D023

   LDA #front_color
   LDX #$00
loop
   STA $D800,X
   STA $D900,X
   STA $DA00,X
   STA $DB00,X
   INX
   BNE loop

[TMR]

If you think it's difficult to deal with color cells just don't use them. You get 4 color background gfx then, just like A8.

 

I meant with no bad lines now since that would affect the audio quality.

 

Badlines aren't caused by the colour RAM being read anyway, at least not in character-based modes... (well, they're not in bitmap mode either, but the screen RAM needs them and that's acting as colour RAM for bitmaps).

Edited September 11, 2009 by TMR

[TMR]

A lot of times debug code lets left in in releases but perhaps that debug area was still needed to continue making the game.

 

Nope, as i say it's been scrubbed from the cracks because it was dead space; saving to $bfff instead of $cfff would've probably worked because Dropzone doesn't keep anything under the I/O or Kernal.

 

So you're saying he didn't need the monitor space to continue with the game?

 

The monitor right at the top of the RAM the game loads into, for working on the game he needed it but for saving the final game to tape or disk for mastering he didn't have to save that area out; S "FILENAME" 8 0801 C000 rather than S "FILENAME" 8 0801 D000 from that particular monitor if memory serves...

Edited September 11, 2009 by TMR

[TMR]

In any case, Draconus on Atari is nice game. I enjoyed playing it a lot in my childhood.

 

If they keep repeating sprites are better, we can also keep repeating the colors are inaccurate

 

In the case of Draconus the A8 colours are inaccurate, the C64 was the original version.

 

it's slower

 

And it's the same speed without having to resort to using half the resolution. =-)

 

Actually, i've been thinking thoughts about software sprites over the last couple of days and in particular writing in and out of a scrolling bitmapped screen... i'm really starting to see why Zybex uses 160x96 for the play area, not just for the faster rendering of soft sprites or the memory overheads but because having an LMS halfway down the screen when you're changing the address on the first LMS to do the coarse scrolling complicates things somewhat!

[Tezz]

...i'm really starting to see why Zybex uses 160x96 for the play area, not just for the faster rendering of soft sprites or the memory overheads but because having an LMS halfway down the screen when you're changing the address on the first LMS to do the coarse scrolling complicates things somewhat!

Well, as was mentioned recently choosing the easy option and using the basic "out the book" features was one reason why A8 releases were rarely as good as they should have been. If people want to term that as being due to lazy developers well that's one opinion but I would say it's moreso for many that creating games for a platform with a small market is not worth taking too much time over commercially. Fortunately there were A8 developers who knew the machine better and cared about their art producing great work too.

[emkay]

In the case of Draconus the A8 colours are inaccurate, the C64 was the original version.

 

Phew.... luckily they did change the colours to be inaccurate there.

Edited September 11, 2009 by emkay

[emkay]

Actually, i've been thinking thoughts about software sprites over the last couple of days and in particular writing in and out of a scrolling bitmapped screen... i'm really starting to see why Zybex uses 160x96 for the play area, not just for the faster rendering of soft sprites or the memory overheads but because having an LMS halfway down the screen when you're changing the address on the first LMS to do the coarse scrolling complicates things somewhat!

 

 

irony or cynism?

 

Just add one LMS line and adjust two additional bytes really slows the whole computer down to 50% ...

[atarian63]

12 - DRACONUS

 

The C64 version has better graphics, sprites and more colours. The Atari version works in low-res graphics with ugly sprites and also doesn't have the animated end sequence. An easy win by C64

Nah! Poor programming by the coder.

No, this shows the weakness of the A8: All PMs are already used for the player sprite and because of this, all other sprites have to be software sprites rendered to the background. This has two major effects:

 

- The software sprites have to use the same 4 colors as the background.

 

- The resolution is reduced because otherwise the CPU would be too busy rendering those sprites (the shots are not the best examples, there are screens with more sprites).

 

Also the software sprite rendering routines eat up space. On C64 they are not required. Maybe that's the reason why they removed the end sequence.

More likely they would sell fewer atari versions therefore less effort. Lazy programming or low budget.

[Lazarus]

Also the software sprite rendering routines eat up space. On C64 they are not required. Maybe that's the reason why they removed the end sequence.

More likely they would sell fewer atari versions therefore less effort. Lazy programming or low budget.

I don't think so. Adding a software sprite routine to an existing game and changing all gfx to a different resolution is quite a bit work. And since the C64 version uses all the memory already they had to sacrifice a few things to get space for the software sprites too.

[TMR]

...i'm really starting to see why Zybex uses 160x96 for the play area, not just for the faster rendering of soft sprites or the memory overheads but because having an LMS halfway down the screen when you're changing the address on the first LMS to do the coarse scrolling complicates things somewhat!

Well, as was mentioned recently choosing the easy option and using the basic "out the book" features was one reason why A8 releases were rarely as good as they should have been.

 

Actually, i love Zybex on both machines personally, but i'm partial to just about anything shooty and preferably horizontal scrolling. That was a serious comment, i've been banging my head trying to get a system going which relies on the looping nature of the screen when you step the LMS values and i sort of have one but it needs three LMS commands and will probably require about 10K of RAM per buffer for what i eventually intend doing with it!

 

Just add one LMS line and adjust two additional bytes really slows the whole computer down to 50% ...

 

And if you'd care to show me just where the hell i said anything of the sort... oh that's right, i bloody didn't.

 

If you're doing two LMS commands and changing the address to handle coarse scrolling, it's a far more complex thing to process in software sprites or columns of arriving data than you seem to reckon, for a start you need to leave a gap between the two halves of the screen so there's "travel distance", so for example the first byte line 81 of the bitmap doesn't follow directly from the last byte of line 80; that means all the software sprite plots and column writes need to "step over" the gap and you're either constantly checking for exceptions or using tables containing the address of each bitmap line which in turn need to be constantly "nudged" whenever the LMS changes.

 

Looking at Zybex i think it can handle that screen in a single 4K block so no need for complex calculations to step over the join, plus it only has to write in over a two by sixteen byte area or thereabouts per sprite to get a reasonably sized object; as design choices go, the more i think about it the more i understand where the programmer was coming from.

 

More likely they would sell fewer atari versions therefore less effort. Lazy programming or low budget.

 

No, that's actually a huge amount of effort and probably more than a "dirty" port would've taken; the sprites and backgrounds have all been redrawn to allow for the change in resolution (i'd have to check but i'm pretty sure they didn't just remove every other byte of each character), the map data for all the screens would need redesigning to allow for the change in character ratios (it's not as simple as it might appear, again i've been thinking about it) and despite what some people say a decent software sprite routine is always a bugger to do and both Draconus and Zybex fare quite well on that front all things considered.

 

i don't think it's impossible to do Draconus at least at 160x192 but in a 48K machine that extra 4K for the screen RAM is a potential killer.

[oky2000]

I think seriously the point is that there simply wasn't enough exceptional coders to replicate C64 standard hardware features using the more restrictive colour resolution of 160x192 displays and the smaller more restrictive PM graphics.

...

You don't need exceptional coders-- it requires a different approach. To me programming C64 color RAM in cell-based graphics mode seems quirky and problematic. But if your company is based on making money, you have to learn C64 stuff and then port it over to A8. 160*192 is restrictive if you don't learn how the rest of the hardware works.

 

But that is how you get 4 colours per 4x8 char block and then any colour within the Sprite system on top of that, which clearly produces some very colourful 16 colour games on the C64 as opposed to 4-7 colour games on the A8.

 

In the case of the A8 the majority of games look as you would expect of a machine that can do 4 colours total + basic horizontal colour graduations via DLIs. The problem simply is that there was no 3rd or 4th generation of games programmed for the A8 because the restrictions the hardware placed were very difficult to break and even then could only be used in certain situations etc.

 

No, the color changes are not limited to horizontal color graduations. GPRIOR mode 0 doesn't care if it's horizontal or vertical and GTIA modes allow vertical and horizontal color graduations. Most games did not use GTIA modes and even without resolution enhancement, the moving sprites would still be at 160*200 on GTIA graphics.

 

For fast action games you can't waste PM on colour underlays or start sapping CPU time just to equalize a deficiency in the hardware to try and replicate the more colourful look of a 16 colour on screen C64 game.

 

My problem is not with the movement resolution of the PMs, just the overall smaller size than the 24x21 x8 per scanline system in VIC-II plus the ability to mix sprite modes so you can have a hires sprite overlay and the colour for the character with an underlying sprite underneath. If you can get this into you multiplexing routine it provides sprite graphics as detailed as a Nintendo game in some ways.

 

Mixing modes and having any of the 16 colours within some basic restrictions gives you quite a lot of flexibility, the A8 Last Ninja project highlights these difficulties really that need to be worked around whereas on the C64 it's all down to an artists drawing ability and not much technical trickery to achieve the lush graphics of that game

 

However doing something like Rainbow Islands as well on the A8 as the C64 version would be difficult to say the least, simply a sign of the times.....the C64 chipset was designed for use as an arcade motherboard first and foremost and these game styles were the ones that lasted all the way up to Virtua Racer by SEGA with just bigger bobs/sprites more colours and faster movement...same basic game design though.

I believe arcade motherboards were superior at the time to what the C64 chipset had to offer.

 

The cost effective chipset was designed for Jack Tramiel by MOS in 1980-81 so in some cases I would beg to differ, plus there is an excellent versions of some of those early arcade games too like Rabbit Software's Skramble (different to Rockford's linked Skramble) and Ocean's Donkey Kong. Both damned close all things considered. You have to remember the R&D investment and changes in arcade chipsets could be measured on a monthly basis not yearly or half a decade like with Atari/Commodore home computers. What Jack was going for was similar to Nintendo's re-usable Playchoice 10 arcade board...profit <> cutting edge expensive monthly chipset designs.

Edited September 11, 2009 by oky2000

[oky2000]

You don't need exceptional coders-- it requires a different approach. To me programming C64 color RAM in cell-based graphics mode seems quirky and problematic. But if your company is based on making money, you have to learn C64 stuff and then port it over to A8.

If you think it's difficult to deal with color cells just don't use them. You get 4 color background gfx then, just like A8.

 

I would like some code to set up that mode-- 320*200*2 and 160*200*4. Perhaps, then I can port some of my A8 stuff to C64.

 

Not hard, for 320x200 mode just ignore the colour ram and write directly to the video ram. For 160x200 x4 mode simply set the multicolour bit and set mutlicolour 1 and 2 as required and background colour then never change the 4th optional colour and keep it static.

[atariksi]

In any case, Draconus on Atari is nice game. I enjoyed playing it a lot in my childhood.

 

If they keep repeating sprites are better, we can also keep repeating the colors are inaccurate

 

In the case of Draconus the A8 colours are inaccurate, the C64 was the original version.

 

it's slower

 

And it's the same speed without having to resort to using half the resolution. =-)

 

Actually, i've been thinking thoughts about software sprites over the last couple of days and in particular writing in and out of a scrolling bitmapped screen... i'm really starting to see why Zybex uses 160x96 for the play area, not just for the faster rendering of soft sprites or the memory overheads but because having an LMS halfway down the screen when you're changing the address on the first LMS to do the coarse scrolling complicates things somewhat!

 

You can have inaccurate colors and be the original. Besides looking ugly, the A8 had that color if it needed it but instead it has shade of the color (which looks better). Any partial or full screen scrolling algorithm should be faster on A8.

[Lazarus]

You can have inaccurate colors and be the original. Besides looking ugly, the A8 had that color if it needed it but instead it has shade of the color (which looks better).

Always going for monochrome looks boring instead of "better". But this is subjective anyway.

 

Any partial or full screen scrolling algorithm should be faster on A8.

True.

[atariksi]

If you think it's difficult to deal with color cells just don't use them. You get 4 color background gfx then, just like A8.

I would like some code to set up that mode-- 320*200*2 and 160*200*4. Perhaps, then I can port some of my A8 stuff to C64.

 

320x200x2:

 

setup_hires:
   LDA #$08
   STA $D016

   LDA #back_color
   STA $D021

   LDA #front_color
   LDX #$00
loop
   STA $D800,X
   STA $D900,X
   STA $DA00,X
   STA $DB00,X
   INX
   BNE loop

 

160x200x4:

 

setup_lores:
   LDA #$18
   STA $D016

   LDA #back_color
   STA $D021

   LDA #mc_color_1
   STA $D022

   LDA #mc_color_2
   STA $D023

   LDA #front_color
   LDX #$00
loop
   STA $D800,X
   STA $D900,X
   STA $DA00,X
   STA $DB00,X
   INX
   BNE loop

 

So the above code won't cause any bad lines? I think I used to set up writing to $D011 and $d016 but can't remember right now, but it did cause bad line (40+ consecutive DMA cycles).

[atariksi]

You can have inaccurate colors and be the original. Besides looking ugly, the A8 had that color if it needed it but instead it has shade of the color (which looks better).

Always going for monochrome looks boring instead of "better". But this is subjective anyway.

 

Any partial or full screen scrolling algorithm should be faster on A8.

True.

 

Not monochrome, but they chose the shade instead of the color meaning shade must be the better choice.

[atarian63]

...i'm really starting to see why Zybex uses 160x96 for the play area, not just for the faster rendering of soft sprites or the memory overheads but because having an LMS halfway down the screen when you're changing the address on the first LMS to do the coarse scrolling complicates things somewhat!

Well, as was mentioned recently choosing the easy option and using the basic "out the book" features was one reason why A8 releases were rarely as good as they should have been.

 

Actually, i love Zybex on both machines personally, but i'm partial to just about anything shooty and preferably horizontal scrolling. That was a serious comment, i've been banging my head trying to get a system going which relies on the looping nature of the screen when you step the LMS values and i sort of have one but it needs three LMS commands and will probably require about 10K of RAM per buffer for what i eventually intend doing with it!

 

Just add one LMS line and adjust two additional bytes really slows the whole computer down to 50% ...

 

And if you'd care to show me just where the hell i said anything of the sort... oh that's right, i bloody didn't.

 

If you're doing two LMS commands and changing the address to handle coarse scrolling, it's a far more complex thing to process in software sprites or columns of arriving data than you seem to reckon, for a start you need to leave a gap between the two halves of the screen so there's "travel distance", so for example the first byte line 81 of the bitmap doesn't follow directly from the last byte of line 80; that means all the software sprite plots and column writes need to "step over" the gap and you're either constantly checking for exceptions or using tables containing the address of each bitmap line which in turn need to be constantly "nudged" whenever the LMS changes.

 

Looking at Zybex i think it can handle that screen in a single 4K block so no need for complex calculations to step over the join, plus it only has to write in over a two by sixteen byte area or thereabouts per sprite to get a reasonably sized object; as design choices go, the more i think about it the more i understand where the programmer was coming from.

 

More likely they would sell fewer atari versions therefore less effort. Lazy programming or low budget.

 

No, that's actually a huge amount of effort and probably more than a "dirty" port would've taken; the sprites and backgrounds have all been redrawn to allow for the change in resolution (i'd have to check but i'm pretty sure they didn't just remove every other byte of each character), the map data for all the screens would need redesigning to allow for the change in character ratios (it's not as simple as it might appear, again i've been thinking about it) and despite what some people say a decent software sprite routine is always a bugger to do and both Draconus and Zybex fare quite well on that front all things considered.

 

i don't think it's impossible to do Draconus at least at 160x192 but in a 48K machine that extra 4K for the screen RAM is a potential killer.

sorry I must disagree, look at some of the great stuff written for appleII series. Now that is a POS from a graphics point of view and yet the effort was put into it. So again I say the effort put into it was probably less as by that time in history they expected to sell fewer copies of that version. Not saying it is easy but enough money and time most things can be done.

Also my experience in my store with customers was that if they knew it was a port from c64 they would not buy the product. I would end up stock balancing the game.

Edited September 12, 2009 by atarian63

[atarian63]

I think seriously the point is that there simply wasn't enough exceptional coders to replicate C64 standard hardware features using the more restrictive colour resolution of 160x192 displays and the smaller more restrictive PM graphics.

...

You don't need exceptional coders-- it requires a different approach. To me programming C64 color RAM in cell-based graphics mode seems quirky and problematic. But if your company is based on making money, you have to learn C64 stuff and then port it over to A8. 160*192 is restrictive if you don't learn how the rest of the hardware works.

 

But that is how you get 4 colours per 4x8 char block and then any colour within the Sprite system on top of that, which clearly produces some very colourful 16 colour games on the C64 as opposed to 4-7 colour games on the A8.

 

In the case of the A8 the majority of games look as you would expect of a machine that can do 4 colours total + basic horizontal colour graduations via DLIs. The problem simply is that there was no 3rd or 4th generation of games programmed for the A8 because the restrictions the hardware placed were very difficult to break and even then could only be used in certain situations etc.

 

No, the color changes are not limited to horizontal color graduations. GPRIOR mode 0 doesn't care if it's horizontal or vertical and GTIA modes allow vertical and horizontal color graduations. Most games did not use GTIA modes and even without resolution enhancement, the moving sprites would still be at 160*200 on GTIA graphics.

 

For fast action games you can't waste PM on colour underlays or start sapping CPU time just to equalize a deficiency in the hardware to try and replicate the more colourful look of a 16 colour on screen C64 game.

 

My problem is not with the movement resolution of the PMs, just the overall smaller size than the 24x21 x8 per scanline system in VIC-II plus the ability to mix sprite modes so you can have a hires sprite overlay and the colour for the character with an underlying sprite underneath. If you can get this into you multiplexing routine it provides sprite graphics as detailed as a Nintendo game in some ways.

 

Mixing modes and having any of the 16 colours within some basic restrictions gives you quite a lot of flexibility, the A8 Last Ninja project highlights these difficulties really that need to be worked around whereas on the C64 it's all down to an artists drawing ability and not much technical trickery to achieve the lush graphics of that game

 

However doing something like Rainbow Islands as well on the A8 as the C64 version would be difficult to say the least, simply a sign of the times.....the C64 chipset was designed for use as an arcade motherboard first and foremost and these game styles were the ones that lasted all the way up to Virtua Racer by SEGA with just bigger bobs/sprites more colours and faster movement...same basic game design though.

I believe arcade motherboards were superior at the time to what the C64 chipset had to offer.

 

The cost effective chipset was designed for Jack Tramiel by MOS in 1980-81 so in some cases I would beg to differ, plus there is an excellent versions of some of those early arcade games too like Rabbit Software's Skramble (different to Rockford's linked Skramble) and Ocean's Donkey Kong. Both damned close all things considered. You have to remember the R&D investment and changes in arcade chipsets could be measured on a monthly basis not yearly or half a decade like with Atari/Commodore home computers. What Jack was going for was similar to Nintendo's re-usable Playchoice 10 arcade board...profit <> cutting edge expensive monthly chipset designs.

maybe,but in 80-81 Atari ruled the arcades,it would have had little to no chance. Though the thought of commodore as a game system instead of atari seems kind of funny,like as in the companies changing places in the perception of the public. That would have been interesting.

[Lazarus]

So the above code won't cause any bad lines? I think I used to set up writing to $D011 and $d016 but can't remember right now, but it did cause bad line (40+ consecutive DMA cycles).

All standard gfx modes on C64 cause badlines. Avoiding badlines is possible but is only used for a number of demo effects. I've never seen a game without badlines.

 

Not monochrome, but they chose the shade instead of the color meaning shade must be the better choice.

If there is only one chroma used for all 4 colors, it's monochrome.

[Lazarus]

Also my experience in my store with customers was that if they knew it was a port from c64 they would not buy the product. I would end up stock balancing the game.

Strange attitude. On C64 people never cared if it was an Atari port or not. That's why some of the most popular C64 games are ports from Atari: Boulder Dash, Bruce Lee, Moon Patrol etc.

[atariksi]

I think seriously the point is that there simply wasn't enough exceptional coders to replicate C64 standard hardware features using the more restrictive colour resolution of 160x192 displays and the smaller more restrictive PM graphics.

...

You don't need exceptional coders-- it requires a different approach. To me programming C64 color RAM in cell-based graphics mode seems quirky and problematic. But if your company is based on making money, you have to learn C64 stuff and then port it over to A8. 160*192 is restrictive if you don't learn how the rest of the hardware works.

 

But that is how you get 4 colours per 4x8 char block and then any colour within the Sprite system on top of that, which clearly produces some very colourful 16 colour games on the C64 as opposed to 4-7 colour games on the A8.

...

Come on, GTIA is linear easily programmed 16+ color mode; it wasn't used for compatibility reasons and memory limits. People targetting 8K cartridges or even 16K can't put lots of GITA-based imagery/soft-sprites in those ROMs. And GPRIOR produces more than 4-7 colors-- it depends on number of PMs you need for game or where you need them.

 

>>No, the color changes are not limited to horizontal color graduations. GPRIOR mode 0 doesn't care if it's horizontal or vertical and GTIA modes allow vertical and horizontal color graduations. Most games did not use GTIA modes and even without resolution enhancement, the moving sprites would still be at 160*200 on GTIA graphics.

 

>For fast action games you can't waste PM on colour underlays or start sapping CPU time just to equalize a deficiency in the hardware to try and replicate the more colourful look of a 16 colour on screen C64 game.

 

There's no deficiency-- it's more to do with a different approach and RAM contraints. You don't need 24*21 sprites to do good games.

 

>Mixing modes and having any of the 16 colours within some basic restrictions gives you quite a lot of flexibility, the A8 Last Ninja project highlights these difficulties really that need to be worked around whereas on the C64 it's all down to an artists drawing ability and not much technical trickery to achieve the lush graphics of that game

 

Well, I can also say C64 has to work around many difficulties to get around LMS instructions, Hscroll/Vscroll, horizontal re-use, etc.

 

>>I believe arcade motherboards were superior at the time to what the C64 chipset had to offer.

 

>The cost effective chipset was designed for Jack Tramiel by MOS in 1980-81 so in some cases I would beg to differ, plus there is an excellent versions of some of those early arcade games too like Rabbit Software's Skramble (different to Rockford's linked Skramble) and Ocean's Donkey Kong. Both damned close all things considered. You have to remember the R&D investment and changes in arcade chipsets could be measured on a monthly basis not yearly or half a decade like with Atari/Commodore home computers. What Jack was going for was similar to Nintendo's re-usable Playchoice 10 arcade board...profit <> cutting edge expensive monthly chipset designs.

 

I remember arcade games being a lot more colorful, smoother, and with many channels of audio. What Nintendo are you talking about comparing to-- Nintendo 64 or SNES?

[atariksi]

You don't need exceptional coders-- it requires a different approach. To me programming C64 color RAM in cell-based graphics mode seems quirky and problematic. But if your company is based on making money, you have to learn C64 stuff and then port it over to A8.

If you think it's difficult to deal with color cells just don't use them. You get 4 color background gfx then, just like A8.

 

I would like some code to set up that mode-- 320*200*2 and 160*200*4. Perhaps, then I can port some of my A8 stuff to C64.

 

Not hard, for 320x200 mode just ignore the colour ram and write directly to the video ram. For 160x200 x4 mode simply set the multicolour bit and set mutlicolour 1 and 2 as required and background colour then never change the 4th optional colour and keep it static.

 

I seem to get that you are keeping one of the bit combinations static by filling Color RAM with constant value, but I can't playback the audio at 11Khz+ w/40+ consecutive DMA cycles interfering. I need plain vanilla graphics mode-- 320*200*2 and 160*200*4. Actually, I am using 320*200*2 and 80*200*16 w/streaming audio but need to compromise that 16 color mode with 160*200*4.