 |
| Register | Login | |||||
 |
Main
| Memberlist
| Active users
| ACS
| Commons
| Calendar
| Online users Ranks | FAQ | Color Chart | Photo album | IRC Chat |
|
| | ||
|
| Register | Login | |||||
|
Main
| Memberlist
| Active users
| ACS
| Commons
| Calendar
| Online users Ranks | FAQ | Color Chart | Photo album | IRC Chat |
|
| | ||
1 user currently in Rom Hacking:  hukka |
| Acmlm's Board - I2 Archive - Rom Hacking - Memory Incrementing for SNES graphics |
 |  |  |
| Add to favorites | "RSS" Feed | Next newer thread | Next older thread |
| User | Post | ||
MathOnNapkins Math n' Hacks Level: 67  Posts: 6/2189 EXP: 2495887 For next: 96985 Since: 03-18-04 From: Base Tourian Since last post: 1 hour Last activity: 32 min. |
| ||
| I was poking around in some code today and I found an instance where register $2115 was written with #80, thereby denoting that the Vram address at $2116 would increment when $2119 was written to. Now, since the processor at that time had a 16-bit accumulator, is it reasonable to assume that if I write a word, say #XXXX to $2118, that word is identically mapped to the address in Vram, and since the accumulator also wrote to $2119 since it's 16-bit, that the Vram address is auto incremented? I'm just clarifying for myself as this seems to be the most logical conclusion. Anybody know? For the record, I've mainly dealt with alternating byte writes to only $2118 or $2119 in the past, so this is new to me. The one question that would remain, is that why would $2115 need to be #80 rather than #00? Would the low byte write first, trigger an auto increment, and the high byte would be stranded one address higher in Vram? |
|||
|
Colleen Administrator Level: 136 Posts: 527/11302 EXP: 29369328 For next: 727587 Since: 03-15-04 From: LaSalle, Quebec, Canada Since last post: 3 hours Last activity: 1 hour |
| ||
Moving the thread to Rom Hacking since you'll get a better answer there.  |
|||
|
BMF98567 BLACK HAS BUILT A SILLY DICE-MAZE! GO! Current list of BURNING FURY >8( recipients: - Yiffy Kitten (x2) - Xkeeper Level: 53  Posts: 66/1261 EXP: 1094149 For next: 62970 Since: 03-15-04 From: Blobaria Special Move: Rising Meatloaf Backhand Combo Since last post: 21 hours Last activity: 1 hour |
| ||
Originally posted by MathOnNapkinsThat sounds right. $2118 writes to the lower 8 bits of the current VRAM address, while $2119 writes to the upper 8 bits (AFAIK, VRAM is always 16-bit). Bit 7 of $2115 is set, so the address auto-increments after $2119 is written to. |
|||
|
MathOnNapkins Math n' Hacks Level: 67 Posts: 7/2189 EXP: 2495887 For next: 96985 Since: 03-18-04 From: Base Tourian Since last post: 1 hour Last activity: 32 min. |
| ||
| Okay... VRAM addresses are always word addresses. Here's a diagram $0000--$0001--$0002 of Vram: XX XX | XX XX | XX XX etc.... Notice that they share no memory space. $0000 shares no bytes with $0001 and so on. Now suppose that $2115 was written with #00 rather than #80. And I write #2110 to $2118. What I'm asking is whether VRAM would look like this: $0000--$0001--$0002 10 XX | XX 21 | XX XX And if $2115 were #80 $0000--$0001--$0002 10 21 | XX XX | XX XX I'm not so much as asking a question as trying to reach a concensus. Qwerty's doc on this is fuzzy in its explanations. |
|||
|
FuSoYa Defender of Relm Level: 26  Posts: 7/255 EXP: 99529 For next: 2746 Since: 03-15-04 From: Moon Since last post: 7 days Last activity: 7 hours |
| ||
| Sounds right to me. But it's easy enough to run the code to check and make sure... *checks* Yes, that's what zsnes does. |
|||
|
MathOnNapkins Math n' Hacks Level: 67 Posts: 9/2189 EXP: 2495887 For next: 96985 Since: 03-18-04 From: Base Tourian Since last post: 1 hour Last activity: 32 min. |
| ||
| Oh my is this the FuSoYa? I'm honored. I mentioned querty's doc because when I trace I usually use sneqr, which he wrote. I have yet to download a version of Zsnes with a tracing debugger. Maybe I should...  |
| Add to favorites | "RSS" Feed | Next newer thread | Next older thread |
| Acmlm's Board - I2 Archive - Rom Hacking - Memory Incrementing for SNES graphics |
| | |
