Interpreter: Enhance compatibility for Robins new favourite C64 One-Liner
Closed this issue · 8 comments
On youtube there is following video from "8-Bit Show And Tell":
https://www.youtube.com/watch?v=VC-lbd8mTOs&t=526s
With compiler and emulator I have no problem with the shown code, but with interpreter the output is other than expected. To see the differences I wrote following code:
0 poke53281,12
1 poke 199,0: rem rvs off
2 rem print chr$(146);
3 print chr$(155)+chr$(169)+chr$(151)+chr$(223)
5 poke 199,1: rem rvs on
6 rem print chr$(18);
7 print chr$(155)+chr$(169)+chr$(151)+chr$(127)
There are two problems:
- The output of chr$(223) is wrong. It should be the same as for chr$(127) (code 192-223 is identical to 96-127)
- POKE 199,1 has not the function "Reverse on"
I know that POKE 199 is not documented here, but it very near to 198 ;-)
And the output of Robin's (better said: Ian's) code is pretty !
You mean when executed in the BASIC shell application?
I did some changes to the BASIC shell, which should improve compatiblity and general behaviour. There's a general issue with casing in the component that's used for the shell, so that the input's casing isn't what you actually want on the "C64" side of things. I tried to handle this by converting back and forth, but it remains a bit clunky.
The shell now supports background colors (53281), setting text colors in 646 (but limited to the whole screen), RVSON und RVSOFF control codes as well as 199,x. Also CHR$(147) but not CHR$(19) yet.
It was never meant to be an emulator or C64 replacement, so the degree to which it can or will become compatible with the actual machine is limited.
Hello again,
regarding BASIC shell:
Probably we are talking about two different things. I was talking about the GUI, which is openend with run_gui.cmd. Since the compiling is done very fast, I assumed that this is a Interpreter.
Is there are seperate basic shell or do you mean the C64Screen ? The last change of C64Screen was 2017 ....
Regarding the emulator:
I do not expect a full emulator here, of course. Who needs a full emulator, should use one of the existing emulators. I read the description in CONSOLE SUPPORT.txt and assumed, that for a good programmer it should be no problem to implement "poke 199".
Regarding the changes:
when I start "java -Xmx256m -jar basicv2.jar" with bash and run the selected file, I can see no difference:
poke 199,1 is not working and chr$(223) is wrong. Are the really changes in the code ?
Oh, that thing...so, yes, we were talking about different things then. There's also a kind of interactive C64 like editor in the package, but there's no batch file to run it directly, because it's a bit flawed.
The thing you are were using is so old that I didn't even remember that it's still there...I'll have a look at it and see what I can do.
I modified the console's font mapping so that your test case seems to work fine now. I'm not sure, if this is sufficient though, because the font that I'm using to render the console output has the characters distributed all over the place and the mapping is quite difficult to do. Not even all chars exist in that font.
Much better now :-)
But there is still a small issue ...
My program for testing also includes pos():
0 poke53281,12
1 rem poke 199,0: rem rvs off
2 print chr$(146);
3 print chr$(155)+chr$(169)+chr$(151)+chr$(223);
4 print pos(0)
5 rem poke 199,1: rem rvs on
6 print chr$(18);
7 print chr$(155)+chr$(169)+chr$(151)+chr$(127);
8 print pos(.)
The problem is the output of pos() , which is " 2" (Space for the sign), and reverse on.
With compiler and emulator this space is dark (line 7), but with "Interpeter" it is blue.
But in both cases the color of the "2" is dark. Very strange ...
It doesn't matter whether poke or chr$() is used for reverse on.
That wasn't related to POS itself but to rendering inverse spaces. Should be fixed now.
Now it is perfect and this issue can be closed :-)