/* This is a simple demonstration file for the Zeus assembler. If you want more sustantial files they're available at www.desdes.com Defining graphics characters. This happens enough to be worth some support, so versions of Zeus after 2.10 understand a DG pseudo-op which makes defining character sets easier; the format is probably best described with examples: This is a typical character defined using the binary prefix. I think you'd agree that without the comments it would be hard to see what the character actually looked like... db %00010000 ; * db %00111100 ; **** db %01010000 ; * * db %00111000 ; *** db %00010100 ; * * db %01111000 ; **** db %00010000 ; * db %00000000 ; Using the DG pseudo-op can make this much clearer: DG takes "." "_" or "-" as indicating a zero bit, and any other character (aside from comments of course) as a one bit. It ignores spaces, use them for formatting if you like. So, from v2.10 onwards that same character could be represented using DG as: dg ...x.... dg ..xxxx.. dg .x.x.... dg ..xxx... dg ...x.x.. dg .xxxx... dg ...x.... dg ........ Or by: dg ...0.... dg ..0000.. dg .0.0.... dg ..000... dg ...0.0.. dg .0000... dg ...0.... dg ........ Or by: dg ---X---- dg --XXXX-- dg -X-X---- dg --XXX--- dg ---X-X-- dg -XXXX--- dg ---X---- dg -------- Or by: dg ___@____ dg __@@@@__ dg _@_@____ dg __@@@___ dg ___@_@__ dg _@@@@___ dg ___@____ dg ________ And so on... Zeus won't allow you to use spaces for zero bits because doing so would make it impossible for Zeus to determine the character width, or to check you hadn't missed a pixel. Right, now I have you believing that I'll admit it's just that I couldn't be bothered to delve into the parser - it normally discards spaces before the rest of the assembler gets to see them and if I wanted to use spaces here I'd have to tell it not to do so... If your character is more than 8-bits wide just carry on across the line, but you MUST specify a mutiple of 8-bits or zeus will regard the definition as invalid. dg ______@@________ dg ____@@@@@@@@____ dg ___@@__@@_______ dg ____@@@@@@______ dg ______@@__@@____ dg __@@@@@@@@______ dg ______@@________ dg ________________ The pixels in a byte are planted with the LHS as the most-significant bit, and multiple bytes are planted LHS byte first. This is the format that most VDU's and programmers would expect; if there are machines or applications out there which would benefit substantially from a different format email me with details and I may add the required options to support it. */