The implementation of that copy function was rather unusual, since there was no text buffer that the system could copy from, all it had was a bitmap in video RAM. The system would read the 8x8 pixels below the copy cursor, and compare the pixels with the 256 known character glyphs one by one, to determine which character it was. One could call this a primitive form of OCR, although even a single modified pixel would make the copy function fail.

The whole copy-by-character-recognition feature in the Amstrad firmware was such a weird hack that it seems unlikely anyone else has ever coded a similar solution for production use, except maybe in some application where the copy functionality had to be bolted-on later. Amstrad did it that way from the start.

You could even use this functionality from your own code - CALL &BB60 would read a character from the current cursor position and return its ASCII code.

Any idea how fast it was? If it was doing a linear search it doesn't sound like it would be fast.

Maybe I couldn't find a better way at the time, but to add a pause/delay to game code, I remember using "for" loops that just counted to an arbitrarily high number because the processor was so slow e.g. count from 0 to X to make it wait a few milliseconds.

It wasn't fast. But if you were really concerned about performance on the CPC you wouldn't be using the firmware anyway.

Standard practice to do a delay on the CPC was a loop around CALL &BD19 - that paused until frame flyback, i.e. 1/50th of a second.

GW-Basic on DOS did the exact same thing in graphics mode. I had quite a bit of fun experimenting with that.

Also, Bill Atkinson, when making MacPaint, actually implemented something similar to edit text that had been placed into the bitmap with the text tool. Since he knew that it couldn't be perfectly reliable (as there might be non-text pixels in there), he got rid of the feature (https://www.folklore.org/StoryView.py?project=Macintosh&stor...)

Cool, that's a pretty weird/neat hack. How come you know about how it was implemented?

The Amstrad CPC firmware manual was for sale back then, but it's freely available now: http://www.cantrell.org.uk/david/tech/cpc/cpc-firmware/

In particular, there's the following note about TXT UNWRITE in the Indirections section: "This routine works by comparing the image on the screen with the character matrices; therefore if the character matrices have been altered the routine may not find a readable a character"

There's an equivalent 6502 routine in Acorn's MOS series, as used in the BBC Micro and derivatives, which had similar text editing functionality.

The code from the BBC Micro version of the OS can be seen here: https://tobylobster.github.io/mos/mos/S-s9.html#SP1

The Apple ][ series had a similar "feature". At the standard BASIC prompt, pushing right-arrow would advance the cursor over the character displayed to the right (whether or not it was part of the current "line" you had typed so far), and – crucially – add it to the internal command buffer.

On its own, this is a useless quirk, but you could also push Escape (I think) to temporarily disable this behavior, permitting the arrow keys to freely reposition the cursor on screen until you hit Escape again.

So if you wanted to "edit" a line, you would list it out to the console, press Escape, move the cursor up to the start of the line, press Escape again, move the cursor right over the stuff you wanted, press Escape again, move the cursor somewhere else, press Escape again, type whatever it was you wanted to insert, press Escape again, move the cursor back to where you left off copying, press Escape again, move the cursor right over the remainder of the line, and press Return.

And then Beagle Bros came out with GPLE and ushered us into the modern era of proper line editing. What a comparative luxury that was.

The BBC Micro has this and I believe it pre-dated the Amstrad

RISC OS for Archimedes/RISC PC also inherited this feature, although, as far as I can remember, you could only use it in CLI mode (after pressing F12 key) and not in windowed mode. My guess would be that the RISC OS version for the Raspberry Pi still has the copy cursor, in that case you could argue that there are even recent systems available with it.

I think tmux's scroll mode (ctrl-b [) is similar. You move the cursor freely and if in vi-mode, you can us vi commands (as if in visual mode) to select and copy (y) contents. Pressing 'enter' goes back to non-scrolling mode, and then you can paste the contents with the configured tmux keys.

You missed this bit (emphasis added):

> You could then press a "copy" key and it would copy one character at a time from the second cursor to your current editing position

Each time you pressed the "copy" key it would literally advance both the main cursor and the copy cursor by one character, with the copied character appearing under where the main cursor just was. To copy multiple characters you would need to press the copy key multiple times or hold it down to trigger autorepeat (even then you would see this process gradually happening until you released).

X11 still has a secondary selection mechanism that allows operations like swapping blocks of text. This was commonly used in Motif apps like Nedit.

The BBC Micro had that too, a 'copy cursor' and an 'insert cursor'. Worked pretty good too.