SNES CHR processing - theoretical questions

Discussion of hardware and software development for Super NES and Super Famicom. See the SNESdev wiki for more information.

Moderator: Moderators

Forum rules
  • For making cartridges of your Super NES games, see Reproduction.
Post Reply
User avatar
Hamtaro126
Posts: 818
Joined: Thu Jan 19, 2006 5:08 pm

SNES CHR processing - theoretical questions

Post by Hamtaro126 »

#1: Is better, Faster CHR processing possible on SNES?
#2: Is CHR-ROM possible on SNES, as well as a mapper for the ROM/RAM selection options for the PPU

For example, I've always wanted to add a hack to allow dynamic uploading of sprite GFX to SMW using up to 4096 Byte CHR file, or the equivlent of a full 4bpp GFX file,

But the problem I, plus ALL SNES hacker/programmers face is the DMA restrictions, the SNES can only DMA up to 5k depending on interrupt use and NTSC/PAL TV limitations, So I may only have at least up to approx. 2-3 KB of DMA memory, which is not even enough memory to do that.

Notice: I still do not plan on making cartridges by myself, All this is currently just theoretical!
AKA SmilyMZX/AtariHacker.
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: SNES CHR processing - theoretical questions

Post by tepples »

The Super NES does not use CHR ROM.

4K is 128 4bpp tiles and less than 5K. To go beyond 5K or so, extend the top and bottom borders using forced blanking.
User avatar
Hamtaro126
Posts: 818
Joined: Thu Jan 19, 2006 5:08 pm

Re: SNES CHR processing - theoretical questions

Post by Hamtaro126 »

Umm... Are you talking about extending the queue time, in a manner similar to how to wait for VBlank on NES? (i.e. waiting until the first DMA set is done before making more?)

EDIT- as I've said, 5k still isn't the right amount SMW uses, 2-3k is still technically free, 2k for actual video freedom, 1k for emergency use and other stuff

The first 2k is SMW's main writing time: HDMA fades (title/course clear/cutscenes/credits), Map16 tiles, Palettes, Tiles and the Animation timing depend mostly on the 2k DMA time, so that leaves 2-3k instead of 5k

Therefore, In case 3k fails, I should fall back to 2k for normal usage, which still is a headache.

SELFEDIT: Reminder- Never say metatiles, say Map16!!!
AKA SmilyMZX/AtariHacker.
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: SNES CHR processing - theoretical questions

Post by tepples »

I'm talking about letterboxing using the forced blanking bit: use an HVIRQ to turn off rendering (INIDISP=$80) around Y=216, then do your DMAs, turn rendering back on but black (INIDISP=$00) in the hblank before Y=8, and finally turn display fully on (INIDISP=$0F) in the hblank before Y=9. This should free up a few more scanlines to copy things.

Or spread your upload out across multiple frames.
User avatar
koitsu
Posts: 4201
Joined: Sun Sep 19, 2004 9:28 pm
Location: A world gone mad

Re: SNES CHR processing - theoretical questions

Post by koitsu »

I would suggest splitting the DMA transfer across ~2 frames, assuming there's no visual/visible artefacting from doing so. If there is, then you're fighting an uphill battle unless you're willing to make sacrifices. Does whatever you're doing really need to be a full 4KBytes? If so, then yeah, you have limited options.
93143
Posts: 1717
Joined: Fri Jul 04, 2014 9:31 pm

Re: SNES CHR processing - theoretical questions

Post by 93143 »

If all the setup was done ahead of time and all you had to do was pure DMA, you could push more than 6 KB in a normal NTSC VBlank. PAL is around 12 KB even with overscan, or more than 14 KB without.

I'm not familiar with SMW's code, so I don't know how much extraneous stuff there needs to be in VBlank or how easy it would be to streamline a hack to fit more snugly. It may be academic, but I just thought it was worth mentioning that the theoretical limits of the hardware are somewhat higher than the OP's assumed numbers.
psycopathicteen
Posts: 3140
Joined: Wed May 19, 2010 6:12 pm

Re: SNES CHR processing - theoretical questions

Post by psycopathicteen »

Hamtaro126 wrote:
EDIT- as I've said, 5k still isn't the right amount SMW uses, 2-3k is still technically free, 2k for actual video freedom, 1k for emergency use and other stuff

The first 2k is SMW's main writing time: HDMA fades (title/course clear/cutscenes/credits), Map16 tiles, Palettes, Tiles and the Animation timing depend mostly on the 2k DMA time, so that leaves 2-3k instead of 5k
HDMA doesn't take up any vblank time. Palettes and tiles don't need to be updated every frame.
psycopathicteen
Posts: 3140
Joined: Wed May 19, 2010 6:12 pm

Re: SNES CHR processing - theoretical questions

Post by psycopathicteen »

An easy way of testing if there is enough vblank time left is by disabling PPU rendering before a DMA and enabling it back afterwards. This creates a black bar at the top of the screen when there is too much to DMA, but prevents other graphical glitches from happening. If you get a flickering black bar on top of the screen you can cover it up with black tiles on the BG3/HUD layer.

Code: Select all

sep #$20
lda #$80                     //bit 7 of $2100 turns rendering off
sta $2100

**insert DMA code here**

sep #$20
lda #$0f                     //clearing bit 7 of $2100 turns rendering on
sta $2100                   //bits 0-3 control screen brightness, which you want to be at full brightness
Post Reply