Unable to paste text into program using INKEY(0)
Closed this issue · 11 comments
The attached disc contains two BASIC programs PASTE and PASTE2. Both read from the keyboard using OSBYTE &81; PASTE invokes OSBYTE directly while PASTE2 uses BASIC's INKEY(0) to do the job. They both exhibit the same problem: when pasting text in they just output a constant stream of ASCII code 13s. Typing at the keyboard works fine. (This works in b-em for both typing and pasting text, for what it's worth.)
Would it be possible for the paste functionality to support this please?
(This came up in the context of pasting user commands into the Ozmoo Z-code interpreter; see https://stardot.org.uk/forums/viewtopic.php?f=2&t=19975&p=296258#p296248.)
Thanks for reporting this. I can take a look. It's interesting, the pasted text appears after I hit Escape to exit either PASTE or PASTE2.
Thanks Chris, much appreciated! I noticed that too, it's odd - I suspect it's because the BeebEm paste is implemented via OSRDCH and it remains "pending" during the OSBYTE calls, so once we get back to the BASIC prompt it calls OSRDCH (via OSWORD 0?) and the paste then taken effect.
You're right. The paste command puts the following routine into memory at address &100:
0100 SEC
0101 LDA &FC51
0104 BNE &010A
0106 LDA &FC50
0109 CLC
010A RTS
and then sets the RDCHV vector at &210 to address &100. The pasted text is read in via address &FC50 (get next char from the clipboard buffer) and &FC51 (check if clipboard buffer is empty). So it's not going through the keyboard, which is why OSBYTE &81 isn't reading the characters. I guess this code needs rewriting to translate the clipboard text into keypresses instead.
I think b-em works by translating the clipboard text into keypresses, but I think that's quite fiddly. It is probably the best solution as it's completely invisible to software running on the emulated machine, but you could probably also use a similar trick to intercept OSBYTE and maybe get 90% of the benefit for 10-20% of the effort. (Ozmoo uses memory at &100 itself and I managed to get a crash as a result of it and BeebEm fighting over that memory. This is slightly dirty code in Ozmoo, I admit - and I will almost certainly tweak things to get rid of this dirtiness - but it does work fine except during pasting on BeebEm.)
I just had a look at the B-Em code. It works by intercepting the REMV and CPNV vectors, see https://github.com/stardot/b-em/blob/b4e3a717af3f37b331dc50eaac2509ba309b31ef/src/6502.c#L324. I could try implementing the same approach, then BeebEm wouldn't need to put that routine into memory at &100.
I wrote an emulator that translated clipboard text into keypresses. I can't remember now if the speed limit is 25 or 50 keys per second. This sounds quick but if you're pasting a large BASIC program, say, it is frustratingly slow. So I switched to the OSRDCH method. (I didn't patch memory though. I just added a trap in the emulator if the 6502 PC entered the default OSRDCH routine.)
Anyway, apart from being a pain to implement it's another reason not to go down the keypress route.
I have hacked together an implementation, copying B-Em's approach, which is working OK. I'll tidy up the code and commit.
I haven't been able to test the CNPV code, but that's a good suggestion. It could simply return 1 if there's any data left in the buffer. Do you have any thoughts on how to test this?