Here's a method I got out of a game then altered for optimization. It just subtracts the hex values of each decimal digit and counts how many times it can be subtracted. Then places the digits one per byte starting at $20 ram. For the largest number ($FFFFFFFF = 4,294,967,295) it takes 776 operations to do the conversion. It could be further optimized by using another subroutine for the last 4 which don't require math on the 16 high bits.

This might be too simple but you could switch to decimal mode and bitshift and add the decimal value of each shifted bit. It would require approximately 42 operations at about 4 cycles per op for the first 13 bits then 21 more operations for the last 3 bits because the converted decimal value would exceed the 16 bit limit. So in total to convert a 16 bit number it would only cost 63 operations and around 250 cycles.

Are you using a register map. This will all be in it. The register for reading VRAM data is $2139 and to set the address is $2116 and to set the address increment is $2115, but this would not be practical to use because VRAM can only be accessed during blanking. If you absolutely had to get values out of VRAM those are the registers you would use.

It sounds like you are planning a hybrid of static / dynamic rendering. This would probably be best accomplished using WRAM to assemble the tiles which would defeat some of the purpose of pre-rendering.

Based upon the decision in Eltra v Ringer and the clear and explicit actions of Congress - the status quo regarding typeface and copyright has remained unchanged and is as firmly in place today as it was since the first Copyright Act in 1790. As it was then, so it is now: typeface designs do not fall within the Copyright Act's definition of pictorial, graphic, or sculptural works that qualify for copyright protection.

Here's what Ogre Battle does to navigate to out of bank subroutines that only have a regular return. It uses JSR and jumps but no branching. First it jumps to ram, snags the bank for safe keeping on the stack, then back out to rom then proceeds to build a return to the ram position then a return long to the original rom position then a return long to the position it wants to jump to which was inserted in the rom after the program address it came from.

$00/119E AB PLB A:1120 X:0F99 Y:0080 P:envMxdizc$00/119F 6B RTL A:1120 X:0F99 Y:0080 P:envMxdizcI rewrote this at one time so it worked more smoothly and was easier to understand but I'm not sure what I did with it.

I could almost imagine something with some code executed from ram. There doesn't seem to be any games that do that though because Snes9x does not even except BRL in relation to ram (either into, out of, or through it). Those guys would normally modify their emulator to compensate for any game that would require something like that.

I was just comparing the SNES instructions "Jump" and "Branch Long" and it occurred to me there is no particular advantage for branching long. It takes 1 additional cycle and has a smaller range than the jump instruction while using the same number of bytes.

Anyone have any thoughts or examples of what purpose it might serve? Maybe it's got something to do with ease of programming.

The font tiles are compressed by some kind of sick compression scheme starting at $80000 in an unheadered rom. Perhaps created by some mad scientist? Maybe it's actually simple but it doesn't look like something I'd want to mess with. If you do want to play around with it, I would recommend pulling the uncompressed tiles out of vram and using them that way.