![]() |
missing colour 9 - bug or feature lack - Printable Version +- Forum (https://www.boriel.com/forum) +-- Forum: Compilers and Computer Languages (https://www.boriel.com/forum/forumdisplay.php?fid=12) +--- Forum: ZX Basic Compiler (https://www.boriel.com/forum/forumdisplay.php?fid=11) +---- Forum: Bug Reports (https://www.boriel.com/forum/forumdisplay.php?fid=15) +---- Thread: missing colour 9 - bug or feature lack (/showthread.php?tid=398) |
missing colour 9 - bug or feature lack - nitrofurano - 11-03-2011 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 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 thanks! ![]() Re: missing colour 9 - bug or feature lack - boriel - 11-03-2011 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" Re: missing colour 9 - bug or feature lack - nitrofurano - 11-03-2011 boriel Wrote:INK 9 is not implemented. Basically, INK 9 = INK 1. 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? Re: missing colour 9 - bug or feature lack - nitrofurano - 11-04-2011 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) Re: missing colour 9 - bug or feature lack - britlion - 11-04-2011 nitrofurano Wrote: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 ![]() Re: missing colour 9 - bug or feature lack - nitrofurano - 11-04-2011 britlion Wrote:nitrofurano Wrote: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? 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 Re: missing colour 9 - bug or feature lack - britlion - 11-04-2011 nitrofurano Wrote: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. Re: missing colour 9 - bug or feature lack - boriel - 11-04-2011 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... Re: missing colour 9 - bug or feature lack - nitrofurano - 11-04-2011 britlion Wrote:nitrofurano Wrote: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 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 boriel Wrote:I already know about the italic/oblique thing (someone in fact, documented that in the wiki already, and has been discussed here). 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 boriel Wrote: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. 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! ![]() |