The second one Kerm
I just thought I should say that you don't actually have to write to the LCD ram to find the delay. You can just send it commands and it still has the lag that you need to measure.
Here is one I wrote that finds the delay in about a second. Although it can be adjusted down to about .05 seconds. I have it check 25,000 times that the number is correct to be absolutely sure it is correct.
My routine zeros out the delay, (well $0C's it), then writes to the lcd driver, waits 60 clock cycles, and checks to see if the lcd is ready for a new command. If it's not, it increases the driver delay and tries again. It does this until it finds a setting where the driver was ready 25,000 times in a row. Also, the reason I use 60 clock cycles is because I know at least Mirage's fastcopy waits 64 clocks, so I did 60 just to be safe.
Here is one I wrote that finds the delay in about a second. Although it can be adjusted down to about .05 seconds. I have it check 25,000 times that the number is correct to be absolutely sure it is correct.
My routine zeros out the delay, (well $0C's it), then writes to the lcd driver, waits 60 clock cycles, and checks to see if the lcd is ready for a new command. If it's not, it increases the driver delay and tries again. It does this until it finds a setting where the driver was ready 25,000 times in a row. Also, the reason I use 60 clock cycles is because I know at least Mirage's fastcopy waits 64 clocks, so I did 60 just to be safe.
thepenguin77 wrote:
I just thought I should say that you don't actually have to write to the LCD ram to find the delay. You can just send it commands and it still has the lag that you need to measure.
Here is one I wrote that finds the delay in about a second. Although it can be adjusted down to about .05 seconds. I have it check 25,000 times that the number is correct to be absolutely sure it is correct.
My routine zeros out the delay, (well $0C's it), then writes to the lcd driver, waits 60 clock cycles, and checks to see if the lcd is ready for a new command. If it's not, it increases the driver delay and tries again. It does this until it finds a setting where the driver was ready 25,000 times in a row. Also, the reason I use 60 clock cycles is because I know at least Mirage's fastcopy waits 64 clocks, so I did 60 just to be safe.
ThePenguin, epic! Would you mind if I used your code instead of JimE's graphbuf/checkbuf code? I'd be happy to credit you on the wiki Credits page. Here is one I wrote that finds the delay in about a second. Although it can be adjusted down to about .05 seconds. I have it check 25,000 times that the number is correct to be absolutely sure it is correct.
My routine zeros out the delay, (well $0C's it), then writes to the lcd driver, waits 60 clock cycles, and checks to see if the lcd is ready for a new command. If it's not, it increases the driver delay and tries again. It does this until it finds a setting where the driver was ready 25,000 times in a row. Also, the reason I use 60 clock cycles is because I know at least Mirage's fastcopy waits 64 clocks, so I did 60 just to be safe.
thepenguin77 wrote:
Sure. I don't care. I basically made it because I didn't like ALCDFIX.
I added it in and tested it out on-emu and on-calc; it saved me 82 bytes and works wonders. Cheers! 
elfprince13 wrote:
Quite the awesomesauce upgrade there. Big improvement over ALCDFIX from what it sounds like. We're closing in on Doors CS 6.8; should be a good one! Register to Join the Conversation
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
Advertisement