| New Post | New Topic |
| Goto page Previous 1, 2, 3, 4, 5, 6 Next | |
| 09 Oct 2011 09:16:38 am by KermMartian | Quote | |
| Indeed you can, but I think it's still more elegant to have as much code cross-compatible as possible. Plus, wouldn't the logical extreme of a single OS version that would work properly on all the calculators be better anyway? |
||
| 09 Oct 2011 01:29:38 pm by SirCmpwn | Quote | |
| No, one OS version to rule them all is a bad idea. For one, routines need to be as fast as possible (I have plenty of space). If I add model detecting code, then they slow down. Plus, USB code shouldn't be in all versions, and hardware is set up differently on some models. Different versions is the way to go. | ||
| 10 Oct 2011 08:35:19 am by KermMartian | Quote | |
| Fair enough, for an OS, that makes somewhat sense. For a non-OS program or application, though, I believe we should go with portable, device-detecting code. | ||
| 06 Nov 2011 10:31:43 am by arriopolis | Menuroutine 2.0 :D | Quote | ||||
| Hey all!
I finally did what I promised to do months before. Menuroutine INPUT: Via the code stream, using the following "syntaxis":
Output: PC: The desired lable. Registers destroyed: AF, BC, DE, HL, IX Size: Huge. Remarks: Does reset AppAutoScroll and TextInverse. I'm sure there are numurous optimizations possible, so do not hesitate to inform me.
|
||||||
| 06 Nov 2011 12:10:36 pm by arriopolis | Inputroutine 1.0 :D | Quote | ||||||
| Hi all!
I found some time to write a far from perfect inputroutine. There is plenty of room for optimization, in both speed and size, but I'm just too lazy to fix it. Inputroutine: Input: - DE = Start of address for the string to be stored to. - C = The maximum number of characters. Output: String at initial DE. Remarks: This inputroutine works with letters instead of tokens, so multiletter symbols like sin( aren't included. Registers destroyed: AF, BC, DE, HL, IX, I. Setup: Since this routine uses its own Interrupt Service Routine, you need to include that one too. I've placed it at $9D9D, meaning you've gotta place it near the beginning of the program. I usually do something lik this:
This makes sure the InputISR is in its correct location. Here is the InputISR:
And finally the Inputroutine itself:
|
||||||||
| 07 Nov 2011 12:22:48 pm by KermMartian | Quote | |
| Out of curiosity, that looks like well over 1KB of code. |
||
| 07 Nov 2011 03:55:47 pm by arriopolis | Quote | |
| Yep, I'm wanting to create an app, using these routines, and DCS doesn't provide an apprunning feature, so I've gotta write them myself.
Btw, does DCS include the multimenuroutine? |
||
| 07 Nov 2011 11:25:54 pm by KermMartian | Quote | |||
|
||||
| 04 Jan 2012 03:42:16 pm by Xeda112358 | Quote | |||||||||
Kerm is there any reason for the sla as? I know it takes twice as many bytes and cycles as add a,a, so is it a timing thing? Otherwise, why not replace those 12 bytes and 48 cycles with 4 bytes and 15 cycles?
And if you need the timing, you can use 8 bytes instead of 12 if you add this, too:
I was going to post about the A_Times_DE routine that I wrote that averages 313 cycles, but I am still trying to optimise. Does anybody have a faster routine that doesn't use a LUT? Worst case is 355, best case is 166. |
||||||||||
| 04 Jan 2012 07:54:54 pm by arriopolis | Quote | |
| I gave it a try. My minimum is 382, and my maximum is 510. |
||
| 04 Jan 2012 09:38:32 pm by Xeda112358 | Quote | |||||
Okay, then I may as well post it and hope others can optimise
I compared it to the following routine that I thought was pretty well optimised:
Notice that the first does not use a traditional counter at all and so it only modifies A and spits out the result in HL. EDIT: The second one works anywhere from 342 to 390 cycles |
||||||
| 05 Jan 2012 06:08:31 am by arriopolis | Quote | |||
Ah, mine is only 15 bytes... I prefer size over speed actually, so I think I'd stick with the one which takes up the least amount of memory.
|
||||
| 05 Jan 2012 11:01:38 am by Xeda112358 | Quote | |
| ! You should use the second routine I provided, then, which is 13 bytes SLA E uses 2 bytes RL D uses 2 bytes DJNZ uses 2 bytes The timing on yours is 382+6x cycles, too, so the second routine I gave is 40 cycles faster. Nice coding, though! |
||
| 05 Jan 2012 11:52:56 am by arriopolis | Quote | |
| Well, yours is even nicer. But thanks anyway. |
||
| 20 Feb 2012 09:53:09 pm by Ashbad | Quote | |||
| quite fast, but large 8 bit signed or unsigned itoa implementation Edit: the reason it's so large is because I inline a semi-generic division routine in there twice, and for multiplication by 10 and 100 I use an unrolled series of additions, and instead of looping three times using the dividends 100, 10, and 1, I unrolled it to 3 inline operations. The only real extra optimization to be had for speed is unrolling division to shave off maybe 150-200 cycles, but that's just overkill I would think. Optimizing it for size is rather easy, but usually I prefer speed over size so that's what I aimed for here.
|
||||
| 21 Feb 2012 02:28:27 pm by Xeda112358 | Quote | |||||
That is for converting an 8-bit number to text, yes? Nice
I am pretty sure that can be optimised a little with some DAA magic :/ I also have a pretty fast routine to convert a number string in base 10 to a 16-bit value in BC:
That will convert a number up to the first non base 10 digit (I use a variation of this in Grammer as well). |
||||||
| 16 Mar 2012 02:16:45 pm by Xeda112358 | Quote | |||
Okay, I forgot to post this here as well, but these are two routines that I made a looong time ago and I use this in almost all of my programs that have graphics commands. These two are my first real use of RRD and RLD and that is why those are two of my favorite instructions in z80:
Why do I think these are so awesome? Compare those to routines that shift the graph buffer right or left 1 and you will see: -They are the same size -This routine is 7680 cycles slower That last one might seem bad, but the fastest routine I have seen for shifting right or left is 22166 cycles. Now do that 4 times for 88664 cycles or do 29846 cycles once. That is about 3 times faster. |
||||
| 02 May 2012 07:19:48 pm by Xeda112358 | Quote | |||
I'm not sure if I posted this here, yet, or not, but I couldn't find it in a quick search. Anyways, this is similar to the routine Grammer uses to convert an ASCII string of decimal numbers to a 16-bit value. I hope the speed is suitable
The ones with t-states as '---' are computed along with the previous instruction to make calculations easier. Anyways, to give an idea, at the slowest, this can execute 9345 times per second (assuming you are using call which takes another 17 t-states). This stops reading when a character that is not a decimal number is run into (for example, a comma or newline). |
||||
| 07 Jun 2012 05:00:52 am by Xeda112358 | Quote | |||
This is a line drawing routine with full clipping and it allows for drawing with patterns. This isn't the most optimised code (the RAM routine is better, but this version is meant for apps).
|
||||
| 07 Jun 2012 09:23:47 am by merthsoft | Quote | |
| Haha, I'm a fan of the Merth pattern! I don't know enough about z80 to say anything about the code, but I'm glad you added that patterning in |
||
| New Post | New Topic |
| Goto page Previous 1, 2, 3, 4, 5, 6 Next | |
[Switch to Desktop view]
© Copyright 2000-2013 Cemetech & Kerm Martian :: Mobile Design by Alex "comicIDIOT" Glanville
Problems? Issues? Or Suggestions? There's a thread for that!
© Copyright 2000-2013 Cemetech & Kerm Martian :: Mobile Design by Alex "comicIDIOT" Glanville
Problems? Issues? Or Suggestions? There's a thread for that!
