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?

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.

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.

Hey all!

I finally did what I promised to do months before. I created a multiple, scrollable, menuroutine.

Menuroutine
INPUT:
Via the code stream, using the following "syntaxis":

Code:

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.

Code:

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:

Code:

This makes sure the InputISR is in its correct location. Here is the InputISR:

Code:

And finally the Inputroutine itself:

Code:

Out of curiosity, that looks like well over 1KB of code. Any reason not to use either the DCS GUI or MOS input functions, both provided from Doors CS, instead?

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?

Doors CS includes tools for simple, fast menus for ASM and BASIC programs, but as you say, it is much harder to use its features from an app/.

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?

Code:

And if you need the timing, you can use 8 bytes instead of 12 if you add this, too:

Code:



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.

I gave it a try. My minimum is 382, and my maximum is 510. I'm pretty curious what your code is like actually.

Okay, then I may as well post it and hope others can optimise

Code:


I compared it to the following routine that I thought was pretty well optimised:

Code:


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

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.

Code:

! You should use the second routine I provided, then, which is 13 bytes Your code is actually 16 bytes, too. The errors are:
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!

Well, yours is even nicer. But thanks anyway.

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.


Code:

That is for converting an 8-bit number to text, yes? Nice I recently had to update Grammer to support 32-bit number displaying, so I wrote some code for that. It is Grammer specific, but in this case, (TempWord1) is 2 bytes pointing to the end of where the string is to be displayed. It creates a zero-terminated string of the number:

Code:

I am pretty sure that can be optimized a little with some DAA magic :/


ASCII String to uint16

Code:

That will convert a number up to the first non base 10 digit.

EDIT: Optimized the ConvRStr code. Also changed name to atoui16

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:

Code:

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.

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).


Code:

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

Here is another routine that I made yesterday for a pseudo-random number generator:


Code:

There are a few other nice features, too. For example, every 16-bit value is hit if you run this 65536 times. Or, if you only read 1 byte (for example, H from the output), it will hit every 8-bit number once if you run this 256 times. Plus, it can be seeded