It is currently Sun Jun 16, 2019 1:54 pm

All times are UTC - 7 hours



Forum rules





Post new topic Reply to topic  [ 38 posts ]  Go to page Previous  1, 2, 3
Author Message
PostPosted: Tue Feb 26, 2019 5:02 pm 
Offline
User avatar

Joined: Sun Sep 19, 2004 9:28 pm
Posts: 4104
Location: A world gone mad
Edit: tepples has chimed in with useful info too, on both subjects.

vivi168 wrote:
I must admit I was a little lost here.
Why does long addressing only work in mode 20/LoROM?

Long addressing works in any mode. However, mode 20 has the memory map/layout where the lower 32KB of most banks (but not all) your code runs in are mirrors of bank $00 -- that way, no matter what bank your code is running in, you can do sta $2118 and it'll do exactly what you expect.

In mode 21, the situation is a bit different. I worry that by describing this memory map that you're going to completely get confused and lose focus on accomplishing your goal, so I'm reluctant to describe it. This is a crappy one-paragraph description with stuff omitted but this is what's important: banks $C0-FF are full 64KB of ROM, that is to say they do not have the lower 32KB of the bank mirrored to $00, so if your code runs out of $C0-FF then sta $2118 will do nothing (while sta $002118 would work fine). Mode 21 does have some banks that have the lower 32KB mirrored from $00 -- such as banks $80-BF and $01-3F. (The latter is needed because all the CPU vectors (ex. reset, nmi, irq, cop, etc.) are read from bank $00 by the CPU itself) Banks $80-FF support high speed mode, too. (I'm not going to get into describing that) Banks $40-7D (yes, 7D) mirror $C0-FD, I believe.

I would love to attach pictures showing you the topologies but I have intentionally gone back and removed all screenshots of the dev manual I've uploaded + don't post them any more out of concern of Nintendo cracking down on IP. That's a separate subject not for this thread please.

In general, I always tell people to stick with mode 20 unless you know right up front that you're going to need TONS of ROM space -- odds are you aren't.

vivi168 wrote:
As for TCD, I've made some research, it transfers the the 16 bits in of the accumulator to the Direct Page Register I think, but I'm not exactly sure what that means?
Does it affect which page/bank you access? For example instead of accessing Zero Page, you access Page 02?

Do you understand zero page from 6502/65c02? If so, then understanding DP is easy!

In 6502/65c02 zero page refers to memory from $0000 to $00FF, hence the term "zero page". Page 1 would be $0100-01FF, page 2 $0200-02FF, etc.

The D register on the 65816 lets you relocate that "zero page" to anywhere within bank $00. D is a 16-bit register. So while lda $20 would, on 6502, read from $0020, on the 65816 it could read from anywhere in bank $00 depending on what D is set to. Code examples to explain it:

Code:
lda #$0000 / tcd / lda $40  ; reads 16-bit value from bank $00, $0000-0001 (i.e. identical to 6502/65c02's zero page)
lda #$0200 / tcd / lda $40  ; reads 16-bit value from bank $00, $0240-0241
lda #$1100 / tcd / lda $18  ; reads 16-bit value from bank $00, $1118-1119
lda #$1f6f / tcd / lda $10  ; reads 16-bit value from bank $00, $1f7f-1f80 with penalty

One thing to keep in mind: there is a 1 cycle penalty on DP addressing operations if the low byte of D is non-zero (e.g. $xx66, $xx20, etc.). So in general you should ensure it's "page-aligned" (e.g. D=$xx00).

Now you see how this trick can be used to potentially allow for MMIO register access using direct page by doing lda #$2100 / tcd.

However, as I stated in an earlier post's last paragraph, ca65/ld65 does not have good support for relocatable direct page on 65816. It does not "decently" handle understanding the situation where a programmer relocates D from $0000 (the default). So, if you use ca65, you should stick with D=$0000 to avoid severe pains, else if changing it always put it back to D=$0000 when done. There is a separate thread on this forum discussing this matter, so if you really find you need to use relocatable DP, look for the thread / ask and one of us can link it.

Quote:
So to clarify, first of all, I've set $2105 (BGMODE) to $01 (bg mode 1, tile size 8). and $2107 (BG1SC) is set to $10 (only one 32x32 tilemap).
At the beginning, I first load the tilemap from the ROM to PPU via DMA. Then when going left and right, I scroll the background. For now, it only wraps back.

What I'm looking to do, is fetch a column of another tilemap in the ROM and write it over a column of the tilemap in the PPU. (So it gives the illusion of a longer level, like the GIF tepples posted). From what I've read in this thread, it might be a good idea to first transfer it to the WRAM, and then copy the column I need from the WRAM to the PPU.

Right -- this is exactly what I was describing with my code, etc.. psychopathicteen came in here to describe something that relates to earlier posts in the thread, talking about how you actually handle the whole "camera situation". Those posts:

viewtopic.php?p=234954#p234954 (but not exactly -- Oziphantom describes something important here!)
viewtopic.php?p=234955#p234955

Implementing what's described in those would be the *next* phase for you to try to accomplish *after* you accomplish what you're currently doing. (This is a common problem with this forum, BTW -- people often will show up and de-rail a training exercise with stuff and the user ends up confused. Forums are not good forms of teaching, IMO, at least in comparison to, say, having a classroom with students listening to you and focused directly on things one step at a time. There are only a few here on this forum who, IMO, are good teachers.)

Again to repeat myself: keep with what you're doing right now. Work on getting routine(s) that can update the PPU RAM in columns and rows (particularly the 4 edges of the screen). From there, you can get a better grasp of what needs to be done. Oziphantom's post though is pretty good. If you need to make 4 separate routines at first (for each edge), then do it that way. It's OK! You can/will consolidate them later once you get a better understanding of it. :-)

Make sure you get yourself a SNES emulator with a good debugger too, ex. bsnes-plus, BTW. You are going to need it, I promise you, because you're going to need to see what's actually in PPU RAM (to ensure your routines are writing to the correct addresses) and in WRAM as well.


Top
 Profile  
 
PostPosted: Tue Feb 26, 2019 5:18 pm 
Offline

Joined: Thu Feb 14, 2019 2:25 pm
Posts: 8
Quote:
so if your code runs out of $C0-FF then sta $2118 will do nothing (while sta $002118 would work fine)


That's exactly what I understood from Tepples last post. thanks for confirming. And after reading your post, I've understood DP :)

Quote:
I would love to attach pictures showing you the topologies

I think I know what page/diagram you're referring to


And as for copying the column, Here is the loop I've written

Next step is to reuse that piece when moving the charcter left and right.
(if anyone wants to see the current state of the demo, click here)

And as for the emulator, don't worry, I'm already using bsnes+ :) and I must say the debugger and memory inspector have been some invaluable tools for understanding how things work/what needs to be done in order to make things work.


Top
 Profile  
 
PostPosted: Tue Feb 26, 2019 5:47 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 21439
Location: NE Indiana, USA (NTSC)
koitsu wrote:
I would love to attach pictures showing you the topologies but I have intentionally gone back and removed all screenshots of the dev manual I've uploaded

Did it look anything like the memory map I drew?

_________________
Pin Eight | Twitter | GitHub | Patreon


Top
 Profile  
 
PostPosted: Tue Feb 26, 2019 6:44 pm 
Offline
User avatar

Joined: Sun Sep 19, 2004 9:28 pm
Posts: 4104
Location: A world gone mad
tepples wrote:
koitsu wrote:
I would love to attach pictures showing you the topologies but I have intentionally gone back and removed all screenshots of the dev manual I've uploaded

Did it look anything like the memory map I drew?

This is a very strange way to draw a memory map -- it's actually backwards (inverted) for starters, which is tremendously confusing ($FFFF should be at the top of the diagram and $0000 at the bottom, not the other way around). All the fancy shaded pixel cells/tiles/art makes it difficult to follow. We can discuss in another thread/different place/maybe I'll just do one myself sometime. Here's an unrelated example that demonstrates how to do it.


Top
 Profile  
 
PostPosted: Wed Feb 27, 2019 4:08 am 
Offline
User avatar

Joined: Fri Jan 04, 2019 5:31 pm
Posts: 35
Location: France, right of a pile of consoles
koitsu wrote:
t's actually backwards (inverted) for starters, which is tremendously confusing ($FFFF should be at the top of the diagram and $0000 at the bottom, not the other way around).

How is that inverted? It's natural to have memory laid out in a reading order - $0000 is first in memory, so it's at the top. Otherwise, consistency would also require bank $00 to be at the far right, wouldn't it?

_________________
The French Lord of Laziness (and a huge Legend of Zelda fan)
https://github.com/ISSOtm
ASMu is laifu <3


Top
 Profile  
 
PostPosted: Wed Feb 27, 2019 5:22 am 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 11369
Location: Rio de Janeiro - Brazil
Some people like to document memory maps from top to bottom, others from bottom to top, I don't think that there's a "correct" way to do it. Doing it from bottom to top seems helpful to convey the concept of stacks, but other than that, I see little reason to not use top to bottom, as has everything ever been written in the history of mankind...


Top
 Profile  
 
PostPosted: Wed Feb 27, 2019 6:02 am 
Offline
User avatar

Joined: Sun Sep 19, 2004 9:28 pm
Posts: 4104
Location: A world gone mad
ISSOtm wrote:
How is that inverted? It's natural to have memory laid out in a reading order - $0000 is first in memory, so it's at the top. Otherwise, consistency would also require bank $00 to be at the far right, wouldn't it?

No, it can be however someone wants it to be, apparently. I took the liberty of pulling tomes off my shelves and the conclusion is: it varies, and in one case the book isn't even consistent:

SNES developers manual: $FFFF top $0000 bottom, bank $FF on left $00 on right
Apple IIGS firmware reference: $FFFF top $0000 bottom, banks not visually depicted in diagrams
Apple IIGS hardware reference: $FFFF top $0000 bottom, however for bank, bank $00 on top $FF on bottom
GTE 65816 document: $FFFF top $0000 bottom (found by looking at MVN/MVP opcodes)
Programming the 65816, Including the 6502, 65C02, and 65802: $FFFF top $0000 bottom, bank $FF on left $00 on right
Programming the 6502: $0000 top $FFFF bottom (or rather, "0" top, "64K" bottom)
6502 Assembly Language Programming: no map, however author depicts visually memory offsets in routines as +0 top, +1 next, +2 next, etc...
6801, 68701, & 6802 Microcomputer Programming & Interfacing: $0000 top $FFFF bottom
Microcontrollers and Microcomputers: $0000 top $FFFF bottom
ARM Architecture Reference Manual: $FFFF top $0000 bottom
Sega Mark III / Master System reference manual: $FFFF top $0000 bottom
Sega Saturn Programmer Tutorial: 25A00000 top 25A7FFFF bottom
Sony PocketStation PDA Hardware Specification: 0x0A000000 top 0x00000000 bottom
PCI Express documentation (referring to BARs): $0000 top $FFFF bottom
SATA/AHCI documentation (HBA memory map, ABARs, FIS): $00 top $1100 bottom

TL;DR -- Do it whatever way you want, tepples.

I should add that tepples and I are having a PM about how to improve upon what he did a few years ago. I like his work, I just think some edits and simplification could make it a lot more useful.


Top
 Profile  
 
PostPosted: Wed Feb 27, 2019 8:21 am 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 11369
Location: Rio de Janeiro - Brazil
I've never seen a diagram of the SNES memory map(s?) that didn't confuse the hell out of me. And I have a decent understanding of how memory mapping works in general, address lines and the like. I'm sure that I would eventually get it if I read more about it, but since SNES development doesn't interest me much I can't really bother. Anyway, my point is that this seems like a very hard concept to convey in a diagram, and that you might need a good amount of text along with it so it makes sense.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 38 posts ]  Go to page Previous  1, 2, 3

All times are UTC - 7 hours


Who is online

Users browsing this forum: e-neon and 8 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group