Show Posts

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 - Xeda112358

Pages: [1] 2 3 ... 315
1
Axe / Re: Looping Through an Array in Axe
« on: June 25, 2021, 04:57:29 pm »
If M  is less than 192, then M-192 will wrap back around to be >=65344.

Is that possibly the issue ? If so, and if Z is small enough, then you can probably change it to compare M with Z+128 instead.

2
ASM / Re: ASM Optimized routines
« on: June 18, 2021, 06:35:59 pm »
Wow, that's really neat. I don't have a use for that at the moment but I bet I can find one in some old, slow code.

How did you go about making the routine generator? I assume there are some simple rules it follows.
It looks through all the numbers 1-65535 to find some good code.
If the number is even, it essentially uses the code for n/2, but with an `add hl,hl` tacked on to the end. Otherwise it is odd and it first tries a shift-and-add algorithm (basically the classic, generic multiplication, but unrolled and with branches removed as we know which path it takes in advance). It registers whatever code it came up with, then it checks if it is faster or smaller to multiply by the factors (for example, it is faster to multiply by 27 by doing *3*9 or *9*3), so it finds all of the factors and checks for anything more efficient.

There are other tricks, too, like checking if it is faster to "negate" (i.e., *65535 is the same as *-1), and if there is a *(2^k-1) with k>3, it uses a subtraction. And it collapse things like 8 `add hl,hl` into `ld h,l \ ld l,0`, and has some pre-populated routines in the table.

It doesn't really know anything about the instruction set, so it can't do any fancy optimizations :(

3
ASM / Re: ASM Optimized routines
« on: June 18, 2021, 05:19:34 pm »
I wrote a program to generate 16-bit multiplication-by-constant routines. It isn't perfect, but it probably produced optimal code for a lot of them!

The attached tar.xz file has the (undocumented) program and a 28.8MB file of routines :P

For example, it has these two routines for mul_hl_1337:
Code: [Select]
mul_hl_1337:  ; size optimized
;17 bytes, 173cc
  ld b,h
  ld c,l
  add hl,hl
  add hl,hl
  add hl,bc
  add hl,hl
  add hl,hl
  add hl,hl
  add hl,bc
  add hl,hl
  add hl,bc
  add hl,hl
  add hl,bc
  add hl,hl
  add hl,hl
  add hl,hl
  add hl,bc

Code: [Select]
mul_hl_1337:  ; speed optimized
;25 bytes, 148cc
  ld b,h
  ld c,l
  add hl,hl
  add hl,bc
  add hl,hl
  add hl,bc
  ld b,h
  ld c,l
  add hl,hl
  add hl,bc
  ld a,h
  ld h,l
  rra
  rr h
  rra
  rr h
  rra
  and 11000000b
  ld l,a
  or a
  sbc hl,bc

4
The Axe Parser Project / Re: Flickering Text (and collision?)
« on: June 04, 2021, 09:25:57 pm »
That is probably the simplest and fastest method and shouldn't slow it down much, but there might be order-of-operations issues, so you might need:
Code: [Select]
If (A>(X-8)) and (A<(X+8))
Alternatively:
Code: [Select]
If (A-X>-8) and (A-X<8)
But for Axe, that can probably be optimized to:
Code: [Select]
If A-X+7 < 15
(This is taking advantage of "negative" numbers actually being really large, so you don't need to make sure A-X+7>=0. If it was "smaller" than zero, it would actually be around 65000 which is not less than 15 :P)

5
The Axe Parser Project / Re: Flickering Text
« on: June 04, 2021, 09:00:09 pm »
Haha, no problem, and I merged those posts together.

The code looks like it should work. So for an optimization, if you draw the sprite with XOR logic, then DispGraph, then re-draw with XOR logic, then you won't have to ClrDraw to remove the sprites. (It's like doing a pxl-change/DispGraph/pxl-change)

So what about the text? You can draw the initial score before the loop, and after that, only re-draw the score when you increment D.

Drawing text can be slow, so only drawing it when needed will save a lot of time in your loop.

EDIT: clarified what xor/disp/xor was doing

6
The Axe Parser Project / Re: Flickering Text
« on: June 04, 2021, 08:50:10 pm »
You have the Fix 4 inside the loop so after the first iteration, it starts drawing directly to the LCD again. If you move it outside the loop (after the End), then it should work.

Also as general forum etiquette, you can Modify your post instead of double- (or triple-) posting :P (Double posting is when you post twice in a row. General rule of thumb is that after a day since the last post it is okay to double-post.)

7
The Axe Parser Project / Re: Flickering Text
« on: June 04, 2021, 08:22:17 pm »
If that is your loop then it shouldn't be flickering as far as I can tell. Can you post the rest of the code? It'll only be flickering of there is another DispGraph between the ClrDraw and DispGraph (or of course if the text is changing :P )

Also, if you only draw the text and update the screen (DispGraph) when something changes, then you'll get a significant speed-up.

EDIT: Ooohhh, I know the issue. At the start of your program (not in the loop), use Fix 5 and before you exit, run Fix 4.
The default behavior of Text( is to draw directly to the LCD and not the graphics buffer (this is what TI-OS expects when your program is finished). Fix 5 switches it to draw to the buffer and not the LCD.

So you would draw the text, and then when DispGraph, the text isn't drawn to the buffer and so it gets erased.

8
ASM / Re: [z80] Floating Point Routines
« on: May 06, 2021, 07:59:08 pm »
Wow, it has been over a year since I last updated this thread! :D

I've added support for IEEE-754 binary32 floats here!
What is really nice about this is that compilers like fasmg have built-in support for these floats, and there are a plethora of existing tools to work with them.
I've rearranged the project a bit and I am working on making the code more agnostic (so not relying on spasm's unique features). I've added a lot of conversion routines, especially for f32 and f24 floats.

I took an unplanned path with the f32 floats and ended up making addition, subtraction, multiplication, division, and square roots work entirely within registers and the stack, so no external RAM was required. I haven't taken the time to do a speed analysis of these, but I'm thinking they are a little slower than the single routines. I expect that multiplication and division are slower, and hopefully addition and subtraction are faster.

9
Computer Programming / Re: Alternatives to Ti-BASIC
« on: April 15, 2021, 07:33:23 pm »
Out of curiosity, why are you trying to avoid Axe and Grammer?

10
News / Re: Bringing the community together!
« on: April 01, 2021, 08:02:21 pm »
I don't think I can do an OnlyFans; I'm just not ready for that kind of responsibility :|

11
TI 68K / Re: Authenticator App
« on: February 24, 2021, 09:01:12 pm »
@ACagliano just implemented sha1 and sha256 for the eZ80 calcs, so maybe Cags would be interested :P

As for the time, on the 84+ you can just read a byte from each port 0x41-0x44

12
TI 68K / Re: Best way to perform clipping with irregular shapes
« on: February 22, 2021, 04:47:29 pm »
I think what I would suggest is what you are already trying to do. For irregular collision boxes, I set a "collision buffer" the size of the screen (1bpp), and in that buffer I set the pixel on if it's a collision point, else off. Then when I am drawing the tile, so draw it's collision sprite to the collision buffer.

I have no idea how to do this on the 68k calcs :P

13
Introduce Yourself! / Re: Greetings
« on: February 18, 2021, 06:38:01 am »
Hi! Have some !peanuts !

I've dabbled in 68k C and assembly, though that was a looong time ago :P What kind of stuff do you make?

14
Again, on behalf of Soru from Discord:
Quote
are you sure it is reset completely? try leaving the room and then come back in

15
@Sorunome ? It has been a while since I played, but I do remember doing one of these puzzles.

EDIT: (Posting on behalf of Soru, quoting from Discord):
Spoiler For Spoiler:
the way you orogress through the tilemaps on the way there through the cave
the shortest path, not the actual one you walked

Pages: [1] 2 3 ... 315