DispGraphº to use SafeCopy.

Perhaps a command to check a certain block of memory for variable bytes.

Search(PTR to start search,bytes to search for (more than one byte),number of bytes forward to search)

return 0 if not found, or offset of first result.

Ex: to clarify

in the block 013450AE2345FF000F ,

Search(PTR,[AE23],9)  returns 3

That can be done pretty easily in pure Axe by looping over each of the 9 bytes and using inData to check for a match each time (and that is how an assembly version would work anyway)

inData can only check for one byte. Im thinking of a function that can search for more than one.

but i do see how that would work.

Something like
Lbl SRC
-1->r4
While r4+1->r4<r3
If inData({r4+r1},r2)
r4:Return
End
End
-1:Return(returns -1 if failure)

Another one: for those of us who have assembly programs on calc that do things like invert text, invert the screen, check ram, or what not. Have a command that parses a compiled z80 executable and inserts it into the program.

command(assembly program)   ; only the source requires the program, not the executable.

That would be extremely difficult because all the pointers would get thrown off (unless you put it in the very, very beginning of your Axe prgm). Anything using fixed addresses (JP, CALL, etc.) would end up where it doesn't expect it to be, which would be disastrous.

Same reason why you can't just jump straight to a different program while running a program.

Quote from: ACagliano on April 01, 2011, 12:13:39 am

inData can only check for one byte. Im thinking of a function that can search for more than one.

but i do see how that would work.

Something like

Code: [Select]

Lbl SRC
-1->r4
While r4+1->r4<r3
If inData({r4+r1},r2)
r4:Return
End
End
-1:Return(returns -1 if failure)

Calc, where do the variables here come from? Which is the search string and which is the string to search? I may use this.

Quote from: calc84maniac on April 01, 2011, 12:21:34 am

Quote from: ACagliano on April 01, 2011, 12:13:39 am

inData can only check for one byte. Im thinking of a function that can search for more than one.

but i do see how that would work.

Something like

Code: [Select]

Lbl SRC
-1->r4
While r4+1->r4<r3
If inData({r4+r1},r2)
r4:Return
End
End
-1:Return(returns -1 if failure)

Calc, where do the variables here come from? Which is the search string and which is the string to search? I may use this.

r1-r6 are the subroutine arguments. For example, if you called sub(SRC,[POINTER_TO_FIRST_STRING],[POINTER_TO_SECOND_STRING],[LENGTH_OF_STRING_TO_TEST],[START_POSITION]), [POINTER_TO_FIRST_STRING] would be r1, [POINTER_TO_SECOND_STRING] would be r2, etc.

It's much easier to just draw two sprites in axe than to write a new set of wrapping sprite display routines in ASM.

SirC's flood-filler would probably be easily modifiable to make grayscale.

IIRC the Circle() routines are coded in such a way that it is very difficult to make it draw on the back buffer.

For For() loops, just use a While loop instead and increment manually, it probably is just as optimized anyway.

As for the flickering on the grayscale, I think Deep Thought already mentioned going across the screen by rows instead of columns as per thepenguin77s grayscale tutorial, so I'll just remention that again

And now I have something I want to say...
People, this has kind of been bugging me. Feature-request-wise, remember that Quigibo is really busy. Complex routines are hard to put in, and most of the time they can easily be written in Axe anyway with a few commands (like the for() and the paint bucket thing). Figure out how to do it yourself; don't just ask for a feature request because you don't want to take the time to code your own routines. Another example: grayscale. Are you really complaining that the shades of gray are too dark/light? It's freaking grayscale on a monochrome screen. Seriously, any asm programmer will tell you that grayscale is a huge pain to program correctly and IMHO we should be grateful that we have it as good as it is. I'm talking to everybody here. I feel like some people are taking Quigibo for granted, and imo something like a paint bucket is in no way really important enough to merit its own command. Something like bit-manipulation, label-addresses or switch-statements or big-endian nibble reads hint hint hint are more appropriate candidates for feature requests. And did someone really ask for multitasking?

I guess what I'm really trying to say, is just try and think about what you are asking for before you post, and whether or not it's practical. Then think about how you could code it; a lot of things are not difficult to code by hand anyway. Some languages don't even have for() loops, for example. And when you do post, try to explain what you are talking about. Not everyone knows what the phrase "stateful goto" or "try/catch" means.

Sorry to rage like this but I felt the need to say it. No offense to anyone intended. Also I do not want to start any kind of war or fight so if you have a problem with this, rate it down and pm me. Leave it off the forums, thanks 

I only ask for stuff I can't do on my own.  For example, I didn't ask for a routine to swap in an extra page of RAM, I just did it myself.  Label addresses is the only thing I'm pushing for right now, and I'm doing so because of three reasons: (1) While I can do it myself, it is a nuisance on both myself and end users, (2) I already have a significant amount of code written for the project I want this feature for, and (3) I don't think it would be very difficult to implement.

In addition, if you want a new feature, like the paint bucket, that isn't a very good candidate for an actual feature, look it up.  For example: How to make a paint bucket