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.

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.

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

Quote from: SirCmpwn on July 05, 2010, 04:41:20 am

Quote from: Deep Thought on July 01, 2010, 10:31:11 pm

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

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.

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?

Good luck SirCmpwn, and I hope nothing bad happens to the project like reformatting or something like that

I have something in mind that may do that for you...