4 ms·

Random Amstrad memory: When you were coding in BASIC, I don't think there was clipboard but there was a way to get a second cursor to appear that you could pos

Random Amstrad memory: When you were coding in BASIC, I don't think there was clipboard but there was a way to get a second cursor to appear that you could position with the (I think) arrow keys somewhere else on the screen. 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. It's weird thinking back to when you didn't have a proper IDE. Has a similar UI been seen on a computer before this? There's a "copy mode" in Screen for Linux that has similarities.

ggrrhh_ta 6y ago
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.
- quietbritishjim 6y ago
  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).
goatinaboat 6y ago
The BBC Micro has this and I believe it pre-dated the Amstrad
- blywi 6y ago
  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.
unnah 6y ago
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.
- seanwilson 6y ago
  Cool, that's a pretty weird/neat hack. How come you know about how it was implemented?
  - unnah 6y ago
    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/ 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"
- Doctor_Fegg 6y ago
  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.
  - seanwilson 6y ago
    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.
colanderman 6y ago
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.
jacquesm 6y ago
The BBC Micro had that too, a 'copy cursor' and an 'insert cursor'. Worked pretty good too.
kevin_thibedeau 6y ago
X11 still has a secondary selection mechanism that allows operations like swapping blocks of text. This was commonly used in Motif apps like Nedit.

ggrrhh_ta 6y ago

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.

quietbritishjim 6y ago
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).

goatinaboat 6y ago

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

blywi 6y ago
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.

unnah 6y ago

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.

seanwilson 6y ago
Cool, that's a pretty weird/neat hack. How come you know about how it was implemented?
- unnah 6y ago
  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/ 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"
Doctor_Fegg 6y ago
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.
- seanwilson 6y ago
  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.

colanderman 6y ago

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.

jacquesm 6y ago

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

kevin_thibedeau 6y ago

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