8k limit for ASM

[puromtec]

Ok, have to say this is a little confusing.

I have found that my application goes nutz when it is past 8k in size. I have re-read the "TI-83 Plus Developer Guide" section on page 120 which states the differences between ASM Programs and Applications where ASM has 8k limit and apps are 16k+. I assumed that I had a 16 k limit on app size that I have been coding in Latenite, apparently not. This is a huge bummer at this point.

Question:
What do I have to do in Latenite and Brass (if at all possible) to have my app be an app that runs from flash so I can get the full 16k page? I have seen a few words about ion and mirage but I'd like to stick with the least amount of layers as possible for my application.

I have read this web page below and it originally lead my to believe that I was dev'ing a flash app. I use safe ram areas, appvars and do not edit between 0x4000 and 0x8000 in my application.
http://z80-heaven.wikidot.com/flash-applications

Thanks.

[King Harold]

That sounds really strange. Sadly, I don't know why this could happen.. sorry

[puromtec]

Thanks for replying..

This page is also pretty straight forward about 16k pages and how to work with branching even: http://benryves.com/bin/brass/tutorials/tiapps.htm

I've got an app so far that has a nice dynamic commanding menu that scrolls and text wraps in small font and can highlight a selected entry and wanted to take this app to the finish line, but now have the breaks put on until I can get past this issue.

Call it the "working-late-at-night" syndrome or my general stupidity, but is there a feature in Latenite/brass that determines whether the compiled code is executed from RAM or it gets executed from a FLASH page inside PTI?

[King Harold]

Yes, apps are always executed from Flash, and normal programs are executed from RAM, unless crazy hacks are used (some shells may do that)
But you'd instantly notice, under normal circumstances (that allow the TIOS to function) they'd be mapped to very different addresses, so any non-relative jump (or call) and most data accesses would die if it were executing from someplace different than you're expecting.

[puromtec]

Have your TI_83Plus apps written with Latenite/Brass gone beyond 8k?

[benryves]

Do you have the same issue if you create an app which starts with 8KB of dummy data followed by code? (Just jump past the dummy data).

There is no size restriction inherently in Brass, but you could have uncovered (yet another) bug.

[puromtec]

If I add just a little more code to my existing source it jacks up the emulator and the file size is at like 8 k (on disk).

My approach will be what you suggest. I'll report back what I find with a single file source file demonstrating it. Might be my setup that is screwy, who knows.

I am glad to hear there is not a limitation of 8k, however I do recall seeing a thread on this site that discussed that limitation.

Thanks for your support.

[benryves]

The assembly program size limitation is caused by execution on particular RAM pages. In the typical memory arrangement this happens when the program counter is $C000 or higher. As the program starts at $9D95 this gives you a $9D95-$C000=8811 byte limit. This only affects execution, so your program can be larger than this if you're only reading or writing data past $C000, not running code. Ion copies its routines to the end of your program when you load it, which can cause problems - MirageOS is not affected by this.

[puromtec]

I ran a test project sucessfully with a larger 8xk file that just printed 'test' to the screen with a really big include file with just NOP's. Both this test project and mine are using the

Code: Select all

.defpage 0, 16*1024, $4000 ;Page 0 definition
.page 0

What actually occurs with my actual project is that my application executes pre-maturely. If I hit "run" in latenite it builds/compiles then PTI starts with the initial calculator screen (I have no buttons pressed automatically by the .debug script). Next, I set "Break On All Points". Instantly, a break point hits in my app. My app is somehow running (badly) as soon as it gets loaded into the calculator. If I remove a single line of code, it reverts back to normal behavior where I have to hit "Apps" and then select my app to start it and things look fine during breakpont stops.

Attached is my project. If you open LaunchInteraction.asm and remove line 19 (NOP comand), it runs fine. This could be done with any line, I am just using NOP for simplicity.

To scroll my window use 1 and 0, use up and down arrows to select/highlight entry.

[benryves]

Once an app has been sent to the calculator it is validated. What seems to be happening is that the app is still validating when the keystrokes to run it from the Apps menu are sent to the emulator. The following debug script (TI-83 Plus (Native).debug) seems to work:

Code: Select all

; TI-83 Plus native script
reset-calc
run 6000000
key-press on 6000000
send-file %DEBUG_BINARY%
run 20000000 ; You may need to increase this as the app gets larger.
key-press apps
key-press 2
breakpoints-on

As for breakpoints triggering before your app is run: breakpoints are only assigned to a 16-bit address in the Z80 memory map. This means that they may be triggered in PindurTI when executing code from a different ROM page (or within the TI-OS), not necessarily where you put them. This can be rather irritating, I know. Offsetting the address by one with a nop before it can help if it keeps getting triggered by accident.

As the debug script now only enables breakpoints at the very last moment you may miss breakpoints firing if they happen early (the key-press instruction runs the calculator for a few cycles to give it time to respond to the key). To combat this a short delay at the start of the app may help.

[puromtec]

Thanks a lot. I'll try this tonight.

Btw, was Latenite/Brass part of a job you were paid to do, or just your own thing? Side-work can be a bitch at times, especially one as big as this IDE and assembler.

[benryves]

I used Latenite to teach myself C# and Brass (which came later) was my first attempt at parsing any sort of program source code. As such both are monumental botch jobs and were done in my free time (this is part of the reason I'm so reluctant to do any further work on them, as they're so poorly written they are virtually impossible to maintain). The only work I make any money out of is PHP web development, alas!

Brass 3 was written later (I forget what happened to Brass 2) and is a rather better, but is overcomplicated (both internally and externally). I never updated Latenite to support it nicely nor did I ever finish the attempt to write a new Latenite IDE. Since then new projects have sprung up (such as the Wabbit suite) which put me off resuming work on my own tools.

[puromtec]

The revised .debug fixed the issue. Thanks.

>I used Latenite to teach myself C#

My first C# apps were simple CRUD/reporting apps in aspx back in 2002. I hope that I have improved since then myself. This asm programming I am doing here is for a real project (pro bono, albeit), but I think it keeps me grounded so I never forget what a real machine is. I saw some of that hardware work you do on some site of yours. Interesting stuff.

[benryves]

I'm glad to hear that the issue has been resolved.

This looks like an interesting project, so best of luck with it!

[puromtec]

Actually the best work-around for breakpoints choking up the TI operations on the same memory addresses is to drop in a bcall(_getKey) prior to a set of breakpoints and turn on break-on all break points while the calculator is waiting that keypress. Then press a key.