Show Posts
136
Axe / Re: Guts of a program editor
« on: September 26, 2019, 06:32:44 pm »
That menu looks so nice in your editor example! I'm about an hour from being able to actually check it out, but it all looks fantastic so far!
|
| Original routine |
Code: [Select]
p_LineShr:
.db __LineShrEnd-$-1
;; l=y2, ix=buff, (sp)=ret, (sp+2)=ret_2, (sp+4)=x2, (sp+6)=y1, (sp+8)=x1
ld a,l
pop bc
pop hl
pop de
ex (sp),hl
ld d,l
pop hl
ex (sp),hl
push bc
;; a=y2, d=y1, e=x2, l=x1, (sp)=ret, (sp+2)=ret_2
cp 64
ret nc
ld h,a
ld a,d
cp 64
ret nc
ld a,l
cp 96
ret nc
ld a,e
cp 96
ret nc
sub l
jr nc,__LineShrSkipRev
ex de,hl
neg
;; a=dx, d=y1, e=x2, h=y2, l=x1
__LineShrSkipRev:
push af ; Saving DX (it will be popped into HL below)
ld a,l ; IX+=L/8+D*12 (actually D*4+D*4+D*4)
rra
rra
rra
and %00011111
ld c,a
ld b,0
add ix,bc
ld a,d
add a,a
add a,a
ld c,a
add ix,bc
add ix,bc
add ix,bc
ld a,l ; Calculating the starting pixel mask
and %00000111
inc a
ld b,a
ld a,%00000001
__LineShrMaskLoop:
rrca
djnz __LineShrMaskLoop
ld c,a
ld a,h ; Calculating delta Y and negating the Y increment if necessary
sub d ; This is the last instruction for which we need the original data
ld de,12
jr nc,__LineShrSkipNeg
ld de,-12
neg
__LineShrSkipNeg:
pop hl ; Recalling DX
ld l,a ; H=DX, L=DY
cp h
jr nc,__LineVert ; Line is rather vertical than horizontal
ld a,h
__LineVert:
ld b,a ; Pixel counter
inc b
cp l
scf ; Setting up gradient counter
ccf
rra
scf
ret ; c=1, z=vertical major
__LineShrEnd:
Optimized routine: -4 bytes, -13cc
Code: [Select]
p_LineShr:
.db __LineShrEnd-$-1
;; l=y2, ix=buff, (sp)=ret, (sp+2)=ret_2, (sp+4)=x2, (sp+6)=y1, (sp+8)=x1
ld a,l
pop bc
pop hl
pop de
ex (sp),hl
ld d,l
pop hl
ex (sp),hl
push bc
;; a=y2, d=y1, e=x2, l=x1, (sp)=ret, (sp+2)=ret_2
ld h,a
ld a,63
cp h
ret c
cp d
ret c
ld a,95
cp l
ret c
cp e
ret c
ld a,e
sub l
jr nc,__LineShrSkipRev
ex de,hl
neg
;; a=dx, d=y1, e=x2, h=y2, l=x1
__LineShrSkipRev:
push af ; Saving DX (it will be popped into HL below)
ld a,d
add a,a
add a,a
ld c,a
ld b,0
add ix,bc
add ix,bc
add ix,bc
ld a,l
and 7
ld e,a
xor l
rra
rra
rra
ld c,a
add ix,bc
ld b,a
inc b
ld a,%00000001
__LineShrMaskLoop:
rrca
djnz __LineShrMaskLoop
ld c,a
ld a,h ; Calculating delta Y and negating the Y increment if necessary
sub d ; This is the last instruction for which we need the original data
ld de,12
jr nc,__LineShrSkipNeg
ld de,-12
neg
__LineShrSkipNeg:
pop hl ; Recalling DX
ld l,a ; H=DX, L=DY
cp h
jr nc,__LineVert ; Line is rather vertical than horizontal
ld a,h
__LineVert:
ld b,a ; Pixel counter
inc b
cp l
res 0,a ; Setting up gradient counter
rrca
ret ; c=0, z=vertical major
__LineShrEnd:
Or this version, it only save 3 bytes, but saves 10 more clock cycles:
Code: [Select]
p_LineShr:
.db __LineShrEnd-$-1
;; l=y2, ix=buff, (sp)=ret, (sp+2)=ret_2, (sp+4)=x2, (sp+6)=y1, (sp+8)=x1
ld a,l
pop bc
pop hl
pop de
ex (sp),hl
ld d,l
pop hl
ex (sp),hl
push bc
;; a=y2, d=y1, e=x2, l=x1, (sp)=ret, (sp+2)=ret_2
ld h,a
ld a,63
cp h
ret c
cp d
ret c
ld a,95
cp l
ret c
cp e
ret c
ld a,e
sub l
jr nc,__LineShrSkipRev
ex de,hl
neg
;; a=dx, d=y1, e=x2, h=y2, l=x1
__LineShrSkipRev:
ld e,a ; Saving DX
ld a,l ; IX+=L/8+D*12 (actually D*4+D*4+D*4)
rra
rra
rra
and %00011111
ld c,a
ld b,0
add ix,bc
ld a,d
add a,a
add a,a
ld c,a
add ix,bc
add ix,bc
add ix,bc
ld a,l ; Calculating the starting pixel mask
and %00000111
inc a
ld b,a
ld a,%00000001
__LineShrMaskLoop:
rrca
djnz __LineShrMaskLoop
ld c,a
ld a,h ; Calculating delta Y and negating the Y increment if necessary
sub d ; This is the last instruction for which we need the original data
ld h,e ; DX
ld l,a ; DY
ld de,12
jr nc,__LineShrSkipNeg
ld de,-12
neg
__LineShrSkipNeg:
cp h
jr nc,__LineVert ; Line is rather vertical than horizontal
ld a,h
__LineVert:
ld b,a ; Pixel counter
inc b
cp l
res 0,a ; Setting up gradient counter
rrca
ret ; c=0, z=vertical major
__LineShrEnd:
139
Grammer / Re: Grammer 2-The APP
« on: September 19, 2019, 07:39:33 pm »
This is just a quick update! I tracked down a critical bug in Grammer that has been around for a few of the mini releases (probably since last year). Send( was returning the wrong pointer, so if you started writing bytes to a file, you would almost certainly end up corrupting variables in RAM. Anyways, the link in the previous post now points to the corrected version 
140
Grammer / Re: Grammer 2-The APP
« on: September 13, 2019, 08:14:30 pm »
Hey folks, have the first official update in over seven years!
Since the last update, I've optimized some more and added in filled circle routines internally. With that, there are now 12 circle drawing methods, with various borders and fills (between white/black/invert/clear).
Download Grammer v2.50.6.3
Since the last update, I've optimized some more and added in filled circle routines internally. With that, there are now 12 circle drawing methods, with various borders and fills (between white/black/invert/clear).
Download Grammer v2.50.6.3
141
Grammer / Re: Latest Grammer Updates
« on: September 13, 2019, 08:08:50 pm »
EDIT: Updated this download with a critical bugfix with the Send( command. Was v2.50.6.3.
EDIT2: Yet more important bugs were fixed, now we are graduating to 2.50.6.7 for this update :|
Grammer v2.50.6.4
There have been many updates, importantly the version naming convention. In the past, the Grammer version was identified by the date that it was made. Now it is separated into 2.major.minor.veryminor.
Updates: This is NOT an exhaustive list.
To the language:
Here are some screenshots:
EDIT2: Yet more important bugs were fixed, now we are graduating to 2.50.6.7 for this update :|
Grammer v2.50.6.4
There have been many updates, importantly the version naming convention. In the past, the Grammer version was identified by the date that it was made. Now it is separated into 2.major.minor.veryminor.
Updates: This is NOT an exhaustive list.
- Older assembly Grammer programs will NOT be compatible with this version or versions going forward.
- Grammer is now a 2-page app (32768 bytes), whereas it used to be a 1-page app (16384 bytes).
- The main menu has been significantly updated, hopefully for the better.
- Some token replacements have been changed.
- Fixed various bugs, made various optimizations.
To the language:
- Grammer programs can now use external modules, via the ▶DMS token.
- G-T returns the address of the default front buffer.
- G-T' returns the address of AppBackUpScreen, a typical backbuffer.
- Wide support for floating point routines.
- Added stack support and better parameter parsing via Pmt_Bgn, Pmt_End, and Param
- Added the ▶Nom( ... End block to preserve a set of variables within the block. For example, you can save vars A, B, and C, use them within the block, and they'll be restored when the block ends. This is very useful for subroutines where you may want to use variables without destroying the callee's variables.
- Input has been changed! It now has a blinking cursor instead of highlighting the text.
- The Input buffer can now be relocated and you can set a max size! Useful for when you want to limit, say, a player's name. Use →Input and →Input'.
- The width argument for Pt-Off( is finally meaningful! Sprites can now be drawn to pixel coordinates and be wider (big sprites!).
- The Menu( command was totally rewritten. It looks similar, but is a lot smoother and will now scroll if there are too many entries (scrolling menu!). It is also much nicer on RAM usage, so you'll be able to fit more options than previously allowed.
- A new menu method is available via Menu('. You can supply a title, location, width, height, and pointers to two Grammer subroutines. The menu will then call your subroutines to get the string to display and the value to return upon selection. Useful for menus that have many options, but options that can be "computed" in some way (for example, reading lines from an external file and supplying those as options).
- Added 9 more Circle( methods using filled circles!
Here are some screenshots:
142
ASM / Re: ASM Optimized routines
« on: September 10, 2019, 06:18:29 pm »
Here is a circle routine that I made!
Draw 2x2 pixels:
Or draw a circle whose "pixels" are circles:
EDIT: Have a separate, filled rectangle routine!
Note that if you pass the same arguments as the regular circle routine, this only draws the inside part and skips the border.
Code: [Select]
;Written by Zeda Thomas, free to use.
;This draws a circle centered at 8-bit coordinates and with radius up to 127.
;IX points to a `plot` routine that takes (B,C)=(x,y) as input and does something
;with it, like plot the pixel a certain color, or plot a "big" pixel, or whatever.
; plot
; Takes coordinates, (B,C) = (x,y) and plots the point.
;
;For example, on the TI-83+/84+/SE the plot routine might look like:
; plot:
; call getpixelloc
; ret nc ;Exit if the coordinates are out-of-bounds
; or (hl)
; ld (hl),a
; ret
;
;
; Required subroutines:
; call_ix:
; jp (ix)
circle:
;Input:
; (B,C) is the center (x,y)
; D is the radius, unsigned, less than 128 (0 or greater than 128 just quits).
; IX points to a `plot` routine that takes (B,C)=(x,y) as input.
ld a,d
add a,a
ret c
ret z
ld l,d
dec a
ld e,a
dec a ;if the pixel is only 1 wide, just plot the point
jp z,call_ix ;Jump to the plot routine
xor a
ld h,-1
ld d,1
scf ;skip the first plot
circleloop:
call nc,plot4
inc h
sub d
inc d
inc d
jr nc,circleloop
_:
dec l
call plot4
add a,e
dec e
ret z
dec e
jr nc,-_
jp circleloop
plot4:
;BC is center
;HL is x,y
push de
push af
push hl
push bc
;If H is 0, or L is 0, we need to draw only half
push hl
ld a,b
sub h
ld b,a
add a,h
add a,h
ld h,a
ld a,c
sub l
ld c,a
add a,l
add a,l
ld l,a
;B is x0-x
;C is y0-y
;H is x0+x
;L is y0+y
;plot(x0-x,y0-y)
;plot(x0+x,y0+y)
push bc
push hl
call call_ix ;call the plot routine
pop bc
push bc
call call_ix ;call the plot routine
;now swap the y coords
pop hl
pop bc
ld a,l
ld l,c
ld c,a
pop de
xor a
cp d
jr z,+_
cp e
jr z,+_
;plot(x0-x,y0+y)
;plot(x0+x,y0-y)
push hl
call call_ix ;call the plot routine
pop bc
call call_ix ;call the plot routine
_:
pop bc
pop hl
pop af
pop de
ret
The really cool feature about this is that you can define a custom plot routine pointed to by IX, so it isn't TI-specific, and you can do all sorts of wonky things like:Draw 2x2 pixels:
Code: [Select]
;calling with `ld ix,pixelOn_2x2`
pixelOn_2x2:
sla b
ret c
sla c
ret c
push bc
call pixelOn
pop bc
inc b
push bc
call pixelOn
pop bc
inc c
push bc
call pixelOn
pop bc
dec b
jp pixelOn
Or draw a circle whose "pixels" are circles:
Code: [Select]
;calling with `ld ix,pixelOn_circle`
pixelOn_circle:
ld a,b
cp 32
ret nc
add a,a
add a,a
ld b,a
ld a,c
cp 32
ret nc
add a,a
add a,a
ld c,a
ld d,4
push ix ;need to save IX!
ld ix,pixelOn
call circle
pop ix
ret
EDIT: I inlined some subroutines because there was no reason to have them called. It was a waste of clock cycles and space!EDIT: Have a separate, filled rectangle routine!
Note that if you pass the same arguments as the regular circle routine, this only draws the inside part and skips the border.
Code: [Select]
;Written by Zeda Thomas, free to use.
;This draws the fill of a circle centered at 8-bit coordinates and with radius
;up to 127.
;IX points to a `horizontal line` routine that takes E=x, A=y, D=width as input
;and does something with it, like plot a horizontal line.
;
; For example, on the ti-83+/84+/SE calculators, you might have:
; horizontal_line:
; ld b,e
; ld c,a
; ld e,1
; ld hl,gbuf
; jp rectOR
; Required subroutines:
; call_ix:
; jp (ix)
filledcircle:
;Input:
; (B,C) is the center (x,y)
; D is the radius, unsigned, less than 128 (0 or greater than 128 just quits).
; IX points to a `plot` routine that takes (B,C)=(x,y) as input.
ld a,d
add a,a
ret c
ret z
ld l,d
dec a
ld e,a
xor a
ld h,-1
ld d,1
filledcircleloop:
; call c,fillcircle_plot
inc h
sub d
inc d
inc d
jr nc,filledcircleloop
_:
dec l
call fillcircle_plot
add a,e
dec e
ret z
dec e
jr nc,-_
jp filledcircleloop
fillcircle_plot:
inc h
dec h
ret z
push hl
push de
push bc
push af
dec h
ld a,b
sub h
ld e,a
ld d,h
sll d ;aka `slia`, undocumented
ld a,l
or a
ld h,c
jr z,+_
add a,h
push de
push hl
call nz,call_ix
pop hl
pop de
_:
ld a,h
sub l
call call_ix
pop af
pop bc
pop de
pop hl
ret
143
Super Smash Bros. Open / Re: [Axe] Super Smash Bros. Open
« on: September 09, 2019, 09:25:05 pm »
So far as I can tell, the latest version is here, but it is incomplete (they note in the readme that some of the attacks might not work, for example). Hayleia is still around in the calc programming community, but I don't think that they do any calc programming anymore.
144
Grammer / Re: Grammer 2-The APP
« on: September 05, 2019, 08:16:30 pm »
Minor update to the above.
The menu routine is now more efficient on scrolling. I did actually take advantage of the "rectangle shift up/down" routines so now it makes fewer calls to the Grammer routines, improving performance.
Here is what it looks like now:
I also remade the rectangle routines. It is 112 bytes larger, but it is cleaner code, uses 4 bytes of already allocated RAM instead of 24 bytes of specially allocated RAM, and doesn't use shadow registers (so it doesn't need to disable interrupts). As well, I added two new methods-- they both invert the border, but one clears the inside, the other sets it to black. I have no idea why that might ever be desirable, but I have all the other methods of setting the border and fill to black/white/clear/invert, so why not? (and it didn't add much to the code). Now I just need to add in left/right rectangle shifts and world domination will be mine.
Attached is the .8xk for those who need the latest.
The menu routine is now more efficient on scrolling. I did actually take advantage of the "rectangle shift up/down" routines so now it makes fewer calls to the Grammer routines, improving performance.
Here is what it looks like now:
I also remade the rectangle routines. It is 112 bytes larger, but it is cleaner code, uses 4 bytes of already allocated RAM instead of 24 bytes of specially allocated RAM, and doesn't use shadow registers (so it doesn't need to disable interrupts). As well, I added two new methods-- they both invert the border, but one clears the inside, the other sets it to black. I have no idea why that might ever be desirable, but I have all the other methods of setting the border and fill to black/white/clear/invert, so why not? (and it didn't add much to the code). Now I just need to add in left/right rectangle shifts and world domination will be mine.
Attached is the .8xk for those who need the latest.
145
Other Discussions / Re: Pokemon Amber
« on: September 05, 2019, 06:48:20 pm »
It turns out that I actually used a lot of the code in the OmniRPG project to get a mockup and the source was available for that. The Pokemon Amber project is essentially dead, but I did look through the code and try to get it up and running. The code was super convoluted and poorly documented, so it would have been difficult to expand upon.
However, it did inspire me to work on an RPG engine (also incomplete) if you are ever feeling motivated! Here's an up-to-date .gif of the example for the project:
You can see the coordinates in the upper right that are on for debugging, and the name input leaves a lot to be desired (in fact, it doesn't even work yet
)
However, it did inspire me to work on an RPG engine (also incomplete) if you are ever feeling motivated! Here's an up-to-date .gif of the example for the project:
You can see the coordinates in the upper right that are on for debugging, and the name input leaves a lot to be desired (in fact, it doesn't even work yet
)146
General Calculator Help / Re: TI-89 and TI-Connect Not working after TiLP install
« on: September 04, 2019, 09:29:29 pm »
Yes, TiLP does let you load programs onto your calc.
I think you need to upgrade your OS if you want to run the program that you are trying to download. Unfortunately, TI's site only has v3.10 (for the 89 Titanium). You'll probably need to email them to obtain a copy of OS 2.09 for the basic TI-89.
I think you need to upgrade your OS if you want to run the program that you are trying to download. Unfortunately, TI's site only has v3.10 (for the 89 Titanium). You'll probably need to email them to obtain a copy of OS 2.09 for the basic TI-89.
147
General Calculator Help / Re: TTI-89 and TI-Connect Not working after TiLP install
« on: September 04, 2019, 11:05:33 am »
I don't know how to help, unfortunately. But for the sake of the next person who might know:
I haven't used TIConnect in years, but I think there might be a new version since that page was updated. I find TiLP to be a bit more reliable, so I've just stuck with that
- Which OS (I'm assuming Windows? If so, what version?)
- Is TIConnect displaying an error message? If so, what is the error?
I haven't used TIConnect in years, but I think there might be a new version since that page was updated. I find TiLP to be a bit more reliable, so I've just stuck with that
148
Grammer / Re: Grammer 2-The APP
« on: September 03, 2019, 02:21:54 pm »
There are perks to both languages, that's for sure. I think Grammer is better for higher-level stuff, and Axe is better for faster, lower level stuff.
EDIT: Here is what the fancy menu looks like now:
For this one, each of the items is generated on-the-fly by a Grammer subroutine, and that contributes to it's slowness. It has to execute the subroutine every time the user moves up or down, as well as whenever an element is generated. In this implementation, every time the menu scrolls, it has to generate all of the elements from scratch. I might make it just scroll the contents up or down and generate a single item instead of the whole thing, but that's for future work. At least Grammer already has code for shifting rectangular regions of the screen up or down!.
EDIT: Here is what the fancy menu looks like now:
For this one, each of the items is generated on-the-fly by a Grammer subroutine, and that contributes to it's slowness. It has to execute the subroutine every time the user moves up or down, as well as whenever an element is generated. In this implementation, every time the menu scrolls, it has to generate all of the elements from scratch. I might make it just scroll the contents up or down and generate a single item instead of the whole thing, but that's for future work. At least Grammer already has code for shifting rectangular regions of the screen up or down!.
149
Grammer / Re: Grammer 2-The APP
« on: September 03, 2019, 12:46:32 am »
Grammer now has proper support for big sprites! With the Pt-Off( command, you can now specify a width argument and it will actually work (with proper clipping, too).
I also totally overhauled the Menu( command. On the surface, it will look largely the same, except that now it allows scrolling if their are too many elements. Internally, it requires a much smaller memory footprint and has a more powerful menu interface. To take advantage of this, I added the Menu(' command. With this one, you can supply two Grammer subroutines to compute the outputs. The syntax looks like:
I also totally overhauled the Menu( command. On the surface, it will look largely the same, except that now it allows scrolling if their are too many elements. Internally, it requires a much smaller memory footprint and has a more powerful menu interface. To take advantage of this, I added the Menu(' command. With this one, you can supply two Grammer subroutines to compute the outputs. The syntax looks like:
Code: [Select]
Menu('"Title",y,x,height,width,GET_ELEMENT_ptr,SELECT_ELEMENT_ptr
The subroutine for GET_ELEMENT will receive the index in Ans. Return 0 if it is out-of-bounds, else return a pointer to the string to display. The subroutine for SELECT_ELEMENT will receive the index in Ans. Modify this as you want, the result will be returned as the result of the menu. 0 is returned if the menu exited due to [CLEAR] or [ON]. An example is:Code: [Select]
Lbl "GET→A
Lbl "SEL→B
Menu('"Title",2,33,59,30,A,B→M
Text('0,0,M
Stop
.GET
→X<26
If !
End
"ITEM A→Z
int(Z+5,X+65
Z
End
.SEL
+1
End
That will display items with the name "ITEM A" through "ITEM Z".
150
TI Calculators / Re: Downgrading OS if nLaunchy is already present
« on: August 29, 2019, 10:17:51 am »
As far as I can tell, once you have had 4.5.1, you will need to wait for a new exploit to be found (and that can take a long while).