3 ms·

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 RA

by 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.
  - Doctor_Fegg 6y ago
    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.
tom_ 6y ago
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 https://tobylobster.github.io/mos/mos/S-s9.html#SP1
shdon 6y ago
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&story=MacPaint_Evolution.txt https://www.folklore.org/StoryView.py?project=Macintosh&stor...)

by unnah 6y ago

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

tom_ 6y ago

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 https://tobylobster.github.io/mos/mos/S-s9.html#SP1

shdon 6y ago

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&story=MacPaint_Evolution.txt https://www.folklore.org/StoryView.py?project=Macintosh&stor...)