I originally had it dividing by 256, but the results were less predictable so I thought I was wrong. :/ I also had tried the CARD to BYTE trick, but it didn't work - likely due to my flawed logic.
Thanks for showing me another way. I wasn't ready to start bit shift learning yet, but theres no better time than the present.
I'm going off to implement the method you've shown here. Thanx!
No problem. Glad to help. After I came up with this I was poking around the collection of toolkit and run-time stuff from OSS/ACS. Turns out they have a PutCD procedure too, and it's different from mine and they way you were approaching it. It went something like this (from memory):
PROC PutCD(BYTE chan, CARD val)
BYTE lsb = val, msb = val + 1
This works because the source CARD get stored in val. the byte variable lsb is declared and set to live at the same address val is. Since a card is stored LSB 1st, that works. The the variable msb is declared and set to live at the same location as the 2nd byte of the CARD val. This works because it contains the MSB of the card. Thus msb automatically is equal to the MSB of the CARD val. Sweet.
What might be confusing to some that are new (or new again) to Action, is that lsb=val and msb=val+1 work on the address of val in the decalration statement, but would provide the actual stored value if used in most parts of the program. Ask me to clarify further if any of that is murky.
Edited by fujidude, Wed Aug 5, 2015 7:44 PM.