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 ... 86 87 [88] 89 90 ... 108
1306
« on: October 12, 2010, 05:18:12 pm »
Jerros already knows, but for every one else... The OS actually delays when it sees an ON interrupt. It runs a 100 t-state loop 4000 times waiting for the state of the ON button to change. That's just stupid, this is horrible for any type of program that needs to run at a decent pace. Anyways, the fix was to put a di \ ld a, %00001010 \ out (03), a after the GetCSC. Oh, and be prepared for a great game from Jerros  .
1307
« on: October 11, 2010, 05:41:00 pm »
Fixed that little problem First, it only knew how to draw spike sprites, so instead of drawing the dark floor, it was drawing spikes. And second, it would appear that when an interrupt is called, the return address is pushed on the stack; a very important aspect of the processor that I overlooked.
1308
« on: October 11, 2010, 03:45:22 pm »
Ok, so this was just too funny to ignore. Here's a behind the scenes screenshot of making the impossible game.
1309
« on: October 11, 2010, 10:10:24 am »
I'll look through it. Basically what I would do is run it in wabbitemu and place a breakpoint at $0038. $0038 is where the calculator goes when an interrupt happens, so if you follow the interrupt through, it will point you back to the location of the hidden EI.
Actually, even just posting the app I could probably find the problem.
1310
« on: October 10, 2010, 01:28:04 pm »
Thats strange. If interrupts are disabled, the on button should do nothing. Are you sure nothing in your loop turns interrupts back on? Also, how fast would you say your program is running? 20fps, 40fps, 150fps? If your program is getting in GetCSC's faster than the interrupts fire, pressing on would slow it down.
Perhaps you could post the source, that way we could see what is really happening.
1311
« on: October 10, 2010, 12:02:09 am »
btw, was there some specific reason that you werent using sprites before now?
I wasn't using sprites because the way sprites are typically done, I thought it would have taken too long to draw all of them to the screen. I originally thought it would have to run at 50 fps also which makes sprites impractical. The way I'm doing them this time though is to have separate code for each possible alignment on screen. This configuration will take up 260 bytes in ram vs none, but the result is about twice as fast.
1312
« on: October 09, 2010, 10:22:58 pm »
Just as a heads up, I am starting on 2.0. From the looks of it, it should work on 83+'s. At 33 fps and 6,500,000 Hz, thats 200,000 t-states per frame. The screen will steal 60,000 and with my new system of drawing the screen (sprites vs. just pure shifting), it should take 20,000 to render. That leaves me with 120,000 to mess around with, meaning that I should definitely be able to make it work. I think that's DCS-related, and not specifically thepenguin77's fault.
Lol, I am like DCS's worst nightmare. This is the third time I have made it glitch with this program. First it was the crash on exit (extra ram related), then it was the upside down screen (memory usage differences), and now it is the stats screen crashing (something to do with mirage's fastLine I assume). Oh well, kerm needs something to work on. Btw, I never finished level 3. I got to 93% several times. The problem is that at 84%, there is a section that has only one frame that you are allowed to jump from. That coupled with this being the hardest level ever have stumped me. Oh well, mine will have more than one frame of success.
1313
« on: October 09, 2010, 08:30:13 pm »
78,720 I found a bigger pokemon table.
Edit:
I only used one ship because I figured multiple wouldn't work correctly.
1314
« on: October 09, 2010, 07:47:04 pm »
41,150 addictinggames.com all games section
56,230 table of all pokemon from all games
The pokemon one took way too long...
1315
« on: October 09, 2010, 01:58:32 pm »
That code you posted should work. When the calculator is in DI mode and something tries to do an interrupt, the calculator remembers that. So then as soon as the EI comes around, it instantly interrupts. You probably don't even need that EI before the GetCSC because the screen routines have their own EI, plus, there's an EI in bcall(_GetCSC). So I would imagine if you just put a DI after each bcall, your problem would go away and GetCSC should still work.
1316
« on: October 09, 2010, 11:23:40 am »
Now I've just got to figure out how "di" exactly works and what it does, but that's what the interwebs is for. ^_^
di is quite possibly the most simple instruction. It is also best friends with ei. Basically, di tells the calculator, stop sending interrupts. The calculator will then stop using interrupts all together and your program flow in never be interrupted by one again. ei turns them back on, when ei is executed, it tells the calculator to start sending interrupts again. The problem with both of the methods mentioned so far is that if you are using bcalls, both are only very temporary fixes. Using di will make bcall(_GetCSC) stop working, and typically routines like bcall(_clrLCDFull) have an ei at the end of them. The problem with disabling only the ON interrupts through port (3) is that the ON key is only disabled for .01 second. This is because as soon as the next Ti interrupt fires, it will turn them right back on.
1317
« on: October 09, 2010, 11:13:54 am »
One last idea before you delete them. They look exactly like .8xp files. Try renaming them .8xp and sending them back to wabbitemu. I wouldn't doubt that they are real programs.
1318
« on: October 08, 2010, 04:31:41 pm »
You would be correct thinking that the interrupts are causing your problems. I'm not exactly sure what your calculator is doing in the background to make ON slow it down, but it no doubt changes from program to program.
The obvious way to fix this problem is to just disable interrupts. A simple di somewhere in your loop should take care of this. But now you have to watch out because TI likes to use interrupts. Bcalls that draw to the screen tend to turn the interrupts back on, so just be careful there. Also, bcall(_GetCSC) relies on interrupts to function, so you are going to have to use direct key input with port (01).
The other option that would kind of work is to disable the on interrupt. You would output %00001010 to port (03) instead of %00001011. However, this is just a temporary fix because as soon as the next timer triggered interrupt occurs, it will re-enable the ON interrupts.
1319
« on: October 06, 2010, 04:27:38 pm »
v1.1 is out. It has full compatibility with the 83+BE. (At least I hope it does, my current version of wabbitemu can't load apps. So I couldn't test it.) It also is perfectly timed with the music. Anyways, to give you an idea of how long till I make v2.0. I am 93% of the way through beat level 2 and 69% through level 3. So a few more days 
1320
« on: October 06, 2010, 04:20:58 pm »
There's no bcall(_unlockFlash). (If there was, BrandonW would fall out of his chair laughing.) You have to glitch the OS into giving control back to your program while flash is unlocked.
Pages: 1 ... 86 87 [88] 89 90 ... 108
|
Show Posts