Switching over to a more appropriate forum... :-)

I don't have a lot of time right now (reorganizing the house) but I still managed to type a quick BCD function. It seems to work to some extent, but my right-most digits are not displaying. My debug traces, however, reveal that I am storing the right values, so it's more of a memory read thing... will post back later when I have time to debug it properly.

And thanks for sharing the idea of the 1-bit pixels. It actually made me realize that I could, in theory, implement it in Flash for speed. See, Flash uses some kind of sprite called "Movieclips" (MC) for everything. Right now, I'm using 1 MC per pixel, but with your method, I could use 1/8 of the total MCs if I can come up with one MC that has 256 frames in it, with all the possible combinations. This could make schip8 emulation possible!

Now I just need a way to generate this MC (no way I'm drawing it by hand, and runtime drawing [as a precalc] would probably be too taxing).

Other than that, just a minor thing - I'm avoiding nested for() loops in Flash because there's a huge performance hit. In C you probably don't need to worry about it, however here's how I wrote my loop for Schip8 scrolling:

(pseudocode from memory, not the actual thing)
x=0;
y=0;
for(offset=0; offset (smaller than) 128x64; offset++) {
x++;
if(x>64) { x=0; y++; }
//process (x,y)
}

Believe it or not this runs SO much faster than:
for(y=0;y (smaller than) 32;y++) {
for(x=0;x (smaller than) 64; x++) {
//process (x,y)
}
}

It may be a Flash-specific glitch though.





[download a life]

Weird that your loop is faster than 2 for's, because technically your loop is doing the same: increment, test, set to 0, jump.

I've done some reading on the HP48 flags, and now I'm pretty certain that it's battery RAM, so you'll have to save it to a cookie on exit (and me too, in a file then). The only game I've seen using it is s-chip Piper.

*edit* regarding your previous topic in this sub-forum. Just use unsigned char (if Flash supports it). You've probably fixed that problem by now, but here's how I do it:

#define BYTE unsigned char /* 8 bit */
#define WORD unsigned short /* 16 bit */

REGV2 is defined as the V register of the value in the (1234) 2nd nibble of the opcode, REGV3 the 3rd.

static void addrr(void)
{ /* 0x8XY4 - add_register_register */
/* v[X]=v[X] [plus] v[Y], carry */
reg_v[15]=((WORD)REGV2 [plus] REGV3)>>8;
REGV2 [plus] =REGV3;
}

While we're on Chip-8, I updated my SMS-native emulator with the "new" roms.

There's a problem. Some of the Chip-8 docs specify that the RND opcode should set the specified register to a random number less than or equal to the byte operand. However, this is wrong; it should set it to a random number ANDed with the operand, according to older docs from the HP-48 days. This is certainly a lot simpler to achieve on a simple CPU.

The former is needed for "rocket.ch8"; the latter is needed for "Tetris", otherwise it bugs out all over the place.

The fix I'm using is to edit "rocket.ch8"; change $20 to $1f at offset $49 and $40 to $3f at $4b.