Omnimaga
Calculator Community => Other Calc-Related Projects and Ideas => TI Z80 => Topic started by: Iambian on March 30, 2009, 11:37:57 pm
-
Made at the request of DJ_Omnimaga. It is a program that copies a file and puts it into a temporary program XTEMP000 to XTEMP009. To use it, first read its documentation, which is included in the zip file attached to this post.
Known limitations and bugs:
(1) Don't try to pass a zero-sized string. Although hard (I'd think) to do by accident, don't try it.
(2) The program won't copy things from RAM. The item to be copied must reside in Flash. Doesn't hurt to try, as the program will refuse to do it.
(3) Not really a limitation, but more along the lines of prevention: The copy to the temp file will not be made if the temp file in question already exists.
On-calc, this program weighs in at 179 bytes. *could* make it smaller if I tried. You know, stuff to the tune of excluding crash-preventing checks.
-
Is this in cletic, or just emulate from xLIB (not emulated, but what xLIB had)? This is definitely optimized well enough, but you can make it smaller if you want haha
-
Wow thanks so much iambian, this should be smaller (and less limited) than resource. I hope it doesn't have any bugs x.x I'll do some testing
Kalan, this actually does something similar than xlib/celtic XTEMP function (real(10, to be exact), but for people who dont want to carry a huge 16384 bytes app with their game just for one single function (since some pure BASIC people might still want to use minimum ASM to prevent their game from being split into chapters like the old Illusiat series or FFTOM)
-
First bug report:
It appears the program has trouble copying programs that contains tokens that are only useable by TI-BASIC programmers on later OSes, such as %, $, #, |, _, the black arrows. When trying to copy such program, either part of the beginning code will be truncated or it will be replaced with random stuff such as RegEx. I use these characters a lot in strings, so it could be a serious issue. I am uncertain if this bug is related directly to these characters but I didn't got able to reproduce it on other files yet. Basically the copied program is corrupted. Since it's locked I had to use CODEX to unlock it to view the content, and could see the difference compared to the original file. All readme instructions followed.
EDIT: Confirmed that it only occurs with programs containing such characters early in it. I'M unsure why this happens, but this only happened with two specific files (two programs containing just strings loaded based on ifs E=a number)
EDIT 2(at least the prgm doesn,t seems signifiantly much slower than RESOURCE, even if I need to run it twice (once for deleting the prgm then another time to copy another)
EDIT 3: Attached to this post is a screenshot of the program code in TI-BASIC editor. Since I couldn't get the files with such characters to send on wabbitemu (until I reinstalled TI-Connect) I used my digital cam for now
-
Do you delete the temp after it is created the first time? It may be that because the program was already created it was overwriten, which worked instead of making it from scratch?
-
Must optimize....
:If E=0
Can be changed to...
:If not(E
-
Must optimize....
:If E=0
Can be changed to...
:If not(E
He will do what is needed later for that, just be glad he is gracing us with a ti-project again!
-
Do you delete the temp after it is created the first time? It may be that because the program was already created it was overwriten, which worked instead of making it from scratch?
Though I may have to check that, the program should refuse to write to a temp file that already exists.
Also, DJ_Omnimaga. Did you try to unarchive, change something "minor" (i.e. add in a closing parenthesis), and rearchive the variable prior to trying it again? If the problem clears up, then it might have something to do with cross-page boundaries that aren't being taken care of (which shouldn't happen because a romcall is used to do the write)
-
Sorry for the double post, but a potential bug may have been fixed. I also managed to get the program shrunken down by 25 more bytes. Try it out and see what the results might be. If it is what I suspect, then the problem should be solved.
EDIT: Not entirely sure if I could make the program smaller, but if you really wanted me to, I could, say, drop some of the checks to make it come close to the 100 byte mark.
EDIT2: Got it smaller by 7 bytes. Will upload soon.
EDIT3: Fixed a serious bug.
EDIT4: Changed copying method altogether
-
sorry still no luck, tried your suggestion as well
And noahbaby94 I'll prbly go back through optimizing at one point, but don't jump on me everytime you see something because it has been a long while since I coded a game and I learned BASIC back when Text(-1 was barely even known and that most people didn't knew we didn't have to end quotes
EDIT: Nvm version 5 works (most discussion occured on IRC btw)
-
The update should've worked. Lemmie know how well it works for large files.
I might produce a smaller file if I find any ways to improve upon the algorithm (however small).
-
Ok confirmed that it works fine. It takes a friggin long while to copy, though (about 6 seconds for a 20.5 KB file).. not that it should be much of a problem for my game, though, but I'll try to keep my files under 10 KB and split map data and events into more sub programs if I have too many in the future, to not slow down loading before an event occurs or when entering a door
-
This version bloats to about 186 bytes on-calc, but the read/write speed is about as fast as you can get it for this type of program ( ~1sec for 20KB files ). Hope this addresses the issue.
-
this one seems faster, map loading in my game returned to ZCOPY speeds so that's good
-
Cool. I will see the code to learn something. I am not used to TI-OS routines :P
Also a nice lib to large but pure BASIC games...
-
Yeah. I always wanted to make one more pure basic game and I did a lot back then, but while you can still do cool stuff with no ASM memory always become an issue, because TI decided that it would be better to disable Archive/Unarchive for programs inside programs. I never understood why they didn't at least let it enabled except when you try archiving a program from itself. If it wasn't for this, The Reign Of Legends 1 would be in pure BASIC
-
Yeah. I always wanted to make one more pure basic game and I did a lot back then, but while you can still do cool stuff with no ASM memory always become an issue, because TI decided that it would be better to disable Archive/Unarchive for programs inside programs. I never understood why they didn't at least let it enabled except when you try archiving a program from itself. If it wasn't for this, The Reign Of Legends 1 would be in pure BASIC
You can execute Archive to archive programs in the home screen...
If you see in TI-BD asm hex there is a hack in flag, iirr, that allow to use Archive command to actually archive programs. That can be considered the most pure massive BASIC games xD
The only issue is that you ought to disable it after using the archive command...
-
Galandros, I was talking about inside BASIC programs. Plus, using hex immediately makes the game not pure BASIC. By pure BASIC people really means that there's 0 bytes of ASM code included with the entire game when you release it.
-
First bug report:
It appears the program has trouble copying programs that contains tokens that are only useable by TI-BASIC programmers on later OSes, such as %, $, #, |, _, the black arrows. When trying to copy such program, either part of the beginning code will be truncated or it will be replaced with random stuff such as RegEx. I use these characters a lot in strings, so it could be a serious issue. I am uncertain if this bug is related directly to these characters but I didn't got able to reproduce it on other files yet. Basically the copied program is corrupted. Since it's locked I had to use CODEX to unlock it to view the content, and could see the difference compared to the original file. All readme instructions followed.
EDIT: Confirmed that it only occurs with programs containing such characters early in it. I'M unsure why this happens, but this only happened with two specific files (two programs containing just strings loaded based on ifs E=a number)
EDIT 2(at least the prgm doesn,t seems signifiantly much slower than RESOURCE, even if I need to run it twice (once for deleting the prgm then another time to copy another)
EDIT 3: Attached to this post is a screenshot of the program code in TI-BASIC editor. Since I couldn't get the files with such characters to send on wabbitemu (until I reinstalled TI-Connect) I used my digital cam for now
Ok iambian, the corrupted copied program bug is happening again now, but this time with the menu program of my RPG. From the beginning until half of a string being stored into Ans, it's fine, but the rest of the program is corrupted afterward (I would say about 3000 bytes of corrupted code). This didn't happen until I decided to have the string be stored before the menu appears instead of displaying it directly in a Output( (which caused a lag during the menu)
-
That sounds symptomatic of an incorrect FlashROM page boundary handler.
Yeah, yeah, yeah. Fancy talk. The update in this post *should* fix it. No other changes were needed, and the file size remains the same. Enjoy.
( on another note, why the hell do I need to keep retrying the SAME THING over and over again? What's wrong with me!? I mean, this is up to version 1.06! Bah, betaware. )
-
wow alerady an update. I'll try this one. I guess it was prbly another incorrect flash rom page boundary handler, since the first 500 bytes or so of code stayed intact. Gonna install now (and do another backup of the game on computer in the meantime, instead of just on my nspire)
EDIT: Ok it works now ^^