Insert key in keyboard event queue?

[cpcitor]

Hello.

(For the record, this is related to http://www.cpcwiki.eu/forum/programming/load-using-firmware-loader-with-messages-without-'press-play-then-any-key' )

Can you imagine a simple and portable (between CPC models) to have the firmware believe that the user pressed a key?

For my use case it doesn't matter much which key the firmware believes is pressed.

Perhaps some simple POKE in the key queue, if its address is stable in RAM between CPC models?

[pelrun]

This is what the firmware guide is for

Code Select Expand

&BB0C KM CHAR RETURN
Action: Saves a character for the next use of KM WAIT CHAR or KM READ CHAR
Entry: A contains the ASCII code of the character to be put back
Exit: All registers are preserved

[cpcitor]

Thanks pelrun for the hint!

Indeed it is in firmware.pdf page 43 and seems a perfect fit.
It is also briefly mentioned in Soft968 chapter 3.

Alas it does not work 

This command:

Code Select Expand

arnold -at '10 |tape : call &bb0c,65 : load""\nlist\nrun\n'

does not prevent the firmware from waiting at the prompt:

[attachimg=1]

I also tried

Code Select Expand

arnold -at 'call &bb0c,65 : input a$\n'

Code Select Expand

arnold -at 'call &bb0c,65 : a$=inkey$ : print a$\n'

[attachimg=2]

I guess that the BASIC prompt reinitialize the keyboard queue, which makes this approch not feasible. 

Other approach?
How does Arnoldemu perform autotype?

[arnoldemu]

on 6128 according to a dissassembly of the os you can poke b1e4.
I think the value is 1 for play, 2 for record.

arnoldemu has control over the keyboard and it simulates keypresses. From the emulated CPC perspective it is like the user is typing the keys. (it does a key down, wait a frame, key up, wait a frame). The wait is for the firmware to see that the key has been released.

[cpcitor]

on 6128 according to a dissassembly of the os you can poke b1e4.
I think the value is 1 for play, 2 for record.

arnoldemu has control over the keyboard and it simulates keypresses. From the emulated CPC perspective it is like the user is typing the keys. (it does a key down, wait a frame, key up, wait a frame). The wait is for the firmware to see that the key has been released.

Thanks arnoldemu. In the meantime I just read your source code and that's what I was expecting anyway. 

Then why when using autotype does arnoldemu causes the CPC to clear the screen and re-print "BASIC 1.x"?

[pelrun]

call &bb0c,65

That's not how it works. The routine requires the value in the A register, but parameters to CALL/RSX's are passed VERY differently (all pushed onto the stack, last parameter pointed to by IX, and number of parameters put into A). So unless you want to pass 65 dummy parameters... (don't bother, the max is 32) you'll have to write a little more machine code to access it from BASIC.

[cpcitor]

That's not how it works. The routine requires the value in the A register, but parameters to CALL/RSX's are passed VERY differently (all pushed onto the stack, last parameter pointed to by IX, and number of parameters put into A). So unless you want to pass 65 dummy parameters... (don't bother, the max is 32) you'll have to write a little more machine code to access it from BASIC.

Thanks for the reminder. I can't find an example from the top of my head, but I remember that some calls with arguments do work from BASIC still, even if more or less by accident sometimes. :-)

Ah, I think one call worked from BASIC using a hack, like calling the address one of two bytes before the call. The bytes there (actually encoding ROM target address of another call), when read as Z80 opcodes happened to include a LD that copied a byte from the value provided by BASIC to the register expected by the targeted call. So, that just worked from BASIC. And those bytes were stable between 464-6128 so the hack worked on all of them.

[cpcitor]

Can you imagine a simple and portable (between CPC models) to have the firmware believe that the user pressed a key?

For my use case it doesn't matter much which key the firmware believes is pressed.

Perhaps some simple POKE in the key queue, if its address is stable in RAM between CPC models?

If the character being typed is not important, the CALL &BB0C hack fits.

This whole approach is doomed for my actual use case anyway ( http://www.cpcwiki.eu/forum/programming/load-using-firmware-loader-with-messages-without-'press-play-then-any-key'; ).