It is currently Wed Dec 12, 2018 5:29 am

All times are UTC - 7 hours



Forum rules





Post new topic Reply to topic  [ 103 posts ]  Go to page Previous  1, 2, 3, 4, 5 ... 7  Next
Author Message
PostPosted: Fri Apr 06, 2018 4:38 am 
Offline
User avatar

Joined: Sun Sep 19, 2004 9:28 pm
Posts: 3722
Location: Mountain View, CA
Get familiar with general purpose DMA. It'll make transferring data from ROM (or RAM space, ex. banks $7E/7F) to PPU RAM easier. Stick with mode 0 for starters -- get some graphics/text up on two different backgrounds, then try playing with the BG scroll registers. This is pretty much what I did in my old iNFiNiTY demo that came with my old SNES docs -- I still think that demo works as a nice "introduction" primer for people getting started. It's not perfect, but it's good enough.

Off-topic and IMO, but the SNES has all the things you wish the NES had. I feel lucky that back in the early 90s I started with the SNES and learned NES stuff several years later; the SNES really spoiled me. :P


Top
 Profile  
 
PostPosted: Fri Apr 06, 2018 7:53 am 
Offline

Joined: Fri Mar 01, 2013 4:46 am
Posts: 301
Thanks for those tips! Much appreciated! :-)

I'm so impressed from a coding perspective, with how much more can be done with the snes. I've worked with the nes since 2005, and I'm just at the point where I feel comfortable now to tackle the snes, since I've had success with nes romhacks, and coded 2 games from scratch. But I'll definitely follow what you suggested. Thank you again! :-)


Top
 Profile  
 
PostPosted: Sat Apr 07, 2018 1:59 pm 
Offline

Joined: Fri Mar 01, 2013 4:46 am
Posts: 301
Hmm, I'm having an issue getting data to be stored within the VRAM. Using bsnes, when I view the Memory Viewer to see the VRAM, nothing is getting stored to it, yet the bytes I want to be read, are read? I'm obviously missing a step or doing something wrong. :-/

Code:
LDA #$80
STA $2115     ;increase VRAM address

;trying to make it so bytes get stored at $0000 in VRAM
STZ $2116     ;VRAM address low byte
STZ $2117     ;VRAM address hi byte

LDA #$01
STA $4300     ;Make DMA write 1 byte to $2118 then $2119

LDA #$18
STA $4301     ;Write to $2118 & $2119

;I want to load my tileset, which is located at $E000 within my 01 bank, and the size is 2000 bytes
LDA #$00
STA $4302     ;low byte for my tiles
LDA #$E0
STA $4303     ;hi byte for my tiles
LDA #$01
STA $4304     ;bank id
LDA #$00
STA $4305     ;low byte of how many bytes to load
LDA #$20
STA $4306     ;hi byte of how many bytes to load

LDA #$01
STA $420B     ;start DMA


So once all of that is done, I can see my entire 2000 byte set of tiles loaded from the 01 bank, (all of my code is in the 00 bank) but when I view the Memory Viewer for the VRAM, it is all 00's. :-/


Top
 Profile  
 
PostPosted: Sat Apr 07, 2018 2:23 pm 
Offline

Joined: Thu Feb 07, 2013 1:15 am
Posts: 116
Location: Sweden
- Are you sure the accumulator/memory width is 8 bits? As the code is written that is the assumption, but it would assemble just fine in 16 bit mode and then all the register writes will put an extra zero at the next address, possibly messing things up.

- Is the system in vblank or forced blanking when DMA is started (and for the duration of the transfer)? If not VRAM is tied up by the PPUs and the writes “won’t bite”.


Top
 Profile  
 
PostPosted: Sat Apr 07, 2018 3:07 pm 
Offline

Joined: Fri Mar 01, 2013 4:46 am
Posts: 301
A is 8-bit. I'm not sure regarding vblank, this is still new to me. Is the routine at least correct looking? And with me loading $2000 bytes, what snes registers do I need to set correctly for vblank? Thanks!


Top
 Profile  
 
PostPosted: Sat Apr 07, 2018 3:42 pm 
Offline

Joined: Sun Mar 27, 2016 7:56 pm
Posts: 176
The code looks correct to me. (In fact, even if A were 16-bit, it looks like it would still happen to work anyway because of the order things are set in, so I think we can rule that out as the cause.)

Vertical blank, or vblank for short, is the span of time between each frame being drawn to the screen. During this time, the PPU isn't reading from VRAM, and it can be freely modified.

NMI is triggered at the start of vblank, so normally you would do stuff like this within your NMI routine. However, vblank is a fairly limited amount of time -- at most, you could transfer a bit under 6 KB of data per vblank via DMA, on NTSC consoles. As it happens, 0x2000 bytes is 8 KB, so it's too much to fit in a single vblank. Doing this during vblank would require splitting up the DMA.

Forced blank is another option. This simply turns off rendering, so VRAM can be modified freely as much as you want without worrying about time running out. The consequence, however, is that the screen is black while forced blanking is on. Thus, this is normally used while loading levels.


Top
 Profile  
 
PostPosted: Sat Apr 07, 2018 4:12 pm 
Offline
User avatar

Joined: Sun Sep 19, 2004 9:28 pm
Posts: 3722
Location: Mountain View, CA
Edit: didn't see post where OP said accumulator is 8-bit. I'll leave the below content here anyway.

I think 16-bit accumulator could break operational behaviour of this code. The big one is how stz $2116 / stz $2117 would result in (operationally) $00 --> $2116, $00 --> $2117, $00 --> $2117, $00 --> $2118, which I think could skew the subsequent DMA transfer results. I don't know what a 2nd write to $2117 would do, same with the subsequent write to $2118. No I'm not going to go look at emulator source code. Really depends on how the "flip-flop latch" thing is done in the hardware. This subject should not de-rail the main purpose of the thread.

There are similar "hmms" in the later parts of the code for the same reason, but as I worked them out, it seems they might actually work by total luck (solely due to the values being written and in the order the MMIO regs are being written to).

OP should get in the habit of checking accum/index sizes when posting code/asking for help. If you aren't sure, generate a code listing in your assembler -- it should be pretty obvious when you have the wrong thing -- else step-trace in a realtime debugger (CPU flags m (accum) and x (index): 0 = 16-bit, 1 = 8-bit). This is a common struggle point with the 65816 in general (read: common mistake/source of issues) so don't feel bad.

The rest of the advice about when this code is run (in VBlank/NMI handler vs. not) and concern over transfer size (while within VBlank) is absolutely correct.

I would make sure the source data you expect to be read really is within $01E000 -- emulator debugger should make this easy. The SNES's mode 20 (LoROM) memory map can often confuse people since sort of a "32KB bank" mode (byte 0 of ROM starts at $008000, byte 65536 ends up at $018000, etc.).

Otherwise the code looks OK.

Are you using a proper SNES initialisation routine, BTW? Many of the MMIO registers need to be initialised at reset. Attached are the recommend values. Things that say "VRAM Data", "OAM Data", and "CG Data" shouldn't be written to.

(2018/08/29 Edit: attachments removed.)


Last edited by koitsu on Wed Aug 29, 2018 6:44 pm, edited 1 time in total.

Top
 Profile  
 
PostPosted: Sat Apr 07, 2018 10:24 pm 
Offline

Joined: Thu Feb 07, 2013 1:15 am
Posts: 116
Location: Sweden
Oh yeah, one more thing: All addresses and lengths on the PPU are specified in 16-bit words. 0x2000 bytes = 0x1000 words, “byte address” 0x6000 = “word address” 0x3000, and so on.


Top
 Profile  
 
PostPosted: Sat Apr 07, 2018 11:35 pm 
Offline

Joined: Sun Mar 27, 2016 7:56 pm
Posts: 176
Optiroc wrote:
Oh yeah, one more thing: All addresses and lengths on the PPU are specified in 16-bit words. 0x2000 bytes = 0x1000 words, “byte address” 0x6000 = “word address” 0x3000, and so on.

It's true that VRAM addresses represent a number of words rather than bytes, so it's something to keep in mind for when you set $2116/$2117 to choose the start of where to transfer to.

However, they are correct in setting $4305/$4306 to $00 and $20, because DMA counts in bytes rather than transfer units.


Top
 Profile  
 
PostPosted: Mon Apr 09, 2018 4:18 am 
Offline

Joined: Fri Mar 01, 2013 4:46 am
Posts: 301
Ok, I'm away from my laptop till tonight, but I'm making progress.

I redid the snes initialization routine, then after that (using DMA) I was able to load and store palettes into the CGRAM.

After that, again using DMA, I was able to load and store my tileset at address $0000 in VRAM.

Then, I started reading up on how the tile maps coexist within the VRAM, and you have to set addresses for them. So I was able to create addresses for the 4 BG layers, starting at $A000, then the following 3 are at $B000, $C000, $D000.

Then manually, I started inserting one tile id into each of the 4 tile maps. I haven't messed with the properties of palettes, priority, flip, but with all 4 BG modes enabled, I was able to see the 4 tiles on 4 different bg's on screen! :-)

I'll post my code tonight, to see if there is stuff that is not needed, or missing.

But, with all of that said, I do have a question regarding the 2bpp/4bpp graphics.

I'm using 2bpp tile graphics. Now again this is all new to me, so I may have done this wrong. I used YY-CHR, to copy a tileset from an NES rom, and I pasted it within my SNES test rom. Now, when the tileset is injected into the VRAM, the 2bpp mode shows my tiles as "every-other", meaning from left to right, 1 8x8 tile is present, the next is blank, the next 8x8 tile is present, the next is blank. This goes on and on. But within 4bpp mode, my tilset looks correctly like it should, all together.

What am I missing/doing wrong with the gfx?

Thanks! :-)


Top
 Profile  
 
PostPosted: Mon Apr 09, 2018 5:02 am 
Offline

Joined: Thu Feb 07, 2013 1:15 am
Posts: 116
Location: Sweden
infidelity wrote:
I'm using 2bpp tile graphics. Now again this is all new to me, so I may have done this wrong. I used YY-CHR, to copy a tileset from an NES rom, and I pasted it within my SNES test rom. Now, when the tileset is injected into the VRAM, the 2bpp mode shows my tiles as "every-other", meaning from left to right, 1 8x8 tile is present, the next is blank, the next 8x8 tile is present, the next is blank. This goes on and on. But within 4bpp mode, my tilset looks correctly like it should, all together.

What am I missing/doing wrong with the gfx?

The graphics you've created is 4bpp tile data (albeit only using the first 2 planes). In VRAM 4bpp tiles is laid out exactly like that – two 2bpp tiles back to back. 8bpp tiles are laid out as four 2bpp tiles in sequence (although you don't see these used too often).

So I suppose you need to fiddle with the save/export settings of the tool you're using to make sure you export 2bpp data.


Top
 Profile  
 
PostPosted: Mon Apr 09, 2018 6:16 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 20854
Location: NE Indiana, USA (NTSC)
The 2bpp option may be called "Game Boy" in the tool you use.


Top
 Profile  
 
PostPosted: Mon Apr 09, 2018 7:00 am 
Offline

Joined: Fri Mar 01, 2013 4:46 am
Posts: 301
I know I've seen a window in yy-chr, where you are able to change the bpp view.

So am I correct with this thinking...

Open snes rom, change the view to 2bpp, paste the tiles I want into the snes rom, and while the view is still set at 2bpp, I then save the rom?

Thanks! :-)


Top
 Profile  
 
PostPosted: Mon Apr 09, 2018 3:51 pm 
Offline

Joined: Fri Mar 01, 2013 4:46 am
Posts: 301
Excellent! I changed it to 2bpp GameBoy, saved the gfx, and when I loaded up bsnes, 2bpp displayed correctly. :-)


Top
 Profile  
 
PostPosted: Tue Apr 10, 2018 5:11 pm 
Offline

Joined: Fri Mar 01, 2013 4:46 am
Posts: 301
Is there a program that can take an NES palette id, and concert it to snes bits? I've wasted hours trying to mimic the colors from the nes. Idk if there's already a conversion table on the Internet? Thanks!


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 103 posts ]  Go to page Previous  1, 2, 3, 4, 5 ... 7  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 3 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group