How long does Pause 1 actually last?

How long does Pause 1 actually last?

This is one of the reasons I took it upon myself to start documenting the size and speed of Axe commands. If you open up Commands.html, select one of the "Show size and speed for" buttons, and find Pause, you will see that it takes approximately 3349*n cycles. The calculator normally runs at 6MHz, so you can figure out the time if you like.

However, that formula is not quite accurate, especially for small values of n. If (on a desktop browser) you hover your mouse over the speed information, you'll get a messy formula that exactly describes the number of cycles Pause takes. In the case of Pause 1, it's actually very hard to determine. Pause basically runs a loop inside of a loop, with the outer loop running the number of times you specify. But Paues was really designed for larger values where a small difference of one or two thousand cycles wouldn't matter, so for the sake of size optimization, on the first outer loop iteration, the inner loop iterates a number of times according to whatever value happened to be sitting in one of the CPU registers at the time. This first outer loop iteration, which in the case of Pause 1 is the only outer loop iteration, can run anywhere from 8 to 3349 cycles; all the following outer loop iterations will run at exactly 3349 cycles. You'd need to look at the disassembly of the code leading up to the Pause command and determine what value will be held in the b register (and sometimes it cannot even be determined) to know how long the first iteration will take, but that's probably overkill for now.

If you want to pause for a very small, precise amount of time, I would suggest something like the following:
For(N)
End
This block of code just executes an empty loop N times, and it will do so at about 13 cycles per iteration.

If you're interested in on-calc assembly coding, probably the best tool for that is Mimas.

Also to search : http://megapowers.net/v/search.htm
Forum search is completely disabled because of lag. It was really slow anyway.

Love at first sight, thanks for the link, runner, though you got ninja'd by a certain search engine. Dp forgove the strange order of the paragraph. You may blame the creators of the search egine for amking a terrible operating system. I cant even read what Imm writimg stm. Thanks for the suggestion by I just used some Google syntax to do it. It wasn't that I couldn't search the forums, it was just a hassle to switch tabs on a plastic brick that makes my calculator feel like one of IBM'S supercalcs... er comps, whatever the difference is.

If you're interested in on-calc assembly coding, probably the best tool for that is Mimas.

If you want to pause for a very small, precise amount of time, I would suggest something like the following:

Code: [Select]

For(N)
End
This block of code just executes an empty loop N times, and it will do so at about 13 cycles per iteration.

Does the push bc \ pop bc get auto-optimized or something?

Right now I'm making (yet another, but even "yet another" is taken) shmup bullet hell game. I'm quite impressed with the amount of data Axe can handle at once, but I've hit a dead end. I think I tackled the initial problem of storing bullet data like how anyone would, in the safe RAM areas, every 6 bytes account for one bullet, as x, y, dx and dy. Enough of boring you with things you are well familiar with, how do I search for empty 2-byte elements in a buffer? Or to solve (and ruin) my solution, what is the most effective way of replacing bullets that have gone offscreen with newer bullets?

Right now, my main loop involves going through every six bytes in the designated buffers, adding dy dx to x and y, and finally check if it's out of screen, and making it zero. The loop ignores data when x + y = 0.

If I need to elaborate further for your benefit, do ask.

There's a pretty ingenious (at least I thought so when I learned it years ago) way to handle this. Keep track of the total number of bullets with some variable. When you add a bullet, increase the bullet total and put the new bullet at the end of the list of bullets, which should be at the memory location old_total*6+list_start. This all probably seems pretty standard. But the trick is in bullet removal: decrease the bullet total and move the data for the last bullet in the list into the position of the bullet that was just removed. In Axe, the code for that might look something like this:

Code: [Select]

.Deletes the bullet at index r₁ (0-indexed)
.Updates bullet total N
Lbl Del
Copy(N--*6+<list_start>,r₁*6+<list_start>,6)
Return


Thank you so so much for your quick reply, as always. But I feel so cheap having such an obvious (albeit impressive and practical) solution spoonfed to me... ;_; it's figuring out these solutions that make programming such a wonderful experience.

Thanks again, anyhow. O(^^O)

Edit: Modern Smartphones are so good at the one or two things they should do, like typing a forum post without subtly sneaking a typo or two in.