I have a question about how the text works. When I call VputMap, what does it do? How does it display text. I know it is a symbol table, but how does it know the character length. How does it know that "cos(" is however many bytes or characters. I would like to see a disassembly of it. I know that the text is written to the screen, but how exactly? Every time I try to see flash page 1, with the address of 455Eh, but it always has page 06 swapped in, and I don't know how to change that through flash debugger. How do I change it to page 1, so I can see that address?
First of all, _VPutMap doesn't know anything about cos( — it displays characters, not tokens. The routine that actually converts tokens to characters is _Get_Tok_Strng, and _PutTokString presumably calls that and then _VPutS.
You don't need to know the details to figure out that it all involves looking things up in tables. How do fonts work? There's two sprite tables, for the small font and for the large. You display a character by indexing into the appropriate table and displaying the sprite stored there. How do tokens work? There's another table which stores the characters that make up each token. In this one, the entries vary in length, so I'm guessing that they're stored as strings with separators of some sort, and there is another table with pointers to each of the strings for easy access.
The easiest way to figure out how all of this is stored is to look it up in the .8xu file (just open it up in Wordpad, it's in hex already). The characters making up "cos(" are 63 6F 73 28.
Okay, another really quick question, about this. If I have a sprite location, in HL, and have the width of the sprite in a, which is probably less than 8, and the height in b, which is less than 8 for small fonts, and I can't use bcalls, what is a routine to have the number displayed? Oh, there is a LCDDelay, to loop for the lcd delay, and the x location is in d, and y is in e Help please? I have no idea? I mean, I know I can do something like this (psuedo code):
change to 8 bit mode set auto increment mode X to move down change row/column to de write the byte to the screen, and loop, until b is zero, so djnz.
Except the only way I can think of this, is to have 8 bytes of free ram somewhere, copy the current location to there, loop through those b bytes, doing an and mask for the width a, and then using "or" to copy the bytes, and then display it. But that seems like a lot of work, for such a little result. Is there a better way to do it?
You probably don't want to draw it directly to the LCD — you're right that writing code to do that is a lot of work, so we generally leave that to a single graph-buffer-copying routine, and only draw sprites to the graph buffer.
If the width of the sprite is less than 8, make it 8 for simplicity's sake (fill in the empty bits with 0 if you're using OR or XOR logic and it won't make a difference). Even then, unaligned sprite routines are a pain in the ass to write — a good assembly programmer should be able to write one, but probably won't have fun doing it. Read up on it here.