This has been troubling me for some time, but I finally can't avoid the problem any longer. binpac8x just doesn't do the trick for me, the files it outputs simply won't run.

Right now I'm trying to compile a .86p file, though I've had issues with .82p files before as well.
I've converted the same binary with mk86p, which works just fine. A side-by-side comparison in a hex editor reveals that binpac8x' file contains a faulty header and end wrapper, and is also 2 bytes shorter.

Any ideas what could be causing this problem? I'm on Debian, using Python 2.7 and binpac8x 1.3.

pasmo is the assembler of my choice... I'm writing code that targets different platforms, so using a TI-specific assembler is not an option for me. I've also tried spasm before, and didn't like it.

Upon more careful examination, I see that binpac8x is indeed bugged. It doesn't include the mandatory $8e,$28 token at the end of the header. Consequently, the binsize info and checksum are also wrong. Meh, I don't want to learn python just to fix this

Well, I've managed to fix the TI-86 part, but it was pretty tricky. Started to look a bit into the TI-82 part, that seems even more difficult to fix. To begin with, It doesn't even add the $dc in front of the program name, which is needed by just about every shell out there. I don't think Kerm ever bothered to test his tool on anything other than the Plus models. In any case thanks Streetwalrus for offering to help. I might get back to you at some point, though at the moment I tend towards writing my own packer from scratch.

Yeah, i think Devpac8x was strictly for the 83+ and BinPac8x was a sort of Devpac-solution for newer OSes, since Devpac was a 16-bit program. I have used spasm to make 82 and 83 programs (i've had trouble with nostub 83 programs though since it compresses everything), i haven't tried assembling anything for the 86 though. I imagine it'd work.

Btw, have you mentioned this to Kerm (over at Cemetech)? I think Kerm would like to know if there are issues using it for other calculators and would probably help fix it.

Also, i'm curious what you didn't like about spasm. I think it's great, it's got a powerful macro system, it's super fast, and all you have to do is type "spasm prog.asm prog.8xp". The only thing i wish it had was a (better) processing of order of operations. As it is you have to make sure you use parentheses when doing multiplications and divisions.

I wrote a tool for converting binaries to appvars. I'm sure I can modify it so it can generate programs too.

http://8times8.eeems.me:81/blog/index.php?archive&thread=380&name=to8xv-windows-software-for-converting-anything-to-an-appvar
Source included I believe.

I'd have to look up the file format for those. I am pretty sure only some stuff in the header changes.

Wow is $ a three-stroke character on German keyboards? With my Spanish keyboard # is more annoying since you've got to use AltGr. What is a real pain on the Spanish keyboard is typing [] and {}, still just AltGr + the key, but they're in a weird spot. Luckily i don't have to worry about that with z80 Also, i'm pretty sure you can suffix hex numbers with an h (FFh), though i've always used $ so it's not an issue for me.  I really don't care for the 0x format (or the ampersand). Anyway, # just makes me think of an immediate value.  And i guess that's true about spasm's formatting, for some reason i didn't think you were using the same code base across different platforms.

And for some reason i thought you were Dutch