DrDnar wrote:
I said "already documented" in response to the "definite reversable relationship between the getcsc codes and the direct input codes." I didn't mean to say that his unique take on key input had already been done.
That was clear to me, I hope it was to Anak too. Smile
I've actually been using a similar routine for in Axe Parser for a long time to allow the getkey and the direct-key routines to have the same keycodes. However, the conversion from the GetCSC code to mask-and-compare code is actually done compile time instead of at runtime. I didn't know that this was "undocumented", I thought it was well known...
Smile shankou. now to move on to more pressing matters, synchronizing sound with graphics in a game.
Anakclusmos wrote:
Smile shankou. now to move on to more pressing matters, synchronizing sound with graphics in a game.
Is that it for this thread, then? You're happy with your code in terms of speed, size, functionality, etc?
no, just a subject add-on.Like I said before, something isn't working right when you check 2 keys from the same group and then a 3rd from another.
Anakclusmos wrote:
no, just a subject add-on.Like I said before, something isn't working right when you check 2 keys from the same group and then a 3rd from another.
OK, I'll try to look into what could be causing that, unless you figured it out already in the intervening two days. Did you find the problem yet?
I rewrote the routine from scratch, fixed the problem and improved greatly, compare and comment.

Old Code:

Code:
CheckKey:
  dec a
  ld b,%00000001
  ld c,%11111110
ck_loop1:
  cp 8
  jr c,ck_loop2
  rlc c
  sub 8
  jr ck_loop1
ck_loop2:
  or a
  jr z,ck_cont
  rl b
  dec a
  jr ck_loop2
ck_cont:
  ld a,0FFh
  out (1),a
  ld a,c
  out (1),a
  in a,(1)
  and b
  ret


New Code:

Code:
CheckKey:
  ld b,$FE
  ld c,$01
ck_loop:
  dec a
  or a
  jr z,ck_getkey
  rlc c
  jr nc,ck_loop
  rlc b
  jr ck_loop
ck_getkey:
  ld a,$FF
  out (1),a
  ld a,b
  out (1),a
  in a,(1)
  and c
  ret
Very nice, that ld a,b takes care of some of the cycles that nop \ nop introduces. I can't remember if that's a 4-cycle or 8-cycle instruction, though. If it's 4-cycle, you should still add a nop in there for an 8-cycle total waste in between outs.
I thought you need a delay between the out and in, though
calc84maniac wrote:
I thought you need a delay between the out and in, though
So he does. If not, I believe that 15MHz calculators will sigh and handwave at your code.
Well, a simple change...


Code:
CheckKey:
  ld b,$FE
  ld c,$01
ck_loop:
  dec a
  or a
  jr z,ck_getkey
  rlc c
  jr nc,ck_loop
  rlc b
  jr ck_loop
ck_getkey:
  ld a,$FF
  out (1),a
  ld a,b
  out (1),a
  nop \ nop
  in a,(1)
  and c
  ret


That'll solve the 83+SE and 84/+SE incompatability, maybe the maximum 5 keypresses as well. I usually use this macro in case anyone want else wants to...


Code:
#define CheckKey(key) ld a,key \ call CheckKey
As I suspected, ld a,b is only four clocks, so I recommend you change out (1), a \ ld a,b to out (1), a \ ld a,b \ nop.
I realized lately that the typical delay we use is really more than 8 clocks, because of the in/out instructions themselves. It might really be as much as 19 cycles. Why is this important, you ask? Well, when scaling delays for 15MHz models, this might make a difference. Just a random thought.
calc84maniac wrote:
I realized lately that the typical delay we use is really more than 8 clocks, because of the in/out instructions themselves. It might really be as much as 19 cycles. Why is this important, you ask? Well, when scaling delays for 15MHz models, this might make a difference. Just a random thought.
You make an excellent point; I never thought of that. Do we know enough about the execution model of the z80 to know at what point the bus lines are actually set?
You seem rather loath to acknowledge that it exists, Kerm, but it's all in the manual.
benryves wrote:
You seem rather loath to acknowledge that it exists, Kerm, but it's all in the manual.
Yeah, I have a bad habit of doing that. Sad I'll take a look in there and see what it says on this issue.

Edit: The manual seems to imply that of the 11 t-states of the in a,(*) and out (*),a instructions, the actual out occurs around the 7th of 11 t-states, and the in occurs between the 8th and 11th t-state.
  
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
Page 2 of 2
» All times are UTC - 5 Hours
 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

 

Advertisement