3/3/11 Development postponed due to short attention span and amazing idea for a PC application that could change how a lot of people develop asm programs for Z80 platforms. More info and personal project thread in the near future.
3/2/11 It's March already? Sorta got sidetracked, but still working on it. I've been reading up on encryption and information theory for the encryption 'module'. I want to code many different schemes, but I don't want to inflate the module more than I need to. I have neat ideas like self-extracting programs, so I might expand this into a separate project down the road.
2/26/11 Finished up the interface and most of the command parser. Built the command dictionary with modularity in mind, which is making development easier, surprisingly. Just started working on implementing a lot of tools. I'd really really like suggestions and ideas about now. Adding a screenshot. Uploading stable demo release soon with source.
2/24/11 Finishing up the interface, then starting on command parser.

---

Hi, I'm new here. My name's Brandon. I'm a computer geek and Junior in high school. I decided to return to the TI scene after a hiatus, which meant relearning Z80 Asm and all of its little nuances. So I'm feeling refreshed enough to start 83+ development.

So for my first full-scale project, I've decided to go for a lightweight console program that packs in loads of extremely useful tools for managing your calculator. Some tools I plan to implement might be very appealing to both asm and basic developers.

Current ideas:
- modular design for possible 3rd party extensions
- some ti-basic function hook for running commands externally
- prgm lock
- prgm rename
- prgm block copy-paste (useful for basic/axe)
- prgm/var archive/delete
- regex searching
- data (de)compression (Huffman, LZ77, RLE/VLE, ...)
- run raw asm (might add mnemonic support much later)*
- data encryption (various methods)
- generate checksum of prgm/appvar/group or buffer (MD5, SHA1)
- easy system flags control
- memory viewer
- disassemble binary and export to Mimas
- interactive debugger (Mimas source support)
- bf interpreter (;
- ideas welcomed!

Screenies:


tl;dr making tiny CLI with collection of useful utilities, need ideas/suggestions/references.

First of all, welcome to Cemetech! You can introduce yourself here.


Is this an OS, or a Flash App? Some apps, like MirageOS, have OS in the name but are actually apps.

Topic moved to "Your Projects" section.

Thanks for that, shaun. Progbeard, welcome to Cemetech. What about making it a DCS ASM program? That would work decently, I think.

*bump* Brandon, while editing your first post with new info and screenshots is excellent, I recommend that you also bump the topic, otherwise most people won't notice the updates.

Oh, I was planning on it. I just hadn't finished editing it.

--

Okay, here's my idea for block copy-paste. You open your basic or axe source to copy from and insert two [->]'s around the block you want to copy, then open the source you want to copy to and insert one [->] where you want the code to be copied. Then the code is copied over and the [->]'s are removed in the process for you.

Sound useful or should I leave this out?

I think that that sounds useful, but I bet it will be fairly difficult to implement. Good luck!

I think that this looks really good. I do not have suggestions at the moment, but I like this idea.

*bump*

Fun stuff. I have a hectic schedule at the moment with school and going through training for Best Buy (:, but if anyone wants to talk or work with me in my off-time, you can send me a PM/email.

Good luck with the orientation; hope you're able to get back to this soon.

*bamp*

I'll be returning to this project shortly. About 50% more of the compression coding needs to be written before I release a development snapshot.

After that, so much work will need to be done for making the Mimas source command line debugger. Running code in realtime through the debugger is going to be a few times slower unfortunately, since it relies on partial emulation, but that's tolerable for debugging. Still working out how I can protect at least PowerCX. I'll end up mapping PlotSScreen and PCX's console buffer to buffers in PowerCX itself and protecting program memory from read/write. The target program would be only partially emulated, since resources handicap any kind of virtualization. This is going to be quite interesting. Sorry for rambling.

Wait, you are going to have ASM program debugging?

What kind of compression? I feel like I might have asked you this already.

How are you going to protect program memory from reading and writing? I'll be very interested to see how you implement this on a CPU that lacks memory page protection flags, traps, and hardware breakpoints.

I think he is going to interpret the machine code for debugging.

If he does fully-virtual emulation, he can indeed trap any kind of breakpoint or memory access that he wants, but it will indeed be painfully slow. I bet many coders might be willing to put up with "painfully slow" for the sake of a powerful on-calc debugger, though.

Exactly, Kerm. I finally realized there's really no way to implement this without complete virtualization. If you have any ideas, let me know.

As for the compressor, Kerm, I wrote Huffman, RLE, and LZ77 routines with mechanisms to warn if data will be inflated. I've been so busy lately, you're gonna have to excuse me if I postpone a lot of what I do. School, work, new date.

Best of luck on real life; I'm glad that you're putting it first. And I agree, full virtualization is really your only option here, unfortunately. I'm curious about some specs on the routine sizes and speeds for those three compression mechanisms.