Re: [Amforth] rshift not zero padded

2020-09-19 Thread Mark Roth
So because of grabbing a word it seems that I was bringing in the PINB register as well that had a value in it. So that is where the extra bits came from. : cylon > $ff ddra c! 1 porta c! > begin 40 ms > 7 0 do porta c@ 2* porta c! 40 ms loop > 7 0 do porta c@ 2/ porta c! 4

Re: [Amforth] rshift not zero padded

2020-09-19 Thread Mark Roth
Okay, hmm. It seems to be because even when I store a value of $80 in PORTA, if I read it right back like that I'm getting a word. Which is actually what I'm asking it for by using @. So I would read back $ED80. Changing it to use the byte size c* and c! was the problem there. Thanks, Mark On Sa

Re: [Amforth] rshift not zero padded

2020-09-18 Thread George Herzog
It's a common display situation in Forth. Leading zeros aren't display, even when they exist. On Sat, Sep 19, 2020, 2:24 AM Mark Roth wrote: > Is there a reason that when using rshift or 2/ the most significant bit > isn't zero padded? lshift and 2* do this correctly. I was trying to > implement

Re: [Amforth] rshift not zero padded

2020-09-18 Thread tur bine
If you are trying to make a led version of a cylons eyes a delay shift or using pwm will always result in a led coming on when not wanted. To overcome this you need to use Mirror Imaged Bit Angle Modulation to get the fading and reverse direction to run smoothly On Fri, 18 Sep 2020 19:24 Mark Roth

[Amforth] rshift not zero padded

2020-09-18 Thread Mark Roth
Is there a reason that when using rshift or 2/ the most significant bit isn't zero padded? lshift and 2* do this correctly. I was trying to implement a simple back and forth led on a port by starting with a value of 1 in the the port. Moving from right to left in the port works perfectly but when m