Reading the Keyboard
Very cool!
I will try (when I have time) to put it inside a small demo and test it. Also will try to write some additional routines for using the virtual matrix.
One thing I was thinking about... With this method keyboard presses are not buffered in any way, so after all, the main program will do a polling on the virtual matrix. If the main program is not quick enough, it might lose some keypresses (the bit in the virtual matrix will become 1 and 0 too quickly to detect).
I am not sure if this could be an issue, but if it is, why not 'accumulate' the presses between pollings? Something like making the IRQ routine NOT clear the matrix, just ora the bits when it detects a keypress and let the auxiliar routines which actually work with the matrix to clear it?
Does it make sense?
I will try (when I have time) to put it inside a small demo and test it. Also will try to write some additional routines for using the virtual matrix.
One thing I was thinking about... With this method keyboard presses are not buffered in any way, so after all, the main program will do a polling on the virtual matrix. If the main program is not quick enough, it might lose some keypresses (the bit in the virtual matrix will become 1 and 0 too quickly to detect).
I am not sure if this could be an issue, but if it is, why not 'accumulate' the presses between pollings? Something like making the IRQ routine NOT clear the matrix, just ora the bits when it detects a keypress and let the auxiliar routines which actually work with the matrix to clear it?
Does it make sense?
In my experience this has never been an issue because the main code has always been faster than the human touch (or tap).
Note: The last statement is not a boast
However for this particular project of Elite where the main code cycle may be a little sluggish i can see you may need to buffer in some way.
I'm sure Dbug can come up with a resolve?
Note: The last statement is not a boast
However for this particular project of Elite where the main code cycle may be a little sluggish i can see you may need to buffer in some way.
I'm sure Dbug can come up with a resolve?
Well, the idea was to have two matrix, the 'prev' and the 'curr', so basically you can query the status of keys on two frames, just return the result of PREV or CURR
If two frames is not enough, I guess we can afford to store the status for more frames, but then it will probably be annoying to handle.
If we have a 50hz IRQ, and if we have the status for two frames, you would really have to have a very very very slow code to make missing keys an actual issue.
If two frames is not enough, I guess we can afford to store the status for more frames, but then it will probably be annoying to handle.
If we have a 50hz IRQ, and if we have the status for two frames, you would really have to have a very very very slow code to make missing keys an actual issue.
Perfect then... I won't bother at the moment and see how it goes.
On another note I tested your code and it seems the CB2 pulse mode is not correctly emulated. At least it does not work. Only sense keys on column 0 and return all the bits set to 1 for that byte in the virtual matrix.
Anyway I restored the old method for selecting columns/rows and it is working now! The virtual matrix is perfectly updated.
May adapt it to work in my program and see how it behaves soon
On another note I tested your code and it seems the CB2 pulse mode is not correctly emulated. At least it does not work. Only sense keys on column 0 and return all the bits set to 1 for that byte in the virtual matrix.
Anyway I restored the old method for selecting columns/rows and it is working now! The virtual matrix is perfectly updated.
May adapt it to work in my program and see how it behaves soon
Sure... More optimizations welcomeTwilighte wrote: May i see this amended code here?
Code: Select all
SenseKeyPrep
.(
sta via_porta
lda #$fd
sta via_pcr
sty via_pcr
lda via_portb
and #%11111000
stx zpTemp02
ora zpTemp02
sta via_portb
rts
.)
ReadKeyboard
.(
;Write Column Register Number to PortA
lda #$0E
sta via_porta
;Tell AY this is Register Number
lda #$FF
sta via_pcr
ldy #$dd
sty via_pcr
ldx #7
loop2 ;Clear relevant bank
lda #00
sta KeyBank,x
;Write 0 to Column Register
jsr SenseKeyPrep
;Wait 10 cycles for curcuit to settle on new row
;Use time to load inner loop counter and load Bit
ldy #$80
nop
nop
nop
lda #8
;Sense Row activity
and via_portb
beq skip2
loop1 ;Store Column
tya
eor #$FF
jsr SenseKeyPrep
;Use delay(10 cycles) for setting up bit in Keybank and loading Bit
tya
ora KeyBank,x
sta zpTemp01
lda #8
;Sense key activity
and via_portb
beq skip1
;Store key
lda zpTemp01
sta KeyBank,x
skip1 ;Proceed to next column
tya
lsr
tay
bcc loop1
skip2 ;Proceed to next row
dex
bpl loop2
rts
.)
KeyBank .dsb 8
I just noticed the delay in this routine is 10 cycles but i seem to remember the Real Oric requires about 12 cycles to settle its curcuits
Also i believe the next (or maybe already in 0.5) version of Oricutron will observe this 12 cycle delay in setting the key state bit in Port B.
It will be interesting to see how reliable modern stuff (especially my demos/games) are once this 'real' delay is emulated
Also i believe the next (or maybe already in 0.5) version of Oricutron will observe this 12 cycle delay in setting the key state bit in Port B.
It will be interesting to see how reliable modern stuff (especially my demos/games) are once this 'real' delay is emulated
Well if some Orics need more cycles, then it is me who has to change the code of Space:1999 and the forthcoming 1337.
In fact, although minor, this is a quite interesting issue that should be tested in real Orics. I don't have mine working now, but I wonder if we could do a small routine for reading the keyboard with different waiting times and check which is the typical value and if there are differences between Orics...
EDIT:
I was wondering... the Oric keyboard is using a 4051 analog mux, isn't it? I had a look at the datasheet here:
http://pdf1.alldatasheet.com/datasheet- ... /4051.html
and in the DYNAMIC ELECTRICAL CHARACTERISTICS it gives out the max delay for several operations. None goes beyond a max of 700 ns, less than one machine cycle of 1us. I am not sure how many operations should be done to read the keypress, or if there are any other delays...
Any hardware expert could help here?
In fact, although minor, this is a quite interesting issue that should be tested in real Orics. I don't have mine working now, but I wonder if we could do a small routine for reading the keyboard with different waiting times and check which is the typical value and if there are differences between Orics...
EDIT:
I was wondering... the Oric keyboard is using a 4051 analog mux, isn't it? I had a look at the datasheet here:
http://pdf1.alldatasheet.com/datasheet- ... /4051.html
and in the DYNAMIC ELECTRICAL CHARACTERISTICS it gives out the max delay for several operations. None goes beyond a max of 700 ns, less than one machine cycle of 1us. I am not sure how many operations should be done to read the keypress, or if there are any other delays...
Any hardware expert could help here?
BTW Xeron, what about moving all these tech parameters (this is a good example) to the configuration file? You could have a section for tech specs, and you can set the kbd_settle_time to 0 or 12 or whatever...
There might be other differences between hardware that could be nice to have there...
Just a thought.
There might be other differences between hardware that could be nice to have there...
Just a thought.
Sure. I am quite sure that 8 cycles worked on a real system (should check with Fabrice again, however).
But I have posted a link to a small program to test on real orics and see what this value is on different machines. The link is on the Space:1999 players area thread in the games forum (I know it is strange, but it is where I was asking people to test the game on real hw).
As soon as we get some tests we could figure out a good typical value.
But I have posted a link to a small program to test on real orics and see what this value is on different machines. The link is on the Space:1999 players area thread in the games forum (I know it is strange, but it is where I was asking people to test the game on real hw).
As soon as we get some tests we could figure out a good typical value.
As suggested to Chema a while ago, this delay that needs to exist.. does it have a maximum? ie. why do we concentrate on trying to waste the right amount of time when (given the right scheme) we could branch off and do some other essential stuff before returning to read the keyboard key state.
Obviously any prospective routine may need to be called the number of times as there are keys.
I think in ZipnZap i used the delay to display the score.. 8 keys.. 8 score digits.
Obviously any prospective routine may need to be called the number of times as there are keys.
I think in ZipnZap i used the delay to display the score.. 8 keys.. 8 score digits.