A new on calc z80 ASM compiler

[Fallen Ghost]

[LolBbq]

No, you misread it, I meant having all three .incs (Ion, MOS, and ti83plus) part of the compiling app, and then if the user needed self-defined incs, they could make a .inc with the ti-basic editor.

[Fallen Ghost]

Ok, so here's what we have now:

-Tokens with registers chosen by menus
-Mos, Ion, ti83plus.inc files included within the apps, and the possibility for the user to create one in a .8xp file.

But for the tokens, choosing registers is okay, but when you have numeric input, here's how I think it should be:

ADC a,[45h
ADC a,[someequate]
ADC a,[10101010b]

ld (***h),hl [9D93
ld (***h),hl [someotherequate

I know the second is ugly, but that's how are tokens. For numeric input, we could use decimal, hex, binary and equates. just put the number after the little [. The parenthesis wouldn't need to be closed.

[LolBbq]

How would the wildcards (*) be dealt with? If the parser in the app comes upon it would it save the value and then compare with the program counter to check where it points to?

In the second example, are 9D93 and someotherequate stored in hl to start with? Or is hl going to be stored into 9D93h?

Also, I guess tokens won't be required on our part. I mean, if the programmer makes the same mistakes that TASM would pick up, then why not just let the app pick up those same errors? Then we can allow a more natural programming environment instead of deviating from the standard z80 instruction set.

[Fallen Ghost]

The fact is that when there's a need for a numerical input, the value is stored after the opcode.

Example: ld (****),hl is 00100010 : [immLSB] : [immMSB]

So if the parser look at ld (***h),hl [someequate, here'S what it should do:

-put 00100010 in current byte of compiled output program (because it's a token)
-increase byte counter
-put LSB of equate at byte counter
-increase byte counter
-put MSB of equate at byte counter
-increase byte counter
-Do something else

[DarkerLine]

how about if you choose a command that requires an immediate value, you have to type it in right there and then, before it inserts the command? This is an ugly way of doing it.

[Fallen Ghost]

And what if you need to enter another value after? you'll need to re-insert the instruction. Isn't very user-friendly

[DarkerLine]

But readable. Besides, you could just come up with a clever way to move the cursor around so that it would be able to edit the inside of the token.

[LolBbq]

[DarkerLine]

Well, if you were to write your own editor, you could display whatever you want however you want.

[LolBbq]

I can always resort to not using tokens and just parsing the whole thing and buffering the hex code.

[Fallen Ghost]

Then the [] become useful just to check what's before and what's after, then take out the value.

Or if tokens are to be used, then have the "ld " token, the ",a" token, the "b,c" token and so on. That will definitely need menus. Or a certain number of "hotkeys", user-definable if needed and the access to the numbers and brackets (and menu, please!)


[Edit]
Or add the token like in the TI-OS, but instead of having the cursor going at the end of the token like in Basic, have the cursor go to the "inside" of the token. The buffer would still look like this (numerically): A3,LSB,MSB, but the display would look like:

ld (45A8h),hl

if we add cursor, represented by \ around the character, then it would look like this when moving right from the beginning of the line:

\l\d (45A8h),hl
ld (\4\5A8h),hl
ld (4\5\A8h),hl
ld (45\A\8h),hl
ld (45A\8\h),hl
ld (45A8\h\),hl
ld (45A8h),hl\ \

[c_plus_plus]

Guys, if you will like, ill give you the format that my code input for phasm will be. Then, you can write the editor for it while I write the assembler.

[LolBbq]

[Fallen Ghost]

[c_plus_plus]

I've made a readme I made mainly as a features summery. It has been posted elsewhere on this forum, but I have changed it. It should summarize not only the features, but also it's syntax.

[Fallen Ghost]

Is this what is currently done or going to be? For now, how do you count on us doing % and @? will it be / and theta, respectively?

Anyway, it looks really nice. As I said before, I'm willing to help.

[c_plus_plus]

[WikiGuru]

This seems like a good idea to me, but coding z80 on the calc just doesn't seem so convient (or safe) at all. Better to just do it on the computer.

[LolBbq]

[quote name='Ti-Ho' date='Nov 19 2006, 07:26 PM']This seems like a good idea to me, but coding z80 on the calc just doesn't seem so convient (or safe) at all. Better to just do it on the computer.
[post="91297"]<{POST_SNAPBACK}>[/post][/quote]

It isn't safe at all either on the computer or a calculator. If your code is bugged, it's bugged. However, convenience can be argued. The main reason I proposed this idea was that I have plenty of spare time in math and study halls to learn some ASM. Now, I couldn't do that if I didn't have an on-calc assembler, right? (Unless I installed TASM on my school account) Anyways, this program is going to be an app, so when you code, all you have to do is archive everything and just program away; if it crashes, only the program that caused the crash would be cleared. Anyways, C++, I'll offer to create the GUI for Phasm once I grasp ASM a bit more.