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 - calc84maniac
Pages: 1 ... 163 164 [165] 166 167 ... 197
2461
« on: December 15, 2009, 07:51:31 pm »
Well, I added a simple lap counter. Also, I made the split-screen support more flexible, which could lead to some nice effects before and after the race.  
2462
« on: December 14, 2009, 03:54:13 pm »
I am talking about getting the Game Boy emulator to work on the newer calculators that don't have the extra RAM pages. What is the current problem caused by not having them?
Since the Game Boy has 8KB of RAM, 8KB of Video RAM, and 32KB of storage RAM, would a completely clean new 84 be able to run the games?
But you also have to consider that the emulator itself needs RAM.
2463
« on: December 14, 2009, 09:30:56 am »
Well, I added 64x64 map support!  And I got the rendering engine to run at exactly the same speed as 32x32. Plus, it's way more flexible now about where I can store the tilemap - instead of aligning to the nearest 4KB, now I only have to align to 256 bytes. And of course, here's a screenshot (Firefox recommended)  In case anyone is wondering, I haven't created any AI way-points for this track yet.
2464
« on: December 12, 2009, 05:44:57 pm »
I voted for Chip's Challenge 
2465
« on: December 12, 2009, 03:06:48 pm »
It reopened on August 25th 2009.
You mean 2008, right?
2466
« on: December 09, 2009, 04:22:20 pm »
Okay, new idea. For ldrb/ldrh:
Set a flag during the load instruction.
For the second instruction, if it uses the loaded register and the flag is set, add an interlocking delay and reset the flag.
Otherwise, if it takes more than one cycle, reset the flag.
For the last instruction, if it uses the loaded register and the flag is set, add an interlocking delay.
Reset the flag.
Same idea for ldr except remove the case of the second instruction.
2467
« on: December 09, 2009, 04:01:02 pm »
Maybe you can do something different with the register accesses on the couple of instructions afterward - basically on the load from memory you could do "interlockcount = cyclecount + 2" and upon register accesses, "if reg == loadedreg and interlockcount > cyclecount: cyclecount = interlockcount"
If I made the translator actually emit code to do that I think it would slow emulation way down, with several real instructions added per emulated instruction. It needs to precompute cycle counts as much as possible.
Well actually, the "reg == loadedreg" part could be purely done in the translator - and if false, you don't even need to add any extra instructions. Also, since the interlocking will add extra cycles to the ARM instruction, I don't think the speed difference would be too costly... And keep in mind that this solution only applies to the ldrb/ldrh opcodes, not ldr. In the ldr case, you can simply add an extra cycle to the following instruction if it accesses the loaded register.
2468
« on: December 09, 2009, 02:46:59 pm »
Maybe you can do something different with the register accesses on the couple of instructions afterward - basically on the load from memory you could do "interlockcount = cyclecount + 2" and upon register accesses, "if reg == loadedreg and interlockcount > cyclecount: cyclecount = interlockcount"
2469
« on: December 08, 2009, 08:31:55 pm »
so does this mean it will run slower on the actual calc then?
Definitely slower than it has been running. No way to tell yet whether it will still run games fullspeed though.
2470
« on: December 08, 2009, 04:45:09 pm »
Really! That's soooo cool!
*Tries*
Edit: It works.
I like that. What's at C7?
C7 is the "rst 00h" opcode, which calls address $0000 (which holds the code that happens before a ram clear)
2471
« on: December 08, 2009, 04:31:18 pm »
Edit: Would more accurate cycle counting slow down the emulation significantly? (Aside from the fact that instructions would take longer) That depends on what version of ARM the Nspire uses. The newer versions have longer pipelines, and the longer a CPU's pipeline is the more complicated it gets to predict how long something will take. Let's just hope it's not an ARM11 model.
Hackspire says it has one of theseEdit: Found the cycle counts here. And my "load byte, look up address in table and branch" routine looks like it will take 9 clock cycles instead of the 2 the emulator currently does...
2472
« on: December 08, 2009, 03:09:54 pm »
By the way, is the emulator's speed accurate? I mean, I added a delay loop of "loop subs r8,r8,#1 \ bne loop" when r8 contained 400,000, and that was for each of 60 frames. That loop should be 4 cycles per iteration, right? That adds up to delays of more than 90MHz, which doesn't add up. It's not accurate. Right now, it just assumes all instructions are one cycle, or 1/90 microseconds. If your computer is not fast, it can lag, however. A tight loop like that is very likely to lag; I would recommend adding a few dozen repetitions of a simple instruction like "mov r0,r0" which nspire_emu can execute very fast.
Well, there wasn't an issue with lag, it was more an issue of the emulator running faster than expected. Edit: Would more accurate cycle counting slow down the emulation significantly? (Aside from the fact that instructions would take longer)
2473
« on: December 08, 2009, 09:22:08 am »
Nice work!
Edit:
Actually, I was able to get the Nspire emulator running in translated mode now since I changed a certain part of my code, and it runs... really fast. I don't think there should be any worries The translator should work with anything, unless you either repeatedly store to memory that was previously used as code (which will slow it way down, since it wipes all translations on this kind of store - this could be improved), or store to memory that is ahead in the current basic block of code (very perverse thing to do in my opinion, I've seen it fail on real CPUs before ). If anything else broke it, I would like to hear about it...
Any reason you are using 16ths and 8ths instead of just 1/6th for all?
Because that would require division. Eww.
The truly correct way to do grayscaling is more complicated even than that:
- Perform gamma expansion on all three channels. Gamma expansion is the non-linear relationship from video input signals (R', G', B') to the amount of energy emitted by the display (R, G, B). On a typical CRT monitor, this can be approximated with the power law x = x' ^ 2.2. (The Game Boy Color uses an LCD instead, so I don't know what the equation for it is.)
- Calculate the luminance. This is a weighted average of all three channels, which takes into account that the human eye is more sensitive to green light than red, and more sensitive to red than blue. The traditional formula is Y = 0.299R + 0.587G + 0.114B, but it really depends on the color space used on that particular display. (Not everyone agrees on just what "red", "green", and "blue" are.)
- Perform gamma compression, the inverse of gamma expansion.
Some people forget the gamma operations, which results in saturated colors ending up too dark.
Yeah, my color conversion is pretty much just a placeholder for now. By the way, is the emulator's speed accurate? I mean, I added a delay loop of "loop subs r8,r8,#1 \ bne loop" when r8 contained 400,000, and that was for each of 60 frames. That loop should be 4 cycles per iteration, right? That adds up to delays of more than 90MHz, which doesn't add up. Edit: Oh, and I did use self-modifying code for a bit, but it was pretty unnecessary (hence why I didn't get it in translated mode sooner)
2474
« on: December 07, 2009, 10:21:29 pm »
Or you could just multiply by .1666 and call it good  . I assume you are doing somthing similar to that with 3/16 = .1875?
Nah, I can divide by 8 or 16 by shifting right 3 or 4 bits.
2475
« on: December 07, 2009, 10:02:20 pm »
Any reason you are using 16ths and 8ths instead of just 1/6th for all?
Because that would require division. Eww.
Pages: 1 ... 163 164 [165] 166 167 ... 197
|
Show Posts