Keyboard scanning and key redefinition library

[fano]

Added a library that scans the keyboard (using existing routine on wiki) , check first key pressed , check a key status (with shift and control), translate a keycode into offset and mask in keyboard buffer to allow fast checking (especially for ingame).
It is written in pure asm , no firmware calls.It is in Sjasm syntax but can be adapted easily to any other cross assembler.


If you have suggestions , comments or technical questions , post here.


Here it is : Programming:Keyboard redefinition - CPCWiki

[TFM]

Hi Fano,


Don't you have to set the PSG to inactive ( out (c),0 ) at the end? Or can you skip that?


My routines in FutureOS are like your and skip it too, but sometimes I'm not sure it this it the best.




Anybody an idea?

[arnoldemu]

I thought to be compatible with plus you need this.
Normally setting the i/o mode with port f7 on a normal ppi will set the outputs to 0, but not on a plus.

[arnoldemu]

Ok, so this statement:

"The ASIC arbitrates accesses to the parallel interface device between the "DMA" channels and the CPU, allowing only one to access it at a time. CPU accesses to the 8255 could be held off by means of wait states for up to a 8 microseconds if the "DMA" channel is currently executing a LOAD instruction. After a LOAD is executed, the ASIC must put the PSG address register back as it was before. To achieve this the 8255 parallel peripheral interface and the 74LS145 decoder have been integrated into the ASIC."

So this means that ASIC when executing a LOAD, assuming it's accessing it *like* the PPI would, would perform a i/o change, a register select, a register write. It will then do a register select (to the value it was previously), and should put it back to the original i/o condition.

This could be tested.

Port F4 needs to be set to input. We need to then either read data from the PPI, or leave it in input mode. Then we need a DMA list executing that is sending values to the AY. if there is no sound, then the ASIC doesn't change the I/O state. If there is sound, it either changes the i/o state or accesses the AY directly. In addition if we don't change the AY register, we should be able to continue to read it, or do a write to one and this would confirm the DMA puts it back again.

the out (c),0 is something that we can test. I always thought it was to do with the ASIC arbitrating between 8255 and itself, but it may be down to the AY itself. Not sure how to test this because switching PPI from input/output clears the outputs.

So although some things can be tested, it will be hard to determine exactly *why* out (c),0 is needed. We know it is, but *why*. Nothing in the arnold5 docs explicitly states it's needed.

Another question I always wondered, WHY does it need 8 cycles for a LOAD operation? Perhaps there are some timing constaints on the AY that require this.

would be good if somebody would hook up a scope on the AY on a Plus. If I can give a suitable test program we should be able to see what it does when it does a DMA load.

[fano]

TFM suggestion is right, i never noticed this missing validation at end of the routine.I used this bit of code for R-Type too and as far i remember that worked on a Plus.

[TFM]

Have ... to ... play ... R-Type NOW! 

[Executioner]

Ok, so this statement:

"The ASIC arbitrates accesses to the parallel interface device between the "DMA" channels and the CPU, allowing only one to access it at a time. CPU accesses to the 8255 could be held off by means of wait states for up to a 8 microseconds if the "DMA" channel is currently executing a LOAD instruction. After a LOAD is executed, the ASIC must put the PSG address register back as it was before. To achieve this the 8255 parallel peripheral interface and the 74LS145 decoder have been integrated into the ASIC."

So this means that ASIC when executing a LOAD, assuming it's accessing it *like* the PPI would, would perform a i/o change, a register select, a register write. It will then do a register select (to the value it was previously), and should put it back to the original i/o condition.

Is that the same document with statements about soft-scroll affecting the whole display? It could be that the 8 microseconds are for all three DMA channels doing a LOAD at the same time. It would be relatively easy to test if the CPU is actually delayed when the ASIC is doing a LOAD by doing a raster interrupt, setting up the DMA channels, waiting for the next line and then accessing the 8255 and doing a palette change after to see if the DMA affects the palette change.

would be good if somebody would hook up a scope on the AY on a Plus. If I can give a suitable test program we should be able to see what it does when it does a DMA load.

That would be nice. I haven't emulated this as per the statement above since I don't know if the Z80 is actually held in Wait while it happens. I also haven't found any existing software which has shown this up.

[arnoldemu]

Is that the same document with statements about soft-scroll affecting the whole display? It could be that the 8 microseconds are for all three DMA channels doing a LOAD at the same time. It would be relatively easy to test if the CPU is actually delayed when the ASIC is doing a LOAD by doing a raster interrupt, setting up the DMA channels, waiting for the next line and then accessing the 8255 and doing a palette change after to see if the DMA affects the palette change.

That would be nice. I haven't emulated this as per the statement above since I don't know if the Z80 is actually held in Wait while it happens. I also haven't found any existing software which has shown this up.

I do plan to test this when I can. Thank you for the test suggestion.