So right now I'm working on a few example programs for the first release of my framework. It has some imperfections here and there, but one bit that really bothers me right now is the style of VRAM address. The macros I'm using for load-time VRAM transfers use word addresses, and so do the VRAM address registers of course. However, bsnes-plus and the constants I wrote for deciding VRAM address use byte addresses. Somewhere I'm going to need to make both the macro and the constants use the same style of address.
Currently I'm leaning toward word address but I'd like to hear what others think.
VRAM: Byte address or word address?
Moderator: Moderators
Forum rules
- For making cartridges of your Super NES games, see Reproduction.
VRAM: Byte address or word address?
SNES NTSC 2/1/3 1CHIP | serial number UN318588627
-
- Posts: 3140
- Joined: Wed May 19, 2010 6:12 pm
Re: VRAM: Byte address or word address?
Wow, a unanimous majority voted for word address!
Re: VRAM: Byte address or word address?
There isn't enough votes yet for that.psycopathicteen wrote:Wow, a unanimous majority voted for word address!
(Free Hero Mesh - FOSS puzzle game engine)
Re: VRAM: Byte address or word address?
Hmm, 9 to 1. Well, that was easy enough. Thanks everyone!
SNES NTSC 2/1/3 1CHIP | serial number UN318588627
Re: VRAM: Byte address or word address?
Except for the (damning!) fact that the VRAM data port register use word addressing, I see little reason to think about addresses in VRAM as word[n], when I think of any other address ever as byte[n].
Re: VRAM: Byte address or word address?
Ignoring mode 7, everything else in the S-PPU works with 16-bit words: both RAMs have the same address.
It made things a lot easier for me (who is, admittedly, coming to this from the point of view of an EE) when I realized not only how the various offset registers in the S-PPU could literally be mapped to address pins on the RAM, but how they were almost all nicely aligned within:
$2101: [...aaBBB] where BBB is literally PPU RAM A15, A14, A13
$2107(8,9,a): [CCCCCC..] and CCCCCC is literally PPU RAM A15, A14, A13, A12, A11, A10
$210b(c): [DDDDEEEE] and both DDDD and EEEE are literally PPU RAM A15, A14, A13, A12
$2107/8/9/a are conveniently aligned to a multiple of 256; you can literally throw away the lower byte (and mask two bits out of the upper byte) and use it, if you're starting with word addresses.
both $210b/c are half nice (the upper nybble is again conveniently aligned) but the lower nybble requires more massaging.
If not for the repeatedly present and unconnected PPU RAM A15, the distinction wouldn't have clicked so strongly for me.
It made things a lot easier for me (who is, admittedly, coming to this from the point of view of an EE) when I realized not only how the various offset registers in the S-PPU could literally be mapped to address pins on the RAM, but how they were almost all nicely aligned within:
$2101: [...aaBBB] where BBB is literally PPU RAM A15, A14, A13
$2107(8,9,a): [CCCCCC..] and CCCCCC is literally PPU RAM A15, A14, A13, A12, A11, A10
$210b(c): [DDDDEEEE] and both DDDD and EEEE are literally PPU RAM A15, A14, A13, A12
$2107/8/9/a are conveniently aligned to a multiple of 256; you can literally throw away the lower byte (and mask two bits out of the upper byte) and use it, if you're starting with word addresses.
both $210b/c are half nice (the upper nybble is again conveniently aligned) but the lower nybble requires more massaging.
If not for the repeatedly present and unconnected PPU RAM A15, the distinction wouldn't have clicked so strongly for me.