...so i tried displaying another sprite afterwards and it gives me an address error (i've come to dread those words, i see them all the time). I'm not sure why, is it maybe because i'm using byte-sized commands and maybe i fill one of the registers with a word or long that doesn't get cleared? I can't see where the problem might be...

EDIT: Ah.. it's the parameters i'm passing to the routine, there must be a mistake in there somewhere. I'll look through the code again...
EDIT2: So i don't get it. The first time through i XOR a byte to $4E58 (well within LCD_MEM) without a problem, the second time through it bugs out on $4E58. Does it have to be word-aligned or something?

Quote from: chickendude on June 17, 2012, 03:41:58 pm

The main thing keeping me from getting any of their newer calculators is the "lack" of native assembly support. To be honest, having a color screen to play with sounds like a lot of fun, but being locked out of assembly (and, by extension, C), just sucks.  I think that was always one of the biggest attractions of their calculators: browsing the massive amounts of programs available and then learning to program them and do things you thought you never'd be able to do. That and knowing that a large number of people would have immediate access to and actually use/enjoy your programs. I guess for ARM programming there are a lot of other communities/platforms out there, i guess you'd just reach a different audience.

The 82-83+ (even the 89) will always be special to me, but not because of the math problems i solved on them Programming them was the reason i bought my first (and second, and third, and fourth, etc.) calculator

Actually the Casio PRIZM, which has a color screen, a bit more RAM and archive, has ASM support. It isn't intentional by Casio, but they have said if we play nice they'll let us use it.

Really? I've never looked much at the Casio calculators but that actually sounds really cool, i may end up picking one up Now you've got me reading up on SH3 assembly

Well, when a level is loaded the entire level is loaded. I could set a certain distance to remove (delete) an object from the list, as i've never really liked resetting enemies back to their original positions when they go offscreen. I remember you talking to me about how you had objects and enemies set up in Super Mario a couple years back, maybe over at RevSoft?

Last night i spent several hours writing a really simple sprite drawing routine. I'm curious if anyone could give me any comments or suggestions on the code. For some reason, i had a lot of trouble trying to rotate the pixels from one register into another so i just doubled the size of the sprite  (initially i was using all bytes)
move.b #0,d0 | X
move.b #20,d1 | Y
lea spriteBox,a1
jsr drawSprite

movea.l AMS_jumptable,%a5 | load the AMS jumptable to a5
movea.l 4*ngetchx(%a5),%a5 | ngetchx()
jsr (%a5)
bra exit


|----------------------------
| drawSprite: draw a sprite to LCD
| d0 = X position
| d1 = Y position
| a1 = sprite location
drawSprite:
move.b d0,d2 | save X coord
and.b #0x07,d0 | how much we need to rotate the sprite
mulu #30,d1 | i think the screen is 30 bytes wide?
lea LCD_MEM,a0 | start of LCD_MEM
add d1,a0 | add the Y offset to a0
lsr #3,d2 | shift d2 (xCoord) right 3 bits
add d2,a0 | add X offset to a0
move.b #7,d2 | display 8 rows
screenLoop:
move.w (a1)+,d1 | put the byte of data into d1
lsr.w d0,d1 | rotate byte of data 'd0' bits to the right
eor.w d1,(a0) | xor (ExclusiveOR) the byte (well, word) into a0 (the LCD)
lea 30(a0),a0 | shift down a row
dbra d2,screenLoop | it's beyond me why d2=7 will draw 8 rows... it must break on -1?
rts

spriteBox:
.byte 0b11111111,0
.byte 0b11111111,0
.byte 0b11100111,0
.byte 0b11000011,0
.byte 0b11000011,0
.byte 0b11100111,0
.byte 0b11111111,0
.byte 0b11111111,0It's also kinda weird that the dbra/deq both break on -1 and not 0. Being able to rotate a byte by X/register number of bytes is pretty cool, though How exactly does that work? Will rotating a byte 5 times take longer than rotating it 3 times? I assume so, but i don't know anything about the size/speed of 68k instructions... I also don't know if "lea 30(a0),a0" is faster than "adda #30,a0", but i like being able to use all the address registers sort of like the z80's index registers (ix/iy).

And, the LCD: it took me a long time to get the sprite drawn right, the screen is 160 pixels wide, or 20 bytes, why does it seem like it's 30 bytes wide? How many bytes tall is LCD_MEM? Could you use the bytes to the right of the screen for smoothscrolling in a tilemapper, for example? Next up, a simple tilemapper

I may have asked this before, too, but why do numbers (except addresses?) need to be prefixed by a pound (#) sign? At first i thought it was to signal a decimal value, but later i realized you need to put it before all numbers.

And does anyone have a list of saferam areas for the 89? Is there a graph buffer somewhere?

Cool, thanks! I've never really touched the VAT, archive, or any of this stuff, for now it's just to test out the game more easily (or more lazily) so really it doesn't matter TOO much if i corrupt the RAM during run-time, but this will be nice if/when it gets released What exactly are you copying the first time through, just the size of the program? What are the extra 9 bytes at the end (+3+3+3)?

And calc84maniac, i assume you would just load that code to saferam somewhere and run it from there.

I'm pretty sure it's just a French localised version of the 83.

I'm having trouble with the 8.8k limit and don't have any executable code after this. Running from Mirage works fine, but the homescreen gives me an error ("ERR: INVALID"). The data isn't even used in the program yet. Any ideas?