This is my assembly code, helloworld.z80:

Code:


I assembled it with SPASM on Ubuntu Server 23.10 using `spasm -I <incdir> helloworld.z80 helloworld.8xk`. I tried transferring the application onto my emulator, TilEm 2.0, and the app sure did work as expected.

However, when I try sending the app to my physical calc via TILP II, it fails with the message "FLASH application rejected (signature does not match)."

I have attempted to get SPASM-ng to output a hex file and manually sign it with rabbitsign instead, but rabbitsign says "application has an incorrect page count (actual: 1)". (???)

How do I create a Flash application for TI-84 Plus with SPASM-ng and possibly Rabbitsign, that works on both TilEm2 emulator and the physical calc?

It's possible you're hitting some bug in spasm, rabbitsign, or both. For example there was an issue (fixed in spasm-ng, but maybe not in the version available in Ubuntu) with signing apps with names shorter than 8 characters.

Historically developers have tended to assume a fixed structure for app headers (even though they're actually a sequence of variable-length fields), so app.inc might be generating a header that confuses the other tools. You might have more success using an old-style app header, like this one I've borrowed from Dwedit's appdev kit:

Code:

I don't read Cemetech on a regular basis, but I was having insomnia last night and came across this post. The code was strangely familiar, and sure enough, it's basically the one I posted in another thread.

I have verified that the modified code posted above works for me with the following dev environment:

* Linux Mint 21.1 (basically Ubuntu 22.04)
* SPASM-ng Z80 Assembler by Spencer Putt and Don Straney Version v0.5-beta.3 (built on Aug 29 2017 @ 21:21:06)
* TiLP2 1.18
* TI-84+SE OS 2.55MP
* TI-83+ OS 1.19
* TilEm 2.0 emulator

I cannot speculate why it doesn't work for the OP.

Hi, I just tried both the code you and Tari posted earlier, and both of them somehow work in TilEm and refuse to be verified on the physical calc. I guess I’ll just stick to Axe for now.

Maybe your physical calculator is broken? Have you tried another one?

For the record, there are definitely bugs in SPASM with regards to signing the flash app, but yours isn't one that I have come across. The 2 bugs that I have encountered are:

1) If the size of the app becomes close to page size boundary (16 kiB, or was it 32 kiB? I can't remember), spasm will error out when trying to sign it. The solution is to just write more code, to break past the size that triggers the bug. I never looked into the cause of this.

2) If one of the flash pages contains less than something like 256 bytes, spasm considers that an error for some reason, and refuses to sign the app. The solution, again, is to just write more code into the sparse flash page. A dummy .db record of some size is sufficient. I did look into the code that triggers this, but couldn't figure out why it was there, so I just ignored it, and just wrote more code.

Point #2 was the one that did it for me. I added 125 lines of
Code:
in a junk label that's never referred to, and viola, suddenly the application works on the physical calc.

Thank you for the assistance.

(Full code here:)

Code:

Glad that you got it working. Fortunately the problem will just go away naturally when you write a non-trivial program.

Just out of curiosity, what is your calculator model and OS version?

And did spasm print out an error message? One of the several annoying things about spasm is that it does not return a status code of 1 (or something non-zero) when it detects an error. So a shell script or a Makefile will think that spasm has compiled properly, when in fact, the program did not assemble. Which has prevented me from creating a GitHub Actions pipeline for continuous integration.

My TI-84 Plus Silver Edition calculator is running boot code 1.10, OS 2.55MP. SPASM did not say anything was wrong, from the output messages I saw.

It looks like my 84+SE is running Boot Version 1.00, same OS Version. Maybe that's the difference?

Or maybe it's some random bug inside spasm-ng? I'm not completely happy with spasm-ng (as I have posted before), but it mostly works, and I haven't had the motivation to look too deeply into the tool itself. Currently, I prefer spending my time on writing interesting application-level code, rather than yak-shaving the assembler and the development tools.

Perhaps SPASM has not been adapted to comply with the new boot code's requirements.

I agree that time is much better spent actually developing software rather than bashing the tool itself for not being perfect I'm currently making the best of what Axe Parser has to offer since I feel much safer coding in it.

Off-topic: I know very little about Axe, other than that it's a language that uses TI-BASIC tokens, then compiles to machine code. Does Axe support flash applications? And can Axe programs be written on a laptop/desktop, with a real keyboard, a terminal, and an editor, then be compiled to *.8xk?

Correct, it's a language that uses slightly modified TI-BASIC tokens, and is compiled to very fast and efficient machine code. (You can find the commands list here and the the raw assembly behind each command here.) It can do all sorts of things like inline assembly in hex format, and it includes built-in commands for most commonly used features like activating the 15MHz mode and link port stuff. Interestingly it doesn't mention hooks at all, though.

Axe does support compiling to Flash applications; however, the last time I tried to compile an application that I thought would have to take up multiple pages, the calculator crashed horribly and my entire archive was erased. So do NOT attempt to compile a Flash application from source code >~9KB in size. iirc, it's a "beta" feature, but it works fine as long as you're not doing anything ludicrous.

It is certainly possible to edit Axe source code with a real computer with a tool called SourceCoder 3. However, I have been in situations where clicking the Export button did not let me download the 8xp source code... so make sure to back up regularly. It also seems to be integrated with an emulator located to the right of the editor which is convenient.

It is very important to note that Axe cannot be compiled on a computer and MUST be compiled in a calculator, either physical or emulated. Also, when you export *.8xk applications, you will notice that you cannot put them back on the calculator due to an invalid signature. To get around this issue, I just re-signed the application with rabbitsign and the 0104 key, and it worked perfectly fine.

Another thing to note: Compilation is usually very fast. It almost always takes less than a second if your program is relatively small, barely more complex than trivial; but even if you're compiling a couple thousand kilobytes of code it barely takes five seconds.

Ultimately Axe is not absolutely perfect, (it seems to have been abandoned,) but it is still very good at what it does.

Ok, your description of Axe is basically what I thought. I will stick with Z80 assembly. I can write it on my laptop, use git for source control, and compile it with an assembler. The Z80 assembly language will never become obsolete. The spasm-ng program has a bunch of annoyances, but it produces working flash apps for me.

Oh yes, the lack of version control where you can actually diff between commits is very annoying. Axe source code is always just a TI binary file.

I should look into Z80 asm again. I gave up last time I tried to learn it but I guess there is no limit to what I can really comprehend as long as I'm willing to learn.

You can always write Axe in a source code editor like SourceCoder and then tokenize it! It even has an Axe syntax highlighting mode, albeit not given quite as much love as TI-BASIC itself.

Edit: And, you know, then also check the plain-text source into source control.

That's.. fun. I've filed a bug about this so at least it's kind of documented somewhere (and maybe somebody can get around to further investigation at some point).

It's because the calculator doesn't accept small applications, it's not really a bug in spasm.

Thanks!

Just for the record, the bug that HackerDaGreat57 is hitting is not the bug that I was trying to remember (although the account of my bug seems to have accidentally helped HackerDaGreat57). The bug that I had misremembered was for apps whose last flash page is < 1024 bytes. I filed a separate bug for that here: https://github.com/alberthdev/spasm-ng/issues/81