A tutorial for another architecture might have described the ROL/ROR operations on non-65xx series CPUs, which tend to use the other kind of rotation that doesn't insert carry into the stream.
6502 ROL/ROR is like 68000 ROXL/ROXR or x86 RCL/RCR.
SNES dev newbie questions
Moderator: Moderators
Forum rules
- For making cartridges of your Super NES games, see Reproduction.
Re: SNES dev newbie questions
Indeed, the book is mostly about old x86 CPUs. Thank you all for the help!
Re: SNES dev newbie questions
So I managed to complete a few tests / demos, but I have yet again come upon a problem I'm not sure I quite understand.
This little project (full code here) only consists in displaying a picture. I used gfx2snes (a fork of pcx2snes I believe) on a 256px by 224px 8bpp PCX image, which resulted in tile data, a tilemap and palette. I chose to go with 16x16 tiles (because why not?) and stayed with 8bpp. The tile data was too big for one ROM bank so I put half of it in two different banks. Everything looks alright to me assembly-wise, but... I'll let screenshots from no$sns do the talking:
Original image:
Video output (same for higan accuracy):
BG1:
Tile data:
I did notice a few oddities when converting the image, however... gfx2snes (and presumably pcx2snes) inserted something like 64 null bytes at the beginning of the tile data...?! I stripped them and adjusted the code accordingly, without much change. Also, the tilemap it generates is quite huge: 2KB. I expected it to be (256*224) / (16*16) * 2 = 448 bytes. The Windows GUI version of eKid's pcx2snes did none of these, but the results were actually worse (which I guess isn't the tool's fault).
Any help / hint / advice would be greatly appreciated. Thank you!
[Edit] I'm still not sure why the generated tilemap is so big, nor why this doesn't work, but I got it working with pcx2snesWIN and 8x8 tiles rather than 16x16. I'll stick with that for now but I guess I know where to look should I decide to try 16x16 tiles again!
This little project (full code here) only consists in displaying a picture. I used gfx2snes (a fork of pcx2snes I believe) on a 256px by 224px 8bpp PCX image, which resulted in tile data, a tilemap and palette. I chose to go with 16x16 tiles (because why not?) and stayed with 8bpp. The tile data was too big for one ROM bank so I put half of it in two different banks. Everything looks alright to me assembly-wise, but... I'll let screenshots from no$sns do the talking:
Original image:
Video output (same for higan accuracy):
BG1:
Tile data:
I did notice a few oddities when converting the image, however... gfx2snes (and presumably pcx2snes) inserted something like 64 null bytes at the beginning of the tile data...?! I stripped them and adjusted the code accordingly, without much change. Also, the tilemap it generates is quite huge: 2KB. I expected it to be (256*224) / (16*16) * 2 = 448 bytes. The Windows GUI version of eKid's pcx2snes did none of these, but the results were actually worse (which I guess isn't the tool's fault).
Any help / hint / advice would be greatly appreciated. Thank you!
[Edit] I'm still not sure why the generated tilemap is so big, nor why this doesn't work, but I got it working with pcx2snesWIN and 8x8 tiles rather than 16x16. I'll stick with that for now but I guess I know where to look should I decide to try 16x16 tiles again!
Last edited by juef on Sun Apr 06, 2014 3:52 pm, edited 1 time in total.
Re: SNES dev newbie questions
I did an update of gfx2snes to avoid 64x64 pix added for blank tile.
It is not yet commited on googlecode, sorry about that.
I will try to do this later this day.
*DONE* Last version of source code available
It is not yet commited on googlecode, sorry about that.
I will try to do this later this day.
*DONE* Last version of source code available