missing colour 9 - bug or feature lack

[nitrofurano]

i did a test with the code below on both zmakebas (tokenizes zxspectrum-basic into a .tap file) and Boriel's zxbasic compiler, and it seems Boriel's compiler is missing colour 9 support:

Code:

10 border 0:cls
12 for i=22528 to 22528+767:poke i,int(rnd*128):next i
20 print at 2,1;ink 8;"transparency test - ink"
21 print at 3,1;paper 8;"transparency test - paper"
22 print at 5,1;ink 9;paper 8;"contrast test - ink"
23 print at 6,1;paper 9;ink 8;"contrast test - paper"
99 pause 0

and the result is this (imagemagick thumbnail link below):


while the tokenized version (using the zx-spectrum interpreter) seems to behave as predicted, the zxbasic-compiler version seems to take wrongly colour 9 (contrast) as colour 1 (blue).

what i'm seeing is that, somehow, zxbasic-compiler is not writing at the 23697 address (please check if i'm wrong), the bits 4 and 5 for ink (0x30), and 6 and 7 (0xC0) for paper - what contrast seems to do is, considering ink is 0 when paper is at least 4 (checking the green bit seems to be enough), and 7 when below 4 - and the same for paper related to ink (i just don't know why in the system variables it were using two bits instead of one, but i think this is up to that one coded the zx-spectrum rom) - i think when using '9' on 'ink' or 'paper' commands, these bits are switched on, and between '0' and '8' they are switched off, with some kind of 'bor' (0x30 for ink or 0xC0 for paper) or 'band' (0xCF for ink or 0x3F for paper)

i think now i found why this part of my library 'print64x32.bas' were not working:

Code:

if (peek (23697) band 16)<>0 then:v6=(v5 band 248) bor ((1-(v5 band 32)/32)*7):end if :'- colour 9 - ink
     if (peek (23697) band 64)<>0 then:v6=(v5 band 199) bor ((1-(v5 band 4)/4)*56):end if  :'- colour 9 - paper

thanks!

[boriel]

INK 9 is not implemented. Basically, INK 9 = INK 1.
INK 8 is implemented, on the other hand.
The same applies for paper.

ZX BASIC uses its own print routine, which is faster than the one in the ROM.
It allows ITALIC and BOLD, and OVER 2 and OVER 3.
Try:

Code:

PRINT BOLD 1; "Hello World"
PRINT ITALIC 1; "Hello World";
PRINT BOLD 1; ITALIC 1; "Hello World";

I will study whether to include INK/PAPER 9 and how, anyway.

[nitrofurano]

INK 9 is not implemented. Basically, INK 9 = INK 1.
INK 8 is implemented, on the other hand.
The same applies for paper.

ZX BASIC uses its own print routine, which is faster than the one in the ROM.
It allows ITALIC and BOLD, and OVER 2 and OVER 3.
Try:

Code:

PRINT BOLD 1; "Hello World"
PRINT ITALIC 1; "Hello World";
PRINT BOLD 1; ITALIC 1; "Hello World";

I will study whether to include INK/PAPER 9 and how, anyway.

thanks - i don't know how to help on it - i think this would be in the part of the code related to the ink/paper 8 - i don't know if my custom library, print64x32.bas , can be useful on helping it

btw, would be great if the 'italic' command could be renamed to 'oblique' or 'slant' - naming 'oblique' as 'italic' is a similar mistake as naming 'ellipse' as 'oval', when they are completelly different things (a mistake sadly used on Nodebox ( <!-- m --><a class="postlink" href="http://nodebox.net">http://nodebox.net</a><!-- m --> ), and fixed on Shoebot fork ( <!-- m --><a class="postlink" href="http://shoebot.net">http://shoebot.net</a><!-- m --> ) ) - maybe 'oblique', for example, being used by default, and deprecating 'italic' (for that people still using that), would be the best idea?

[nitrofurano]

meanwhile, i'm using this custom library, complementarily to my print64x32.bas:

Code:

'- library for the lack of colour 9 support on zxbasic-compiler (and also print64x32.bas library)
'- this library will be removed when 'ink 9' and 'paper 9' will be defaultly supported
sub ink9on()
  poke 23697,peek(23697) bor 48
  end sub
sub paper9on()
  poke 23697,peek(23697) bor 192
  end sub
sub ink9off()
  poke 23697,peek(23697) band 207
  end sub
sub paper9off()
  poke 23697,peek(23697) band 63
  end sub

[britlion]

btw, would be great if the 'italic' command could be renamed to 'oblique' or 'slant' - naming 'oblique' as 'italic' is a similar mistake as naming 'ellipse' as 'oval', when they are completelly different things (a mistake sadly used on Nodebox ( <!-- m --><a class="postlink" href="http://nodebox.net">http://nodebox.net</a><!-- m --> ), and fixed on Shoebot fork ( <!-- m --><a class="postlink" href="http://shoebot.net">http://shoebot.net</a><!-- m --> ) ) - maybe 'oblique', for example, being used by default, and deprecating 'italic' (for that people still using that), would be the best idea?

You're absolutely right - it's not technically another font, it's an oblique version of the current one. However, as wikipedia points out "In many computing interfaces, the text leaning effect is called Italic, whether or not an italic font is used to render the text." - there's a certain convention to doing this. I'd much rather it was called italic that people would understand and use, rather than oblique, which people might miss. Even if it's technically incorrect.

We can put a note on the web page for the command though

[nitrofurano]

btw, would be great if the 'italic' command could be renamed to 'oblique' or 'slant' - naming 'oblique' as 'italic' is a similar mistake as naming 'ellipse' as 'oval', when they are completelly different things (a mistake sadly used on Nodebox ( <!-- m --><a class="postlink" href="http://nodebox.net">http://nodebox.net</a><!-- m --> ), and fixed on Shoebot fork ( <!-- m --><a class="postlink" href="http://shoebot.net">http://shoebot.net</a><!-- m --> ) ) - maybe 'oblique', for example, being used by default, and deprecating 'italic' (for that people still using that), would be the best idea?

You're absolutely right - it's not technically another font, it's an oblique version of the current one. However, as wikipedia points out "In many computing interfaces, the text leaning effect is called Italic, whether or not an italic font is used to render the text." - there's a certain convention to doing this. I'd much rather it was called italic that people would understand and use, rather than oblique, which people might miss. Even if it's technically incorrect.

We can put a note on the web page for the command though

the problem, or danger, of naming oblique as italic is just like "telling a lie often to become a true", just like the indian castes, or people saying bullfight is tradition or culture, or even saying hackers are the same as crackers (like most of the "journalists" shamefully does, ignoring completelly about MIT hacker ethics), etc.. - in my oppinion, the only way to correcting this kind of mistake, specially when sadly it is becoming a convention, is doing our part on avoiding it, even when we are doing this alone

[britlion]

the problem, or danger, of naming oblique as italic is just like "telling a lie often to become a true", just like the indian castes, or people saying bullfight is tradition or culture, or even saying hackers are the same as crackers (like most of the "journalists" shamefully does, ignoring completelly about MIT hacker ethics), etc.. - in my oppinion, the only way to correcting this kind of mistake, specially when sadly it is becoming a convention, is doing our part on avoiding it, even when we are doing this alone

I honestly think that there's more likelihood of creating more confusion than less - most people won't understand because it's becoming a convention; so they'll lose access to such a nice feature.

More importantly, I also think this is such a small issue that I'd much rather Boriel spends his time getting new features into the compiler or making it faster than spending time renaming functions - and while he's at it, breaking all the code written that uses "italics" as well. That's just going to annoy programmers who will have to recode projects if they want them to work again.

[boriel]

I already know about the italic/oblique thing (someone in fact, documented that in the wiki already, and has been discussed here).
I neither compare it to such horrid thinks (e.g. the bullfight in Spain, and many spaniards -me included- think it should be banned nowadays, regardless its a "tradition") nor understand very well the relation to this matter. :?:

I just simply use Italic because as other people pointed, it's a most common used term (even in Word, the I is for oblique). Also the word Italic is much more known than Oblique. In Spanish we say "Cursiva", by the way. So don't know where this come from.

There are many other examples of mis-application of words. Ej. for Function Library, the mistranslation "Librería" (book shop) has been widely accepted insted of "Biblioteca", etc...

[nitrofurano]

the problem, or danger, of naming oblique as italic is just like "telling a lie often to become a true", just like the indian castes, or people saying bullfight is tradition or culture, or even saying hackers are the same as crackers (like most of the "journalists" shamefully does, ignoring completelly about MIT hacker ethics), etc.. - in my oppinion, the only way to correcting this kind of mistake, specially when sadly it is becoming a convention, is doing our part on avoiding it, even when we are doing this alone

I honestly think that there's more likelihood of creating more confusion than less - most people won't understand because it's becoming a convention; so they'll lose access to such a nice feature.

More importantly, I also think this is such a small issue that I'd much rather Boriel spends his time getting new features into the compiler or making it faster than spending time renaming functions - and while he's at it, breaking all the code written that uses "italics" as well. That's just going to annoy programmers who will have to recode projects if they want them to work again.

that's why i suggested the deprecation - the focus on 'oblique', and using 'italic' as alias, showing a kind of error message while compiling, but compiling anyway

I already know about the italic/oblique thing (someone in fact, documented that in the wiki already, and has been discussed here).
I neither compare it to such horrid thinks (e.g. the bullfight in Spain, and many spaniards -me included- think it should be banned nowadays, regardless its a "tradition") nor understand very well the relation to this matter. :?:

the relation is only just another example of "lies told often becoming true", i just cited some examples about that, and that about 'ellipse vs oval' situation were also included there

I just simply use Italic because as other people pointed, it's a most common used term (even in Word, the I is for oblique). Also the word Italic is much more known than Oblique. In Spanish we say "Cursiva", by the way. So don't know where this come from.

There are many other examples of mis-application of words. Ej. for Function Library, the mistranslation "Librería" (book shop) has been widely accepted insted of "Biblioteca", etc...

well, "Word" (from Microsoft) is a specialist on making (and spreading) mistakes, see MSDN for example, they are struggling all the time on that huge and redundant documentation they pretend to write - Microsoft is just a joke, and i think they must not be took seriously! - and see also a list of mistakes Microsoft also helped a lot on spreading: http://www.gnu.org/philosophy/words-to-avoid.html