In extended colour mode:
For characters 32 to 63 on background 1 (53281/$D021 value), I can add 192 to get the same on background 2 (53282/$D022 value). For characters 64 to 95 on bg1, I can add 128 to get the same on bg2
...at least that's the theory. But I'm finding that character chr$(63) is falling in to the second set: so 63 + 128 = chr$(191) prints correctly, but chr$(255) doesn't? Not a biggy, I can workaround, but i'm reluctant to believe that the documentation is wrong especially as 64 seems to be a more sensible cutoff point than 63. This may be a Vice bug?
It looks like you're confusing the PETSCII values (CHR$()) for the screen codes that are used in display.
Screen codes 0-63 use background 0, 64-127 use background 1, 128-191 use background 2, and 192-255 use background 3.
There is not a 1:1 mapping between screen codes and PETSCII values. You can't take the ASC() value of a character and do something like CHR$(ASC("X")+64) to reliably get a screen code that happens to be 64 more, even though you may find some cases in which that might be true.
According to the manual in the ^RS command the second parameter sets the read/write position of the tag.
But in the description it says
For the ZD500R only: F0 to Fxxx (where xxx is the label length in
millimeters or 999, whichever is less)
But it also says
The printer prints the first part of a label until it reaches the
specified distance and then begins programming. After programming, the
printer prints the remainder of the label.
So I'm confused, the value in mm has to be the length of my entire label or the distance between the beginning to RFID tag?
I'm converting a Sinclair Spectrum 128 ZX +2 into a Raspberry Pi-powered computer and I'm using a Teensy 3.2 USB Development Board for mapping the original keyboard with the original membrane and get a normal USB keyboard. I'm not planning to maintain the original key mapping, probably I'll buy some stickers and I'll convert it in a UK keyboard.
I've reused the original ribbon connectors in this way:
5 Rows > Teensy Pins 1 to 5
8 Columns > Teensy Pins 6 to 13
(I noticed the disconnected cables after I took the photo, now fixed)
I've found a Teensy code for something similar online (thanks Chad Boughton) and I've tried to adapt it for the Sinclair, the first attempt was to simply check if all the keys were working.
Here the code: https://gist.github.com/federicocappelli/7f61d6bc2095cbc278df12519b721435
Briefly, I've created a fake keys matrix:
const byte ROWS = 5;
const byte COLS = 8;
char keys[ROWS][COLS] = {
{KEY_1,KEY_2,KEY_3,KEY_4,KEY_5,KEY_6,KEY_7,KEY_8},
{KEY_9,KEY_0,KEY_A,KEY_B,KEY_C,KEY_D,KEY_E,KEY_F},
{KEY_G,KEY_H,KEY_I,KEY_J,KEY_K,KEY_L,KEY_M,KEY_N},
{KEY_O,KEY_P,KEY_Q,KEY_R,KEY_S,KEY_T,KEY_U,KEY_V},
{KEY_W,KEY_X,KEY_Y,KEY_Z,KEY_ENTER,KEY_TILDE,KEY_DELETE,KEY_BACKSPACE}
};
byte rowPins[ROWS] = {1,2,3,4,5}; //connect to the row pinouts of the keypad
byte colPins[COLS] = {6,7,8,9,10,11,12,13}; //connect to the column pinouts of the keypad
But the result is not what I was expecting, for instance, pressing
spacebar the keyboard prints 12345678
u the keyboard prints 5cs
graph the keyboard prints 6d4b
I expected 1 character for one keypress.
What I am doing wrong?
Here the Sinclair service manual with the keyboard membrane explanation
The keyboard as reference:
if you're still interested by this topic,
I wrote a code to handle the ZXSpectrum+ specific Keyboard (compared to Legacy Spectrum) with an Arduino MICRO MCU.
only SYMBOL+A combo does still not work
based on the PDF that you sent...
ZXKeyb with arduino micro
I'm trying to create a script for Linux that will detect where the text cursor is. This should be done in maximum 1 second. In order to implement this, the best solution seems to be to programmatically add some text via xdotool, take a screenshot via some other utility, try to figure out the position of that text, and then remove the text we've inserted using xdotool again.
I tried inserting a random string (like <-- CURSOR HERE). Using Tesseract 4 it takes about 20 seconds to find the position of the string, although it's very precise in terms of pixel coordinates. I was not able to use whitelisting (in version 4 of Tesseract) to narrow result to specific letters or digits only, which I assume would speed up processing.
I don't know what font the user will be using, but every font has dashes and slashes, so I could create some sort of shape (for instance, |/\|/\|/\|/\|), and use some library to detect that shape. What would be a good choice?
I don't care about what's on the rest of the screen: it could be more text, images, etc. I only need o know where my random string is (<-- CURSOR HERE, |/\|/\|/\|/\|, or can you think of anything else), and get its X/Y position in pixels.
Code ^[[00;00m means reset color to default, however, in some programs (like source highlighter highlight for example) code ^[[m is used as if it would also serve the same purpose. What does ANSI state about such code, and also about similar ^[[0m?
"ANSI" in this context was obsoleted long ago by ECMA-48. So the appropriate place to start is that document.
Section 8.3.117 SGR - SELECT GRAPHIC RENDITION says
Notation: (Ps...)
Representation: CSI Ps... 06/13
Parameter default value: Ps = 0
SGR
is used to establish one or more graphic rendition aspects for subsequent text. The established aspects remain in effect until the next occurrence of SGR in the data stream, depending on the setting of the
GRAPHIC RENDITION COMBINATION MODE (GRCM). Each graphic rendition aspect is specified by a parameter value:
0
default rendition (implementation-defined), cancels the effect of any preceding occurrence of SGR in the data stream regardless of the setting of the GRAPHIC RENDITION COMBINATION MODE (GRCM)
That is, 0 is the default parameter if none is given (so ^[[m and ^[[0m mean the same thing. Repeating the parameter also makes no difference (cancelling something that was already cancelled does not uncancel it), so ^[[00;00m still means the same thing.