Sunday, November 27, 2016

Working on the MEGA65 IDE

It's been a bit of a while since the last post, and there are some good reasons for that.  Chief among those is that I have been busy temporarily moving to Germany with my family for work.  We are staying just long enough that we have to go through all the formalities as though we were staying forever, but not long enough to be able to settle properly.  The net result is even less time available than normal.  However, on the upside, I am located nearby to most of the other MEGA folks for a few months, which is very nice.

What I have been working on in the meantime in what spare moments I can find, is the beginning of the MEGA65 IDE.  This IDE will integrate with the m65dbg debugger, and will run mostly from within LGB's MEGA65 emulator.  That is, the user interface will in fact be a C65 program.  While this might sound strange, it has the added benefit that we will end up with a (hopefully rather nice) native text editor/viewer for the MEGA65.

I have a large part of the editor working now, including the ability to load multiple files (even if they don't all fit in RAM at the same time), switch between them, and even display multiple files on screen at the same time, as the following screen-shot shows, showing some of the C source code of the editor itself loaded (it is being written using the cc65 6502 C compiler):

The idea of the split-screen mode is to make it easier for debugging: The current stack-trace could be displayed visually showing the recent call graph.  Also it is handy to be able to look at two files at once when programming.

The editor also natively uses ASCII instead of PETSCII, so that it is easier to work on source files intended for cross-compilers and cross-assemblers (or in the future at some point, cc65 or ca65 running natively on the MEGA65)

Here is a more ordinary looking screen-shot with a single file in view:

You can see here that we have curly-braces as part of our ASCII-goodness.

The next step is to finish cursor movement functions, and then work on editing functions.  The editor controls are based rather loosely on Emacs and the UNIX shell conventions, e.g., control-A and control-E to jump to start and end of line, respectively.

11 comments:

  1. This helped me to decide using between PESCII and ASCII in The Ace OS - now I decided it will be ASCII what was my attempt, but then was unsure if it will be accepted.
    Same reason like here - cross-platform.
    Miro

    ReplyDelete
  2. I hope it won't be as cumbersome as "vi" is. Will it support any form of mouse select/copy/paste usage? Menus?

    ReplyDelete
    Replies
    1. We don't have enough memory to make a program as hard to use as vi ;)

      More seriously, I intend to add simple to use hold-C= and move cursor to select areas for copy-paste, but haven't got as far yet as thinking about mouse support. Basically I want it to be as useful and nice to use as possible, but there will of course be trade-offs in order to make it fit on the limited hardware.

      But of course, this need not stop people adding their favourite features, as it is open source, after all! It's also written in C, so not as hard to extend as if it were in assembly.

      Paul.

      Delete
    2. Good use of the cursor keys would be fine I guess :)
      Any plan on C/asm syntax highlighting? It makes things so much more readable.

      Delete
    3. I am hoping to add syntax highlighting, but need to think about how I can do it in a compact way. Assembly is easy, because there is no inter-line context to worry about. C is harder. I'd also love to add function folding etc, but that might just be stretching things too far.

      Delete
    4. Could the editor support a simple hypertext format, like Amiga Guide?
      It's simple to write, is human readable, and is very effective as tech documentation, dev guide, etc...
      Any form of keyboard/mouse driven hypertext markup would be nice really.

      Delete
    5. Hello,
      If it were possible, it would still be limited in terms of the styles, as italic worked on the Amiga because the text windows were actually bitplanes. Of course that isn't to say that someone else couldn't write such a feature for it, but it isn't currently top of my priority list.

      Paul.

      Delete
    6. I forgot to ask: How are you generating 4510 code with cc65/ca65 ? Do you plan on expanding them to support the new CPU? Is it already done in a way or another?
      Thx.

      Delete
    7. 4510 support has already been pushed upstream into cc65/ca65. Just specify 65c02 as the CPU type. This also results in cc65 producing slightly smaller code sometimes, although it doesn't take advantage of the stack-relative addressing mode as far as I am aware, which could greatly reduce the size and speed penalty of passing multiple arguments to functions.

      Delete
  3. Fascinating work. I'm trying to find a solution for VIC-II hardware level emulation for my project. If you are interested, is like to get in touch with you to ask some questions and discuss some things.

    ReplyDelete
    Replies
    1. Yes, very interested in advancing the state of VIC-II emulation in general. Poke me if you can't find my email address.

      Paul.

      Delete