[Coco] ccasm question

[Hugo Dufort]

I'm using RegX as an additional accumulator, so it just carries a value, 
and it doesn't actually point to anything meaningful in memory. Instead 
of using the user stack to store additional fields I like to work with 
the existing registers as much as possible. In the actual case, RegX 
contains the sum WIDTH+COLORS and is used as a classical "selector" 
(compare, branch, code, branch).

I don't know if it makes sense with the 6809, e.g. using 2-byte pointers 
to hold values or to count, even though the possible operations on these 
registers is limited.

Hugo

Le 2015-03-10 17:20, Robert Gault a écrit :
> 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
>
>


---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast.
http://www.avast.com