1156
TI Z80 / Re: [AXE] input routine.
« on: February 11, 2013, 06:02:20 pm »
Nice, that seems much better already!
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. 1156
TI Z80 / Re: [AXE] input routine.« on: February 11, 2013, 06:02:20 pm »
Nice, that seems much better already!
1157
Grammer / Re: What's wrong with this code ?« on: February 11, 2013, 06:01:13 pm »
I did not have the problem you described, but I do see a big problem with the code and a bunch of smaller problems (maybe).
The big problem is that they never used End for one of their While loops ![]() The little problems are just regular coding optimisations ![]() Code: [Select] Full1 Is the same as:Code: [Select] Full Code: [Select] While Y>0 Since Grammer only has non-negative integers (0,1,2,3,4,...,65535), you can do:Code: [Select] While Y Instead of 'X:-X>0:→X'you can just do X-X>0→X or even better, since Grammer doesn't have negative numbers, X-!X→X In fact, for movement, this is better: Code: [Select] X+K=3 Say X=0 and you press [Left]. Then the first two lines do 0-1 which is 65535, and since 65535≥86, it isn't stored to X.Here is how I optimised/fixed it: Code: [Select] .0:Return It is not perfect, but it works a lot faster (faster than before, even without Full). And more, it is now easy to add more barriers on the screen at once! Here is the screenie of the version I made with better collision detection and variable speed and stuff ![]() 1158
ASM / Re: Opcodes that should have been incorporated into the Z80 processor« on: February 11, 2013, 07:27:25 am »
Yes, add, sub, adc, and sbc with hl for immediate values would have been nice o.o
1159
Miscellaneous / Re: Pronounciation« on: February 10, 2013, 07:29:31 pm »I always think of it as ohm-nee-may-gahI typically pronounce it this way, but I think Fireicee1's way is the way it is intended to be pronounced. 1160
TI Z80 / Re: [AXE] input routine.« on: February 10, 2013, 01:26:23 pm »
I like how it looks. I wonder if it can be optimised more o.o
1161
Ash: Phoenix / Re: Optimization help [A:P]« on: February 10, 2013, 11:49:04 am »
Wait, so :
Code: [Select] r3^10→{a--} Doesn't work? (You will need to initialise A as 8457h instead of 8456h) I think it is more optimised by 3 bytes if you do it that way (and 16 t-states).
1162
TI Z80 / Re: Four Level Grayscale Video« on: February 09, 2013, 07:16:25 pm »
@Spenceboy: Could you upload that and will it fit on my calc? o_o I want to show that to non-believers
![]() 1163
ASM / Re: Opcodes that should have been incorporated into the Z80 processor« on: February 05, 2013, 06:39:47 am »
@chickendude: I have thought about that, too o.o What if there was a way to refer to a specific shadow register, even if it were an extended instruction. This way you could do something like ex hl',hl or copy hl,hl'.
@tr1p1ea: If there was such a command, it would detract from the fun of creating a multiplication or division routine ![]() 1164
TI Z80 / Re: Mimas - an on-calculator assembly IDE« on: February 05, 2013, 06:30:43 am »
I personally like the last version that you presented. It loses readability, but I really think that that is okay with macro's. We can just describe what they do in a readme or something if it is really needed.
As well, I am not sure how you parse the files, but the way I have been doing it is to basically read the source as a type of program (I basically used ideas that I had already developed in Grammer+FileSyst). When a letter is concatenated with an opening parentheses, it tells the parser that it is a macro, so it searches the file for the macro and treats it as a "subroutine" of source code. This way you can add in some complicated macros for sure. I have been thinking of doing this for defining variables, too. It would really slow down compile times, but it would allow the user to define variables like String = "Hello" and then adding in a command like len(String) would make this easy: Code: [Select] .db len(String),String I have wished to be able to this quite often instead of needing to count the length of a string with PC math and labels.
1165
ASM / Re: ASM Optimized routines« on: February 04, 2013, 01:03:55 pm »It's interesting to see how our syntax/style differs even on bits of code that do exactly the same thingI noticed that, too, it is kind of neat. I noticed that I mask A and then shift, whereas you shift, then mask. I've done both, but I typically do the former. And if you don't mind sacrificing just a few clocks (altogether maybe between 8-64), maybe you could try this and save 2 bytes:Nice, I like that! When B is not 0, that is actually anywhere from 6 cycles faster to 18 cycles slower, so I think that is a great trade-off. By adding a byte, I can make your routine anywhere from 0 cycles to 24 cycles faster when b>0 Code: [Select] ComputeByte: This happens to be faster than my original and smaller by one byte. Still, it is larger than yours ![]() 1166
ASM / Re: ASM Optimized routines« on: February 04, 2013, 07:23:40 am »
EDIT Five years later, I found my code didn't work that well
![]() Hmm, for 'rectangle_loop_x' and 'rectangle_loop_x_end' you have 'or (hl)' which I think needs to be SMC'd. I decided to try and optimise my code a bit and I managed to optimise it for speed in most cases and size. Unfortunately, the code is still much bigger than chickendude's at 133 bytes ![]() my old routine, 9x18 rectangle : 1926 times in two seconds my new routine, 9x18 : 5668 times in two seconds chickendude's old routine : 1287 times in two seconds chickendude's new routine : untested .__. So for cases where you don't need crazy speed, chickendude's is still very fast and much smaller (73 bytes versus 133). Code: [Select] Rectangle_or: Necro-edit: This code is working, and it performs clipping. Using the above benchmarks, this code draws approximately 4240 of those rectangle per two seconds at 6MHz on an actual calc. The downside is the size ![]() Code: [Select] ;;
1167
News / Re: TI-Concours 2013 !« on: February 02, 2013, 05:44:33 pm »
Yes, I saw that there was a problem yesterday, but it is now fixed.
1168
Art / Re: General purpose art thread« on: February 02, 2013, 07:41:26 am »
This is a drawing that I never finished in my drawing class. We were supposed to sketch two models from some given perspective:
![]() 1170
News / Re: TI-Concours 2013 !« on: February 01, 2013, 04:41:30 pm »Is there supposed to be a confirmation email or something?You just wait and your entry request should be accepted within 24 hours, I think. |
|