Tilem - TI Linux Emulator / Bugs / #7 ORG LCD write mode missing on 84pcse

Thank you for reporting this. I'm aware of the issue and I've been working on it, but as you say, the ILI9335 documentation is very unclear and the actual behavior of the HW is hard to pin down.

Here are my notes on the subject so far, please let me know if this doesn't match your experience or if you can answer any of the open questions:

 Seems to ignore R20/R21 completely and always start at the start
 of the window.  However, writing (anything!) to R20 or R21 resets
 the cursor to the start of the window.

 - What about reads?  What about mixing reads/writes?

 - Are the actual R20/R21 values affected?

 - It seems that writing R20/R21 puts it into an "uninitialized"
   state which will cause it to jump to the start of the window
   when the next pixel is written.

    - Changing R03 doesn't reset the cursor position.  But you can
      change R03 after writing R20/R21 and before writing pixels.

        => See Frogger for an example

    - Changing R50-R53 doesn't reset the cursor position (&
      previous absolute position is maintained, not relative
      position.)

      - But if former position is outside the new window, it's
        now *invalid* (pixels written at that point will either be
        sent to the bit bucket or will trigger panic mode.)

    - Does reading a pixel also put it into "initialized" state?
      If not, where is the pixel read from?

Thomas Moore - 2014-02-24

I see. Well, that's lots of good questions I am unable to answer without writing a more extensive test program. However, developing for this calculator is a pain in the ass (after seeing the mostly undocumented "AsmComp(" command, I thought you could at least write z80 asm on board, but I guess that just "compiles" ASCII hex codes to binary, so the only thing left is the nearly non-functional language known as TI Basic, not much better than my ancient TI-66). I'm currently working on an alternative on-board development environment, but it'll probably take months or even years to finish.

At least I've written a simple test program to answer my own questions (and confirm one of your statements): the patch as written works correctly in all AM/I1/I0 modes. However, as you mentioned, all writes to R20/R21 reset the position to the origin, and R20/R21 are not updated at all; they return the value last written. I have updated my patch based on my simple tests, and have attached that. Again, at least with this simple patch, Frogger and Image Viewer display their text. You've already done most of the hard work; I'm pretty impressed at how well Image Viewer (and pretty much everything else I've tested) matches the real calculator.

Of course one way to deal with the rest of your behavior questions/notes is to just ignore them until some programmer decides to take advantage of discouraged/uncodumented behavior in the chip, causing their emulation to fail. This emulator isn't perfect, anyway, right? Or is it? Does it emulate USB yet? That would be more important (for me) to get working (and unlike the video chip, there isn't even a poorly written official users' guide for the USB crap). I'm guessing, by the complete lack of working code in the usb branch, the answer is "no".

You mentioned Frogger, but since I don't have source code for it, I can't really include it in my debugging other than saying "looks OK" (which it does -- I can see no flaws). I assume we're talking about the same Frogger (http://www.ticalc.org/archives/files/fileinfo/455/45544.html). In fact, the only reason I looked into the ORG mode at all was to see why Image Viewer (by the same author, but this time with source code, at least for the calculator side) wasn't displaying the file list or menu keys. I was also miffed by the fact that I couldn't load the sample image using tilp or tilem, but that was cured by manually setting the archive bit in the file (perhaps the official TI software does that automatically if there's not enough memory? I can't even get it working with Wine, so I can't comment). In general, tilp and tilem also require renaming the .8c? files to .8x?, which is also a bit annoying, but not enough to pursue. I should just be happy I can transfer and emulate without resorting to Wine (assuming that would work at all). In fact, while running these tests, I almost thought that only having an external development environment isn't such a bad thing, since loading and running them in the emulator and real calculator was pretty painless.

Sorry for rambling so much on unrelated topics.

org.patch

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Benjamin Moody - 2014-02-25

It's true, imperfect emulation is better than none in a case like this. And it looks like your revised patch should work for all the common cases, at least. I'll apply the patch but leave this issue open for now, and possibly make some changes after further testing.

Off-topic:

Yes, there is definitely a lack of good documentation for CSE assembly programming. (I'm sure TI has some and isn't sharing for whatever reason, but in any case the community, myself included, should be able to do better. :)) There are a handful of on-calc development tools for programming in assembly and other low-level languages on the 83+/84+, but I haven't heard of any yet for the 84+CSE.

USB emulation would be great, but it hasn't been a priority. It's a complicated issue, and we should move that discussion to another bug report. :)

.8x? vs .8c? is primarily a libtifiles issue, which really needs to be fixed in any case for TILP's benefit.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

ORG LCD write mode missing on 84pcse

Group

Searches

Help

#7 ORG LCD write mode missing on 84pcse

Discussion