LOL

Only, yahknow, numerous hours' trial-and-error and a little bit of progress, and, well, the some 10+ minutes it takes to load ZAC with my cable setup...

Hey, at least I'm laughing... you shoulda seen what I went through at the start of today's endeavor.

<s>This project has probably reached its end for a while.</s>

Update...

My stepdad always says "if you get frustrated with a project, call it a day then come back to it the next" ish...

And, frankly, that's never really worked for me, I tend to "fight through" and often work on projects for days on end, sometimes without stopping to eat or sleep. 

...yesterday's endeavor got off to a rocky start, the likes of which could've easily led to "time to call it a day" before even starting. I fought through. That, in this case, meant ignoring something that I find EXTREMELY difficult to ignore... but I managed, surprisingly.

 ... until the mem-clear, which wasn't so frustrating because I lost that work... in fact, it'd be MUCH easier/faster the second time around, since I now have a better idea what I'm doing (I now know some z80 assembler pneumonics!). And I can probably do it better this time, starting fresh... (make libraries of em, dingbat! E.g. PrintBinary()). No, the problem wasn't with the loss, I could even laugh about that... (BTW, be sure not to delete the 'return from call' at the end, or it'll try to execute whatever garbage is in the RAM /after/ your program! That's my guess what happened, anyhow). 

No, the problem was that the loss of productivity gave me a moment to recall what I had to ignore to get started in the first place. And THAT got gnarly, quickly. I actually wrote it three different ways, here, but decided it wasn't really shareable.

....

Anyhow, today I had an idea of a potential explanation for some of the oddities I had to ignore, and some experimenting confirmed them. I guess my stepdad was right this time.

...

The key factor is: DO NOT try to execute your Assembly code as though it's a (TI-BASIC) program! Otherwise TI-BASIC will reformat everything, including removing leading and excess spaces, and more. This may seem like an obvious "do not" since obviously it won't execute, but it's really quite easy to do /by mistake/...

...

Here's a really weird one I've not wrapped my head around...

" jp  ProgStart" has a leading space, as all asm instructions do, and two spaces after jp... TI-BASIC turns it into "jpProgStart" with all spaces removed. Weirder, if you change ProgStart to ProgStar, it leaves a (one) space after the jp. If you change it to ProgStart1 it removes all spaces again. And, again, as I recall, if you change it to PROGStart. Similarly, the jp can be changed to anything and it does the same, it seems. Apparently "Start" is quite special?

.

Now, onto the memory-cleared issue...

I could see this being quite a recurring risk... in fact, in my old TI-82 days, as I now recall, I got into the habit of running a full backup of my programs every night, and even more often when I was programming TI-BASIC next to my computer... I've so many shoddily-sorted backups from those days, I have no idea which is the latest, and it'd be quite an effort to try to find out.

The goal, here, was to have a completely self contained devel system... and that it is... until something goes wrong, and that memory gets cleared, or otherwise mangled, which is easy to do in assembly, and even easier when you're working with really low-level stuff like I plan to... like modifying the ports which configure the Interrupt rates or the LCD configuration...

So, regular backups to something truly non-volatile is even more important. And... that stupid factor, too, of that there's no "undo" and most efforts are saved somewhat immediately... being in pseudo-nv-RAM, after all...

So... at what point does it make more sense to devel on a laptop, despite all the difficulties of doing-so in my situation...?

Some of those issues are learnable to work-around... e.g. save to a new file often for the sake of undo, or always make sure there's a return at the end before clicking "run", or make sure ALL the batteries are fresh, especially the backup batt. But some things'll just happen in this line of 'hackery' and that's to be expected, but this system's much more sensitive to total data loss than one with say a floppy drive. (On the plus side, "bricking" shouldn't be feasible!)

So, now may be the time to at least start considering things which might've been early show-stoppers in the beginning... like, how'm I going to run backups regularly when it takes ten minutes to transfer a file and the laptop can only run for an hour before needing a recharge, and I can only do one lappy recharge before needing to do a starter-battery recharge... So, maybe, then, I should spend more time with the tilp2 connectivity library to figure out how to increase the transfer speed, which means a lot of sit-down with the laptop which can only run for an hour before needing a recharge... 

Or, maybe I should think of non-volatile memory options... The RAM only uses half the available banks... maybe a FLASH chip could be soldered-up. But that'd still require support-software which would be in static ram... "memory cleared" would still require a load from the PC of that support software... UNLESS there's some way to throw something extra in ROM somehow... and that might be accessible via short hand-enterable "ASCII" assembly program... just a simple call to a certain address, hmmm... and, actually, that *might* be doable to run a function from the new FLASH, so ROM may be unnecessary... hmmm...

And that'd beat trying to use an SDCard, since the code could be executed /directly/... hmmm...

So, now, I guess I need to look at the PCB and try to locate the pins... there's only one that might be missing/inaccessible...

Or, is there an empty bank in ROM that could be bypassed with another chip? Hmm...

But, then, need to make sure those locations are actually accessible via assembly... which is why the self-contained devel system was a great idea to start with. Heh!

I think, maybe, I'll go follow some traces... which differs greatly from yesterday's goal. Weee!!!!

.....

But... shoot... the whole reason for this project was to try to get back into "the groove" of doing projects, and most of /those/ require using a laptop... so, in light of that higher goal, maybe I should be trying to figure out better solutions for laptop usage, (e.g. a "house battery" of sorts, again? Sheesh, I've fought /that/ battle So Many Times, in So Many Ways...) which regular backups of the calculator would help motivate... UGH!