I have a 12x12 sprite, and it occurred to me that it might be easier to write the sprite to the LCD in 6-bit mode. How does doing this differ from normal 8-bit writing? And do the vPutS bcall work the same in 6-bit mode?

I would like some help writing a routine to draw a 12x12 sprite to the LCD, in 6-bit mode, at coords passed as a parameter to the routine. By help, i just mean someone to answer questions I may have along the way. I really want to attempt to do the coding myself. It's about time I learn this.

Edit: First question. I need the internal pointers explained. First off, in X increment mode, we know the X increments itself every time a write instruction is sent. But, say I then increment the row. The X pointer does not move back, does it?

In that case, the pointer won't move.
It moves only after a Read or Write instruction to the LCD data port ( $11 )


I can thank you : you made me realize there was a mistake in my fastercopy routine

So basically, once you hit the end of a "row" you have to set the next row, and move to the start of the column again manually? Below is some code I started writing to do this. It's a 12x12 sprite. I don't assume its done, but am I on the right track?


Code:

I don't understand something :
why out($10),a twice ?


Code:

I'm supposed to be writing the X coord and the Y coord to the column/row thing, but i realized, i forgot to load in the Y before doing out ($10),a again.

Code revision:


Code:

I think you forgot an "inc hl" after "ld a,(hl)"
and I suggest to replace the drawSprite_innerloop with 2x "ld a,(hl) / out ($11),a / inc hl"

How many out(), this routine needs ? Perhaps you'd need less if you choose another way of writing (I mean : column by colum)

I tend to prefer X increment mode. In this case, would using Y-dec make anything easier? This is my first attempt writing my own LCD routine, so I'll defer on that.

Yes, I prefer using row-increment because it just needs 2*(2+12)=28 out()
Your version needs 12*(2+2)=48 out(),
But you can see this manner later, succeeding in writing/debugging your 1st own sprite routine is the most important thing
By the way, did you add the missing "inc hl" ?

Yes, I did. Here's what the routine now says:


Code:

Seems okay, now...except "add $20" which does not exist among z80 mnemonics : add a,$20 is correct.
Do you know the instruction outi ? It's a kind of " out(c),(hl) / inc hl / dec b "
Thus, It could replace "ld a,(hl) / out ($11),a / inc hl "

Did not know about outi, but I shall use it.
Byte to write = hl, port to write = c? That correct?

Also, another question, related to this. Does bcall(_vPutS) and other text-placing bcalls work properly in 6-bit mode, or will using those calls reset to 8-bit mode?

The OS always expects the LCD to be in 8-bit word mode, and you can't mix 6-bit and 8-bit rendering. So all OS (and basically all third-party) drawing code is off limits if you're using 6-bit word mode.

Why are you drawing a sprite directly to the screen, anyways? Buffered graphics are almost always the correct way to go from most perspectives, including visual quality, speed, and ease of implementation.

Understood, to the first part.

To the second part: in all honesty, i figured its easier to write sprite to LCD within the context of my program, instead of sprite to buffer then buffer to LCD, including having to make two routines instead of one. And the second reason... I just wanted to write my own LCD writing code.

So I attempted to debug this program and saw in the emulator that instructions that should be changing the HL register actually don't. Even something simple like 'ld hl,address'. Thinking that this might be an emulator bug, I decided, against my better judgement, to try the program on my actual device. Ever since doing so, every attempt to send a file to my calculator returns a "serious communications error" in TI Device Explorer and "incompatible device" in tilp2. What did I do to my OS? I've tried reinstalling the OS, to no avail. Anyone can tell me a more radical way of purging/reinstalling?

http://pastebin.com/RLHtpsjt

That is my most recent source code.

bump. I did manage to get one file transfered successfully, but then it went right back to the aforementioned error.

If by the "aforementioned error" you mean the emulator issues, I'm not sure what's up with that. But glancing at the drawing routine in your code, shouldn't add a,$79 on line 484 be add a,$7F?

EDIT: Also, outi decrements B, so that's messing with your loop counter. With two outi's and the djnz, B is decremented by 3 each iteration, so a simple fix would be to initialize B to 12*3.

By aforementioned error, im referring to my inability to transfer files (see 3 posts up). And oh, didnt realize outi decrements b. And why $7F?

I had troubles with usb connections (I'm using TILP2 too) . I found it was USB3.0 (xhci) . I deactived xhci in bios menu, then everything's okay, now