Omnimaga
Calculator Community => Other Calc-Related Projects and Ideas => TI Z80 => Topic started by: DrDnar on April 25, 2013, 09:54:01 pm
-
As most of you probably don't know, two years ago I wrote flash editor utility for the TI-84+/SE. The TI-84+CSE has prompted me to revive the project and rewrite most of it. MicrOS now functions on the TI-84+CSE and has the three vital utilities you'd want to see in a Calcsys replacement: port monitor, hex editor, and disassembler. Additionally, MicrOS, once loaded into RAM, does not use ANY B_CALLs; MicrOS has its own set of keyboard, screen, memory, and flash routines. Thus, you can use MicrOS to edit any part of the OS without fear of crashing MicrOS.
To run MicrOS, copy both MICROS and MILO to your calculator. Make sure MICROS is archived! Unarchive MILO and run it with the Asm( command. MILO will archive itself, load MicrOS into RAM, and transfer control to MicrOS. You'll notice that, because MicrOS doesn't use the OS display routines, it feels faster than the OS.
This initial beta release of MicrOS does not feature full functionality of the hex editor. In particular, the user interface side of the flash editor has not been implemented, nor has the find feature, nor the text mode of the hex editor. Currently, I am requesting comments before continuing major development. In particular, I would like opinions on whether to keep the existing font, or move to a 5x7 font with 2x upscaling. The 5x7 font would make displaying text about 40-50% faster, reduce the size of the font data set by over 1.5 KB, and be a lot uglier.
-
Nice :D
-
That is awesome, CalcSys is such a useful utility and it is nice to see it on the cse :D
-
Very cool. I wouldn't mind if the font didn't look as great (160x240 mode maybe?) as long as it's easy to read (the ones shown above seems fine). I wouldn't even have any problem if you used the original 84+ large fonts.
-
The ONLY reason I'm even considering a 2x upscaled font is for use with the 2x width mode. I tried making a font with 2x wide pixels but 1x high pixels, and I didn't like it. (The logic for vertically up-scaling by 2 is dead simple, because MicrOS scans pixels for the font top-down, the left-to-right. Thus, it's a simple matter of outputting each value twice.) The old 6x8 font would be less ugly, but would reduce the text mode to 26 columns and 15 rows. The speed improvement would be closer to 30%. And I'd have to adjust the hex editor and disassembler layout---there'd be no label at the start of each row.
-
The "small" letters definitely look great... But yeah, if the speed is so slow that it's becoming a pain for the user, well...
(Also, could you actually leave the font choice to the user, or would that be too much trouble to make ?)
-
The "small" letters definitely look great... But yeah, if the speed is so slow that it's becoming a pain for the user, well...
Not at all. Like I said, it feels faster than the OS, and the screen repaint time feels like it matches the key repeat rate. It doesn't, but MicrOS feels more responsive than the OS because it can queue a keypress that's registered while the screen is still painting, thanks to improved, interrupt-based keyboard routines. I also optimized some of the screen handling routines. For example PutSClrWind displays a string, and writes whitespace into any unused area; thus, when displaying a new menu, it doesn't need to clear the whole screen at once (including areas that are already blank anyway), then display the string, because PutSClrWind takes care of both, such that each pixel need only be visited once.
(Also, could you actually leave the font choice to the user, or would that be too much trouble to make ?)
It's not technically impossible, but it's definitely not something I would implement. The most you might get is support for it being a compile-time switch.
If you have questions about the internal architecture of MicrOS, I suggest looking in the source code. MicrOS is fairly modular, and the routines are actually documented, so you shouldn't have too much trouble figuring out how to add your own code. You're also free to use MicrOS code in other projects. For example, you can rip the interrupt and keyboard routines out and copy them into another project without much trouble. The convoluted logic of the keyboard debouncing code is probably the best example of well-commented code in the entire Z80 community.
-
In my opinion, lots of the work you've done here is worthy of being put into the "ION" of CSE, with libraries for display and such. This is godly.
FLASH EDITING UTILITY? I see no such thing.
-
I'm confused; how does this stand-alone, low-level calculator management utility relate to a shared programming/graphics library like Ion? To me, they seem to serve different purposes, and one can't really be molded to serve the purpose of the other.
-
Well he says he wrote his very own functions for stuff like this, and I think that the very minimalist nature of the project would serve well for a library that game programmers are waiting patiently for to better write CSE games :)
-
[stupid comment]what exactly is CalcSys, an OS on top of an OS? I have no idea.[/stupid comment]
Looks awesome, though I have no idea what it is :P
-
[stupid comment]what exactly is CalcSys, an OS on top of an OS? I have no idea.[/stupid comment]
Looks awesome, though I have no idea what it is :P
CalcSys is a flash application written for the Ti83+ that hasn't been updated in forever even though it could use some updating. It was basically zStarts partner as the ultimate swiss army knife app, though it came first. It could be described as "WikiTI in an app" for all the things you can learn about the calculator using it, but it's really just a Hex editor for memory on your calc. There is a flash editing version called CalcSysX but no binary of it has been built, it's source is online with BrandonW.
It allows for low level control of just about anything, and if you know the structure of the ASM code of a game well, you can use it to cheat. Axe is especially easy to cheat on :P
You can use it to set system flags to change how the OS works, and dissassemble programs on the fly to find certain instructions. In the final of THIS, I'm guessing, will be included the feature I'm about to describe for Calcsys:
A console. Epic, right? :D
It also has key-press info, font info, token info, and link port monitoring.
My very favorite, though, is hardware port modifying. You can pretty much use calcsys for ANYTHING.
-
Nifty :)
Relayed to TI-Planet (in French), so that hopefully, more people can comment on the matter of the font: https://www.tiplanet.org/forum/viewtopic.php?t=11692
-
General feature requests:
- Preserve the OS backlight setting
- Suppress final keypress on exit (I believe this can be done with a properly placed B_CALL(_GetCSC))
- Allow quitting from the main menu with CLEAR (and is that confirmation to quit necessary?)
- Cancel capability in data entry (CLEAR?)
- Backspace capability in data entry (DEL?)
- Everything CalcSys does that MicrOS still doesn't *runs* (mainly VAT interaction)
Hex editor feature requests:
- Use a unified representation for pages (ports 06/0E/07/0F, port 05, and the cursor location all use different notations)
- Make the string find location default to the location VARS jumps to
- Make a string length specification of 0 enable auto length (partially a feature, partially because 0-length strings don't make sense)
- Allow hex string data entry (lets the user just keep entering data until they press a key to stop)
- Allow searches to wrap
Hex editor bug reports:
- Pressing VARS or G to goto an address doesn't actually put the cursor on that address. The address occupies the first address in view as expected, but the cursor stays in the relative spot on the screen it was before.
Readme issues:
- "Go some free RAM you can use for the string find feature"
- Add a mention that ON halts searching