391
TI Z80 / Re: zStart - an app that runs on ram clears
« on: February 29, 2012, 04:20:33 pm »
Glad we could help. (I also take pride in the fact that every program you just mentioned was written by me )
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. 391
TI Z80 / Re: zStart - an app that runs on ram clears« on: February 29, 2012, 04:20:33 pm »
Glad we could help. (I also take pride in the fact that every program you just mentioned was written by me )
392
TI Z80 / Re: TruVid - 4 level grayscale video with sound« on: February 29, 2012, 04:18:06 pm »
Sorry for not responding. I realized that I had my old email address as my omnimaga address, so that's why I didn't notice the email.
In any case, I converted the video. Though, I bet you could install the .net framework pretty sneakily. Its made by microsoft and is required for quite a few programs to run. (I forgot it was needed because the actual program that requires it wasn't written by me.) 393
TI Z80 / Re: zStart - an app that runs on ram clears« on: February 28, 2012, 07:24:12 pm »
Yes. This problem is actually completely unrelated to zStart and actually more related to Axe. The universal exploit that was developed several years ago actually modifies the OS. This wasn't discovered until recently, but it does screw it up. This patch that I created changes the OS in such a way that when the universal exploit does it's damage, the write to flash actually causes no change and the OS functions normally.
394
TI Z80 / Re: zStart - an app that runs on ram clears« on: February 28, 2012, 07:04:29 pm »
Happybobjr, do you happen to have OS 2.55? If so, I have a patch for you.
395
TI Z80 / Re: zStart - an app that runs on ram clears« on: February 28, 2012, 02:53:20 pm »Re-installing the OS doesn't kill the "run on RAM Clear" option ? Oh, you meant reinstall the OS. Yes, that will get rid of zStart. However, just pulling up that screen won't do much of anything. Wow this thread grew a lot compared to when I last checked it! I don't think I'll bother going through the 45 pages lol, but I'm glad to see this is still progressing. Eventually I might give it a try but unfortunately now I can't, because I'm using Doors CS7 and I have heard about compatibility issues between both apps. DCS compatibility is as good as I can get it from my side. The only thing missing is properly chaining hooks. Kerm says he can't really fix that because he ran out of space. can you use asm from home screen? Asm from homescreen - yes Linking - zStart won't affect it for the better or worse and yes the appvars are transferable 396
TI Z80 / Re: zStart - an app that runs on ram clears« on: February 27, 2012, 04:38:37 pm »Any ideas?Remove a battery and re-insert it while holding DEL. The calc will ask an OS to be installed and zStart would probably be uninstalled (at least the run on RAM Clear option). There is nothing radical about this in the slightest way. It does literally nothing besides clear ram. And no, it wouldn't affect zStart at all. As for C0deH4cker, somehow manage to turn your calculator on, (VARS while rebooting should do it). Then simply delete the zStart appvar and clear ram again. I'm not sure what's going on, but that fixes all problems. 397
TI Z80 / Re: CalcRAR« on: February 23, 2012, 06:42:49 pm »
LZ77 is good for really big amounts of data, and it gets rid of byte boundaries, but here's a small example.
First of all, since you'll be working with sizes no bigger than calculator ram, you should probably make your sliding window just big enough to include the whole program, (2,048, 4,096, 8,192, 16,384). So, for this example, I'll go with 2,048 (11 bits). Also, for max match size, I'll use 7 bits. Also, 0 will mean uncompressed and will be followed by the number of uncompressed bytes (7 bits) and 1 will mean compressed and will be followed by search distance then size. Key: (1 bit) 8 bits [11 bits] {7 bits} 00 01 02 03 04 05 06 07 08 09 00 00 06 07 08 09 00 00 06 02 03 04 05 06 08 09 04 03 06 06 06 06 06 06 06 06 06 06 04 04 05 08 09 09 01 01 01 02 03 04 05 (0) {12} 00 01 02 03 04 05 06 07 08 09 00 00 (1) [6] {7} (1) [17] {5} (0) {5} 08 09 04 03 06 (1) [01] {9} (0) {8} 04 04 05 08 09 09 01 (1) [45] {5} That wasn't easy. In this small example, even though we didn't fully make use of all the bits we had in the size fields, and this data was super short, we still went from 408 bits to 292 bits. Also, if you manage to follow what happened there, you'll see that this method actually encompasses RLE 398
TI Z80 / Re: CalcRAR« on: February 23, 2012, 05:34:54 pm »Would you perhaps be so kind as to write me a routine that compresses and decompresses a file? Or perhaps psuedocode it.isn't that just asking for him to write the entire thing for you? I think Iambian made a pucrunch compressor as an Axiom (or something similar to that). For ACagliano, there are a couple different methods you could use, but RLE is definitely not the right choice. There are two main reasons you wouldn't use RLE. The first is that most programs on calc do not have long strips of the byte and the second is that if a program did have long amounts of the same number, the programmer would either compress it themselves or render that on the fly. What this means is that I would assume that RLE would make most programs larger So, for a better alternative, so far in my life I've used LZ77 and DEFLATE. LZ77 is what's called a floating window where you search the past X bytes to see if you can find a match for the data your are currently looking at. X can be whatever you want, but for this project, since you probably won't be compressing stuff that won't fit in ram, you can just search the whole program for a match. DEFLATE uses the exact same principle as LZ77 except it also compresses the "data" used to tell the decompressor where to search for a byte. What I would suggest is that first you take a look at LZ77 and get that running. Once you're happy with how that works (even if you're still increasing size when you compress), you can then make a few slight modifications and you'll be using DEFLATE, at which point you'll probably get some nice ratios. If you want some source examples, I've done LZ77 and DEFLATE compression on the computer and I've decompressed them both on the calculator. (Though DEFLATE was done in TruVid so the code is rather scary (and runs at $F000)). The only problem with my code is that I made up my own data format to fit my needs. And for information on these two, the LZ77 Wikipedia page is probably enough to get you going. For DEFLATE this is the page I used. (You can't make up DEFLATE like you can LZ77) 399
TI Z80 / Re: zStart - an app that runs on ram clears« on: February 22, 2012, 08:44:17 pm »
For now, you guys should hold off a little bit on test running. I didn't reset the stack, so it will slowly stack overflow. You have about 5 test runs though before that happens.
400
TI Z80 / Re: zStart - an app that runs on ram clears« on: February 21, 2012, 05:25:22 pm »
Love me, hate me, whatever, I spent like 15 minutes working and zStart now mostly works on 83+BE's.
Things that I know do not work:
Key, (i) - impossible to fix, (h) - hard/lengthy to fix, (p) - probably fixable, (s) - silly to fix, (?) - no idea If something doesn't work, make sure you tell me, I might be able to fix it. If you're using an 84+, there's no reason to update since I literally changed nothing else. Also, here's the readme again because I'm assuming the 83+ guys will need it. (not that you're unintelligent, you just haven't been here for the process) 401
TI Z80 / Re: zStart - an app that runs on ram clears« on: February 20, 2012, 10:25:04 pm »Just keeps getting better and better That seems logical, I'll see how difficult it is. I have a feeling it's very difficult or else I would have already done that. (The Lbl menu actually scrolls right if you get enough) Quote Also a q: would it be possible to, when axe is compiling/zooming a program and it encounters an error, go in and edit the program then when you quit the editor go back to continue or restart compiling/zooming? This could make for fast debugging as well Deh.... What? I believe quigibo will return the offset to the error back to me in his next update, so if an error occurs, it will just go there. Hopefully that does what you want. Quote Edit: ok imma post bugs as I find them while programming as normal Have at it, I don't mind if you flood this thread with bug reports. (It's like bumping ) And yes, I noticed that right after I uploaded it here. The first colon is the only colon in the entire editor that is not actually a token, so I have to add it manually. It used to work, but I believe I broke it when I made the first line stop starting in column 0. 402
TI Z80 / Re: zStart - an app that runs on ram clears« on: February 20, 2012, 08:07:36 pm »Is it possible to start programs from prgm menu like with noshell or DCS ? If it's possible, then your application could be really usefull to me because DCS7 take really huge memory on my 83+... Yeah, it doesn't really work on the 83+. There's not much I can do about that at this point. 403
TI Z80 / Re: zStart - an app that runs on ram clears« on: February 20, 2012, 05:00:20 pm »Bug: when you copy/paste/restore tokens that axe replaces (Copy, Rect, Data, etc) they get changed to a Y# token. This one is actually quigibo's fault. I reported it. Update!! All of these changes apply to the program editor
These ones don't apply to the program editor
Thanks to runer for suggesting the test features, I have a feeling that this might be the last thing I need to get every single axe user to become a zStart user as well. If you test an app, it doesn't return to the program editor. In theory I could make this work, but it's a mess. Also, in order to accommodate all of these changes, I optimized like 600 bytes out of the app. What this means is that I probably broke some stuff. So if something that used to work no longer works, make sure you let me know; it's probably a 1 line fix. The next thing I want to work on is adding some system to get the shortcut keys to work wherever they can. I'd work on that now, but I don't know how long it will take. Edit: This screenie also shows my awesome axe skills. 404
Axe / Re: Calling one axe program from another« on: February 20, 2012, 04:02:26 pm »can you call the program within the program that is being called? I assume you are asking if a program can call itself? The answer is yes, but only if the program was not run with a shell. If it was run with a shell, you are going to run into problems. 405
The Axe Parser Project / Re: Bug Reports« on: February 20, 2012, 03:58:26 pm »
I found an error in the way the token hook is handled. When you copy the text string to ram, I noticed that you don't actually configure the first byte of the string. Since most of the tokens end up being somewhere in the 01xx range, the first byte of the ram string is 1.
But here's the problem. On closer analysis of how this hook works, that first byte actually means something. The format looks like this: [Key code][length of string][string] Where key code is the actual key you press to signal the token. As you can see, the key codes you are returning are incorrect and then that leads to all sorts of problems. (01 translates to right, when you use axe tokens in a Recall queue, the calculator hangs because tokens aren't actually being inserted) So the simple fix is just to put the proper key codes in. The quickest way to get the proper key code is to simply put the token in DE and call _GetKeyPress, that will return the proper key in A. Edit: If you are going to call _GetKeyPress from within your hook, make sure you temporarily disable the hook. Otherwise you're going to have fun with recursion. |
|