Omnimaga
Calculator Community => TI Calculators => ASM => Topic started by: utz on August 03, 2014, 03:09:35 pm
-
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.
-
Why not switch away from such an outdated tool ? Which assembler do you use ? Most modern assemblers include a linker for all z80 calcs (spasm, brass).
-
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 :(
-
You don't need to learn Python. Just glance at the code and you'll most likely figure it out. :)
I can probably help if you can't (I know Python 3, but Python 2 shouldn't pose too much of a problem).
-
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.
-
No problem, glad you got it partially fixed. :) I think the fact that hardly anyone does z80 asm for anything else than the 83+ makes it less interesting for devs to spend time making tools for the other calcs. :/
-
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.
-
Ummyeah, I should probably report this at Cemetech, but somehow I doubt Kerm really cares. I mean the tool was released some 4 years ago, so these very obvious bugs should've been noticed by now.
Spasm - it's a matter of taste, really. I don't doubt that it's a good assembler, it just doesn't suit my coding style. It's mostly minor things that irk me, e.g. having to prefix hex numbers with $ when I prefer # (one keystroke less on German keyboard), strange handling of local labels, etc. Spasm is too TASM-ish, if you will. It also lacks support for some other Z80 platforms I code for, and due to the quirks in syntax porting stuff over is usually quite a hassle.
-
I wrote a tool for converting binaries to appvars. I'm sure I can modify it so it can generate programs too.
-
Yes, gimme gimme gimme! Ima beta test the hell out of it!
-
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.
-
Jaa... but I need you to add the functionality to create .xxp/s files for all Z80 calcs ;) Otherwise I could just write my own tool, obviously.
-
I'd have to look up the file format for those. I am pretty sure only some stuff in the header changes.
-
Kerm said he'll look into fixing binpac8x, so don't worry about enhancing to8xv for now.
-
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 :-X
-
$ is a two stroke character on German keyboards, # is one stroke. But other than that, German keyboards are anything but programmer friendly - [],{}, ~, and \ are all on an AltGr combination. Whatwheretheythinking.
True, on 65xx # would be an immediate value. But on Z80 luckily we don't have that "problem" ;) The people who's code I studied in order to learn asm mostly use # for hex, so naturally it became a habit for me, too.
-
Hmmm on azerty (which I'm switching away from when I get ky new keyboard, in favor of QWERTY or Dvorak) it's altgr+3 for #, [] and {} are also on altgr.