What's a foolproof (and preferably not exceedingly large) method to determine the first free application page on an 83+ or 84+? Importantly, such a method also needs to determine if there are no free application pages left.

So Builderboy has requested that the vector table for im 2 interrupts in Axe be moved, because right now it occupies an area of safe RAM that Axe users often want to use to store data (statVars). And I agree that this is probably a good idea. The question is, where's a good, safe spot to put it in static RAM that Axe doesn't expose to users? Axe exposes the following RAM areas, so they are off limits:

• saveSScreen
• statVars
• appBackUpScreen
• plotSScreen (duh)

Also off limits are any areas of RAM that are needed by B_CALLs in any Axe command; for example, all of $8000-$8400 is off limits because of possible archive operations.

So far the best idea seems to be $9200, which is in the middle of where table data is stored. Destroying table data seems like it could be an acceptable side effect, but are there any better options?

Is it possible to store a value to an arbitrary real number variable? I tried expr("1"+Str0+"A") as a test (where Str0 contains a store arrow), but it throws an error. I suspect it may not be possible, but if you can think of any hackish way to do it, that would be great. I don't want to have to resort to a 27-branch conditional.

What the title says would be nice. I always struggle to make my IRC bot's output look proper in OmnomIRC  because of a lack of support for some IRC control characters. Here is what I've noticed omnomIRC is still missing, listed in order of decreasing importance to me:

• [0x0F] Strip: any alterations applied by previous control characters are removed
• White background color
• More accurate colors
• [0x02] Bold: Is a toggle
• [0x1F] Underline: Is a toggle
• [0x1D] Italic: Is a toggle
• [0x16] Reverse: Acts like color 0,01 except it's actually a toggle that overrides, but does not cancel, color

Hold down both Shift keys and type the following sentence:

the quick brown fox jumps over the lazy dog.


My Dell laptop:
HE QUIK BROWN FO JUPS OER HE LA DOG

I've been planning this project for a long time, and with the recent release of Axe 1.1.2, I can finally begin to make it a reality!

YAAM

YAAM? How is a vegetable going to help me develop Axe projects?

YAAM is no vegetable! It stands for Yet Another Axe Mapper, my friend! It is an Axe library designed to make smoothscrolling tilemapping in Axe both fast and easy by providing all the necessary routines for you in an easy to use manner! Instead of having to write your own tilemapping engine to your custom specifications, select the options you want from the built-in variety of options in YAAM and your tilemapper is done! (This will be more true in later versions as I add more features)

But drawing a whole unaligned tilemap every frame is slow! I don't want my game to be slow!

Au contraire, YAAM makes scrolling tilemaps very quick by shifting the previous frame's tilemap and redrawing only the tiles shifted in, which is quite fast. If the tilemap doesn't shift between frames, you don't need to redraw it at all!

That sounds cool! What other cool features does it have?

Here, let me draw you up a quick list: Very fast tilemap shifting Handles all drawing and shifting through a few easy to use routines Works with any tile size up to 8x8 Works with any map width and height

But I want this feature! And fix this bug!

For any feature requests and bug reports, just post them in this thread. However, I am already planning many features for the future, so your feature request may actually already be on my to-do list: Spoiler for To-Do List: Allow many variables, like pointers and map size, to be defined as constants instead Allow tile sizes larger than 8x8 Add support for grayscale Implement optimized multi-pixel shifting Add support for inflated coordinates (256 = 1 tile, instead of 1 = 1 pixel) Add support for archived tiles and tilemaps Add support for nibble or bit tilemaps Implement packed tile reading (e.g. 4x4 = 2 bytes, grayscale 5x5 = 7 bytes) Optimize all the code!

Awesome! Where do I get it? How do I use it?

Easy there, one question at a time! The latest version of YAAM (v0.2) can be found attached to this post. It requires Axe 1.1.2. Download the zip file, send YAAM.8xp to your calculator, include it anywhere in your program, and you're good to go! Full usage details can be found in the included readme. No they can't, because I haven't written one yet. However, I have included a sample program using YAAM that should detail the basics of using it. You can also learn more about YAAM's options and variables by looking at the options section in the library itself, which has small comments to generally explain what everything is. To set constants like tile width and height to your own values, redefine these values before including YAAM. To set everything else like tilemap size and pointers, store values to the variables listed after including YAAM.

More features will be coming soon!

The subject line mostly explains what I want to do. Inside of the OS program editor, I'm wondering what the easiest way is to "jump" to a point in the edit buffer. I don't want any scrolling, any adjusting of the cursor position on the screen, really any noticeable changes to the user. I just need the edit pointers to be adjusted and for the data in the edit buffer to be moved around properly. I probably explained that awfully, so let me sketch it out. I want to be able to start with a program in the edit buffer like it was just loaded:

X...............
................
.........XXXXXXX
XXXXXXXXXXXXXXXX

And "scroll" to a certain byte:

XXXXXXXXXXXXXXXX
XXX............
................
...........XXXXX


I feel like there's some easy way to do this involving a bcall or two instead of having to do the copying and pointer updating myself, but I don't know what it is. Sort of like an instant goto, but without any actual displaying. If you can only think of a way to do it with the displaying, that might be acceptable as well, so feel free to suggest whatever comes to mind.

Well I was messing around with grayscale, and this happened. I have no idea what is going on here. Does the screen have some strange physical quality that is causing this? Left is supposed to be white, middle is supposed to be gray, right is supposed to be black. However, the middle appears to be cycling between dark gray and super-white. Also the center of the screen has more wild contrast changes than areas further away from the center.



<a href="http://www.youtube.com/watch?v=GqnrT0uLP0E" target="_blank">http://www.youtube.com/watch?v=GqnrT0uLP0E</a>




EDIT: I have attached the program I used to observe this strange effect. It will only work on 15MHz calculators. Use +/- to tune the frequency, CLEAR to quit. Don't press - too much or it will probably crash! I can't easily give the source because it is part Axe, part Axiom, and part raw hex edited. But if you do look at the disassembly of it, please don't mind any unoptimized code or code that seems out of place, I never actually meant to release this.


EDIT 2: PLEASE READ THIS BEFORE DOWNLOADING

It's hard to keep track of bug reports, feature requests, and optimizations with the massive amount of posts in Axe threads. This is my attempt to compile all of them into one post in one thread. Hopefully this should make sure bug reports and good feature requests aren't lost and make it easier for Quigibo or any other coders who want to help to spend their time coming up with solutions instead of trying to find problems to solve.

If there are existing posts containing bug reports, feature requests, or optimizations that you don't see here, please try to direct me to the original post. If the post has some standing, I will add it to the list with ratings of importance and ease that I feel are appropriate. Please try not to debate much over the importance of items, the ratings I assign are just my rough opinions. Quigibo and any other coders can address items in any order they want.

Feel free to discuss any of these items either here or in their appropriate threads. I will try to merge good ideas and important points into the discussion section for each item.

---

• 12/18/11: [Axe 1.1.1]
  
  • -3 bugs
    
    • Error thrown at empty hexadecimal data brackets
    • [Unconfirmed] Compiling from archive sometimes fails
    • Issues with lowercase in getKeyʳ
  • -3 feature requests
    
    • Reporting name of source file upon compile error
    • More meaningful compilation progress information
    • Display size of the compiled program during compiling
  • ~1 feature request
    
    • Switch statement
  • -4 optmization suggestions
    
    • Optimized general mutliplication
    • Optimized fixed-point multiplication
    • Optimized signed division and reciprocal commands
    • Peephole optimization of sbc hl,de \ ld a,h \ or l
• 12/18/11: [Axe 1.1.0]
  
  • +4 bugs
    
    • Error thrown at empty hexadecimal data brackets
    • Issues with lowercase in getKeyʳ
    • Misdocumented EndIf and End!If
    • Duplication of commands referenced in Axioms
  • +5 feature requests
    
    • Automatic backup of included programs
    • Ability to execute programs upon compilation
    • Display size of the compiled program during compiling
    • Better sorting routines
    • Nested preprocessor conditionals
  • +5 optmization suggestions
    
    • Optimized general mutliplication
    • Optimized fixed-point multiplication
    • Optimized signed division and reciprocal commands
    • Peephole optimization of sbc hl,de \ ld a,h \ or l
    • Returning the full 32-bit result from the *^ operation
• 12/10/11: [Axe 1.1.0]
  
  • -15 bugs
    
    • operandNAME() parses NAME as a variable, not a function
    • Horizontal -(BUFF) does not properly adjust BUFF
    • High-order multiplication calls the wrong routine
    • Erroneously throwing errors for some pointer reads
    • Multiple bugs with peephole optimizer
    • Precedence issue with negating constant pointer reads
    • Occasional issue importing tilemaps
    • The Axe application doesn't disable G-T mode
    • The ʟ token lacks special meaning in strings
    • Address replacements fail in inline Axiom commands
    • Buff(CONST) accepts undefined constants
    • Lack of peephole optimizer control from API
    • ᴇ and π don't throw an error, given bad/no digits
    • Incorrect key for float{ in command list
    • CONST→ as last line in source
  • -5 feature requests
    
    • Pre-processor conditionals
    • Improved handling of lowercase by getKeyʳ
    • Arbitrary-sized sprite drawing command(s)
    • For(EXPR) loop
    • Including any external variable as data
  • ~1 feature request
    
    • Manual stack control for experienced users
  • -5 optmization suggestions
    
    • Optimized sort and reciprocal commands
    • Peephole optimization of inc hl \ dec hl
    • Optimized Bitmap() routine
    • Optimized input command
    • Optimized checksum routine

---

---

---

---

Attached below is my patched version of Axe 1.0.3 with a corrected multiplication routine. As far as I know I didn't introduce any new bugs. I suggest that any Axe programmers who need fixed-point or high-order multiplication download and use this.



I know how much Builderboy has been aching to release Zedd, but he is held up because no version of Axe can safely/successfully compile it. 0.5.3 lacks a needed feature, 1.0.0 and 1.0.1 are too dangerous to use, 1.0.2 doesn't handle constants correctly, and 1.0.3 has broken fixed-point and high-order multiplication.

It's been about a month since the last release of Axe and I'm sure Quigibo has been very busy now that he's back in school. He's probably working on 1.0.4 in the background, but with his schoolwork I understand if progress is slow. I haven't heard any news about when 1.0.4 might be released, or even just a bugfixed version of 1.0.3. So I decided I'd try to help by fixing what I would consider the most major bug in 1.0.3, the broken multiplication. Long story short, I was able to locate the broken multiplication routine in the compiled application, edit the hex so it would properly work with fixed-point and high-order multiplication, and resign the application.

I realize that Axe is the work of Quigibo, not myself, so I don't plan on making releases like this a habit. But the multiplication bug was a somewhat big and unavoidable bug that was holding back a few coders' projects, and I wanted to give them the ability to continue their awesome work.



Attached below is my patched version of Axe 1.0.3 with a corrected multiplication routine. As far as I know I didn't introduce any new bugs. I suggest that any Axe programmers who need fixed-point or high-order multiplication download and use this.

What's the minimum number of cycles at 6MHz that should exist between LCD outputs to be safe on just about any calculator? I think I recall someone in IRC suggesting 66, which is what Ion's routine uses, while routines used in Axe are closer to 70. And how exactly might things like the LCD delay port, bad LCD drivers, and ALCDFIX affect the timing that should be used in such a routine?

Simple question: how do you pronounce the z80 mnemonics? Don't feel compelled to mention every single instruction, but at least mention those you pronounce differently from me.


Capital letter means pronounce the letter, lowercase letters means pronounce the word. Ones in bold are ones I think I pronounce strangely!

ex		ex
exx		ex
ld		load
ldd		L-D-D
lddr		L-D-D-R
ldi		L-D-I
ldir		L-dir
pop		pop
push		push
adc		add-C
add		add
cp		C-P
cpd		C-P-D
cpdr		C-P-D-R
cpi		C-P-I
cpir		C-P-I-R
cpl		C-P-L
daa		daah
dec		deck
inc		ink
neg		neg
sbc		S-B-C
sub		sub
and		and
bit		bit
ccf		C-C-F
or		or
res		rez
scf		S-C-F
set		set
xor		X-or
rl		R-L
rla		R-L-A
rlc		R-L-C
rlca		R-L-C-A
rld		R-L-D
rr		R-R
rra		ruh-rah
rrc		R-R-C
rrca		R-R-C-A
rrd		R-R-D
sla		slah
sll		S-L-L
sra		srah
srl		SRL
call		call
djnz		D-J-N-Z
jp		J-P
jr		J-R
nop		no-op
ret		ret
reti		ready
retn		ret-N
rst		R-S-T
di		D-I
ei		E-I
halt		halt
im		imm
in		in
ind		I-N-D
indr		I-N-D-R
ini		I-N-I
inir		I-N-I-R
otdr		O-T-D-R
otir		O-T-I-R
out		out
outd		out-D
outi		outie

I've been waiting for you to show up in IRC since Friday so I could give you this routine, but since I haven't seen you yet there, here it is! It returns strings like the OS would when displaying numbers on the home screen with the Float setting. It perfectly mimics the OS routine for every reasonable input I've tried, even when using hacked float variables that have exponents above 99. The only thing it doesn't perfectly mimic is hacked floats that contain invalid hexadecimal characters. But that shouldn't happen too often.

Anyway, you said you wanted this for speed. Good news! The OS routine appears to take an average of about 5500 cycles in my tests, whereas my routine takes an average of about 1600 cycles. It'll cost you 244 bytes, but the choice is yours.

And anyone besides Hot_Dog, feel free to grab this routine as well. Note though, that because I made this routine to Hot_Dog's specifications, it has a few weird quirks. The location of the string returned has to be a constant, but you can change that. Right now it's set to OP4. You'll also probably want to get rid of the ld (hl),20 \ inc l at the start of the routine, another weird quirk Hot_Dog said he needed. Also, note that the string returned is a null-terminated string of tokens, not characters. You should be able to change this though by simply changing all the token values in the routine to ASCII values.

For the past week or so, I worked on an Axiom that includes a lot of commands for interfacing with the LCD driver. I think I've finished adding just about everything I wanted to and hopefully it has no bugs, so I'll release it. Here are its features:

• Turn the LCD on or off    ← This one's cool
• Get the on/off status of the LCD
• Set the contrast (I just realized as I'm writing this that Axe could already do this, but this command is safer)
• Get the contrast set by the OS (useful for setting the screen contrast back to normal)    ← Pretty useful
• Set the screen's z-address (internally shifts the rows of the screen up/down)    ← This one's really cool
• Apply screen flipping effects (on newer calculators with compatible drivers)
• Read and write individual bytes/words to and from LCD memory
• Copy a stream of bytes to or from LCD memory

That's a lot of information to throw at you about what it can do. To give you some ideas of how you could use some of these commands, here would be some useful applications of this Axiom:

• Turn the screen off for a teacher key or to save power in a waiting state
• Make contrast effects based around the active (OS-defined) contrast value and then return the contrast to the proper value when done
• Use z-addressing to apply an earthquake effect without having to worry about shifting the buffer image (or make crazy tunnel games)

Anyway, without further ado I will attach a zip file containing the LCDKit Axiom, its source code (sorry if it's tabbed oddly, I designed it in wabbitcode), a readme, and a command list. The Axiom appvar is fairly small for a library with 31 routines, weighing in at 651 bytes. Note that Axe will NOT add the whole thing to your program, only the routines that you actually use, so don't worry about any unnecessary code bloating.

---

Changelog

• 1.0.1 (Mar 28 2011):   Fixed a bug that slipped by, breaking the →imag() commands
• 1.0.0 (Mar 28 2011):   Initial release

MAKE SURE YOU DOWNLOAD THE LATEST VERSION, CURRENTLY: LCDKit_1.0.1.zip

Hi. I don't think this has ever been properly addressed, so I would like to formally address the matter of crediting others when it comes to programming works. Although everything that follows is only my opinion and you do not need to agree with it, I would like to state it. Feel free to post responses agreeing or disagreeing with me. The first paragraph will deal with what I would deem to be general etiquette. The second paragraph will be focused on Axe.

When making a project, you may often turn to others for help. Whether it's requesting sprites, using a routine somebody created, or simply letting someone optimize some parts of it, I feel that it is courteous to recognize their help in some form. In some cases, like in the case of minor code changes or optimizations by another person, a simple thank you would suffice for their aid. If you want, you can give them a small credit in the readme for your finished program. Or if you learned some stuff about coding from a help post somebody made, you may want to shoot them a quick thanks for the guidance, but it isn't necessary to cite small amounts general programming help. But I believe that if someone contributed specific help that your game relies on, like sprites or an important routine, it is fitting to cite who contributed that important part of your finished product. No need to put their name in your program's splash screen, or necessarily in the program at all. But a thanks at the bottom of a readme, no matter how small, can mean a lot. It means the efforts this person made to help you were really helpful after all. It means the time they put aside to help, no matter how much, was time spent well and worth spending again to help others.

When it comes to Axe projects, in a lot of cases the programmer will release the Axe source with their finished work. Sometimes he or she will say that their project is an Axe project but will want to keep the source protected, which is completely fine. But what can irk me a bit is seeing programmers produce something with Axe and fail to report is as being an Axe project. On one hand, I find it a little unsettling that it isn't mentioned, possibly as if they want others to think that they wrote it in assembly. But a possible slight deception is not what I find most unsettling. What I find unsettling is that failing to recognize it as an Axe project means failing to recognize perhaps the most important part of your project's existence: Kevin Horowitz. As I stated earlier, I believe it is proper to give credit in a final product to someone who may have provided you with some graphics or some code. But what about Quigibo? He provided every routine your program uses. He provided bug fixes for problems you might have run into. He provided a documentation and command information which likely taught you a lot of the concepts and commands you know. And most importantly, he provided his time. More than a year of it, so your program could exist. And I think the least any one of us can do to repay that is give a few seconds of thanks and recognition in return.


~~~

I can never focus on one project at once and have thus never really finished and published any projects, or the readmes to go along with them. I have never had the chance to give thanks in any published projects. But I have still programmed in Axe and enjoyed it for countless hours. So I would like to be the first to officially say:

Kevin Horowitz, thank you for the work you have done. Your helpfulness and commitment to Axe have known no bounds, and neither do my thanks to you.