I have not yet tried it. I know you don't, that's why I recommend you ask your users to install Python/wxPython and distribute a 50KB program rather than distributing a 15MB program, 300 times as large as it needs to be.

Or maybe distribute both Next version will have both, but this one is only .exe.

Eh, I personally feel that you should still just include the Python source, but you're the coder, it's up to you.

So huh hum... Anybody has any comment on this?

Just tried it, a couple of comments:
-Make the menu option "Convert decimal to hexadecimal" convert the entire document (addresses at least) into hexadecimal. People use hex to talk about locations, not decimal. You can keep stuff like "ld hl,1000" as decimal, it's only locations like: ld (9D95h),A.
-Fix the resize issue and make the location of the middle block relative instead of absolute.

Also, it took me a minute (no readme looking >.>) to realize how to import my .8xp file. Could there be a simple "File > Load .8xp" option?

Edit: Is there a readme?

Edit: Also, where is the scroll bar for the right side? I assume it's because my screen isn't as big as yours and that the positions are absolute.

Also, could you make the disassembly real-time, as in you type in the hex and it automatically shows you the disassembly without clicking Convert?

Edit: Can you make the disassembly not appear in a text box unless you want to include re-assembling?

This. Also, could there be a way to make another thread for converting stuff, because otherwise it seems like the window is lagged out and dead. Or at least, go through and edit the other side as you are converting it.

Edit:
This also. Or at least make it so people have to want it to show up. I'll personally never use that side, simply because it looks like (no offence) garbage. If it had locations in random places, that would be good. Like maybe every 4 bytes add a line break with the location (In hex!) right before it.

Assembly to Hexadecimal, in other words, Assembling, is not planned and will not be done, at least by me.

All of the others will be considered, starting by hexadecimal addresses, the most important one. This will be implemented right after Bcalls.

Then come GUI updates, starting with the making positions relative.

Umm, I'm afraid you aren't getting the concept (No offence). What we mean by Decimal to Hexadecimal is this: Taking "ld a,(999)" and turning that into hexadecimal. I think when Souvik says Disassembly, he means the "inc hl \ nop" sort of thing. So that he could type on the left some hexadecimal numbers, and it would return the "inc hl \ nop" sort of stuff in the right, in real time. Correct me if I'm wrong.

1. You don't have to press F5, just press Enter, real-time like Tokens would be a nightmare. It's almost real-time ;D
2. Nothing else to say, why was the 1. anyways

Also, could you allow the characters a-f for hex input in addition to A-F?

I'm sure Python has a "ToUpper()" function, so that doesn't sound like it'd be too difficult.

str.upper() yeah, I'll add that souvik, first thing, real easy.

It wouldn't be that bad if you did it intelligently. But I can certainly understand that you'd be hesitant to do it.

Features:
> Disassembles a .8xp file (pre-beta stage, working more or less)
> You can type Hexadecimal code and it'll be converted to Assembly code in almost real time
> Convert decimal to hexadecimal
> Convert hexadecimal to decimal

> Edit menu:
>> Select All
>> Undo
>> Redo
>> Copy
>> Cut
>> Paste
>> Clear
>> Number of Words
>> Find and Replace

> File Menu
>> New
>> Load .8xp File (working better now)
>> Open a hex file (.txt, .hex)
>> Save Asm (.txt, .asm)
>> Save HeX (.txt, .hex)
>> Save Asm and Hex (.txt)
>> Exit


> Convert Menu
>> Convert

> Tools Menu
>> Decimal to hexadecimal
>> Hexadecimal to decimal

> Help Menu
>> About

RAM Addresses and Labels are now written in hexadecimal with a $ before.

What I'm sure will be updated next version:
> Possibility to save as .z80;

What I still have to do:
> Bcalls;
> Negatives;
> GUI Fixes;
> Optimizations (not that the program is slow, it's quite fast actually);
> Try real-time conversion.

Link

www.davidgom.co.cc/Assemblex0004.zip

How would you differentiate a negative signed integer from an unsigned integer?

In assembly, you can't. It's just implementation-dependent, that is, completely up to the programmer. The two main conventions are $00=0, $01=1, ..., $FF=255, and $00=0,$01=1, ..., $7F=127, $80=-128, $81=-129, ..., $FF=-1, $00=0. In the latter system, the 7th (most significant) bit is set for negative numbers and reset for positive. You can easily also choose $00=9000 through $FF=9256, although arbitrariness is not common.

Index register offsets are -128 to 127, and this might be what he is talking about.

So, from which bytes to which bytes are they negatives? Or this can't be really done this way?

As I said above, whenever the MSb (bit 7) is set, the number is negative by that convention, and when it is reset, the number is positive.