ML coding question

[yorgle]

After disassembling a short joystick routine I'm confused as to something that perhaps someone here can explain. (The routine uses DATA statements to POKE opcodes and arguments into ML). In one part, 173,220 are poked into memory to read the joystick. In my dissassembly, the 173,220 disassembles to LDA 632. Why is 220 used in the DATA statement instead of 632? I'm coding on unmodded 1200xl.

[Bryan]

After disassembling a short joystick routine I'm confused as to something that perhaps someone here can explain. (The routine uses DATA statements to POKE opcodes and arguments into ML). In one part, 173,220 are poked into memory to read the joystick. In my dissassembly, the 173,220 disassembles to LDA 632. Why is 220 used in the DATA statement instead of 632? I'm coding on unmodded 1200xl.

 

173 ($AD) is load absolute. It is a 3 byte instruction. You need the next 2 bytes (LSB, MSB).

[Shamus]

The short answer is because 632 is greater than 255. In other words, you need TWO bytes to represent that value (one byte can only hold a value from 0-255).

[yorgle]

Oh yeah, how silly of me. Thanks guys.

[yorgle]

Ok, I give up. Before I pull the rest of my hair out, can anyone here point me to an assembly source listing for a routine to read two paddles as x and y coordinates so I can get some ideas? Or perhaps, better yet, look at my code and tell me if I'm at all close to what I'm trying to do? All I need to do is read the values and branch to one of four locations depending on four conditions: a) if paddle(2)<100 then branch xxxx; b) if paddle(2)>150 then branch xxxx; c) if paddle(3)<114 then branch xxxx; and d) if paddle(3)>114 then branch xxxx. (Yes, I'm playing with a touch tablet here) Here's what I've been messing with so far:

1683  lda 626 ; paddle2(x)
1686  cmp # 100
1688  bcc 1731 ; move left
1690  cmp #150
1692  bcs 1735 ; move right
1694  lda 627 ; paddle3 (y)
1697  cmp 114 ; center
1699  bcs 1723 ; move up
1701  cmp 114 ; center
1703  bcc 1727 ; move down
1705  bne 1683
...
1723  lda # 142 ; f1 up
1725  bne 1737
1727  lda # 143 ; f2 down
1729  bne 1737
1731  lda # 134 ; f3 left
1733  bne 1737
1735  lda # 135 ; f4 right
1737  sta 764 ; poke764,keycode
...

Up, Down, and Left work as expected, but for some reason, whenever the program branches to 1735, garbage values get put into 764 (causing junk to appear on the screen).

[JayoK]

Hmmm... code looks fine to me. However, I am actually wondering about your use of the location 764. I know in BASIC poking this location will output the appropriate character, however, in ML you might experience a different effect.

 

Location 764 (CH) is actually used with location 754 (CHI)... here's an extract from Master Memory Map.

 

"CH is the middle guy between the keyboard and the keyboard handler. When a key is pressed, a keyboard value (yes, yet another kind of character value) gets put into CH. The keyboard handler then picks it up, puts it into CHI (754), and puts a 255 into CH to indicate that it got the value OK. There are a few exceptions to this. First of all, if we're in the middle of debouncing (see KEYDEL [753]. the key is ignored completely; it doesn't even make it to CH. If CTRL-1 is pressed, then SSFLAG (767) is updated, but CH is not affected. Finally, CH also gets changed by the key repeat process mentioned under SRTIMR at location 555. To repeat a key, the OS takes the value in KBCODE (53769) and stores it in CH."

 

With BASIC command processing is a little different in behaviour as its not done a ML speed par-se. Take a look at the locations $F2BO and $F24A (Outchar and GetChar) if you are using the XL OS.

 

I remember building a Keypad reader with E: output in the VBI and ran into a similar problem.

 

-- Edit: Have you stepped this code and determined that the correct value actually is going into 764? i.e.

 

1731 lda # 134 ; f3 left

1733 bne 1737

1735 lda # 135 ; f4 right

1737 sta 764 ; poke764,keycode

173A sta 1536 ; temp location that can be checked

173D BRK

Edited December 19, 2007 by JayoK

[yorgle]

Hmmm... code looks fine to me. However, I am actually wondering about your use of the location 764. I know in BASIC poking this location will output the appropriate character, however, in ML you might experience a different effect.

 

Location 764 (CH) is actually used with location 754 (CHI)... here's an extract from Master Memory Map.

 

"CH is the middle guy between the keyboard and the keyboard handler. When a key is pressed, a keyboard value (yes, yet another kind of character value) gets put into CH. The keyboard handler then picks it up, puts it into CHI (754), and puts a 255 into CH to indicate that it got the value OK. There are a few exceptions to this. First of all, if we're in the middle of debouncing (see KEYDEL [753]. the key is ignored completely; it doesn't even make it to CH. If CTRL-1 is pressed, then SSFLAG (767) is updated, but CH is not affected. Finally, CH also gets changed by the key repeat process mentioned under SRTIMR at location 555. To repeat a key, the OS takes the value in KBCODE (53769) and stores it in CH."

 

With BASIC command processing is a little different in behaviour as its not done a ML speed par-se. Take a look at the locations $F2BO and $F24A (Outchar and GetChar) if you are using the XL OS.

 

I remember building a Keypad reader with E: output in the VBI and ran into a similar problem.

 

-- Edit: Have you stepped this code and determined that the correct value actually is going into 764? i.e.

 

1731 lda # 134 ; f3 left

1733 bne 1737

1735 lda # 135 ; f4 right

1737 sta 764 ; poke764,keycode

173A sta 1536 ; temp location that can be checked

173D BRK

 

764 works in ML because I ran a similar routine using a joystick and it worked fine. I'll try the stepping idea. Maybe if I can see what values are getting sent to 764 I can find out where they are coming from. What I'm ultimately hoping to use this routine for is to create a touch tablet cursor controller (like the touchpad on a laptop) that can be run while writing basic programs.

Edited December 19, 2007 by yorgle

[JayoK]

764 works in ML because I ran a similar routine using a joystick and it worked fine. I'll try the stepping idea. Maybe if I can see what values are getting sent to 764 I can find out where they are coming from. What I'm ultimately hoping to use this routine for is to create a touch tablet cursor controller (like the touchpad on a laptop) that can be run while writing basic programs.

 

Sounds good. The stepping idea will allow you to see what's left in 1536 and what's going out! It's something simple. Just one thing on you whole code. I assume there is a routine for outputting nothing - i.e. there's no cursor movement?

[yorgle]

764 works in ML because I ran a similar routine using a joystick and it worked fine. I'll try the stepping idea. Maybe if I can see what values are getting sent to 764 I can find out where they are coming from. What I'm ultimately hoping to use this routine for is to create a touch tablet cursor controller (like the touchpad on a laptop) that can be run while writing basic programs.

 

Sounds good. The stepping idea will allow you to see what's left in 1536 and what's going out! It's something simple. Just one thing on you whole code. I assume there is a routine for outputting nothing - i.e. there's no cursor movement?

 

Well, now that you mention it, I left out the "no cursor movement" code because I assumed if nothing touched the tablet LDA 626 would automatically be zero. But that's not true- it's actually 228 when untouched. I'll tinker some more with it. Thanks.

[ac.tomo]

Ok, I give up. Before I pull the rest of my hair out, can anyone here point me to an assembly source listing for a routine to read two paddles as x and y coordinates so I can get some ideas? Or perhaps, better yet, look at my code and tell me if I'm at all close to what I'm trying to do? All I need to do is read the values and branch to one of four locations depending on four conditions: a) if paddle(2)<100 then branch xxxx; b) if paddle(2)>150 then branch xxxx; c) if paddle(3)<114 then branch xxxx; and d) if paddle(3)>114 then branch xxxx. (Yes, I'm playing with a touch tablet here) Here's what I've been messing with so far:

1683  lda 626 ; paddle2(x)
1686  cmp # 100
1688  bcc 1731 ; move left
1690  cmp #150
1692  bcs 1735 ; move right
1694  lda 627 ; paddle3 (y)
1697  cmp 114 ; center
1699  bcs 1723 ; move up
1701  cmp 114 ; center
1703  bcc 1727 ; move down
1705  bne 1683
...
1723  lda # 142 ; f1 up
1725  bne 1737
1727  lda # 143 ; f2 down
1729  bne 1737
1731  lda # 134 ; f3 left
1733  bne 1737
1735  lda # 135 ; f4 right
1737  sta 764 ; poke764,keycode
...

Up, Down, and Left work as expected, but for some reason, whenever the program branches to 1735, garbage values get put into 764 (causing junk to appear on the screen).

 

 

What I can see with your routine and what you say happens seems to be doing what it's programmed to do, although you could erase lines 1701 and 1705 as they're not needed, and on line 1697 don't forget to include the # symbol, you seem to have overlooked it.

The reason why garbage keeps coming up on the screen is because a keycode is put into location 764 and when control comes from the machine-code routine back to the editor or basic the key is then output to the screen via the keyboard handler.

Hope that helps?