#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!
SNES CHR processing - theoretical questions
Moderator: Moderators
Forum rules
- For making cartridges of your Super NES games, see Reproduction.
- Hamtaro126
- Posts: 818
- Joined: Thu Jan 19, 2006 5:08 pm
SNES CHR processing - theoretical questions
AKA SmilyMZX/AtariHacker.
Re: SNES CHR processing - theoretical questions
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.
4K is 128 4bpp tiles and less than 5K. To go beyond 5K or so, extend the top and bottom borders using forced blanking.
- Hamtaro126
- Posts: 818
- Joined: Thu Jan 19, 2006 5:08 pm
Re: SNES CHR processing - theoretical questions
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!!!
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.
Re: SNES CHR processing - theoretical questions
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.
Or spread your upload out across multiple frames.
Re: SNES CHR processing - theoretical questions
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.
Re: SNES CHR processing - theoretical questions
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.
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.
-
- Posts: 3140
- Joined: Wed May 19, 2010 6:12 pm
Re: SNES CHR processing - theoretical questions
HDMA doesn't take up any vblank time. Palettes and tiles don't need to be updated every frame.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
-
- Posts: 3140
- Joined: Wed May 19, 2010 6:12 pm
Re: SNES CHR processing - theoretical questions
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