Reading the Keyboard

[Dbug]

That's why I was suggesting in a previous post some month ago, that we could use this time to maintain a real in memory matrix, with the status of the keys, currently pressed or not, and transitions from a state to another one.

[Chema]

Something like that is what we are using in 1337 (see my post on the previous page for the code... Twilighte's code basically with some additions). The only unused time are the three nops a bit after the loop2 label.

That implements a waiting of 10 cycles.

There is another part of the code which uses all the cycles to update the matrix.

So 6 unused cycles in all the routine for keyboard reading, which is not bad, imho.

[Dbug]

So 6 unused cycles in all the routine for keyboard reading, which is not bad, imho.

I would call that "pretty good" instead of "not bad"

[Chema]

Well I must admit it is 6 cycles per each of the 8 rows.

But I have been reading some discussion I had with Fabrice a couple of years ago about this. And we found no explanation for this waiting time. In addition, he confirmed me that the version with just 2 nops (IIRC) worked on real hardware too.

We did not come to any conclusion on this matter, but surely it is not the multiplexer, as it reacts in less than one microsecond.

The fact that Symoon tested my keyboard testing program on a real Oric and it worked even with a wait of just 3 cycles makes me suspicious about the need of large waiting times.

I am not sure how many of you are able to load tap files on real orics, but please, if any of you can, download and test this program:
http://www.defence-force.org/ftp/forum/ ... YBOARD.tap

It checks keypresses of ZXMB=- and CTRL (printed as C). Every time the user presses ESC, the waiting time gets lower. Check the minimum value at which your Oric works and let us know.

Let's try to figure out this bit of info!

[Symoon]

The fact that Symoon tested my keyboard testing program on a real Oric and it worked even with a wait of just 3 cycles makes me suspicious about the need of large waiting times.

What I say may be stupid but - would the hardware configuration change something? I mean, for instance with an Oric with a disk drive, would the result be different?

I might try your program on other Orics this weekend, I'll let you know if I do.

[Chema]

Thanks Symoon. I don't think the fact of having a disk drive changes things... I don't see how it would, but I might be losing something.

Do you have a working Microdisc? Any possibility that you test the alpha version of 1337 and check a couple of things for me (one is the keyboard reading, of course)?

[Symoon]

Do you have a working Microdisc? Any possibility that you test the alpha version of 1337 and check a couple of things for me (one is the keyboard reading, of course)?

Yes I do, but not here in Paris. Actually I'm leaving tomorrow morning to the place where I store my Oric things, so I will have a Microdisc this weekend, but:
- It's a 3" unit, and I won't have the required computer to transfer a DSK file to 3" disk. I only have it in Paris (yes, that's complicated, I know
- not 100% sure I'll have time to dig out the Microdisc and do the test

So if you ever manage to send me a DSK file tonight or early tomorrow morning, I'd say there's a 10% chance of me transfering it before taking my train, and doing the test this weekend.
If not, it will have to wait for about 3 weeks :-/
(sorry I had to bother you with my life details )

[Chema]

I completely overlooked the fact that original microdiscs used 3'' disks, so it might be difficult to transfer the dsk. I thought it would be difficult enough to find a computer with a 3 1/2'' floppy drive

I clearly read this too late, Symoon. Anyway thanks for your help. These tests can wait for 3 weeks anyway.

I have been talking to Fabrice about the keyboard reading. Despite the general believings we both agree that the delay cannot be due to the multiplexer (see the datasheet I posted), but could not find the reason.

Anyway he told me that Fabrice Broche wrote the telestrat keyboard routine as:

Code: Select all

stx viaportb
inx
lda #8
and viaportb

That is a wait of 8 cycles, taking into account that the viaportb is accessed at the end of the and instruction, which takes 4. If the Telestrat uses the same keyboard as the Atmos, then that is a good indication of which could be a good number for the waiting time.

This also agrees to the experiments we had. An alpha version of Space:1999 with a routine with 2 nops between the writting of VIA port B and the reading, worked on Fabrice's computer (we think it didn't but it was due to other matters). That is also 8 cycles.

The routine Symoon tested makes a jmp absolute (3 cycles) and then the and viaportb, which is 7 cycles (3 is printed onscreen as it is what the jmp takes, but I did not include the 4 of the actual and viaportb instruction)!

The limit could be somewhere around there, but I think this is quite a much better approximation than 20 cycles, and it is quite easy to fill those with code, not wasting anything.

[Xeron]

I'll probably set oricutron to 7 cycles for now then.

[Chema]

More news on this, thanks to Symoon...

He tested my code in another Atmos and it worked too! but not only that. Even with less cycles it worked. This is the actual code (written by Twilighte, where I removed all the waiting) for reading the keyboard (only ZXMBT=-, CTRL and ESC) is called every 4th interrupt and it is:

Code: Select all

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
        lda #08
        and via_portb  
        ; ***********
        bne skip1 
        dex 
        bpl loop1 
        lda #00 
        sta KeyCode 
        rts 
skip1   inx 
.) 
        stx KeyCode 
        rts 

.)



;Row and column tables for Z,X,M,B,T,-,=,CTRL and ESC 
KeyRow 
 .byt 2,0,2,2,1,3,7,2,1 
KeyColumn 
 .byt $df,$bf,$fe,$fb,$fd,$f7,$7f,$ef,$df

KeyCode .byt 0

So, at least in one Oric, just 2 cycles plus the 4 of the "and via_portb" (as the access is done at the last cycle of the instruction), is working.

Xeron, I'd use a much more conservative approach. I'd say that 4-5 cycles of delay would be more convenient than 7... but not sure.

More to investigate here... I want to setup a routine to read the whole keyboard as fast as possible, using Dbug's approach of updating a virtual matrix (which is done in 1337) and make more tests...

[Twilighte]

That is brilliant Chema, after all these years of assuming 12 cycles, it may have been Fabrice who originally suggested the delay or it might have been reading the Atmos ROM, but then again the ROM will have a tendancy to lye on the conservative side of reliability

I doubt specific keys will require more or less cycles before their state can be read but it i recognise the importance to check all aspects of the reduced settle time.

Furthermore i wonder if the settle time varies for the number of keys being sensed at one time. For example setting the column register to Zero allows a complete row of keys to be sensed but how long is the settle time in this case?

[JamesD]

Maybe the prototype Oric had a slow part or the engineer that built it came up with that based on past experience with slow parts and it was never removed.

[Chema]

Yeah most probably, JamesD. Also the fact that Fabrice Broche reads the Telestrat keyboard with 8 cycles is a good clue about what we can expect from the hardware.

Twilighte, I really think that what is needed is come up with several small test programs (like the one I did) that could be loaded into real Orics and see how they behave.

I intended to do the full keyboard reading, but had no time yet. Will do anyway in the near future.

The problem is that only Symoon is able to load them on Orics for now. I know Dbug has his Oric and the necessary hardware to do this inside some forgotten box, and you can ask him what he is doing to load them correctly, so you can do the same

It seems it is nearly a must to do that from a PC, as mp3 just usualy don't work.

I must have a look and try to find my old oric to do the same.

I think there are other people around that are able to load programs into real machines, but they either don't read these threads, or have no time for testing

[Twilighte]

There is a slight improvement you might try with the above keyboard routine..

Replace..

Code: Select all

       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 

with..

Code: Select all

       ldy #%10111101 
        sty via_pcr 

        ;Scan for 9 Keys (0-8) 
        ldx #08 
.( 
loop1 
        lda KeyColumn,x 
        sta via_porta 
        lda via_portb

What i have done above is to change CB2 PCR mode to Pulse CB2 whenever PortB is accessed.
This was something i used ages ago to produce samples so i know it works on real Oric.
I think i got the code right. Needs testing tho

[Chema]

Never tried your trick, Twilighte.. yet.

I think it is a good domain to explore, as soon as emulators support it, and we can confirm it works in real machines... maybe a next step.

For the moment, and after the discussion and testing you can follow in the game forum (thread about 3D game 1337) I have posted the sources of the keyboard reading routine and a small C demo program here:

http://miniserve.defence-force.org/svn/ ... /keyboard/

There is also a TAP file you can test. The whole keyboard matrix is scanned by interrupts and the virtual matrix is updated. The test program dumps the matrix into screen, so you can see the detected keypresses.

The .s assembly file also includes a couple of extra routines (very simple) to read a char with and without repeating and returning its ASCII value, so you can see how the virtual matrix bits are mapped into the oric's keyboard.

Any ideas, optimizations and such, are welcomed!