Author Topic: Keyboard scanning and key redefinition library  (Read 1366 times)

0 Members and 1 Guest are viewing this topic.

Offline fano

  • Supporter
  • 6128 Plus
  • *
  • Posts: 835
  • Country: fr
  • Easter Egg Programmer
    • Easter Egg
  • Liked: 278
  • Likes Given: 614
Keyboard scanning and key redefinition library
« on: 10:55, 15 January 14 »
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
"NOP" is the perfect program : short , fast and (known) bug free

Follow Easter Egg products on Facebook !

Offline TFM

  • Visit the mysteries of the CPC at www.futureos.de
  • Supporter
  • 6128 Plus
  • *
  • Posts: 9.899
  • Country: aq
  • Space Chicken for FutureOS is free!
    • index.php?action=treasury
    • FutureOS - The revolution on CPC!
  • Liked: 1983
  • Likes Given: 4650
Re: Keyboard scanning and key redefinition library
« Reply #1 on: 19:16, 15 January 14 »
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?

TFM of FutureSoft
Also visit the CPC and Plus users favorite OS: FutureOS - The Revolution on CPC6128 and 6128Plus

Offline arnoldemu

  • Supporter
  • 6128 Plus
  • *
  • Posts: 5.336
  • Country: gb
    • Unofficial Amstrad WWW Resource
  • Liked: 2277
  • Likes Given: 3478
Re: Keyboard scanning and key redefinition library
« Reply #2 on: 19:26, 15 January 14 »
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.
My games. My Games
My website with coding examples: Unofficial Amstrad WWW Resource

Offline arnoldemu

  • Supporter
  • 6128 Plus
  • *
  • Posts: 5.336
  • Country: gb
    • Unofficial Amstrad WWW Resource
  • Liked: 2277
  • Likes Given: 3478
Re: Keyboard scanning and key redefinition library
« Reply #3 on: 20:01, 15 January 14 »
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.


« Last Edit: 20:03, 15 January 14 by arnoldemu »
My games. My Games
My website with coding examples: Unofficial Amstrad WWW Resource

Offline fano

  • Supporter
  • 6128 Plus
  • *
  • Posts: 835
  • Country: fr
  • Easter Egg Programmer
    • Easter Egg
  • Liked: 278
  • Likes Given: 614
Re: Keyboard scanning and key redefinition library
« Reply #4 on: 22:10, 15 January 14 »
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.
"NOP" is the perfect program : short , fast and (known) bug free

Follow Easter Egg products on Facebook !

Offline TFM

  • Visit the mysteries of the CPC at www.futureos.de
  • Supporter
  • 6128 Plus
  • *
  • Posts: 9.899
  • Country: aq
  • Space Chicken for FutureOS is free!
    • index.php?action=treasury
    • FutureOS - The revolution on CPC!
  • Liked: 1983
  • Likes Given: 4650
Re: Keyboard scanning and key redefinition library
« Reply #5 on: 23:05, 15 January 14 »
Have ... to ... play ... R-Type NOW!  :laugh:
TFM of FutureSoft
Also visit the CPC and Plus users favorite OS: FutureOS - The Revolution on CPC6128 and 6128Plus

Offline Executioner

  • Supporter
  • 6128 Plus
  • *
  • Posts: 783
  • Country: au
  • WinAPE Developer
    • WinAPE
  • Liked: 392
  • Likes Given: 60
Re: Keyboard scanning and key redefinition library
« Reply #6 on: 02:57, 28 February 14 »
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.

Quote
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.

Offline arnoldemu

  • Supporter
  • 6128 Plus
  • *
  • Posts: 5.336
  • Country: gb
    • Unofficial Amstrad WWW Resource
  • Liked: 2277
  • Likes Given: 3478
Re: Keyboard scanning and key redefinition library
« Reply #7 on: 10:58, 28 February 14 »
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.
« Last Edit: 11:05, 28 February 14 by arnoldemu »
My games. My Games
My website with coding examples: Unofficial Amstrad WWW Resource