[Coco] ccasm question
Hugo Dufort
hugo at seshat.ca
Tue Mar 10 18:06:04 EDT 2015
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
More information about the Coco
mailing list