Chema wrote:I would like to request anybody who has ever tried this game in a real oric to state so and if he had any problem with keyboard reading.
Chema, I don't have a disk drive here but I found back a demo version of Space 99 in TAP format. Would it help if I made a test with this version on a real Oric ? (that means: do you remember how you managed the keyboard in this version !)
Ok. I did a minimalistic test program that read the keys used in Space:1999, but I substituted the 4 nops with the ldy #4: loop dey: bne loop.
After loading, pressing ZXMN should print the keys (no repeating), but pressing ESC patches the absolute value loaded in the ldy to 3, thus decreasing the number of cycles waited. The next time it is pressed it decrements it to 2, then to 1.
Chema wrote:Ok. I did a minimalistic test program that read the keys used in Space:1999, but I substituted the 4 nops with the ldy #4: loop dey: bne loop.
That makes for quite a large granularity. NOP is 2 cycles long, DEY+BNE is 2+3 cycles.
Something that could work better, is to do that:
jmp nops
nops
nop
nop
nop
the JMP takes 3 cycles instead of 2, but still the result is quite close, and you can reduce the number of NOPs just by incrementing the jmp adress.
Dbug wrote:the JMP takes 3 cycles instead of 2, but still the result is quite close, and you can reduce the number of NOPs just by incrementing the jmp adress.
Simple an brilliant.
Will do that in the second attempt, where I think reading the whole keyboard matrix would be another good idea. Meanwhile I would like to hear about tests with this one in real hardware, so I can limit the search.
irq_routine
.(
;Preserve registers
sta irq_A
stx irq_X
sty irq_Y
;Protect against Decimal mode
cld
;Clear IRQ event
lda via_t1cl
;Process timer event
dec TimerCounter
lda TimerCounter
and #3 ;Essentially, every 4th irq, call key read
bne skip1
;Process keyboard
jsr ProcessKeyboard
skip1
;Restore Registers
lda irq_A
ldx irq_X
ldy irq_Y
;End of IRQ
rti
.)
ProcessKeyboard
.(
;Setup ay to point to column register
;Note that the write to the column register cannot simply be permanent
;(Which would reduce amount of code) because some orics freeze(crash).
lda #$0E ;AY Column register
sta via_porta
lda #$FF
sta via_pcr
ldy #$dd
sty via_pcr
;Scan for 9 Keys (0-8)
ldx #08
.(
loop1
lda KeyColumn,x
sta via_porta
lda #$fd
sta via_pcr
sty via_pcr
lda via_portb
and #%11111000
ora KeyRow,x
sta via_portb
;Whilst not needed on Euphoric, this time delay is required for
;some Real Orics otherwise no key will be returned!
;We should use this time for something else if given an oppertunity
+_patch_wait
ldy #4
loopw
dey
bne loopw
lda via_portb
and #08
bne skip1
dex
bpl loop1
lda #00
sta KeyCode
rts
skip1
inx
.)
stx KeyCode
rts
.)
Compiled a new version of the test program, including Dbug's suggestion. Now it prints the actual number of cycles of the waiting loop and starts from 19, which should be more than enough, and decreases by 2 at evert press of the ESC key (a message is printed).
Please anybody able to test it on real hardware report results here... I tested it on Euphoric and Oricutron and both run it well, so the only thing left I can think of is the waiting time in real Orics.
Yeah, sure. That is what worries me. The program waited what should be more than enough initially.
I have reviewed my old email and I am sure that Space:1999 (an alpha version, but it include sfx and music and intro, so surely using this routine for keyboard reading) worked on Fabrice's system. And it waited just 8 cycles.