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 ... 90 91 [92] 93 94 ... 108
1366
« on: August 23, 2010, 10:01:35 am »
Ok, I feel like I need to say this. There is another hacky way that you can get info off the second page of your app, or any flash page for that matter.
ld (saveSP), hl
ld a, 1
out (05), a ;puts ram page 1 in $C000, (it's usually page 0)
in a, (06)
inc a
out (07), a ;puts second page of app in $8000
ld sp, textShadow+$4000 ;anywhere will work as long as it's free
;now you access your variables+$4000 because they
;are swapped into $C000 instead of $8000
ld a, 4
ld (enemies+$4000), a
;even cooler yet, you can put ram routines way out in the
;$C000 region and execute them
ld hl, doStuff
ld de, statVars+$4000
ld bc, doStuffEnd-doStuff
ldir
call statVars+$4000
;or you can call a routine on the second half of your app
call secondPageRoutine ;it's address is ($9123) or something
ld a, $81
out (07), a ;ram page 1
xor a
out (05), a ;ram page 0
ld sp, (saveSp)
ret
doStuff:
ld a, 5
ret
doStuffEnd:
This essentially makes your app run from $4000 through $8000 to $C000. You could actually even have your second page .org $8000 and just run it like this. The only downfall is that you can't use bcalls. You would either have to make a bcall routine that puts memory back to normal and calls it, or not use bcalls.
Edit:
Just realized why no one does this. It won't work on an 83+. That doesn't bother me, but you might want it to work on those.
1367
« on: August 22, 2010, 08:19:56 pm »
Well, it works on the flash debugger as well as 2.53. I would say that's a pretty good indication that it is Ti's mistake from the beginning and is on all OS's.
1368
« on: August 18, 2010, 06:52:04 pm »
Uhhh... Another glitch I have to fix. I just did it on my calc. Recall it once, you get about 2000 F's, recall it twice you get about 500 F's then unlimited random charaters.
I'll look into it.
Oh, and 100% guarantee it has nothing to do with extra ram pages as those aren't used for this kind of thing.
Edit #1:
It only works with two byte characters. The OS checks to see if the total ram used is equal to the total ram available. If you count by twos however, 999!=1000, 1001!=1000, the OS misses it's chance and guess what happens.
Edit #2:
Found it. I'm not going to go through the trouble of fixing it because 1) I'm lazy, and 2) I'm not sure this has ever caused someone an accidental ram clear. But for future reference here is the problem:
In bcall($4942), (editTail) is checked with (editBtm) to see if they are equal, and if they're not, it figures that there is enough space to put another character. But if it is putting a two byte character, it goes past the end of the editBuffer and copies into oblivion. The way to fix it would be to either stop it once it goes over, or check for two byte characters and handle them accordingly.
For all those who couldn't get the recall glitch, delete your second recall. Add in one more byte, pressing enter will work. And then recall it again.
1369
« on: August 17, 2010, 09:04:03 pm »
will the bosses be sprites or made of polygons? i'm particularly wondering about andross; i don't think he wouldn't seem the same if he was a sprite... 
Yes, bosses will be easier in that sense. During the boss battle there are no background shapes. Therefore, all rendering power goes straight at the boss.
1370
« on: August 17, 2010, 07:17:08 pm »
There's nothing permanent at $8000, it's used as scratch space by the OS for archiving. $8100 is also open up to $8180 as OS scratch space.
1371
« on: August 17, 2010, 07:00:44 pm »
Oh wait, there was 83+ support??  I was sure this game was only gonna be for 15 MHz calcs
It's just for 15MHz, all of his problems were caused because of the fact that he didn't know that. I was just wondering...is the 3D in this engine capable of full rotation? It would be really cool to use this for games like Descent! Can you only face forward, like raycasting, or can you look up and down?
Ooh! If that is possible, maybe you could do an "all range mode" style of play like in the n64 version of starfox! I always liked that part the most.
No, it doesn't do rotation. That would require much more math. I actually sat on the couch for about an hour moving my arms in different rotations trying to visualize how you could rotate coordinates. But thankfully I realized that starfox doesn't rotate them either. I was envisioning Descent too (though I've always thought it was called destination saturn) but I think that would be way too slow with the numbers of polygons. Plus the rotation would give it enough calculations to really slow it down. If you haven't figured it out, this means no "all range mode." You know, if you were to enable music for this game, I could make a pretty sweet rendition of the Star Fox 64 Versus music 
That would require way too much processor time. Any spare time I have would be going towards a bigger screen anyways. I'm all for the 83+ support!
Ahh! Stop posting while I'm posting. lol. I don't see any possible way to make this happen on the 83+. By the end of this, I wouldn't doubt that the program will be 20kb + 5kb for program data and it will be using 20kb of storage memory. Not to mention the lack of crystal timers and 6MHz.
1372
« on: August 17, 2010, 04:25:17 pm »
Silly fix. You couldn't turn your calculator off if you used the key input.
Supporting extra characters is super easy. I currently have a big list of (cp xx \ jr nz, next)'s that I use. The finished product is output in pure assembly so it's size all varies with what you want. Very unoptimized assembly I might add. (32 straight inc (hl)'s in some cases)
The program starts right at the beginning of appBackUpScreen. If you need more space, use a whole bunch of >'s.
Here is a program that takes a 1 digit input, squares it, and outputs the 2 digit result.
:BF,AA
:,----- ----- ----- ----- ----- ----- ----- ----- ----- ---
:[
:>+
:>+
:<<-
:]
:>
:[
:>
:[>+>+<<-]
:>
:[<+>-]
:<<-
:]
:>>+++++ +++++.
:>[>+<-] ;hex to decimal starts here (after the >), give it the number in (current) and it will output the result
:>
:>+++++ +++++
:<
:[
:>
:[>+>+<<-]
:>
:[-<<-[>]>]
:>
:[<<+>>-]
:>+
:<<<<
:]
:+++++ +++++
:>[<->-]<
:[>+<-]
:+++++ +++++ +++++ +++++ +++++ +++++ +++++ +++++ +++++ +++
:[>+>>>>+<<<<<-]
:>>>>>.<<<<.
:>+++++ +++++.
There's a hex to decimal converter in there. It just can't accept numbers that end in 0. 20 is 1:.
Edit:
Forgot to attach program. Source's there too if you want it.
1373
« on: August 17, 2010, 04:01:56 pm »
It uses appBackUpScreen. So as long as you don't do +[>[-]+]. You shouldn't have any problems.
1374
« on: August 17, 2010, 02:07:55 pm »
* DJ Omnimaga also hopes that Brainfuck becoming Nemo's new hobby doesn't mean the end of his calculator hobby 
Worry no more. Now you can combine brainfuck with your calculator. prgmBRAINFCK Language is exactly like the real thing, ignores formatting and illegal characters. $0A is even new line. On compile, it only includes the subroutine that you need, the text input is like 50 bytes so you don't always want that. Here are the specifics to make a source file. The first two characters must be "BF". Then there is an optional comma indicating safe mode (more info later). Finally the name of your program followed by an enter. That's it! Now go program to your heart's content. Then to get it to compile. Store your source name in string 1. Then just run prgmBRAINFCK. It even warns you if you have different amounts of ['s and ]'s. The safe mode I added is so that your programs will never clear ram. It puts a little subroutine before every ] that checks for ON presses. Enjoy.
1375
« on: August 17, 2010, 11:48:32 am »
First a little background. Like I said earlier, I had to make a custom font routine. But since the whole small font map is about 2kb or something, I just left it out. Instead, I go to _sFont_len, and use the page number from the bcall to look for the start of the font table.
The difference between the two is that Kerm Martian tried to play it on an 83+ and said it wasn't working. He told me that it crashed when it was searching for the font. So I switched to using _Load_sFont instead. That was the only change, and it still doesn't work on os's 1.xx. The problem is that I have no way to test on those calculators.
1376
« on: August 17, 2010, 11:35:12 am »
This post got passed by by every one.  sad Anyways, there are a few ways to access jump tables. I assume you don't know about the instuction jp (hl). It jumps to HL. It's not mentioned in asm in 28 days but it's really useful. Here's an example that's all about speed. ;before hand
ld hl, tableStart
ld de, $8000
ld bc, tableEnd-tableStart
ldir
;super fast access
ld a, (toJump)
add a, a
add a, a
ld l, a
ld h, $80
jp (hl)
;the nops are there to make them 4 bytes
;but you could remove them and multiply by 3
tableStart:
jp lbl0
nop
jp lbl1
nop
jp lbl2
nop
jp lbl3
nop
jp lbl4
nop
tableEnd:
This kind of table is typically used in super fast sections, like drawing and such. You could simplify yours a lot by making it a .dw table and not aligning it to a $100 boundary. But I think all the magic you are looking for is in jp (hl). It's only 4 t-states to boot. There are also jp (ix) and jp (iy), but unless you use undocumented instructions, those are rather hard to use.
1377
« on: August 16, 2010, 08:35:33 pm »
It's when it gets over 16,384 bytes that it requires two pages. There are two ways to check for this.
1. compile your app as a program and check it's size on the computer. This will give you a rough estimate of how bit it is.
2. Download Omnicalc run it and press 6, 1, 3. Then find your app, when you have it selected, press Alpha H. Your are now looking at your app as it is in calculator memory. Alpha G is goto, so by using that, you can look for the end of your file. You'll know you found the end because it will go from random bytes to all FF's. The max size for a one page app is $4000 bytes, so if the end is around $7800, you'll be needing two pages soon.
I think you meant Calcsys, not Omnicalc.
Good thing you caught that, he would have been really confused. Calcsys is what you're after. Calcsys Omnicalc, sp pc, they're all the same thing.
1378
« on: August 16, 2010, 11:14:27 am »
It's when it gets over 16,384 bytes that it requires two pages. There are two ways to check for this. 1. compile your app as a program and check it's size on the computer. This will give you a rough estimate of how bit it is. 2. Download Omnicalc run it and press 6, 1, 3. Then find your app, when you have it selected, press Alpha H. Your are now looking at your app as it is in calculator memory. Alpha G is goto, so by using that, you can look for the end of your file. You'll know you found the end because it will go from random bytes to all FF's. The max size for a one page app is $4000 bytes, so if the end is around $7800, you'll be needing two pages soon.
1379
« on: August 15, 2010, 11:39:04 pm »
The code you sent me works anyways. Something else is going on.
As for break points. I would put one at the top of this subroutine and step through it.
1380
« on: August 15, 2010, 10:57:14 pm »
Everything there says to me that it should work. I never use getKey, but while unoptimized, I see no problems other than a push DE up top with no pop.
Could you give the full context of where this is used? I can't really debug it since there are a lot of variables not initialized within the routine.
Pages: 1 ... 90 91 [92] 93 94 ... 108
|
Show Posts