Thank you all so much! I can't wait to get home from work to try it...

Yet another Newbie question: Is changing from ADL to z80 mode multiple times in a program a "bad idea"? Does the CPU actually change modes, or does the assembler just use different op-codes?

I totally understand how creating a user guide would be a lower priority... not nearly as fun as development.

Thanks again!

This is really great! I can now debug assembly programs! It's like Christmas in October!!

I also found that I can disassemble and read through the ROM subroutines that I have been calling, such as _MEMSET. Quite a clever little routine, and a fun way to learn. This brings up 2 new questions, in case anyone has the time to spare...

Do programs run faster from RAM than ROM, or is a clock cycle always a clock cycle? I ask because I'm wondering if including ROM routines within a time critical RAM program would speed things up a bit.

There seem to be several screen buffers, some for text, some for graphics. Is there some documentation on setting which screen buffer is displayed? Is the only way to display a screen buffer is by copying it to Vram? Are there "conventions", such as using a specific buffer to save the current screen, and then restoring the screen after the program completes?

Thanks again... CEmu has opened up a whole new world for me. If only I didn't have to work all day...

I'm not a TI-eZ80 expert, so I'll just answer the first question, although I think I know where to find the answers to your second set of questions - namely, in the documentation of the community C libraries:


Yes, they do, and the community of users & developers would probably have noticed if TI had changed this recently with a new hardware revision.
The TI-eZ80 series' raw processor speed is severely crippled by waitstates, and in the default configuration, RAM access takes half the amount of cycles than Flash access does - IIRC, 4 vs. 8 (EDIT: 10, as indicated by Runer112). RAM-based programs should therefore run approximately twice faster. There's even a kilobyte of special cursor RAM, with fewer wait states than the regular RAM.
There's a program (by DrDnar, IIRC ?) for reducing the waitstates count for at least Flash memory until the next time the calculator turns off. Runer112 wrote on IRC that 1 less than the default value seems to be a safe value. However, reducing the waitstates count too much will simply cause random unwanted calculator crashes, so beware, if you want to use such programs

Yes, code does ran faster in RAM than in ROM. It takes 4 CPU cycles to read a byte from RAM, while it takes 10 CPU cycles to read a byte from ROM.

There are also even faster sections of memory than RAM. It takes 3 CPU cycles to read from the memory-mapped LCD controller. The LCD controller includes 1KB of memory at mpLcdCrsrImage for a cursor image feature that's more or less useless, so more advanced programs will just copy time-sensitive routines into this area at startup.



There's little reason to use the OS's graphics buffers for their intended purpose. It's usually best to just draw straight to VRAM using a library like graphx or with custom drawing code. The OS buffers do make for great storage space for arbitrary data, though!

In addition to the above replies; you can see how many cycles instructions take by using the cycle counter in the debugger. Simply press the 'Zero Cycles' button to reset the counter. Taking the number of cycles and dividing by the clock frequency will give you the physical time.

Wow! Thanks for all the responses and info! This makes sense, since when I worked with other hardware, the precious zero page memory would execute faster than the rest of RAM.

Quick question... Does the debugger take the ROM vs RAM cycle times into consideration, or does it assume all instructions are in RAM?

Thanks again!

Of course it takes them into consideration. Btw, here is the page with all the waitstates: http://wikiti.brandonw.net/index.php?title=84PCE:Wait_States

Any way to manually set the size and location of the windows for the emulator? I've found that the very top line of the calculator display is cut off. The laptop I'm using only has a resolution of 1280 x 800, so space is at a premium. If UI edit mode is disabled, the top row of the display is gone. If UI edit mode is enabled, or if the display skin is enabled, or if the display scale is set to 150% then the top row is visible. However, if all this is disabled, I have more room to work with. If I could just move the display window down one row, it seems that the top row of the display would be visible. As it is, I just leave it with UI edit mode enabled. I'm using the screen in monochrome mode ( 1bpp ) if that matters.

It's no big deal, but if there is an easy fix... please let me know.

I could try to post pictures if the above description doesn't make sense. Thanks to all again for all your help!

Where is the memory-mapped LCD controller located? Is it from vram to vram+(320*240*2)?

Where is mplcdcrsrimage?
My include file lists mplcdcursorimg = $0E0800 and plcdcursorimg = $4800.

Thank you for the info!

The LCD controller and VRAM are separate. The memory-mapped LCD controller exists at mpLcdRange ($E30000), which is separate from vRam ($D40000).


My include file calls it mpLcdCrsrImage (the value is not given directly, but works out to $E00800). Does your file have a different name for it? If so, I suggest you change to use this include file. This is the one used by most CE assembly developers.

Also, the include file may change slightly over time as new things are discovered or as mistakes are corrected. If you register for an account on that site (which requires manual approval, so it may take a while for your account to actually be created), you can watch the page to be notified of any updates.

Thank you for the response and info!

I was using the include file that you reference, but it didn't have a value for:

bitLcdLnBuim

which was needed for a LCD page flipping routine written by Mateo. After some digging, I found an include file (also called "ti84pce.inc") with this value and assumed it was an updated version. I'll try copying the bitLcdLnBuim equate to the original include file for use from now on.

I was going through the wait-states file (copied below)...
--------------------------------------------------------------------------
Wait State Layout

Address Range Read Write Description
000000-3FFFFF 5+ Crash Flash wait states are controlled by 1005, adding to the minimum of 5. The OS sets a total of 9 wait states.
400000-7FFFFF 257 Crash Unmapped address space. Can be mapped to Flash using 1002, after which Flash wait states are active.
800000-CFFFFF 257 257 Unmapped address space.
D00000-D3FFFF 3 1 RAM
D40000-D657FF 3 1 VRAM
D65800-D7FFFF 3 1 Unmapped address space. Reads garbage.
D80000-DFFFFF 3 1 Mirror of D00000-D7FFFF
E00000-E0FFFF 1 1 Memory-mapped port range 1000 (mirrored every 0100 bytes)
E10000-E1FFFF 1 1 Memory-mapped port range 2000 (mirrored every 0100 bytes)
E20000-E2FFFF 3 3 Memory-mapped port range 3000 (mirrored every 0200 bytes)
E30000-E3FFFF 2 1 Memory-mapped port range 4000 (mirrored every 1000 bytes)

---------------------------------------------------------------------------------------------------
I moved a memory intensive program (Game of Life simulator) from usermem to vram, and the timing didn't change. I moved it to pmLcdCrsrImage and about a 20% speed improvement resulted (based on the CEmu cycle counter). My question is, is there any space from E00000-E1FFFF that could be used for ASM programs? It seems this area would be even faster. All I could find is that E10000 and up may be involved in Cryptography... whatever that is.
What does "mirrored every 0100 bytes" mean?

bitLcdLnBuim was renamed to lcdIntLNBU at some point.

Regarding faster memory than mpLcdCrsrImage: there's only one area. Sadly, it's a mere 64 bytes large and you have to jump through some hoops to access it (which TI doesn't want you to be able to). It exists at $E10010 and is part of the SHA256 chip.

Thank you, Runer112!

64 bytes is quite small, but the idea of trying to further optimize code to fit these constrains is kinda fun! Could you please point me in the right direction for discovering how to "jump through some hoops" in order to access the area?

Worse that could happen is that I wind up "bricking" my son's calculator... wouldn't be the first time I've fried something.

My Game of Life simulation is coming along well.

Is it possible for a real physical calculator to send and recieve data from CEmu?

Suggestions/requests/pleas for possible improvements for CEmu:

-Stop it from timing out: Whenever the display of CEmu goes out, and I turn it on, I can't resend or send any files. I get an error box that comes up... I have to exit CEmu and start over.

-If I am debug'ing a program with a number of breakpoints, reseting the calculator doesn't work. I have to exit the program, then reload files and such. Can there be an option to reset calculator that ignores breakpoints?

-Have a way to manually adjust window positions (like an .ini file?). The top line of the LCD display is cut off if CEmu is not in "enable UI edit mode". This happens to me on 3 different systems with 3 different screen resolutions.

-Have the default location for adding a debug breakpoint to be usermem instead of $000000--just saves some typing for us that need to do lots of debuging...

-The pop-up windows in debug mode when one hovers over registers is great! Could they also include the binary value for single-byte registers?

-I've tried using the Watchpoints on the debug mode, but they don't seem to cause a break. Any info would be great!

==> NONE of these requests are important. <==
Just things to make the work of debug'ing more efficient.

Thank you again for this wonderful tool. The more I use it, the more I appreciate it!

If you download a newer build; there is an setting to "Pause emulation on focus change", which should do what you want


Sure; but the question is when should breakpoints be re-enabled?


This may be out of the realm of customization; but we can fix the line issue.


Seems reasonable enough to me.


I don't see why not


They won't break; rather they will open the debugger when the memory address is written or read.

Thanks so much for the info and ideas!

I guess I was hoping for a "master reset" option on the "calculator" menu which would do the same as reset, but would do so even if the debug mode is active. That way I can make changes in the code, refresh the new code into the calculator without having to set everything (such as visual memory tool) up again.

I'm sorry, but I still don't understand the watchpoints. If I set one, and the program reads/writes to the location, the program keeps running. I was hoping for a function that would break the program (like a breakpoint) and go to the debugger, when a certain memory location is accessed.
The program I'm working on is a simulation of the "Game of Life" originally developed by Conway in the 1970's. There were "bugs" in the program which would cause incorrect plots on the screen. If I could have the program break when these plots occurred, debugging would have been easier. Instead I had to keep going through the loops until I got to the point where the problem occurred.

Again, nothing critical here... just trying to get things more efficient.[/b]

That is what they do. Are you sure you are setting the address correctly?

Wow...

The watchpoints work as expected. I must be losing my mind...

Thank you again... I will try to be worthy of the awesome CEmu in the future!

Do you happen to know what is involved in accessing the SHA256 area? I was informed that there is a 64 byte part which has minimal wait states but is restricted...

Which kit should I choose as the auto detect isnt working.