First and foremost, lack of usable memory. The editor buffer had to be capped at 16Kb because of programs size limitations, namely that the saferam is shared between the program code, the BSS (containing the buffer), and the heap. I moved the buffer to vram because then it can be one continuous, relatively safe, section of memory. However, this means I can't do 8bpp double buffering, and the graphics are horribly choppy with single buffering. 4bpp rewrite = up to 4 buffers (two used for the editor buffer and two for graphics) = can make smooth graphics with less memory used.
Additionally, column major mode = no diagonal line.

Also on the plate are rewrites to the way it renders the text; currently it draws every character on the screen after every keypress, causing the editor to become noticeably slower as the screen fills up. I'd like to fix that, and using 4bpp means the bits and pieces I need to store take up less space, so I can keep more around. For example, the status bars don't change, so I can just draw them once to a different buffer and copy them onto the screen any time they need to be drawn. (They get destroyed on the screen by the menus, so I can't just keep them around).

Some other things need to be reworked as well, like the rc file parsing. I'm not happy with how fragile it is, and how oddly specific certain aspects of the file have to be, like the spacing.

All in all, I've decided it's easier to rewrite the whole thing and pull chunks of code when necessary from the original rather than to start with the original and redo certain portions.

Current progress.
Right now, the screen is in 4bpp mode, column major.
The line drawing routine is a fixed point efla written in C, and which will soon be replaced with a faster assembly one.
The rest of the routines, such as double, triple, and quadruple buffering, blitting, and pixel operations are written in assembly.
Also if anyone can help me turn this into a clib-like dll afterward that would be great

CEdit will now soon have a computer-side counterpart for editing and/or creating files that work with the calculator.

Development of CEdit2 has continued. Currently, font routines work. And I think they work pretty well, considering the amount of thought I've given to optimization.Please don't kill me, I know memcpy for drawing is bad, I'll rewrite them in ASM later

I'm glad to see this still worked on. I didn't check it often for progress before as I just got back into calc stuff 2 years ago and checked mostly games at first, but this sounds very promising. Font colors seems like a nice addition for notes. My notes would often get cluttered if I had school so having parts in different colors definitively helps. Will you add support for fonts generated by Iambian's AA.8xp font tool?

Odds are, no.
Cedit uses a specific font format, which is partly caused by its rather strange drawing routines. It stores fonts as 8x16 bitmaps, packed down to 16 8 bit integers per character, and stored column major with two integers per column. (This is because it uses column major mode for drawing). The uncompressed fonts are 64 8 but integers per 8x16 character, because it uses 4bpp mode.
However, I might be able to put in some kind of parser later to do conversions.

Yet another double post, but it's a rather large status update.


As stated in the image, I have completely rewritten the keypress routines. Now, it's possible to use modifiers by pressing and releasing them, like the CE's homescreen, or by holding them down. In fact, they follow fairly similar mechanics to the 68K calcs.

TODO:
(re)implement file loading and/or saving, including some kind of CoW as an optional flag.

It might be possible as well to do triple buffering; if there's a region of memory that's relatively safe to use and is 38400 bytes in size, I can just use that as an additional vram buffer.

I ended up tossing out the rendering and storage backends because of how hard they were to work with. The renderer needs a little bit of work, especially with optimization, but now it's a little bit better

I now have an abstraction for the text buffer that lets me treat it as an expandable array instead of two chunks.
As mentioned on IRC there is also a new burst typing mode meant to reduce dropped keystrokes when typing on a computer keyboard. This mode works by skipping all the drawing routines and program logic except for decoding and buffering typed characters before inserting them in a large chunk.

My current plan for the renderer is a two-stage process:
1) render text to a big array of strings
2) render the array to the screen

My font drawing routines are fairly fast, so redrawing the entire screen isn't too much of an issue. However, I'm still wondering whether there's a more efficient (faster) way to do this. I'm not short on RAM because I can just eat the rest of the vram, so if anyone has any ideas, please share them!

EDIT:
A big thank you to Zaalane and calc84maniac who helped me rewrite my C putChar routine into (decently optimized) assembly. It's much faster at rendering now, but the rendering engine still needs a rewrite.