This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Messages - the_mad_joob
Pages: 1 ... 9 10 [11] 12 13 ... 24
151
« on: April 18, 2014, 11:16:58 am »
I'll try to test that when possible =]
152
« on: April 18, 2014, 11:09:49 am »
The swap sector should always exist, so that shouldn't be a problem.
Hmm, actually, it seems it is created during the very first garbage collect (according to wabbit, for what it's worth).
153
« on: April 18, 2014, 11:05:29 am »
Oh, you are indeed correct, I didn't know that. In that case, I have no idea what a status byte of $FC would mean. Are we even sure it exists? I absolutely don't know, but i guess if it's mentioned in wikiti, there is a significant chance it does. I'm sure someone will clarify that =] I'm thinking of something else about the swap sector. What happens if the archive is totally full (with no swap sector), then you unarchive a small variable, then perform a garbage collect ? I mean, can the OS handle garbage collecting without enough space to create a swap sector ?
154
« on: April 18, 2014, 10:58:10 am »
Hey there.
I have 2 answers, actually:
- TI will only ever put the swap sector starting at page $08 or $0C, but technically third-party code could put it somewhere else and the OS should theoretically still function fine. If you need to locate it, I'd recommend using B_CALL(_FindSwapSector). Despite what that documentation says, I wouldn't worry about the swap sector not existing, and the call is not pointless.
- Sounds like you got a little mixed up about the variable data flag: "The flag byte will be 0FCh (valid) or 0F0h (deleted, ignore it)." To clarify, $FC marks the start of an archived variable and $F0 marks the start of a deleted archived variable to be removed at the next garbage collection. These flags exist at the start of every archived user variable, not just at the start of user archive sectors, but of course if a user archive sector is non-empty, it will start with a user variable, and that will start with $FC or $F0. So if a sector starts with either of those two flags, it's a user variable storage sector.
Thx for the answers =] About question 2 : Actually, the sector status byte and the variable status byte are two different things. I am talking about the sector status byte, not the other one. For example, if you have a random variable stored at the very begining of the archive, and that variable is valid (not to be deleted), the first byte will be $F0 (meaning the sector is used for variable data storage), followed by $FC (the variable status byte). In other words, when a variable starts at the begining of a sector, its status byte is the second byte, not the first. What i want to know is, under which circumstances can the sector status byte be $FC, as mentioned in wikiti.
155
« on: April 18, 2014, 08:36:45 am »
Hey there.
I have 2 questions, actually :
1) the swap sector
According to TI offcial documentation (pdf), it can only be either the first ($08>$0B) or the second ($0C>$0F).
According to wikiti, it can be any of the sectors.
I made some quick tests, and it seems that the OS uses only the first & second, but i'd like to be sure...
2) the sector status byte
We're assuming the sector i'm talking about doesn't include any app data at all.
From what i've tested, $FF specifies an empty sector, $F0 a sector used for variable data, $FE a sector used for swap.
What is $FC supposed to specify ? (according to wikiti, it can start with that byte).
Thx in advance =]
156
« on: April 25, 2013, 07:31:06 am »
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.
157
« on: April 24, 2013, 05:42:36 pm »
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 ?).
158
« on: April 24, 2013, 10:03:50 am »
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.
159
« on: April 23, 2013, 03:53:59 am »
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).
160
« on: April 20, 2013, 09:01:22 pm »
Thx for feedback Dapiano.
Much appreciated =]
161
« on: April 20, 2013, 12:30:22 pm »
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 ?
162
« on: April 20, 2013, 03:16:58 am »
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.
163
« on: April 20, 2013, 03:07:47 am »
I added a download link for 84+CSE users. 22 72 72 72
I find it rather strange, since so far the MicrOS keyboard routines I've written appear to work fine at 32 cycles delay. I promise you the ASIC is identical to the one in my TI-84+SE. If the keyboard is slower, it would be due to hysteresis in the keyboard matrix, not the ASIC.
Thx for the results dude. They are indeed kinda paranormal  . 83+: 5 (N-0305H)
84+SE: 4 18 18 18 (no serial number listed, it's actually an 84+SE in an 84+ case)
These are short delays ! Too bad you don't have the serial but i assume it's one of the later models. Thx for time.
164
« on: April 20, 2013, 02:22:39 am »
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...
165
« on: April 19, 2013, 01:45:59 pm »
Yay !
Pages: 1 ... 9 10 [11] 12 13 ... 24
|
Show Posts
