z80 Development Kit
You are not logged in.
When using getstr() there are written 2 unnecessary spaces to screen (behind the characters that are typed in). This may also affect the next line!
After you have compiled the test program add this lines to the generated P file and then RUN it
2 print "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"
3 print "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"
4 print "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"
200 rand usr 16514
300 goto 300
You will notice, that getstr() overwrites 2 more X than necessary.
And you will also notice, that the BASIC print position (behind the last X) does not match the print position (top left corner) used by the compiled C program (my other bug report about not matching print positions)
Siggi
//zcc +zx81 -startup=2 -create-app -vn -o test.bin test.c
#include <stdio.h>
void main(void)
{
char buffer[10];
gets(buffer);
}Last edited by siggi (2011-11-15 10:49:47)
Offline
This should be closed now, right ?
Offline
Not really.
The behaviour is the same: 2 characters ("_"+" ") are written to screen to enter 1 char (IMHO a "_" would be enough). That also affects the next line (when I want to enter a string of length 32 in the first line the next line is also affected(*) and the first characters are deleted :-( )
The only difference now is, that I can see the first character as "_" (was displayed also a SPACE before).
Or is the current behaviour the intended behaviour?
That is the latest test program:
//zcc +zx81 -startup=2 -create-app -vn -o testgets.bin testgets.c
#include <stdio.h>
#include <zx81.h>
void main(void)
{
char buffer[80];
printf("XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX");
zx_setcursorpos(0,0);
gets(buffer);
}Siggi
(*) That is part of another probem: when the last char of a line is printed, the print position moves immediately to the next line, making formating a text using "\n" complicated: when I do a
printf("32chars\n")
and then a
printf("....")
there is a blank line on screen, because "between" the last char and the "\n" the print position is already moved to the next line, so processing the "\n" does an additional linefeed :-(
And when I do a print to the lower right screen position, the screen scrolls up. Scrolling and automatic linefeed should only occur, when I want to print PAST the last column or screen position, not AT the last ...
Last edited by siggi (2012-03-13 09:16:40)
Offline
I see.. btw note that it is affecting gets only and it is a consequence of my attempt to show a cursor on every platform in a dummy way.
Perhaps I should just remove the cursor, on some platforms (i.e. on the osca the backspace character is not easy to get and the output is even worse).
Then, some target platform has its own hw cursor and this trick is a bit reductive in those cases.
Should I just get rid of it or try to fix ?
Offline
The cursor is "nice to have", but I lived long without any cursor on the Zeddy and was also happy ;-)
So if there is no cursor, that would be ok for me ...
But the other behaviour (too early scroll/auto-linefeed) should be solved (my current workaround is to use only 23 lines/31 chars) ...
Siggi
Offline
Well, I just excluded it in the source hiding the code behind an "IF def".. could you check it ?
Offline
I did. Thanks for the new ASCII conversion and the inverted capital letters :-)
The first impression was: OK.
But now the BACKSPACE does not work correctly: it can only be used to delete 1 char, not more characters.
And it leaves SPACES on screen: when I enter
"123BACKSPACE4"
I get on screen
"12SPACE4"
Siggi
Edit: same behaviour in ANSI mode, but "zx_setcursorpos(0,0);" has no effect ...
Last edited by siggi (2012-03-19 10:39:31)
Offline
My fault, I forgot part of the code for backspace. It should now do the backspace, type a space char and do backspace again..
Offline
Hmm, I just downloaded the latest build, but the behaviour is the same ...
?
Siggi
Offline
The lastest build is still wrong: backspace can now delete more than 1 char, but writes 2 spaces to screen (one too much) ...
Siggi
Edit: the current keyboard handling (ASCII-ZX81 conversion) is also strange: getchar() returns lowercase characters, in_Inkey() uppercase ...
Last edited by siggi (2012-03-23 14:03:22)
Offline
Today (using the current build) I also found, that after using BACKSPACE there is garbage in the edited buffer (contains char 8).
Here is a test program for ZX81, which shows the error:
//zcc +zx81 -startup=2 -create-app -vn -o testgets.bin testgets.c
#include <stdio.h>
#include <zx81.h>
#include <string.h>
void main(void)
{
int i;
char buffer[80];
printf("XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX");
zx_setcursorpos(0,0);
gets(buffer);
printf("\n\n\n");
printf("->%s<-\n", buffer);
printf("lenght=%d\n", strlen(buffer));
for (i=0; i < strlen(buffer); i++)
printf("char %d = %d\n", i, buffer[i]);
}Siggi
Offline
Here is a screencopy, made with my ZX81 running the test program:
HUHI xxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxx
->HUHI<-
LENGHT=12
CHAR 0 = 104
CHAR 1 = 117
CHAR 2 = 104
CHAR 3 = 117
CHAR 4 = 8
CHAR 5 = 8
CHAR 6 = 104
CHAR 7 = 117
CHAR 8 = 8
CHAR 9 = 8
CHAR 10 = 104
CHAR 11 = 105The buffer contains the complete edit-history (including char 8 for BACKSPACE). So currently using BACKSPACE in gets() is useless!
Siggi
Offline
Thankyou, now it is more celar..
So we have a functional bug *and* a visual bug.. are you concerned for both ?
Offline
stefano wrote:
are you concerned for both ?
Indeed.
Siggi
Offline
Could that problem be resolved within the near future?
I have written a web-browser for the ZX81 and would like to use the latest enhancements in ASCII-ZX81 character set conversion (to get less errors 404 when trying to get a file from the web with special characters in its name).
To avoid the BACKSPACE error (when entering the URL) I currently use an old z88dk version without that enhancements :-(
Siggi
Offline
Ok, you got the priority now ![]()
Offline
Thanks!
Siggi
PS: Here is the link to "ZeddyFox V1.0": http://forum.tlienhard.com/phpBB3/viewt … &t=714 ![]()
Offline
Should be fixed.
Forgive me, I preferred to let the cursor in.
Your test program was just perfect, I could also spot a couple of problems on the Spectrum and TS2068 console libs.
Offline
Thanks.
This problems seems to be solved
, but there is another one (SHIFTED CHARS, see other bug report).
Siggi
Offline
Glad to know this one is sloved !
Sorry for taking so lonk before understanding you.
Perhaps the next bug needs the insertion of the character code conversion routine.. we'll see.
Offline