There might be a hardware issue. I'd suggest implementing a hardware check for some of the more obscure stuff you do in the emulator just to see if it really is the hardware. I'm suggesting, because it works on some people's calcs, and not others.

Just an idea to throw out at ya.

EDIT: Maybe the differing bootcode versions on these calcs might be telling of this difference, but all these ideas are just speculations at the moment. I'd trust you would have the resources and the time to actually test them all out.

[...]
When you talked about changing buffers stuff, I had an idea that I don't know what could bring in real implementation.
The idea is to make in pairs of two bytes with dark and light layer:
(x1,y1)dark , (x1,y1) light , (x2,y1)dark , (x2,y1)ligh ...

To get the light layer is just inc hl...

(to prevent the page from getting too long, much stuff was omitted,but the post can still be referenced)

When I say that the gray buffer is interleaved, what is quoted is exactly what I mean. Except that the buffer is also vertically aligned: (x1,y1)dark, (x1,y1)light, (x1,y2)dark, (x1,y2)light, ...

[...]
edit:
what size are the tiles and why do you need masks to merge the prerotated tiles?

The tiles are 16*16, but they'll be treated as 8*16 for the purposes of the tilemapper.
I'm using masks to put together the prerotated tiles to achieve horizontal scrolling. Say that the tileset has been rotated 4 times so far (to provide the illusion of moving to the side 4 pixles). The line of the tile on the left reads  %11011011 and the first line of the tile on the right side reads %01010101. The mask will be %11110000 and after the merge, the byte will read %11010101. I assume there's a faster way?

Okay. I've run into massive problems with regard to the tilemapper. Simply put, I just don't have the CCs needed to run it without a degradation of grayscale quality, or some serious slowing. Only a few solutions present themselves:

1. Change interrupt scheme. Previously, everything's being run in the interrupt. This could change so that the "main code" would contain the tilemapper

2. Reduce framerate further to fit in the interrupts. This calls for 14FPS and a doubling up of scrolling, so it'll scroll 2 pixels at a time.

3. Restrict this project to the 83+SE/84+(SE) calculators, to take advantage of the 15MHz clock and the spare RAM.

4. Just keep trying again and again to accelerate the tilemapper. Currently, I'm using prerotated tiles with two masks to merge the tiles to achieve horizontal scrolling. The specific logic is the follows: " ld a,(de) \ and b \ xor (hl) \ and c \ xor (hl)" to achieve the sprite. C the logical not(B). Enlightening me on alternative schemes would be of best help. Currently, the tiles are interleaved and the buffer is the same, and is also vertically aligned, so if this was a simply aligned version, it would be a few LDIRs to the buffer.

Help would be appreciated in this respect.

Quick question: What's being run during the waste cycles between LCD writes? I was suspecting instructions, but maybe sound? I know you have around 180CCs that you can use, so what izzit?

For making something using an engine that you've previously written, you should not have announced that you were making something from it prior to this contest. If you can say no one really knows about this engine, then it should be fine to make a contest entry from it.

This question was already answered in the topic immediately below this one, in fact (as of this writing).

http://ourl.ca/3390

Next time you ask for help, you might want to peruse the first page of the help and support section. I won't suggest the forum's search bar, since I've never gotten anything good from that. If you *must* search yourself, try giving Google a spin. "grayscale TI-83 Plus" is a good start.

You're going to want to ask DJ Omnimaga personally. Or wait until he posts.

As far as I've gathered, Illusiat is a series of text-based RPGs that the creator of this here community, DJ Omnimaga, has ... well... created. Illusiat 13 is the latest one he's working on. This upcoming RPG keeps well with the spirit of the others by being text-based, but to hell if that doesn't make it great.

In fact, DJ Omnimaga has been well known to make ASCII graphics look sexy. See teh screenshots of his newest game as he makes it, in his own thread. Link? That's for luzerz that can't browse forum for themselves.

EDIT: DANG. I'm freaking LATE with the responses. Well, at least I can verify what I've said with the owner...

To answer a few:

(1) Just because the buffer is vertically aligned has nothing to do with the scanlines. The buffer is always rendered top to bottom, then left to right. As in this scheme, the action of doing so is easier. The same interlacing is performed, albeit with a bit more play with respect to clock cycles. Might have to bump up the interrupt frequency at some point to make the gray look better, but as it stands, the gray is good enough for developmental purposes.

(2) The 4x4 aligned tilemap isn't hard. It's a close enough multiple to 8 to work out wonderfully. In fact, to get the half byte, I have each tile copied on both nibbles to take up the full byte for that line. When it comes time to rendering, a side is selected and masked out to get the appropriate side. The two sides are OR'd to provide a full 8x4 tile and four bytes are written out. The scheme that's used is very time-efficient, but rather bulky (as it uses SP to traverse the mapper, and uses shadow registers).

(3) Somewhat similar to (1), the scanlines *are* still diagonal. That is just how the interlacing routine works.

(4) Related to (2), implementing 4x4, as was previously said, wasn't too hard. The coding was rather straightforward, with some paper notes used to enhance the logic used for masking. The last bug to be fixed before the thing worked perfectly was a logic error between a combination of a null byte and a tile object in the same 8 bit space. One instruction was changed and another was added and that worked out perfectly. Really, the most time consuming part of this 4x4 tilemapper was NOT coding it. It was actually putting in the tile data (which I retried after some point because of some oddities.

Along with the 4x4 tilemapper, the mentioned oddities in (4) relate more to the 4*8 text. (4 wide, 8 high). Each character takes up two tiles but I knew there wasn't enough tiles in 256 to code in the borders, the small text used for box descriptions, the standard A-Z, a-z characters, a few punctuations, and all of the symbols relating to the inventory and status (4 tiles large). I overcame this by noting that some top and bottom halves of characters matched that of others, so I remapped different characters to take advantage of these similarities. The result? I now have just enough space to do the job.

The downside? Since the whole map takes advantage of the symmetry found in the characters, the line height may NOT be changed for any reason whatsoever. These optimizations were absolutely necessary. Also, I don't want to have to recreate both the entire tile bitmaps AND the ASCII character mappings.

After I finish testing out the routines, I'll make the cursor symbol to start and work on a menu system. At first, it's going to consist of just a moving cursor (which is also aligned to the 4x4 tilemap), just to get on and off of the title screen. Then, it'll be integrating the box drawing routine, the text routine, and cursor selection into a mess that roughly equates to my semi-successful menu system I wrote for my much earlier Cellular Automata project. (Don't ask for a link; UTI's download section is DOWN and I don't feel like asking for the file. Ask for it yourself if you're feeling adventurous. They'll probably honor the request.)

EDIT: Screenshot of the dialog box written via textmapper: http://www.mediafire.com/imageview.php?quickkey=dmlwzkegdz4&thumb=4
Still does not demonstrate the 4x8 text routine yet.