Omnimaga
Calculator Community => Other Calc-Related Projects and Ideas => TI Z80 => Topic started by: SirCmpwn on June 22, 2010, 04:42:41 pm
-
Posts feature requests for Mosaic here.
-
Possibly you've already thought of this, but will Mosaic be able to compile to applications, like Axe can/will be able to? I think that might be a useful feature.
-
Complete use of define and equ. I really want those if they aren't already planned. :)
-
Making the hex code publicly viewable (that's actually what I liked about OTBP). Wouldn't it be small and simple to parse each individual nibble and simply display its token after the assembling is complete? Maybe it could be an option?
-
Complete use of define and equ. I really want those if they aren't already planned. :)
Full compatibility with popular include file formats is planned. The goal is for you to be able to pick up your projects and work on them oncalc without any modifications. You can even code off of a flash drive.
Making the hex code publicly viewable (that's actually what I liked about OTBP). Wouldn't it be small and simple to parse each individual nibble and simply display its token after the assembling is complete? Maybe it could be an option?
Probably not. Im basically going to include calcsys though, so you can achieve a similar effect.
Possibly you've already thought of this, but will Mosaic be able to compile to applications, like Axe can/will be able to? I think that might be a useful feature.
Possibly.
-
Making the hex code publicly viewable (that's actually what I liked about OTBP). Wouldn't it be small and simple to parse each individual nibble and simply display its token after the assembling is complete? Maybe it could be an option?
Probably not. Im basically going to include calcsys though, so you can achieve a similar effect.
What do you mean by including CalcSys? Will Mosaic have a built-in hex viewer? That'd be nice :D
-
I think he means that plus the ability to edit the hex (maybe to fix things caused by a program crashing, for example, providing you know what you are doing)
-
Oh, that'd be useful.
So about how many equates are already supported (just for a sense of scale)?
And another feature request (if it hasn't been included already): allowing OTBP-style syntax, at least partly (i.e., not having to type all the special characters like #, _, etc.)
-
It would be a very cool feature to have it do both compiling and disassembly. Even if the disassembler is done very simply without creating local labels or anything complicated like that, it would still be very useful.
-
Constantly displaying the line getting assembled. That would give a sense of "where it is".
-
Wouldn't that be slow? Plus it would assemble each of the 1000+ lines so fast that you wouldn't even have time to read the text
-
Constantly displaying the line getting assembled. That would give a sense of "where it is".
That would be very slow, wouldn't it. It may be cool as an option that could be toggled on or off. :)
-
display every 3rd or 4th or even 5th line of the program?
-
I would prefer maybe just a progress bar or percentage, like in Axe Parser
-
Automatic header insertion (e.g. for Mirage or Ion) in the editor, and an option as to which header should be added.
Does Mosaic support Mirage and Ion equates?
-
Assuming there's enough space left in the app, maybe the more common include files (or, at least, the one for compiling without a shell) could be built into it, like CrunchyOS and Basicbuilder do with programs? That would save space on the calculator, as I think it was said that the include files would take up a lot of space.
Of course, that assumes there would be enough space left on the app to keep it at a single page- I don't know, there might not be. (Unless Mosaic ends up being a two-page app anyway, of course).
-
In Axe, it only updates the progress every 256th parsed expression. Do not update it any more frequently than that! If there is anybody who has used Axe Parser since 0.0.1 you may remember how slow it was when I used to update after every expression... displaying the progress was literally taking up more than 95% of the CPU.
-
yeah I remember that x.x
It took like 10 secs to compile a 500 byte program XD
-
Oh, that's why it seemed to skip right to 100%.
Yeah, a GUI similar to Axe would be nice, and editing/assembling out of archive could be very useful.
-
In Axe, it only updates the progress every 256th parsed expression. Do not update it any more frequently than that! If there is anybody who has used Axe Parser since 0.0.1 you may remember how slow it was when I used to update after every expression... displaying the progress was literally taking up more than 95% of the CPU.
Ah, memories... ;D All the 0.0.x releases did that. :D
I think include files may be kept on a external flash drive, but I'm not sure. ;D
-
Flash drive support or reading from archive would be good, because uncompiled assembly code is massive and you will run out of memory very fast with small programs
-
Whoops, my feature request was already supported long ago:
Yes, there is enough room. Plus, the way that I am doing it, all the code will be in the archive. I also plan on supporting assembling straight from the flash drive, so you can keep your files on a flash drive.
It's a really good idea, since the source and assembled code together would otherwise take up a lot of RAM.
I think include files may be kept on a external flash drive, but I'm not sure. ;D
They don't have to be on a flash drive, do they? Because that would mean that 83+ owners wouldn't be able to use it :(
It'd be convenient if the include files were packaged inside the app, as TC01 mentioned, but being able to edit the include file on-calc would be really useful (that's what I liked about OTBP).
-
Making the hex code publicly viewable (that's actually what I liked about OTBP). Wouldn't it be small and simple to parse each individual nibble and simply display its token after the assembling is complete? Maybe it could be an option?
Probably not. Im basically going to include calcsys though, so you can achieve a similar effect.
What do you mean by including CalcSys? Will Mosaic have a built-in hex viewer? That'd be nice :D
Basically, I will take the source from CalcSys when I am done with Mosaic, and add stuff until I fill up the leftover room on the last page. I say "last page" because although I am trying to target one page, I don't want to lock myself into a single page so early on.
It would be a very cool feature to have it do both compiling and disassembly. Even if the disassembler is done very simply without creating local labels or anything complicated like that, it would still be very useful.
Disassembly, assembly, and hex editing is all planned. The hex editor and disassembler are the first to go in from CalcSys.
Constantly displaying the line getting assembled. That would give a sense of "where it is".
It won't do this. It's a bit complicated, I'll explain below.
Oh, that's why it seemed to skip right to 100%.
Yeah, a GUI similar to Axe would be nice, and editing/assembling out of archive could be very useful.
Assembling from the archive is definately planned. Editing, however, uses the edit buffer and free RAM.
About the errors, the assembler does not stop assembling when it hits an error, unlike OTBP. It makes a note of the error code, where it is, and saves it to a list. Then, it moves on. At the end of assembling, the assembler gives that list to the GUI, which then will display it in a nice, organized and browsable format, which programmers can use to see where in the source each error is. Think of assembling in an IDE, like Visual Studio or ZDS, and you get the idea.
-
Wow nice, I like the idea of being able to know where is our error in a more easier way. With TASM it took me so long to figure out where was my issue in Hello World causing No END Directive Before EOF x.x
-
That's a good idea. The assembler's probably so fast that if it corrects errors as it gets to them, like OTBP, it'll probably just get confusing :)
So what's the include file going to be? Is it a program of its own, or is it stored somewhere inside the Mosaic itself?
-
Include files will be AppVars with raw text, unless this proves impractical. If so, I will revisit them. Of course, popular include file formats from PC assemblers will be supported via flash drives as well. Let me work out basic assembling first, and I'm almost done with that one. I will support include files soon, never fear.
-
Good luck SirCmpwn, and I hope nothing bad happens to the project like reformatting or something like that
-
If it's possible, what about some sort of added ASM call that can would assemble a program without going through the GUI?
And good luck with this!
-
I have something in mind that may do that for you...
-
Do you mean like a hook that lets you use a command like real(prgmNAME) from the home screen and it launches the compiling portion of Mosaic?
-
Yes, something like that.
-
Nice, I would love to see that actually, especially if we want to quickly compile something