A new on calc z80 ASM compiler

[LolBbq]

I believe I speak for the community when I say we need a better Z80 ASM editor and compiler that resides on the calc. Of the current ASM compilers, TASM-on-calc is very hard to use (in my opinion), and not very user-friendly. There are various other compilers, but none of them are quite developed. Now, if I were to coerce UTI to group together and develop a flash app ASM editor and compiler, would anyone agree or try to take on this project? For starting ideas, I guess z80.tab and ti83plus.inc could be included in the app itself by using multiple ROM pages. All the functions could be accessed through menus similar to TI-BASIC editor's interface, and we would need to find a good syntax parser. I think if we can get enough members to accept the idea, then we could assemble a project forum and get discussion going there.

[Fallen Ghost]

Ok, why not, there is already Chasm, but it does not tell if there is an error in the lines, so if there was one, then your calc is pretty much assured ram-clearing. The only things missing in it are the error detection, and relative adresses (for jr and djnz). And maybe somehow equates for TI-OS rom calls and why not even Ion ones.

I'm working on something else now, but I should be able to spare time for that project too.

[LolBbq]

This flash app should address all the shortcomings of previous assemblers, but also should provide menus for registers and commands to provide ease of programming. Equates should be handled with a large part of the rom page partitioned off to contain purely all rom calls and manifest constants.

[Fallen Ghost]

Chasm had all the instructions hard-coded registers. Menus, well, they might be usefull. Like you want ld h,l, then go in menu "Data" and there will be the ld sub-menu, which will contain the instruction with all types of parameters (hey, that sounds like tokens, but in the place, it will be the instruction's opcode). And also let's make the .db instruction available!!!! (the most useful thing that most compilers don't even have). Using tokens should be nice because you know you can't have errors (except synthax)

Some menu like the TI menus, stored in archive, preferably 1 page, but if all (equates, instructions, GUI, compiler) is added, then 2.

[LolBbq]

I like that idea for menus, but I was thinking about maybe pressing [PRGM] to access, say, XOR, and then pressing [VARS] to access all valid registers that can be used with that command. It would lessen the size of the [PRGM] menu and would allow the programmer to press a few shortcuts to access either command or register.

Edit: Instead of accessing XOR thru [PRGM], I think it should be more related to TI-BASIC's interface of [2nd][Test], or using [2nd][Draw] for common bcalls for LCD clearing, etc. Also, I guess the use of "tokens" or just a plain conversion to hex could suffice if the user needed to save the asm code but not compile it.

[Fallen Ghost]

Here is what I think about your idea: Great! (what were you expecting?)

So here's the scheme ({} are keypresses, [] are menus, - are options, they can be combined). They could also be sub-menued classed like in the TI-OS menus (right, left keys)

{2nd}{Catalog}[Overall]
-[Data move]
-[Arithmetic]
-[Bit test]
-[Shift/Rotate]
-[Control]
-[Hardware]
-[B_CALLs]

{Prgm}[Control]
-Call
-DJNZ
-JP
-JR
-Nop
-Ret
-Reti
-Retn
-RST

{Stat}[Data move]
-EX
-EXX
-LD
-LDD
-LDDR
-LDI
-LDIR
-POP
-PUSH

{Apps}[Hardware]
-DI
-EI
-HALT
-IM
-IN
-IND
-INDR
-INI
-INIR
-OTDR
-OTIR
-OUT
-OUTD
-OUTI

{2nd}{Test}[Bit test]
-And
-Bit
-CCF
-Or
-Res
-SCF
-Set
-Xor

{X-1}[Arithmetic]
-ADC
-ADD
-CP
-CPD
-CPDR
-CPI
-CPIR
-CPL
-DAA
-DEC
-INC
-NEG
-SBC
-SUB

{X2}[Shift/Rotate]
-RL
-RLA
-RLC
-RLCA
-RLD
-RR
-RRA
-RRC
-RRCA
-RRD
-SLA
-SLL
-SRA
-SRL

{Vars}[B_CALLs]
-List of all possible B_CALLs classed in graphic, and all kind of stuff.



[Edit]Is it only me or we are kind of alone?

[LolBbq]

Yes, Fallen Ghost, we are alone in this cold void of what we call UTI. =P lol. I'm loving the menus idea a lot, especially the organization and classification of commands. If only this could attract more attention...maybe we'll have to wait a few days.

[Fallen Ghost]

Or maybe because of the hour it is now. Too late for Europe, suppertime for western america, news time for easterna america.

Or maybe just a feeling of boringness after a school day.

The only thing I think about is how the registers would have to be. Self-token registers? (would require to add certain numbers to the opcode, and also the fact that the register codes are the same for most instructions, so choose a difference between each) Instruction+register token, which could take a bit more space in the table, but save much for the compiler code (and less errors possible). Text-file (like Chasm or Computer version of TASM32 with .z80 files), that require more space, but let the user choose more and decide what to do (hmm), but alot more errors, code-check, string check for determining instruction, and errors (again!?!), a huge more memory taking of the source-code and instruction table. (so really not an option if we want a 1-page apps).

The GUI wouldn't exactly need to be beautiful (the normal one is okay, but just getting of that lousy line in the top of screen "prgm:ABCDEFGH")

501th post!! youppi

[Edit]Now I am really alone in a place called UTI forums

[LolBbq]

I'm not in favor of the text file because of the immense amount of processing power required to go through the entire file to find maybe one command. I still like the token idea, where an instruction combined with a register would automatically be recognized by the program as the appropriate hex code, therefore easy to save the asm code or to compile.

As for the GUI, I don't want one as simplistic as the TI-BASIC one, maybe one where pressing [Y=] could bring up a menu for saving the code or compiling, etc.

Well, I'll just let it roll, I guess, I'll be out in Boston for the whole day tomorrow and I'll get back to this on Friday.

[Fallen Ghost]

[c_plus_plus]

I am working on an on-calc asm! It is called Phasm. It gives errors too. I will later make a editor after I have completed the assembler itself. If you would like, I will add menus to the editor (good idea!) The first version I am currently working on is a ram program. I will later change it to an app (when I finish the assembler, should I make the app first or the editor?)

[Fallen Ghost]

[elfprince13]

http://www.ticalc.org/archives/files/fileinfo/392/39241.html

yes it works, and yes its in Basic, and yes its the best one Ive seen thus far.

[Fallen Ghost]

Oh my god! that is really nice. Ok, the program is big, but it should work. I'll try it tomorrow (cause I need sleep).

I'll try to make an ASM program that Arcs that all when the Basic program quits (if needed, I don't want to redownload the compiler each time), with it, just to see how it works well.

I'll also try to get what instructions are accepted and what are not.

[Edit]After reading, the z80 instruction file is in BASIC, so editable on-calc too, so we can add instructions (I think). I'll contact the creator for it.

[Iambian]

I couldn't help but notice this topic has gotten some interest. If you're still planning to build this project, you may want to consider the use of this utility:

http://www.unitedti.org/index.php?download=228

[LolBbq]

Well I'm considering that it would be run with asm, but I don't want to hijack C++'s program and totally run it. I really don't know what is best, I guess trial and error would provide information about that. Anyways, if we can get a group instead of a few wandering souls, maybe we can assemble a project team.

[Fallen Ghost]

After testing out that compiler, hem, I really am not sure at all about if it works that great. He says it does look errors, but it doesn't really.

Ok, well, if the first letter of the instruction isn't in the z80inc.8xp file, then there's an error return, but otherwise, it justs give out some strange data. And as it must all be in lowercase, it takes so much space (for the source code)

Home-made solutions are often better. I'll stick with a new one.

[LolBbq]

I still am flipfloppy on the decision of how to use the includes. I think the we should supply editable .incs with it, but I don't think we can make them part of the program if the program is going to be an app (it resides in flash rom, therefore no data of itself can be edited). Then again, keeping them as .8xp files are ok I guess.

[Fallen Ghost]

[LolBbq]

Or, just have all three part of the app and just let the user define their own include if they want to. So that way if people are fine with the standard .inc then just let them be.