Author Topic: Bug Reports (Read 404895 times)

Freyaday · « **Reply #1170 on:** April 04, 2011, 03:12:59 am »

If changing the clock speed doesn't harm the CPU, then why is overclocking so bad? And try this:
0->X->Y->M
[F09090F000000000]->Pic4
Normal
Repeat getkey(15)
Repeat getkey(0)
Pt-Change(X*4,Y*4,Pic4
Pt-Change(X*4,Y*4,Pic4)^r
If M
DispGraph^{rr^{Else
DispGraph^r
End
End
X+getkey(3)-getkey(2)+16^16->X
Y+getkey(1)-getkey(4)+16^16->Y
If getkey(55)
not(M)->M
End
Pause 200
End
Full}}

Runer112 · « **Reply #1171 on:** April 04, 2011, 03:18:18 am »

Quote from: Freyaday on April 04, 2011, 03:12:59 am

If changing the clock speed doesn't harm the CPU, then why is overclocking so bad?

The z80 processor in the calculators supporting 15MHz mode was designed to be able to operate at 15MHz. Setting it to 15MHz isn't overclocking it. In fact, the calculator normally runs at 15MHz, so it would be more realistic to say that setting it to 6MHz is underclocking it. And there would be no damage from changing the CPU speed, that's just like changing the value of any other internal data or port in the calculator.

As for your speed discrepancy, I'm guessing you're seeing it because the DispGraph^rr routine is slower than the DispGraph^r routine.

Freyaday · « **Reply #1172 on:** April 04, 2011, 03:26:34 am »

Try the code and move the cursor and lightly press MODE a couple of times and you'll see what I mean. And I was talking about overclocking in general.

Runer112 · « **Reply #1173 on:** April 04, 2011, 03:35:40 am »

I don't notice any speed difference at all. Holding down an arrow key for 2 seconds and then letting go, the sprite moved the exact same number of pixels in both grayscale modes.

And I'm not entirely sure how a general overclocking discussion would be pertinent to the Axe Bug Reports thread.

Builderboy · « **Reply #1174 on:** April 04, 2011, 03:37:33 am »

Try simply this:

For(F,0,9000
Pt-Change(0,0,0
End

and then this

For(F,0,9000
Pt-Change(7,0,0
End

there should be a tremendous speed difference, even though there isn't even a dispGraphrr in the picture. Whenever you are measuring speed, never include display updates in your code because the time they take to execute can be variable, and can mess with your readings.

Quigibo · « **Reply #1175 on:** April 04, 2011, 03:41:46 am »

The display routines are actually consistent now and will run the same speed every time. Its the system interrupts you should turn off when doing speed tests.

Freyaday · « **Reply #1176 on:** April 04, 2011, 03:48:19 am »

And how do I do that? And I was judging speed by the blinking of the cursor. Watch it on a real calc and see what happens.

Builderboy · « **Reply #1177 on:** April 04, 2011, 04:00:55 am »

Did you try the programs I suggested? I can assure you the speed difference lies within Pt-change and not the display routines. And I also might point out that if you only have a single Pt-change in your code, along with a pause and a display, any changes in speed are going to be near impossible to change, and indeed I didn't see any change in the blinking of the cursor when I tried it.

Freyaday · « **Reply #1178 on:** April 04, 2011, 04:09:22 am »

Did you move the cursor? Did you press MODE lightly?

Mighty Moose · « **Reply #1179 on:** April 05, 2011, 04:57:04 pm »

There's is a silly GetCalc(Name,File) bug in some of the more recent versions of Axe

Explained here in a PM between Fast Crash and me when I first noticed it...

Quote

2:You were right, Axe has a bug; it doesn't always give the right pointer. Let's say that the length of the program's name is L ("prgmA": L=1), and the beginning of the program is P. Here is what Yx will point to:

L=1 : P+1
L=2 : P
L=3 : P-1
L=4 : P-2
L=5 : P-3
L=6 : P-4
L=7 : P-5
L=8 : P-6

Well that's confusing...

Anyway, just I thought I should mention this, since this is kind of a problem.

Runer112 · « **Reply #1180 on:** April 05, 2011, 04:59:46 pm »

I believe this bug was fixed in Axe 0.5.1. Are you using the latest version of Axe?

Mighty Moose · « **Reply #1181 on:** April 05, 2011, 05:08:52 pm »

I thought so, but I could be wrong...I'll go try soon.

EDIT: Yep, using Axe 0.5.1 and got a 20kb sized file in ram after creating an appvar using the (incorrectly) read size byte of an archived program

Quigibo · « **Reply #1182 on:** April 05, 2011, 06:19:20 pm »

You're using {Y₁-2}^r or something similar to get the value right? The value returned from the GetCalc is not a pointer if you're reading into a file, its just a boolean to check if it exists.

Mighty Moose · « **Reply #1183 on:** April 05, 2011, 06:24:11 pm »

Yes, I am using {Y1-2}^r. P was just used as an arbitrary example - probably should have used Y1 or something else instead to avoid confusion.

Freyaday · « **Reply #1184 on:** April 07, 2011, 04:24:08 pm »

When I did Copy(L3,X^o,2) it gave me an ERR:ARGUMENT on the parenthesis. I tried removing the parenthesis, and it errored at the start of the following line. It only stopped erroring when I put in ,2 as a fourth argument. It did the same thing on Copy(X^o,L3,2). I don't think it has to do with the specific value of 2 for that fourth arg, cause that's the only one I've tried.

Author Topic: Bug Reports (Read 404895 times)

Freyaday

Re: Bug Reports

Runer112

Re: Bug Reports

Freyaday

Re: Bug Reports

Runer112

Re: Bug Reports

Builderboy

Re: Bug Reports

Quigibo

Re: Bug Reports

Freyaday

Re: Bug Reports

Builderboy

Re: Bug Reports

Freyaday

Re: Bug Reports

Mighty Moose

Re: Bug Reports

Runer112

Re: Bug Reports

Mighty Moose

Re: Bug Reports

Quigibo

Re: Bug Reports

Mighty Moose

Re: Bug Reports

Freyaday

Re: Bug Reports