Yeah I know, I was responding to willrandship's concern about horizontal scanlines being produced by the LCD.

By the way, will the vertical LCD make it harder to display sprite data? Will the sprite binary/hexadecimal data have to be rotated in ASM/Axe source code in order to display fine?

Data can be displayed in either direction, but displaying vertically will likely be easier due to only needing 8-bit coordinates for the output window. Also, displaying vertically is pretty much a must for games that abuse horizontal scrolling if the sprites are going to wrap around GRAM properly.

TilEm does support 160x240 mode, yes.  Most of the documented LCD controller features are supported at this point; some of the undocumented features still need to be tested.

As far as sprite orientations are concerned: in most cases, you should be able to store the sprite in whatever orientation you like, and flip/rotate it by switching the output mode as desired.  As for the case of wrapping around that calc84maniac mentions: that's one of the undocumented features I still need to explore.

Actually, for the wrapping around, I'm referring to having a window of (y1,y1+height-1) and (0,319). If you draw vertically, you'll wrap around after 319 (not undocumented at all).

Ah yes, good point.

However, from what I saw on the SVN, you may not be clipping LCD coordinates to 8-bits or 9-bits upon write. Any bits listed as 0 in the data sheet is forced to 0 (i.e. writes are ignored). This should be useful for some code optimizations, I think.

Ooh, excellent observation, you're right, I forgot to do that (although, for most of the registers, it shouldn't make any difference in practice.)  This also suggests an obvious test for undocumented registers/bits, and indeed there are several:

 - R04 (undocumented on 9335) has the significant bits 0777.  (On the 9325 this is the "resizing control" register and ought to have significant bits 0333.  So maybe the 9335 allows resizing after all, and maybe it even has more modes than the 9325?  On the 9221 this is one of the two comparison registers and should have significant bits 3F3F.)
 - R05 (as documented) has the significant bits 0003, though as I've noted elsewhere it doesn't seem to have the documented effect.  (On the 9221 this is the other comparison register and should have significant bits 003F.)
 - R06 (not documented anywhere that I know of) has the significant bit 0001.
 - R10 has the significant bits 1717; according to the docs it should be 17F3. (edit: not true, it's just that reading registers doesn't work correctly when the STB bit is set.)
 - All of RE2-REF, RFE, and RFF have some significant bits; of these, only RE6 is documented.

Indeed.  The only way I've found to exit "panic mode" is to toggle STB on and off (maybe SLP would work as well.)  I think this is the controller's way of saying it doesn't like what you're doing.

It seems that it does indeed have a resizing function, but it doesn't work reliably (sometimes it works correctly, sometimes it draws a few pixels and then panics.  Something to do with timing, I guess.)  I'm not sure exactly what all the resizing modes are doing, but all 7 modes are down-scaling.  And when they do work, they apparently work by simple resampling (dropping pixels, not doing any sort of averaging), so it really is a basically useless feature.

What is this calcsysX I keep hearing about?

I've been working on a port of Calcsys, but for the time being it's on the back burner as we wait for the SDK.

I've been working on a port of Calcsys, but for the time being it's on the back burner as we wait for the SDK.

Is there an official SDK coming out (Flash Debugger?) or do you mean a community one? (Such as the one with Doors CS and WabbitCode)

Also an example of fast pure BASIC graphics using this mode, in case people didn't see it. This takes 5 seconds to generate (although it's not a tilemap, so it's a bit limited, but it only uses drawing commands):