| Author |
Message |
|
thepenguin77
Advanced Newbie
Joined: 17 Jul 2009
Posts: 72
|
 Posted: 26 Sep 2009 09:38:44 pm Post subject: |
|
|
So the other day I hacked FTUN to use fast mode and my own fastcopy. But I noticed that on some calculators it would run almost twice as fast as others. So I decided to make a program to test the LCD speed because those fast calculators also didn't need ALCDFIX. Since I was making a speed program I also decided to test to CPU clock speed.
But whenever I run my program, it is determined to tell me that my cpu runs at 15,770,000 hz. This is the actual timing part.
Code:
ld a, $46 ;128 hz
out ($30), a
ld a, 2
out ($31), a
ld a, 128 ;1 sec
out ($32), a
ei
cpuLoop:
ld a, 1 ;7
ld hl, timer ;10
add a, (hl) ;7
ld (hl), a ;7
inc hl ;6
ld a, 0 ;7
adc a, (hl) ;7
ld (hl), a ;7
inc hl ;6
ld a, 0 ;7
adc a, (hl) ;7
ld (hl), a ;7
jr cpuLoop ;12
;97
cpuDone:
;multipy by 97 and display
The interrupt basically just goes to cpuDone:.
The calculator is in 01 speed, the CLOCK program on ticalc says 14990000, and the flash debugger confirms that this is 97 t-states.
So any ideas? |
|
| Back to top |
|
|
calc84maniac
Elite
Joined: 22 Jan 2007
Posts: 770
|
| Posted: 26 Sep 2009 09:49:58 pm Post subject: |
|
|
| The ALCDFIX program increases the delay which is automatically included after you access the LCD hardware (which is why it fixes all those problems). So the program running more slowly is due to that delay. |
|
| Back to top |
|
|
thepenguin77
Advanced Newbie
Joined: 17 Jul 2009
Posts: 72
|
| Posted: 26 Sep 2009 10:22:30 pm Post subject: |
|
|
That's why I wrote the other half of this program. Because I wanted to see how much difference there actually was.
Last edited by Guest on 26 Sep 2009 10:23:11 pm; edited 1 time in total |
|
| Back to top |
|
|
calc84maniac
Elite
Joined: 22 Jan 2007
Posts: 770
|
| Posted: 26 Sep 2009 10:27:10 pm Post subject: |
|
|
thepenguin77 wrote: That's why I wrote the other half of this program. Because I wanted to see how much difference there actually was.
Well, you're not going to see any difference if you're never interfacing with the LCD hardware though. Here's the technical info, by the way. |
|
| Back to top |
|
|
DrDnar
Member
Joined: 28 Aug 2009
Posts: 116
|
| Posted: 27 Sep 2009 12:52:11 am Post subject: |
|
|
By the CLOCK program do you mean mine? What model are you using? I've wondered how different calculators measure on CPU clock speed, and with different battery levels.
Can you post the full source to your program? I noticed that you're running the whole loop with interrupts enabled. If the interrupt triggers while the counter is incrementing, you could get a very odd value. I know it's not likely, but it's possible. There might also be some other odd bug in the code.
Take a look at the ALCDFIX source. You might be able to get it to just directly tell you how much it's slowing things down. |
|
| Back to top |
|
|
calc84maniac
Elite
Joined: 22 Jan 2007
Posts: 770
|
| Posted: 27 Sep 2009 08:07:09 am Post subject: |
|
|
[quote name='Dr. D'nar' post='136881' date='Sep 27 2009, 01:52 AM']By the CLOCK program do you mean mine? What model are you using? I've wondered how different calculators measure on CPU clock speed, and with different battery levels.
Can you post the full source to your program? I noticed that you're running the whole loop with interrupts enabled. If the interrupt triggers while the counter is incrementing, you could get a very odd value. I know it's not likely, but it's possible. There might also be some other odd bug in the code.
Take a look at the ALCDFIX source. You might be able to get it to just directly tell you how much it's slowing things down.[/quote]
I don't think ALCDFIX comes with source.  |
|
| Back to top |
|
|
thepenguin77
Advanced Newbie
Joined: 17 Jul 2009
Posts: 72
|
| Posted: 27 Sep 2009 10:04:06 am Post subject: |
|
|
Yes I meant your clock program. I have a 84+ SE hardware M.
For ALCDFIX I could probably just look at the value in the screen delay port after I run it.
As for interrupts giving weird results, I also tried this with just checking port 4 and got basically the same result.
And the soure is probably pretty inefficient but I don't use bcalls that much.
Last edited by Guest on 27 Sep 2009 10:15:03 am; edited 1 time in total |
|
| Back to top |
|
|
DrDnar
Member
Joined: 28 Aug 2009
Posts: 116
|
| Posted: 27 Sep 2009 02:48:55 pm Post subject: |
|
|
I get about 15444100 on my calculator. Are you sure the xMult routine works correctly? I did
Code:
cpuDone:
ld hl, moo;Timer
ld de, temp1
ld bc, 4
ldir
ld bc, 4
ld e, 1;97
ld ix, temp1
call xmult
. . .
moo: .db 11,11,11,11
but the numbers don't seem to come out right. Have I misunderstood how the routine works?
You might be getting a larger number because you leave the CPU in the fast mode longer. My program switches rather fast. |
|
| Back to top |
|
|
thepenguin77
Advanced Newbie
Joined: 17 Jul 2009
Posts: 72
|
| Posted: 27 Sep 2009 03:01:18 pm Post subject: |
|
|
The way it works is bc = number of bytes, e = number to multiply by, and ix = start of the number.
I confirmed that the xmult works because I was a little skeptical too. The way I check it is by using the Flash Debugger and changing the ram it looks at just before it executes it. So I have put in 14990000/97 and multiplied it and got 14989992 or something. And I just ran the $11111111 through with e = 1 and got $11111111.
The multiply and displaying parts are right, even though ugly. That's what made me confused.
Edit: just found your problem, you typed in 11d, 11d, 11d, 11d = $B0B0B0B0. Is that what you got?
Last edited by Guest on 27 Sep 2009 03:05:52 pm; edited 1 time in total |
|
| Back to top |
|
|
DrDnar
Member
Joined: 28 Aug 2009
Posts: 116
|
| Posted: 27 Sep 2009 04:29:35 pm Post subject: |
|
|
Ahh, yeah, forgot the h suffix. So it does work.
I think I actually like your method better. Who knows, your program could be right and mine wrong. Your program gives 15000080 Hz in Wabbit and mine gives 15.03 MHz. I think it's more likely that Wabbit's fast mode is clocked to exactly 15MHz and not 15.03MHz.
Oh yeah, the FPS test gives 119 fps, which is the correct theoretical value IIRC.
Last edited by Guest on 27 Sep 2009 04:49:34 pm; edited 1 time in total |
|
| Back to top |
|
|
thepenguin77
Advanced Newbie
Joined: 17 Jul 2009
Posts: 72
|
| Posted: 27 Sep 2009 05:00:44 pm Post subject: |
|
|
I tested it on a friend's 84+. It said 15080000 and the FPS was 117. My FPS is 120 so the difference is probably just cpu.
These FPS rates suck for games though. The average game probably runs at 30 FPS, so that is 1/4 of cpu time gone to the screen.
And I see what you mean about CLOCK. Maybe the cpu is just getting warmed up when you perform you're tests.
Edit: Ok a lot more tests.
cpu speeds:
1 x 15 mhz BE
5 x 15.7 mhz SE
1 x 16.1 mhz BE
1 x 16.3 mhz BE
lcd speeds:
3 x 120 fps BE and SE
3 x 240 fps SE
2 x 280 fps BE
Obviously this isn't a very large sample. But it seems kind of strange that the BEs can have really weird results. The two BEs that were in the 16 mhz were also the ones with the 280 fps. And that one BE had 15 mhz.
Last edited by Guest on 28 Sep 2009 03:11:09 pm; edited 1 time in total |
|
| Back to top |
|
|
|
Z80 & 68k Assembly => z80 & ez80 Assembly
