Omnimaga
Calculator Community => Other Calc-Related Projects and Ideas => TI Z80 => Topic started by: FloppusMaximus on December 17, 2012, 09:58:12 pm
-
I've released version 0.4 of Mimas (http://www.ticalc.org/archives/files/fileinfo/431/43140.html), an on-calculator IDE for writing assembly programs on the TI-83+/84+.
First, this release fixes a number of long-standing bugs and annoyances:
- incorrect definition of fullScrnDraw
- plotLoc flag should be cleared upon exiting
- div/mod operators
- detection of dependency loops
- archive-on-exit when multiple programs were edited
- support for IFDEF/IFNDEF in asmto8xv
Second, I've made a few improvements to the conversion tools:
- use a default output filename for 8xvtoasm (instead of standard output)
- prompt before overwriting output files
- asmto8xv accepts options --case-sensitive, --preserve-case, and --fold-case
And third, I've added some new features in the form of "plugins":
- library symbols menu
- instruction info popup
- scroll bar
The plugin concept is something of an experiment. The idea is that this way I can add new, optional features, while keeping the base application the same size. I'm interested to see what folks think of this - is it too complicated? Is it worth the (not insignificant) extra effort of continuing to add features this way?
As always, I welcome your comments, suggestions, bug reports, flames, etc.
-
wow, pretty nice, maybe i should start trying to learn asm again >.>
-
Woot, gotta transfer this to my calcs soon. Looks great!
-
I use Mimas since two years, so keep it this way :D ! And all the features you described really look useful !
-
Craps. I blew up my link port so I cannot send this D:
Oh and another request you might add in a next release: Empty lines. I find it quite useful if you can add empty lines to organize your code. :D
-
aeTIos, you can create a comment with no text by just typing a semicolon. It's what I do.
I find that creating a simple program in Mimas to test something is faster than creating it on a computer and sending it over. Certainly, an in-system assembler is useful, if not always pleasant.
You might consider making the C000h limiter more flexible, by allowing one to define any address. This would be useful for making applications and for program only intended for the TI-83+SE/TI-84+/SE, which allow code up to 0C3FFh (http://wikiti.brandonw.net/index.php?title=83Plus:Ports:26).
-
I'm not opposed to the idea, but I'm pretty sure you're reading that wrong. It's not that execution is allowed on page 80, but that it would be allowed in the first kilobyte of page 82 if the execution limits did not wrap around at 32k (see port 21.)
It's not at all difficult to run large programs on the SE/84+: you can temporarily copy page 80 to page 83 and set port 5 to 3. Of course, you can't use the system USB routines, and of course you need to restore the app base page table afterwards.
Blank lines: visually, I kind of like the use of blank comments instead, since they show you that there's something there (like the colons at the start of lines in the BASIC editor, if you see a semicolon at the bottom of the screen you know there's more to come, but if it's a blank line you know you're at the end of the section.) UI-wise, maybe it would make sense for pressing Enter/Ins to automatically create a blank comment (if you don't type anything else.)
-
Blank lines: visually, I kind of like the use of blank comments instead, since they show you that there's something there (like the colons at the start of lines in the BASIC editor, if you see a semicolon at the bottom of the screen you know there's more to come, but if it's a blank line you know you're at the end of the section.)
I'd never thought of doing that :P Thanks for the tip.
Mimas is one of my favorite apps (it's either Mimas or Calcsys or Axe for me). IMO it's got one of the most polished UIs I've seen so far. Glad you're working on it and can't wait to see what happens next :)
-
I'm not opposed to the idea, but I'm pretty sure you're reading that wrong. It's not that execution is allowed on page 80, but that it would be allowed in the first kilobyte of page 82 if the execution limits did not wrap around at 32k (see port 21.)
Ah, you're right.
-
I would just like to remind people that making all of $C000-$FFFF executable is entirely possible. For example, see Fullrene (http://ourl.ca/13513).
-
And I would like to remind everyone that unlocking flash is dangerous and not to be done lightly. But that's a discussion for another time and place.
-
I like Mimas, I think it is the best on-calc asm editor (other than the AsmPrgm, which has TOTAL functionality at the cost of nonlegibility)
I like the plugin idea, you can add some sweet stuff with that!
Could someone make a plugin for Mimas that's basically the Asm in 28 Days tutorial, so I could read asmin28days on-calc and on the go/at school with no computer?
-
Wow, how did I not see this update! Mimas does indeed have a very well made interface and I definitely like to use it for the more complicated pieces of code. I can't wait to give it a try.
-
BTW is Mimas bootstrapped? :P Just wondering...
-
Could someone make a plugin for Mimas that's basically the Asm in 28 Days tutorial, so I could read asmin28days on-calc and on the go/at school with no computer?
Moody's Flash Book app is, perhaps, the best e-book reader for the TI-83+ series.
BTW is Mimas bootstrapped? :P Just wondering...
No, Mimas is written for ZDS. I don't think Mimas could build a 2-page app at once due to memory limitations. It also doesn't support directly writing to flash. It's certainly possible to build and sign apps on-calc, but he seems unlikely to implement such functionality since he seems to think screwing with flash is too dangerous.
-
OMG!!!! This is so cool! Now I don't have to remember all the hexadecimal opcodes! (But first I need a link cable :3 )
-
No, Mimas is written for ZDS.
Well, it's written for tpasm, but it's more or less the same.
I don't think Mimas could build a 2-page app at once due to memory limitations. It also doesn't support directly writing to flash. It's certainly possible to build and sign apps on-calc, but he seems unlikely to implement such functionality since he seems to think screwing with flash is too dangerous.
No, I would merely say that it needs to be approached with appropriate caution. A program that, one time in ten, crashes and wipes your RAM is annoying. A program that, one time in a thousand, crashes and corrupts the OS, or your archived data, is intolerable.
I do hope to eventually support assembling Flash apps on the calculator - it could be implemented as a plugin, although that might be too slow. The larger problem with using Mimas to assemble Mimas would be the need for macros (which I also intend to implement in the future.) Also, I don't know how many symbols are used in Mimas - there may not be enough RAM for all of them. :P
I do like the idea of an assembly tutorial on calc. It could certainly be done as an ebook, but maybe it could be more interactive than that? I'm imagining an app that installs itself with a key hook so that, while you're writing your program, or hacking with Calcsys, or whatever, you could press a key to pop up the tutorial, read some more, then go back to what you were doing. Something like Virtual Calc but much more lightweight.
-
Now I don't have an excuse. Now I have to learn ASM.
-
#define wont work
-
RTFM. It is not implemented yet.
Edit from the future : Sorry if I offended anyone. That's just how you get when you know the Minecraft community which tends to avoid reading /any/ doc and complains about it not working.
-
If you want to define a constant, the syntax is as follows:
symbol = valueThere is no macro support.
-
So, #define (as used in tasm/spasm) has two fundamentally different purposes:
- "Expression-like" macros:
#define SUM(x,y) (x + y)
#define PC ($)
- "Instruction-like" macros:
#define CP_HL(reg) or a / sbc hl,reg / add hl,reg
#define CRASH rst 00h
I probably won't implement the former type unless there is huge demand. But as DrDnar points out, often macros of this sort are really just constants, and an equate would do equally well. (I suppose it's also worth mentioning that since Mimas is a true multi-pass assembler, you can use equates in ways that wouldn't work in spasm or tasm.)
As far as instruction-like macros, I've thought quite a bit about them since I first started the project. There are several ways that they could be implemented:
- Call by value: arguments to a macro must be constant numeric expressions, which are evaluated before calling the macro. This would be the easiest to implement but also very limited (registers can't be used as arguments; symbols used as args can't be modified; the behavior of PC, @B, and @F would be unlike the way macros are expected to work.) Many folks would rightly say that this isn't really a macro.
- Call by reference: arguments could be either constant expressions or literal symbols. The bookkeeping gets a little bit more complicated than call-by-value; this would allow a macro to define symbols that are passed as arguments.
- Call by name: arguments could be any expression not involving a register, and would be evaluated at the point in the macro where they're used (so PC would work the way you'd expect, and arguments that aren't used wouldn't be evaluated.)
- Any of the above plus special support for registers: I could add special syntax that would let you choose a register by number. For example, CP_HL above could be written as "OR A / SBC HL,R#(reg) / ADD HL,R#(reg)", and to call it you could write "CP_HL(\BC)" (note the backslash), or equivalently write "CP_HL(8)" (8 being the internal code for BC.) (Obviously the exact syntax is up for debate.)
- Call by syntactic substitution: arguments could be any valid expression (including registers), and would essentially be pasted into the syntax tree at the appropriate location. This would require special syntax for parameter names (such as "SBC HL,{reg}") so that Mimas knows not to fully parse the instruction until compile time. This would be a PITA to implement (especially if macros defined in one source file can be called from a different file, which I think is important to support.)
- Call by textual substitution: take the text of the argument and paste it into the text of the macro, then parse the result. This is, I think, less semantically "correct" than syntactic substitution (you lose symbol scoping) and possibly also a bit slower than the other options, but is arguably closest to the way tasm does it. Like syntactic substitution, this would require special syntax for parameter names within the body of the macro.
Mostly unrelated to the above, I've also considered having macros use numbered parameters rather than named ones; e.g., you'd have to write CP_HL as "or a / sbc hl,#1 / add hl,#1" - sort of like function parameters in a shell script. This would be considerably easier to implement than named parameters, plus would offer the possibility of variadic macros - the downside would be decreased readability. In fact, the easiest way to implement this would be for all macros to be variadic, but then you lose error checking.
What do you folks think? What do you typically use macros for, and how do you intuitively expect them to work?
-
I personally like the last version that you presented. It loses readability, but I really think that that is okay with macro's. We can just describe what they do in a readme or something if it is really needed.
As well, I am not sure how you parse the files, but the way I have been doing it is to basically read the source as a type of program (I basically used ideas that I had already developed in Grammer+FileSyst). When a letter is concatenated with an opening parentheses, it tells the parser that it is a macro, so it searches the file for the macro and treats it as a "subroutine" of source code. This way you can add in some complicated macros for sure. I have been thinking of doing this for defining variables, too. It would really slow down compile times, but it would allow the user to define variables like String = "Hello" and then adding in a command like len(String) would make this easy:
.db len(String),String
I have wished to be able to this quite often instead of needing to count the length of a string with PC math and labels.
-
Mostly unrelated to the above, did you released any documentation on writing plug-ins for Mimas ? I dig through all the files included in TiCalc's mimas-0.4.zip and found many docs on how to use them, install them etc but nothing about how to create one D:
-
Mostly unrelated to the above, did you released any documentation on writing plug-ins for Mimas ? I dig through all the files included in TiCalc's mimas-0.4.zip and found many docs on how to use them, install them etc but nothing about how to create one D:
He expects you to dig through to the source code and base your plugin on the example provided. This is an attitude common in Unix/Linux culture.
-
But I'm not good enough in ASM to understand how a system works from a code :(
-
It's great that you're interested in writing a new plugin! What do you want it to do?
It's true that all the documentation is in the code. The documentation of individual routines is extensive (and where should it go but in the code?) What I haven't written, and probably should, is a high-level "introductory guide to hacking Mimas" - doing that hasn't been a priority. I am, of course, always willing to answer any questions you have.
As far as the actual process of writing a plugin - first of all, there aren't any general-purpose hooks that new plugins could attach themselves to. You could write a new plugin and build it against Mimas 0.4, but it wouldn't do anything. So to create a new plugin, you'll first need to figure out where in the app those hooks need to be added. You'll need to decide on the inputs and outputs for the plugin. Assign it a plugin ID in defs.inc. Depending on what the plugin does, it's likely that you'll want to call Mimas routines that aren't part of the current API - to do that, add them to plugapi.dat.
-
So I think writing a plugin requires modifying and recompiling Mimas ? If so, it doesn't make plugins portable :/
And I wanted to write a plugin to add to the parser CHIP-8 pseudo-assembly mnemonics, I wonder if that's possible.
-
I think what Flop is getting at is that he is still working on the plug-in API; it hasn't really be finalized. He encourages you to add hooks, which may be incorporated into the official releases.
-
Right, well, there isn't a fixed ABI partly because the plugin feature is new and experimental, but also because a fixed ABI would require some space to store a table of addresses. The same goes for hooks: it would be nice to have a system of hooks whereby plugins could register their interest in various sorts of events - but implementing that would take up valuable space.
I'm not really familiar with CHIP-8. Are you saying you want to be able to generate CHIP-8 bytecode, or that you want to use CHIP-8 mnemonics and have them compiled into Z80 machine code? Either way it is definitely possible. Here's what needs to be done to define a new instruction type:
- Choose a bytecode format. Special instructions consist of a 7-bit ID (23 of which are currently defined) and up to 62 bytes of argument data. The arguments can either be expressions or raw binary data (indicated by bit 7 of the ID byte.)
- Write a routine to parse text into a bytecode instruction.
- Write a routine to format a bytecode instruction as text.
- Write a routine to assemble a bytecode instruction.
- Optional but recommended: also patch asmto8xv and 8xvtoasm :)
So this would require three calls to the plugin: one in ParseInstruction, one in FormatInstruction, and one in AssembleProgramInstr.
-
I seriously doubt I'm good enough to write a hook-like loader, so I'll stay with modifying Mimas to integrate the plugin and I'll let you do what you can :/
I want to make Mimas able to compile CHIP-8 mnemonics into CHIP-8 bytecode (which you'll can use with a CHIP-8 interpreter I'm currently working on).
In regards of all the things to do, I think it'd be better to have a bit of training with a simpler plugin, like one to display line numbers, I'll start with that.
-
*bump*
When can defines be used and such? Also, I've found some bugs while using the (IX) register, I have to do (IX+0) and such instead of just (IX)
-
HOLY NECROPOST :o
but yeah, sorry, can't help you
i'm not so much of an asm programmer (the only command i know is C9-Return)
and i'm not sure if you're going to get another reply since this topic is kinda old...
-
Well, Ben is still around (as far as I know), so I wouldn't be surprised if he did reply.
-
When can defines be used and such?
I'm not sure what you mean by this. You can define anything you want, and you chain defines. (That is, make one define based on another.)
Also, I've found some bugs while using the (IX) register, I have to do (IX+0) and such instead of just (IX)
It's a well-known issue. Just deal with it.
-
I thought #define wasn't implemented yet ?
-
Could you add support for TASM commands?
It seems like that's the only program for calculator programming people with bother writing tutorials about!
By the way Great Program!!
O.O :o
-
This is because the updated version of the most used ASM guide is not on ticalc.org, but rather a different URL now. Unfortunately, https://tutorials.eeems.ca/ASMin28Days/lesson/toc.html shows a Cloudflare error and I forgot the other link. I am surprised people even get TASM to run considering I never got it to run on any 64-bit system.
-
This is because the updated version of the most used ASM guide is not on ticalc.org, but rather a different URL now. Unfortunately, https://tutorials.eeems.ca/ASMin28Days/lesson/toc.html shows a Cloudflare error and I forgot the other link. I am surprised people even get TASM to run considering I never got it to run on any 64-bit system.
It's up for me. I think I was just having network issues when you were looking.