Posts: 92
Threads: 8
Joined: Mar 2011
Reputation:
0
10-03-2022, 08:18 PM
(This post was last modified: 04-04-2023, 08:57 PM by boriel.)
Code: Declare sub CenterText (ByVal Row as ubyte, ByVal Text as string)
Ink 6
Paper 1
Print at 20, 0; "\k";
Ink 7
Paper 0
'Print ; 'Put here to update colors, there is a bug in the compiler.
CenterText (21, "Hello")
Sub CenterText (ByVal Row as ubyte, ByVal Text as string)
Dim i As UInteger
i = Len(Text) / 2
i = 16 - i
Print at Row, i; Text;
End sub
Hi there Boriel.
The above code does not work correctly, both the "K" and the word "Hello" come out with blue paper and yellow ink unless you unrem the print statement. Then the "Hello" comes out with black paper and white ink.
This was not a problem before, this is a recent problem. I can use this "print" workaround for the time being but there is a bug in the complier.
Posts: 1,770
Threads: 55
Joined: Aug 2019
Reputation:
24
10-04-2022, 06:54 AM
(This post was last modified: 10-04-2022, 06:57 AM by boriel.)
Posts: 92
Threads: 8
Joined: Mar 2011
Reputation:
0
(10-04-2022, 06:54 AM)boriel Wrote: Hi, Darkstar!!!
Glad to see you here.
What version are you using? I upgraded the PRINT routine recently...
Try this version, btw:
http://www.boriel.com/files/zxb/zxbasic-...ta5.tar.gz
http://www.boriel.com/files/zxb/zxbasic-...-beta5.zip
http://www.boriel.com/files/zxb/zxbasic-...-win32.zip
http://www.boriel.com/files/zxb/zxbasic-...x64.tar.gz
http://www.boriel.com/files/zxb/zxbasic-...cos.tar.gz
I am using 1.16.3 and I tried 1.16.4-beta5 or the version you supplied now thank you very much with the same results, both of the outputs are blue paper and yellow ink so this did not fix the problem sadly. I noticed you said that you made the print routine smaller and faster, you must have introduced a bug. It was working fine before.
Posts: 1,770
Threads: 55
Joined: Aug 2019
Reputation:
24
(10-04-2022, 09:44 AM)Darkstar Wrote: (10-04-2022, 06:54 AM)boriel Wrote: Hi, Darkstar!!!
Glad to see you here.
What version are you using? I upgraded the PRINT routine recently...
Try this version, btw:
http://www.boriel.com/files/zxb/zxbasic-...ta5.tar.gz
http://www.boriel.com/files/zxb/zxbasic-...-beta5.zip
http://www.boriel.com/files/zxb/zxbasic-...-win32.zip
http://www.boriel.com/files/zxb/zxbasic-...x64.tar.gz
http://www.boriel.com/files/zxb/zxbasic-...cos.tar.gz
I am using 1.16.3 and I tried 1.16.4-beta5 or the version you supplied now thank you very much with the same results, both of the outputs are blue paper and yellow ink so this did not fix the problem sadly. I noticed you said that you made the print routine smaller and faster, you must have introduced a bug. It was working fine before.
Okay, I'll check it this evening and keep you posted 
Posts: 92
Threads: 8
Joined: Mar 2011
Reputation:
0
I just checked it with 1.16.0, before you made the changes to the print routine and the bug is there. It means that the bug got introduced before you made the changes to the print routine so now you know where not to look. I am looking forwards to hearing from you and have this matter resolved. Thank you.
Posts: 1,770
Threads: 55
Joined: Aug 2019
Reputation:
24
The print changes were introduced in 1.16.0!
Indeed that was one of the updates from 1.15 to 1.16. I'm on it. 
Posts: 92
Threads: 8
Joined: Mar 2011
Reputation:
0
(10-05-2022, 07:01 AM)boriel Wrote: The print changes were introduced in 1.16.0!
Indeed that was one of the updates from 1.15 to 1.16. I'm on it.
I tested 1.15.2 and the bug was there so it must have happened before 1.16.0. You state in your changelog that you changed the print routine in 1.16.1 so you are contradicting yourself. The print routine is just likely incomplete as it does not reflect some changes that you have made to the core codebase, but the print routine is just fine under the old conditions.
I had a color bug myself as I was compiling my program under the new version of the complier, it was not updating the color when I was tripple buffering. I had to change the code from this:
Code: Sub fastcall SetScreen (ScreenPtr as uinteger)
Asm
ld (.core.SCREEN_ADDR), hl
End asm
End sub
To this:
Code: Sub fastcall SetScreen (ScreenPtr as uinteger)
Asm
ld (.core.SCREEN_ADDR), hl
ld de, 6144
Add hl, de
ld (.core.SCREEN_ATTR_ADDR), hl
End asm
End sub
This might give you a clue.
This makes me wonder if other statements like DRAW, PLOT, CIRCLE have this bug as well. I hope you figure it out.
Posts: 1,770
Threads: 55
Joined: Aug 2019
Reputation:
24
Could be. I fixed this exact issue a long while ago.
Probably it's a regression bug (a repeated one), related to code generation, not to IO routines themselves: I was refactoring the code generation to move forward into ZX Basic 2.x and that requires deep changes whilst preserving backward compatibility.
I will fix it and add some tests cases to prevent this to happen again.
This code snippet and the fact that it happened in 1.15.2 really helped me. That narrows down the search scope a lot. Thanks!
Posts: 92
Threads: 8
Joined: Mar 2011
Reputation:
0
Last good known version is version 1.14.1.
Your welcome.
Posts: 1,770
Threads: 55
Joined: Aug 2019
Reputation:
24
10-07-2022, 10:53 PM
(This post was last modified: 10-07-2022, 11:04 PM by boriel.)
Posts: 92
Threads: 8
Joined: Mar 2011
Reputation:
0
10-08-2022, 01:36 AM
(This post was last modified: 10-08-2022, 02:02 AM by Darkstar.)
(10-07-2022, 10:53 PM)boriel Wrote: Ok, Can you try this new version, plz?
If possible, please try it extensively (I did already, even with drawing primitives, but a 2nd look is always welcome).
http://www.boriel.com/files/zxb/zxbasic-...ta6.tar.gz
http://www.boriel.com/files/zxb/zxbasic-...-beta6.zip
http://www.boriel.com/files/zxb/zxbasic-...-win32.zip
http://www.boriel.com/files/zxb/zxbasic-...x64.tar.gz
http://www.boriel.com/files/zxb/zxbasic-...cos.tar.gz
This is partially fixed but not completely. The print routine works fine but when I tried it on a bigger project that tripple buffers I found out that it was not updating the screen colors as it should. The:
Code: Sub fastcall SetScreen (ScreenPtr as uinteger)
Asm
ld (.core.SCREEN_ADDR), hl
ld de, 6144
Add hl, de
ld (.core.SCREEN_ATTR_ADDR), hl
End asm
End sub
workaround does not work anymore. There are portions of the screen instead of coming of as paper blue ink yellow they are coming of as paper black in white and in on sections the color flickers on one graphical item. The print routine as a standalone works fine but the rest is a mess as before. So this did not fully fix things.
I did not check PLOT, DRAW and CIRCLE as I assume that they are ok and as I said, this is not a full fix.
Posts: 92
Threads: 8
Joined: Mar 2011
Reputation:
0
Correction, the workaround still does work, it was a mistake on my part sorry. That should be a clue.
Posts: 1,770
Threads: 55
Joined: Aug 2019
Reputation:
24
10-08-2022, 08:04 AM
(This post was last modified: 10-08-2022, 08:24 AM by boriel.)
Thus, the print routine does work, but from time to time you have to "reset" the screen buffer with that buffer pointers, isn't it?
Let me check that part...
EDIT: If you have any short code snippet to reproduce it, please send it to me (even privately), as it will help me a lot.
Many thanks, again!
EDIT2: Does your project scroll the screen or reach the end of the screen?
Posts: 92
Threads: 8
Joined: Mar 2011
Reputation:
0
10-08-2022, 08:37 AM
(This post was last modified: 10-08-2022, 08:41 AM by Darkstar.)
(10-08-2022, 08:04 AM)boriel Wrote: Thus, the print routine does work, but from time to time you have to "reset" the screen buffer with that buffer pointers, isn't it?
Let me check that part...
EDIT: If you have any short code snippet to reproduce it, please send it to me (even privately), as it will help me a lot.
Many thanks, again!
I am sorry but I don't have any short code snippets to share as this is tied up in a big file. Yes, it looks like you have to reset the buffer pointers from time to time. It goes against the basic premise of just having to set the pointer once to the base of the screen memory and forget about it. This was not a problem in 1.14.1 as everything worked fine there including the print routine and the namespaces were old style and gosub was allowed between subs and functions. Meaning that 1.14.1 was the last of the workable old style versions and as such I think I going to hang on to that as I use the newer versions in my newer projects. The compiler is coming along nicely getting more professional as time goes on, keep up the good work and I am sorry I could not be of more help this time around.
"EDIT2: Does your project scroll the screen or reach the end of the screen?"
No it does not, just uses the entire screen memory and prints to it according to the screenptr and then copies between screen buffers. I have three screens set up in memory, one is at address 16384 the other two are above that as you might suspect. It prints on the other two.
Posts: 1,770
Threads: 55
Joined: Aug 2019
Reputation:
24
10-09-2022, 06:30 PM
(This post was last modified: 10-09-2022, 06:34 PM by boriel.)
That's weird: the "system variable" core.SCREEN_ADDR is initialized with 16384, and core.SCREEN_ATTR_ADDR with 22528 respectively, and they are not modified anymore (in other words, all the instructions using these variables are read-only).
Are you sure that it's the PRINT routine? couldn't it be that a third party is corrupting that variable in some way?
|
