Color control codes

[LCD]

Hallo boriel, you wrote, the control codes can be used like in BasIn, I tested it:

Code:

print at 0,0;"\{i7}\{p2}\{b1}Test"

works fine, but BasIn allows this too:

Code:

print at 0,0;"\{i7p2b1}Test"

which does not work. Is this a bug?

The escape sequences for control characters are as follows:
\{in}
Ink colour n, where n is in the range 0 to 7.
\{pn}
Paper colour n, where n is in the range 0 to 7.
\{bn}
Bright n, where n is 0 or 1.
\{fn}
Flash n, where n is 0 or 1.
Note: Control character escape sequences can be combined, so that for instance \{i6p1f1} is equivalent to \{i6}\{p1}\{f1} - flashing yellow ink on blue paper.

Btw: Release 1.2.1 is excellent. My latest test Program needed 8 Kb before, now it is only 4 Kb...

[boriel]

Hallo boriel, you wrote, the control codes can be used like in BasIn, I tested it:

Code:

print at 0,0;"\{i7}\{p2}\{b1}Test"

works fine, but BasIn allows this too:

Code:

print at 0,0;"\{i7p2b1}Test"

which does not work. Is this a bug?

Yes: Didn't know BASIN allowed that. Which version do you have?
I will implement it, anyway.

Btw: Release 1.2.1 is excellent. My latest test Program needed 8 Kb before, now it is only 4 Kb...

Errr. It needs 4Kb less to load, but once run, the HEAP zone will be created and it will take another 4Kb (Heap is the temporary memory for string management). So you ended up using 8kb again. In the next releases a new flag for the heap will be used so you can specify a 1024bytes heap, etc.

[LCD]

Hallo boriel, you wrote, the control codes can be used like in BasIn, I tested it:

Code:

print at 0,0;"\{i7}\{p2}\{b1}Test"

works fine, but BasIn allows this too:

Code:

print at 0,0;"\{i7p2b1}Test"

which does not work. Is this a bug?

Yes: Didn't know BASIN allowed that. Which version do you have?
I will implement it, anyway.

Release 15 beta, but it was implemented earlier. It was described in chapter "the .bas file format". There are also other escape sequences like Puond Sterling code too...

Btw: Release 1.2.1 is excellent. My latest test Program needed 8 Kb before, now it is only 4 Kb...

Errr. It needs 4Kb less to load, but once run, the HEAP zone will be created and it will take another 4Kb (Heap is the temporary memory for string management). So you ended up using 8kb again. In the next releases a new flag for the heap will be used so you can specify a 1024bytes heap, etc.

This is what I expected, 4K less to load is still very good result... I hope, the heap does not go over 49152, because this will surely cause a nice crash if I switch the bank on Spectrum 128 .

[LCD]

Now BorIDE can calculate the available free space correctly, after compilation. If you find some time (next month, I suppose), boriel, please check the colour codes again, in
print at 0,0;"\{i7p2b1}Test"
as it still refuses to work :wink:
maybe for 1.2.6 Final?

[boriel]

Now BorIDE can calculate the available free space correctly, after compilation. If you find some time (next month, I suppose), boriel, please check the colour codes again, in
print at 0,0;"\{i7p2b1}Test"
as it still refuses to work :wink:
maybe for 1.2.6 Final?

This is not implemented yet. Only:

Code:

print at 0,0;"\{i7}{p2}{b1}Test"

Is this BASIN compatible?
I will try this weekend, but the @label bug is more important at the moment.

[LCD]

Now BorIDE can calculate the available free space correctly, after compilation. If you find some time (next month, I suppose), boriel, please check the colour codes again, in
print at 0,0;"\{i7p2b1}Test"
as it still refuses to work :wink:
maybe for 1.2.6 Final?

This is not implemented yet. Only:

Code:

print at 0,0;"\{i7}{p2}{b1}Test"

Is this BASIN compatible?
I will try this weekend, but the @label bug is more important at the moment.

Quote from BasIN instruction as in the first post:

so that for instance \{i6p1f1} is equivalent to \{i6}\{p1}\{f1}

I understand that the @label bug is more important, so I wrote that this color codes are not THAT important. It was just that over one year ago you said, you will implement it anyway :wink:. No need to hurry. It was just a question :mrgreen:

[britlion]

I understand that the @label bug is more important, so I wrote that this color codes are not THAT important. It was just that over one year ago you said, you will implement it anyway :wink:. No need to hurry. It was just a question :mrgreen:

2.5 years ago Wow. Has some stuff really been that long?

[LCD]

I understand that the @label bug is more important, so I wrote that this color codes are not THAT important. It was just that over one year ago you said, you will implement it anyway :wink:. No need to hurry. It was just a question :mrgreen:

2.5 years ago Wow. Has some stuff really been that long?

Oh, that long already? Oh my god!!!