Author Topic: Bug Reports (Read 404141 times)

calc84maniac · « **Reply #135 on:** April 12, 2010, 06:37:21 pm »

Quote from: Builderboy on April 12, 2010, 06:35:22 pm

Is this intentional?

5->{L1}->A

Now A does not hold 5, but rather the address of L1. This just caused me a horrible debugging session until i figured it out

Yeah, I asked about that earlier so I could know if I could use that for optimizations (it can be useful for post-incrementing pointers)

Quigibo · « **Reply #136 on:** April 12, 2010, 10:30:42 pm »

Originally, it was unintentional, but it produces the smallest code. It could return the answer, but then it adds an extra byte or 2 every time you store to a pointer. Both ways have advantages in optimization.

You can optimize this:

A->{L1}
B->{L1+1}
C->{L1+2}

like this:

C->{B->{A->{L1}+1}+1}

So don't think that its a bad thing it returns the pointer, there are some good things you can do with it.

calc84maniac · « **Reply #137 on:** April 12, 2010, 10:32:00 pm »

Quote from: Quigibo on April 12, 2010, 10:30:42 pm

Originally, it was unintentional, but it produces the smallest code. It could return the answer, but then it adds an extra byte or 2 every time you store to a pointer. Both ways have advantages in optimization.

You can optimize this:

A->{L1}
B->{L1+1}
C->{L1+2}

like this:

C->{B->{A->{L1}+1}+1}

So don't think that its a bad thing it returns the pointer, there are some good things you can do with it.

I especially like being able to do things like Fill(0->{L1},15)

Edit:
Oh, and anyone who wants to use these optimizations, please note that ->{}^r will return the address plus one.

Quigibo · « **Reply #138 on:** April 13, 2010, 02:49:43 am »

Uuugggg....

I just noticed that the grayscale command is not working. It worked fine on wabbit, but it fails on actually hardware. Its too fast for the LCD drivers, and on Full speed mode its even worse. I thought becasue it was grayscale that extra code would give it that time delay it needs, but damn that LCD driver is slow! I have one of the newer 84s by the way with the slower driver. I think the only reason Pyoro worked in gray was that I had a triple buffer, which was just slow enough for the delay.

I'll have it fixed next version.

DJ Omnimaga · « **Reply #139 on:** April 13, 2010, 03:40:23 am »

ouch sorry to hear

I hope you find a solution. I guess this is a major issue when it comes to calcs without memory-mapped LCD

Raylin · « **Reply #140 on:** April 13, 2010, 06:58:06 am »

I have sympathy for you.

That sucks...

I also hope you find a solution.

SirCmpwn · « **Reply #141 on:** April 13, 2010, 05:10:24 pm »

Found a bug:
You cannot divide negitive numbers. So, this does not work:

Code: [Select]

-2→A
A/2→A

A temporary workaround is this:

Code: [Select]

-2→A
-(-A/2→A

Quigibo · « **Reply #142 on:** April 13, 2010, 05:15:20 pm »

Wait, what do you mean "by zero"? Anytime you divide by zero the calculator is supposed to explode! (or return -1)

I'm already aware of that the current division routine is unsigned, and purposely so. The signed division will come soon. You can do signed division with the "//" operator in the future.

SirCmpwn · « **Reply #143 on:** April 13, 2010, 05:18:44 pm »

Oops, divide by anything.
My bad. Edit now.

DJ Omnimaga · « **Reply #144 on:** April 13, 2010, 05:41:47 pm »

Quote from: Quigibo on April 13, 2010, 05:15:20 pm

Wait, what do you mean "by zero"? Anytime you divide by zero the calculator is supposed to explode! (or return -1)

I'm already aware of that the current division routine is unsigned, and purposely so. The signed division will come soon. You can do signed division with the "//" operator in the future.

I thought division by zero results with Axe were >9000?

Quigibo · « **Reply #145 on:** April 14, 2010, 02:56:39 am »

Okay, I've got headers working now for all shells

But I found a problem. When text is displayed past the last line, scrolling the rest of the text upwards, the Mirage OS version freaks out and starts displaying the text diagonally o_O I'm guessing that MOS is either using some other ram like the text shadow or its setting some type of weird flag before running the programs. This makes me worried that some other commands might not work either due to this issue.

I should probably get a list of ram locations used by other shells so I can mention where NOT to write to in the documentation. I made a screenshot of what's happening. Does anyone know what's causing this?

DJ Omnimaga · « **Reply #146 on:** April 14, 2010, 03:15:14 am »

o.o

Wow,

it acts exactly like when I tried to run Galaxian in No-stub mode on OS 1.14 :O

I guess it conflicts with Mirage or something

, but I'm not sure. I can't help since I don't know ASM.

EDIT:

Quote

[03:10:10] <+Buckeye> DJ_Omni
[03:10:27] <+Buckeye> you should have quigibo check out appautoscroll flag
[03:10:46] <+Buckeye> mirage might unset that
[03:10:59] <+Buckeye> although im not sure if it would cause diagonal text

Quigibo · « **Reply #147 on:** April 14, 2010, 03:27:29 am »

Yup, that was it. I guess I'll just have to add an extra 4 bytes to shell programs to set the flag.

DJ Omnimaga · « **Reply #148 on:** April 14, 2010, 03:49:29 am »

X.x

oh well glad it is fixable ^^

SirCmpwn · « **Reply #149 on:** April 14, 2010, 10:47:37 am »

Could you change the sprite routine to use IonPutSprite if you are running from a shell? Save on size?

Author Topic: Bug Reports (Read 404141 times)

calc84maniac

Re: Bug Reports

Quigibo

Re: Bug Reports

calc84maniac

Re: Bug Reports

Quigibo

Re: Bug Reports

DJ Omnimaga

Re: Bug Reports

Raylin

Re: Bug Reports

SirCmpwn

Re: Bug Reports

Quigibo

Re: Bug Reports

SirCmpwn

Re: Bug Reports

DJ Omnimaga

Re: Bug Reports

Quigibo

Re: Bug Reports

DJ Omnimaga

Re: Bug Reports

Quigibo

Re: Bug Reports

DJ Omnimaga

Re: Bug Reports

SirCmpwn

Re: Bug Reports