Omnimaga
Calculator Community => Other Calc-Related Projects and Ideas => TI Z80 => Topic started by: the_mad_joob on April 12, 2013, 07:21:56 am
-
A new project on its way...
edit8X+ will mainly be a text viewer|editor.
The main idea is to be able to read text imported from a computer.
I know that doesn't sound very original, but i really wanted to code my own.
Also, i might use it later for a larger purpose.
A challenge will be to make the code OS-independant (avoiding system routines when possible).
*****
PLANNED FEATURES :
compatibility with as many models as possible
The default large font will be used but the characters order will match :
ASCII printable characters (full compatibility)
ISO-8859-1 printable characters (partial compatibility)
CP-1252 printable characters (partial compatibility)
block selection , cut , copy , paste
undo
compatibility with the tab control character
compatibility with different versions of the enter control character :
$0A
$0D
$0D,$0A
temporary system & extra ram usage during edition
view-only mode for archived files too large to be edited (if unsufficient free ram)
new , save as , save
backspace (maybe)
horizontal scrolling
...
*****
WHAT'S DONE FOR NOW :
The font :
242 printable characters
153 of them are compatible with notepad (instead of 92 in the original system font).
The other 89 are specific to the calculator (I needed them for another project).
11 undefined characters (dedicated sprite)
The 3 remaining slots are used for control chars (tab & enter).
*****
Any suggestions are welcome =]
-
Sounding cool ! Now we'll have a decent text editor for our calcs. :3
-
disp_char routine coded =]
-
wait, for the calculator? Nice idea!
I hope it'll turn out well :)
-
I can provide a backspace routine from cmdOS if you want, it's OS-independant :)
-
You mean like I could do .txt.8xp? or rename a .txt to .8xp?
Extraordinary!!!! :D
-
I can provide a backspace routine from cmdOS if you want, it's OS-independant :)
I'm far from that part but thanks a lot for the proposition =]
I'll think of it if i encounter difficulties.
You mean like I could do .txt.8xp? or rename a .txt to .8xp?
I'm not totally sure which variable type i'm gonna use but i'll probably go for the 8xv format.
But yeah, the file will have to be converted to that format before sending it to the calc (not just renamed).
A converter should be included.
Unfortunately, files won't be larger than 65535 bytes, due to VAT limitations.
The converter will automatically split the file if necessary.
-
Handling tab seems to be harder than expected...
-
If you are keeping track of character coordinates, you could try to make 'tab' work by adding, say, 4 to the coordinate, then use AND %11111100 to mask out the lower bits. Or, for 8 or 16 (like if you are doing it by pixel), you could add 8 or 16 and mask with AND %11111000 or AND %11110000 respectively. That will make sure that it aligns properly :)
-
Well I'll be waiting for it. Maybe the best type is Application for variables.
-
I'm actually designing the view mode algorithm.
Is it true that an archived file cannot cross a sector or is it just rumors ?
If yes, that would compromise the handling of large files...
-
It is true: archived files cannot cross sector boundaries.
-
Hmm...
I assume the reason for that is the way how swapping is performed by the OS or something.
Or maybe ti coders were too lazy to handle the sector status byte.
I'm still curious to see what happens when sending a 65535 long variable.
I'll check that out.
-
the_mad_joob as far as I know, you can't. I've tried it with many programs and utilities, the maximum, even if sending directly to archive, is however much USER RAM you have left.
-
That definitely sucks =[
I guess the only way to support very large files would be to handle them as applications.
Unfortunately, that implies some space wasting.
Anyway, if i decide to do so, i have an idea :
Defining a special header that automatically calls edit8x+ when the app is executed.
What you think ?
-
I think that's very smart and probably necessary. If this is user oriented, then ease of use is appreciated. MSD8x has a similar feature for autorun
-
Thx for feedback Dapiano.
Much appreciated =]
-
the_mad_joob as far as I know, you can't. I've tried it with many programs and utilities, the maximum, even if sending directly to archive, is however much USER RAM you have left.
Since i wasn't sure, i decided to give it a try.
The good news is that it works =]
I mean, the OS can totally handle very large variables properly, as soon as they don't cross a sector boundary.
For what i've tested, the ultimate size (actual data) of an archived appvar|group|program is exactly 65522 (name length = 1 in that case).
Of course, such variables cannot be unarchived.
I used wabbitemu for now so i'm not sure yet if ti connect lets you send such files.
Anyway, i prefer to use appvars more than apps, mainly to avoid space loss (and dealing with app signature stuff i must confess =P).
-
Well good luck, then.
I was concerned because the huge size of those files makes them unarchivable, and thus uneditable, unless you edit the flash directly, which is dangerous and hard as F***.
Really, you can handle sector boundaries, but not signatures?
I understand lol
-
Well, since i intend to use all the available ram for edition (including extra ram), it'll be possible to handle such large variables.
Once edition is complete, the variables will be moved back to rom if too big to fit in user ram, so yeah, i'll have to deal with flash writing.
-
Well that'll cause some wear on the archive, but since EVERYBODY focuses on writing to flash as little as possible, even after years of use with this program, it may not ever be a noticed effect. Nobody has ever worn their chip to the bone.
You do realize that will require AT LEAST 1 page of free user archive space, no matter what?
-
Thx again Dapianokid, for the interest you have for this project =]
Are you refering to the swap sector ?
If yes, i'm aware of that (but it's four pages actually).
If no, i've already tried to allocate all the available rom pages and haven't noticed any secondary effects (Maybe you have ?).
-
the_mad_joob as far as I know, you can't. I've tried it with many programs and utilities, the maximum, even if sending directly to archive, is however much USER RAM you have left.
Since i wasn't sure, i decided to give it a try.
The good news is that it works =]
I mean, the OS can totally handle very large variables properly, as soon as they don't cross a sector boundary.
For what i've tested, the ultimate size (actual data) of an archived appvar|group|program is exactly 65522 (name length = 1 in that case).
Of course, such variables cannot be unarchived.
I used wabbitemu for now so i'm not sure yet if ti connect lets you send such files.
Anyway, i prefer to use appvars more than apps, mainly to avoid space loss (and dealing with app signature stuff i must confess =P).
Don't quote me on it, but I'm pretty sure that files can be larger than that. I seem to remember DJ Omnimaga saying he's sent apps (songs made with realsound) that took up most of the archive to his calc before. I just takes a very long time, and the calculator did fail sometimes with larger files. You might do good to set a limit regardless, as things will get slow sending larger apps(from what I've heard). Also, I know all Ti-84s have at least 64k of extra RAM, but what about the 83+? If it is less, will it be a issue?
-
Apps work, but regular variables cannot exceed 65535 bytes of data in archive (take out 9 bytes +name length plus a few more bytes for the header, and 1 byte from the 64KB sector). The reason is because the OS stores the size bytes as a 2-byte word and a 2-byte word can only hold a value from 0 to 65535. Apps, though, use a different technique in that they have a byte telling how many pages they are, so they can be much larger.
-
Don't quote me on it, but I'm pretty sure that files can be larger than that. I seem to remember DJ Omnimaga saying he's sent apps (songs made with realsound) that took up most of the archive to his calc before. I just takes a very long time, and the calculator did fail sometimes with larger files. You might do good to set a limit regardless, as things will get slow sending larger apps(from what I've heard). Also, I know all Ti-84s have at least 64k of extra RAM, but what about the 83+? If it is less, will it be a issue?
I've already decided not to use apps for file storage.
About the total ram, it can go from 48k to 128k, as far as i know.
It won't be an issue, since the usable amount will be auto-detected.
Of course, trying to edit, let's say, a 64k file, will only be possible on models having 128k of ram, tho it will be possible to view that file on other models.
****
A problem i'm currently facing :
When i want to manually add an appvar to the archive, it fails (doesn't appear in mem mgmt).
Here is what i currently do :
- write the appvar in archive
- write the corresponding entry in vat
- adjust (ptemp)
Something else must be done but i dunno what.
Probably another pointer to adjust...
****
EDIT :
Dumb me...
Also got to adjust (ops) & (opbase), maybe (freeram) too.
-
Okay EDITING can be done like this:
Just archive the file, and create a copy in archive/RAM to edit. No need for extra RAM.
Might be slow, though.
By the way, theoretical App size could be as big as 1.07 gigabytes (1 073 725 440) but the largest I"ve ever sent to my calc was 15XX kilobytes (maximum size)... Tilp crashes on that stuff lol
-
Okay EDITING can be done like this:
Just archive the file, and create a copy in archive/RAM to edit. No need for extra RAM.
Might be slow, though.
By the way, theoretical App size could be as big as 1.07 gigabytes (1 073 725 440) but the largest I"ve ever sent to my calc was 15XX kilobytes (maximum size)... Tilp crashes on that stuff lol
Archive works like this:
You can turn a bit OFF, but you cannot turn a bit ON unless you erase the whole 64KB sector. That is the challenge.
I would also like to point out that 1.07 gigabytes is about 1000 times as much archive space as any of these calculators have :P Also, I think you are assuming that it uses a two-byte page size when it actually uses 1 byte. Apps are stored in a completely different format than other variables :/
-
Then only like... 4177920 bytes, nuuu!
lol that's okay though
I know about flash writing. I didn't think I'd have to make that clear to him.
-
I was just pointing out that the_mad_joob has a fairly decent method that he is employing as it currently is :P Note that the flash chip is limited in how often it can be written to, so it would be best to do all of the editing in RAM and save to flash once everything is done.
-
Yes, however it has over 12000 writes per byte, right? :P