Search found 433 matches
- Wed Apr 15, 2015 3:15 am
- Forum: SNESdev
- Topic: BS-X memory mapping - discrepancy between fullsnes and higan
- Replies: 4
- Views: 2115
Re: BS-X memory mapping - discrepancy between fullsnes and h
It seems someone called LuigiBlood or Seru-kun has done exhaustive reverse engineering of the BS-X cartridge, as well as translating it to English. And wiki.superfamicom.org is criminally hard to navigate... it took me this long to find this page: http://wiki.superfamicom.org/snes/show/BS-X+MMIO whi...
- Tue Apr 14, 2015 9:48 pm
- Forum: SNESdev
- Topic: BS-X memory mapping - discrepancy between fullsnes and higan
- Replies: 4
- Views: 2115
Re: BS-X memory mapping - discrepancy between fullsnes and h
if((addr & 0xe0e000) == 0x206000) { //$20-3f:6000-7fff return memory_access(write, psram, addr, data); } The only address translation that memory_access() does is to wrap the address within the total size of the memory object accessed, so the mapping is as I described it. The code before the me...
- Mon Apr 13, 2015 5:19 pm
- Forum: SNESdev
- Topic: DMA reset using DMA? [Apparently not...]
- Replies: 8
- Views: 3572
Re: DMA reset using DMA?
You can't use DMA to read or write to S-CPU registers ($40xx, $42xx, $43xx). They aren't on either the A-bus or the B-bus.
- Fri Apr 10, 2015 1:07 pm
- Forum: SNESdev
- Topic: BS-X memory mapping - discrepancy between fullsnes and higan
- Replies: 4
- Views: 2115
BS-X memory mapping - discrepancy between fullsnes and higan
nocash's fullsnes document says the following: xx-3F:6000-7FFF PSRAM (Mirror of 8K at PSRAM offset 06000h..07FFFh) However, that's not how Higan maps this address range. Higan maps PSRAM offset 06000..07fff to 00:6000-7fff, offset 16000..17fff to 01:6000-7fff, offset 26000-26fff to 02:6000-7fff, etc...
- Sat Mar 28, 2015 11:08 am
- Forum: SNESdev
- Topic: SNES PPU Schematics
- Replies: 15
- Views: 6081
Re: SNES PPU Schematics
So is it kind of like this? http://www.system16.com/hardware.php?id=747 1 = Top 8 pens appear over sprites (split tilemap) Hey, you know, I just thought of something... If you had a 256 color BG that was behind sprites but above a 4 color BG that was above the sprites, couldn't you make it to where...
- Wed Mar 25, 2015 1:18 am
- Forum: SNESdev
- Topic: SNES PPU Schematics
- Replies: 15
- Views: 6081
Re: SNES PPU Schematics
Addendum: The weirdness of the BGnHOFS write semantics makes sense when you consider how BG rendering works. Each BGnHOFS register is actually two physical registers, one on each chip: the low 3 bits are on PPU2 and the rest of the bits are on PPU1. PPU1 has a common 8-bit latch that is shared by al...
- Tue Mar 24, 2015 11:38 am
- Forum: SNESdev
- Topic: SNES Transparency
- Replies: 6
- Views: 2568
Re: SNES Transparency
Leaving hardware registers or RAM uninitialized is probably the number one source of "My code works on emulators, but..." bugs.
- Tue Mar 24, 2015 11:13 am
- Forum: SNESdev
- Topic: SNES Transparency
- Replies: 6
- Views: 2568
Re: SNES Transparency
So, the water is high-priority BG2 tiles and the part of the ground that's turning white is low-priority BG2 tiles? Make sure you've initialized COLDATA to black by writing #$e0 to it. Otherwise if there is no layer under BG2 then it will get blended with whatever is in that register, with halving f...
- Tue Mar 24, 2015 10:31 am
- Forum: SNESdev
- Topic: SNES Transparency
- Replies: 6
- Views: 2568
Re: SNES Transparency
You're going to need to provide more information, it's not at all clear from the screenshot what you're even trying to do. What parts of the screen are on each BG layer and what PPU register settings are you using (particularly TM, TS, CGWSEL and CGADSUB)?
- Tue Mar 24, 2015 9:13 am
- Forum: SNESdev
- Topic: SNES PPU Schematics
- Replies: 15
- Views: 6081
Re: SNES PPU Schematics
Assuming the pin names on jwdonal's schematic are reasonably descriptive, it looks like there's a pixel bus between the PPUs, but only for sprites. It's the nine lines labeled CHR0-CHR3, PRI0-PRI1 and COLOR0-COLOR2. Also, you can see that the VRAM data lines are connected to both chips, but the addr...
- Wed Feb 18, 2015 3:26 pm
- Forum: SNESdev
- Topic: Documentation on offset-per-tile
- Replies: 18
- Views: 7262
Re: Documentation on offset-per-tile
Tomathious is a bit confused. The "third tilemap" used in offset-per-tile modes isn't a full 32x32 tilemap; it's only 32x2. The first row contains the horizontal offsets for each full column of the other tilemap(s); the second row contains the vertical offsets for each full column. For on...
- Wed Feb 18, 2015 2:21 am
- Forum: SNESdev
- Topic: Documentation on offset-per-tile
- Replies: 18
- Views: 7262
Re: Documentation on offset-per-tile
http://www.sega-16.com/forum/showthread.php?18434-Comparison-of-4th-generation-(-quot-8-16-bit-quot-)-system-hardware/page78 In this thread Tomathious says that offset-per-tile mode requires every tile to be individually scrolled, but that is incorrect because I've done collumn-scrolling before, an...
- Mon Nov 10, 2014 12:11 pm
- Forum: SNESdev
- Topic: Force Blank timing issue - SNES vs. higan
- Replies: 18
- Views: 8312
Re: Force Blank timing issue - SNES vs. higan
Mainly for AWJ: I'm under the impression EXTBG only applies (i.e. is only visible/usable) in mode 7. The only time EXTBG is mentioned, other than in the "mode capabilities chart", is within the "BG SC data (mode 7)" section. Other docs I find online hint at the same thing. It's ...
- Mon Nov 10, 2014 10:28 am
- Forum: SNESdev
- Topic: Force Blank timing issue - SNES vs. higan
- Replies: 18
- Views: 8312
Re: Force Blank timing issue - SNES vs. higan
Could this have anything to do with the fact that the artifacting on the left hand side of the first active scanline looks like it comes in 8-pixel chunks on the real system, but definitely doesn't in higan? Or is this just a coincidence (the artifacting on the right side of the last blank scanline...
- Tue Nov 04, 2014 11:40 am
- Forum: SNESdev
- Topic: Background plane numbering: 1 or 0 based?
- Replies: 11
- Views: 4385
Re: Background plane numbering: 1 or 0 based?
I'm pretty sure the EXT pins are always inputs. In a stock SNES, /MASTER on PPU1 is tied low and the PPU2 EXT pins are inputs (for Mode 7 EXTBG). /MASTER probably determines how sync timing is generated--whether to generate it inside the PPU or to let external logic drive it, presumably via the /EXT...