[Coco] ccasm question

[Robert Gault]

Hugo Dufort wrote:
> Re-reading the previous message and checking the code I've pasted, I need to add
> a few explanations.
> - There was a typo in "hhcolors", it should have been "hcolors", e.g. the name
> of the globally-defined variable.
> - I have added that last line ("sta hcolors") as an example of a reference to a
> global variable.
> - That last line was not part of the original procedure, and it gives a "Symbol
> Doesn't Exist" error when compiling.
>
> Sorry for the conflicting statements in my previous messages!
>
> I can paste the whole code for my HSCREEN procedure here, but it's very long and
> It's by no means optimized. I would like this procedure to set global variables
> when it initializes the graphics port, so that other procedures and code
> sections will have the chance to use these values to make their work easier. For
> example, I would like to set a variable defining the number of pixels per byte
> in the current graphics mode. If I can't refer to global variables, then I will
> map these values to specific (fixed) memory locations, but I prefer writing
> "cleaner" code.
>
> I'm not (yet) proficient in 6809 ASM, so I'm not using all the nice tricks,
> optimizations and addressing modes available.
>
> Here is my "horrible" ASM code for HSCREEN:
>

OK! It could work except for one major bug and one exception.

BUG

ldx width,u      this gets you the address of what seems to be a table.
lda colors,u     a pointer into the table but what is the value of colors?
leax a,x         Oh Oh !!!
cmpx #someNumber

If regX pointed to a table such as
width fcb 644, 642, 516, etc.
then regA is can't be the number of screen colors and can't even be an index 
value such as 0,1,2,3. RegX is increasing in value but the comparisons are 
getting smaller with many targets requiring 2 bytes. Also regX never gets loaded 
with the contents of the address so the comparison will not work.

A routine that might work would be

ldx width,u
lda colors,u
ldx a,x       now regX is loading a 2byte value from the width table

The problem with this version is the index value 'color'. It can't be the actual 
number of colors because there are multiple entries for every width except 160 
pixels. Also if it is an index value, it needs to be 0,2,4, etc.

I think it would be better to use three tables. The first table could be bytes 
per line vs HRES value. The second could be colors vs CRES value as shown. The 
third would be colors vs pixels per byte.
HRES     BYTES per line
111        160
110        128
101         80
100         64
011         40
010         32
001         20
000         16
CRES     Colors
  10         16
  01          4
  00          2
Colors    Pixels per byte
  2           8
  4           4
16           2

Now the input into the HSCREEN routine could be actual color count and width in 
pixels. Convert color count to pixels per byte. Use pixels per byte to get bytes 
per line. Width/PixPerByte = BytesPerLine
Look up the value in HRES table and shift it twice to the left. Look up the 
value in CRES and OR it with the shifted HRES value. That's the value to use 
with 'testh'.

EXCEPTION
You included a 320 x abc x 2 graphics mode which is not supported by the ROM 
code and may or may not work be supported by hardware.


> =======
> testw322@    cmpx    #322
>      bne    testw272@
>      orb    #%01100
>      bra    testh@

Let us know if you get a usable screen with a setting like 320x192x2.

Robert


---
This email has been checked for viruses by Avast antivirus software.
http://www.avast.com