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 - thepenguin77
Pages: 1 ... 87 88 [89] 90 91 ... 108
1321
« on: October 04, 2010, 10:59:58 pm »
When changing single bits in flash, you can only set them to 0 (or leave them as 1). To set bits to 1, you have to set the whole sector to 1 (which is called a sector erase)
This is what Axe is doing that makes compiling Apps take longer. 
Actually making apps is slow because flash is horribly slow. Each flash command takes about the same amount of time I believe. So erasing happens near instantly. But then you have to go rewrite those 65536 bytes you just erased. Which takes about 4 seconds. But not only does it have to write it once, first you have to copy the whole sector to the swapSector, and then copy it back. That's two full sector copies. If you ever wondered why OS mods take so long, this is also why. OS mods usually require erasing more than one sector too 
1322
« on: October 03, 2010, 10:34:42 pm »
3. Due to 3, I am eliminating all halts in my program, this means that the 83+ speed will be very close to perfect.
Recurse much?
Anyway, nice to see you're still working on this!
Lol, I couldn't figure out what you meant the first few times I read that. That should be "Due to 2." But I'll leave it because it's awesome.
1323
« on: October 03, 2010, 02:29:20 pm »
Holy crap!!! They made new levels!!! Level 2 and Level 3. As soon as this 1.1 is done. I am going to be hard at work on The Impossible Game 2. However, I don't think this one will be 83+ compatible.
1324
« on: October 03, 2010, 02:00:39 pm »
So yesterday, I decided to show my brother how the impossible game is timed so perfectly that you can watch a video of the level and beat it on the calc. It didn't work. So after a little debugging, I realized that it was detecting the calculators wrong. This means I'm currently working on v1.1. The fixes I am doing are: 1. The bad checking, (change z to nz) 2. It will now officially work on 83+'s. (Thank you Iambian) 3. Due to 3, I am eliminating all halts in my program, this means that the 83+ speed will be very close to perfect. If you know of any other glitches with it, let me know.
1325
« on: October 02, 2010, 02:52:03 pm »
that is most definitely epic. are you as fast on an actual calc keyboard?! regardless, ima have to try this out
I wish. I did that in 5% speed. Did anyone have trouble transferring the libraries to their calc?
Yes, Ti Connect doesn't like the period in all of the names. For instance the file Hooks.8xv is Hooks.h on calculator. The way around this is to open the Ti Connect device viewer and drag and drop the file to the calculator. It will attempt to send, and then say that you need to rename it. Change the period to something like p (for period). Ti Connect will then send it, but it will make all of the letters upper case. Make sure it is in ram then go find it with Calcsys's vat viewer. When you are viewing the individual appVar, press Alpha V. Then press left until you see the name. Then change it back to what it should be. (A quick hint on changing the name. Lower case letters are 20h higher than the uppercase ones. So to change 'A' (41h) to 'a'. 41h + 20h = 61h = a. Also, period is 2Eh.)
1326
« on: October 02, 2010, 01:38:39 pm »
This program has my respect.
Warning, epic screenshot.
Edit:
Dang, I made it in high framerate. Watch it with firefox as it's twice as fast.
1327
« on: October 02, 2010, 11:41:11 am »
Wow, this is really nice. It works almost exactly like a computer compiler. One of the great features I've found so far is all the shortcut menus. i.e. Apps puts in "BCALL" and then brings up a list of all the bcalls.
I will definitely be using this in school to make quick asm programs.
1328
« on: October 02, 2010, 12:27:53 am »
I found the cheat. It does not appear to be functional though. It was a fourth difficulty that has the same stats as easy. But the way the code is designed, you can't select it.
1329
« on: September 30, 2010, 05:50:10 pm »
As far as the Nspire goes. If the z80 line does get completely discontinued. I would imagine that the Nspire would start getting cracked as fast as new iPod OS's. I mean, imagine if every person in this community was working with the Nspire. There would be quite a few who just want to make programs and such, but there would also be quite a few devoted to cracking it. Imagine if brandonW was devoted to cracking the Nspire.
1330
« on: September 28, 2010, 04:50:16 pm »
First, to find a program, you have to start at the VAT. The VAT is the variable allocation table and it starts at (ProgPtr). It then works it's way backwards through memory. It ends at (PTemp). The VAT entry for a program looks like this.
Offset: -14 - -7 -6 -5 -4 -3 -2 -1 0
Item: name name length page addr high addr low version reserved type
Where type is 05 for a program and 06 for a protected program. Reserved is always 0. Version changes, but 1 is usually normal. The address low and high are where you can find the program. Page is the flash page, or 0 if in ram. The name length is how many characters and in the name and the name is name.
Then when you follow out that address to a location in ram, you are given the start of the program. The first two bytes are the size bytes. Then the program data. Then the next program in ram. There is nothing ending the program. There is also nothing marking the program aside from it's size bytes, which don't look any different than normal bytes.
And that is the VAT.
Edit:
Formatting that table.
1331
« on: September 27, 2010, 04:46:38 pm »
I don't know how possible it is, but is this what you are saying?
Create our own loader in say 10kb. Then use like 50kb to try to fake the checksum? If that's possible, it would be really cool, maybe if we devoted a few computers to such a feat it would be possible.
1332
« on: September 26, 2010, 08:13:24 pm »
Nice. I wonder if this could be an united project between Netham45, you and Thepenguin77? It migth help finding optimizations and ways to make it run faster (and in all browsers except IE)
I don't know JS, I was writing mine in C++. But I'm sure I could figure out quite a bit of it in a day since I'm already pretty good at C++.
1333
« on: September 26, 2010, 01:51:21 pm »
Correct. The OS actually double increases the page when going to the next. So for instance, say while making the group header, the OS runs out of space on page 08, it increases to page 09, then increases again to page 0A. This causes two problems, 1. Your files weren't written. And 2. When eventually the OS moves on to write to page 0A, the calculator is going to freeze when it attempts to write to an area that has already been written to.
1334
« on: September 26, 2010, 01:24:48 pm »
Those are assembly games. They must be run differently so that the calculator knows that they are different. Some games are literally a whole bunch of calculator commands all just run right after another, these are called basic and are run with "prgmGAME" The other half of games are assembly games. These games are written in the native language of the calculator. These must be run with "Asm(prgmGAME" or from a shell like Mirage or DCS. The way assembly games work is this: all games can be run from DCS (though there are few that are written specifically for it), MirageOS can run about 98% of them, and about 50% of them can be run with "Asm(prgmGame" Edit: Ninja'd, but I have links
1335
« on: September 26, 2010, 12:30:23 pm »
Yeah, I just started working on a Javascript emu. Messing with half-carry if fuuun...
I was working on an emu the other day too. Wouldn't this work pretty well for the half carry? ((A & 0xF) + (B & 0xF)) & 0x10 Just take the bottom nibbles of each and check for a carry out of them.
Pages: 1 ... 87 88 [89] 90 91 ... 108
|
Show Posts