It is currently Sun Dec 17, 2017 1:03 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 17 posts ]  Go to page 1, 2  Next
Author Message
PostPosted: Thu Jun 15, 2017 10:48 am 
Offline

Joined: Mon Jan 30, 2017 5:20 pm
Posts: 303
Location: Colorado USA
I don't get why Nintendo decided to have the ROM on the end of the NES memory map rather then in the front. Wouldn't it make programming it a whole lot easier? You wouldn't have to .base to get all of the code in the right address. Another great advantage would be that you would have zero-page in the ROM. Wouldn't having that make programming a whole lot easier? All you would have to do to let's say copy a bunch of .db statements into the nametables would be this simple loop,
Code:
.db $a bunch of numbers
Loop:
  LDA $db address,X
  STA $2007
  INX
  CPX EndPoint
  BNE Loop

That would mean that you could have larger levels with less space. Maybe they thought that zero-page RAM was more important? Of course, I don't often find myself needing to copy large amounts of the same data to RAM.


Top
 Profile  
 
PostPosted: Thu Jun 15, 2017 10:52 am 
Offline

Joined: Sat Apr 25, 2015 1:47 pm
Posts: 337
Location: FL
ROM is at the end of the memory map because the processor requires the interrupt vectors to be at $FFF8-FFFF and the stack to be at $0100-01FF. It wasn't really Nintendo's decision.


Top
 Profile  
 
PostPosted: Thu Jun 15, 2017 11:02 am 
Offline

Joined: Mon Jan 30, 2017 5:20 pm
Posts: 303
Location: Colorado USA
then what purpose do .db statements provide? I mean I guess if you want to load registers with constant values from the ROM and have names for the numbers without using zeropage, but if you ask me, it just uses an extra byte in the ROM for the other half of the address. Another situation where having the NES run off of a z80 would've been useful.


Top
 Profile  
 
PostPosted: Thu Jun 15, 2017 11:06 am 
Offline

Joined: Sun Mar 27, 2011 10:49 am
Posts: 219
Location: NYC
Zero page RAM is definitely more useful than zero page ROM.

I mean, on the 6502 you're limited to 256 bytes in zero page. Even in your example, that's not enough to store a single nametable, even if that's all you used zero page for! You'd lose almost all of the use of the fastest memory and instructions on the system for the sake of one copy loop for a quarter of a nametable. And most programs need to do a whole lot more than that. Aside from hardcoded values (which would have to somehow overlap with the quarter of your nametable) you wouldn't be able to use the indirect indexed addressing modes at all.

And any data that you might want in your ROM zero page you could always...just copy to a RAM zero page initially, instead? There's a one-time cost there, I s'pose, but the cases where you'd want this and that'd be a problem are vanishingly small and can't hope to compete to all the cases where you'd want RAM zero page.


Top
 Profile  
 
PostPosted: Thu Jun 15, 2017 11:13 am 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5899
Location: Canada
DementedPurple wrote:
(ZP ROM)

That's a truly bizarre idea. The NES could have mapped ROM to the ZP if it wanted, but that would not have been a sane design choice at all.

Most games have a lot more than 256 bytes of data. Even a nametable is 1024 bytes alone. What use is such a small space for storage?

Programs need RAM variables. They're accessed much more frequently than read-only data. The ZP is an optimization for those.

FWIW you can put your sprite buffer in ZP if you want.

DementedPurple wrote:
then what purpose do .db statements provide? I mean I guess if you want to load registers with constant values from the ROM and have names for the numbers without using zeropage, but if you ask me, it just uses an extra byte in the ROM for the other half of the address. Another situation where having the NES run off of a z80 would've been useful.

I don't know what you think .db does, or why you think it's related to the ZP at all. It simply stores a byte in ROM. I can't comprehend what alternative you're comparing it to?

If you have a bunch of bytes in a .db array, you use a loop to iterate through them. That it's a 2-byte address isn't really a problem at all because there's only one LDA in the loop. If it's not an array, if it's a single byte, you would just use the immediate form LDA #byte instead of fetching from a .db elsewhere.


Top
 Profile  
 
PostPosted: Thu Jun 15, 2017 11:30 am 
Offline
User avatar

Joined: Thu Mar 31, 2016 11:15 am
Posts: 221
I suppose it would be nice if the PPU registers were mapped to zeropage.


Top
 Profile  
 
PostPosted: Thu Jun 15, 2017 11:36 am 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5899
Location: Canada
rainwarrior wrote:
That's a truly bizarre idea. The NES could have mapped ROM to the ZP if it wanted, but that would not have been a sane design choice at all.

I should clarify, though, that this opinion on design sanity is limited to just the fixed ZP of the 6502.

The 65816's movable "direct page" would actually be very sensible to temporarily move into ROM in many situations.

pubby wrote:
I suppose it would be nice if the PPU registers were mapped to zeropage.

Yeah, that sounds like a good trade to me.


Top
 Profile  
 
PostPosted: Thu Jun 15, 2017 11:43 am 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10169
Location: Rio de Janeiro - Brazil
If ROM was mapped to ZP, you wouldn't be able to use dynamic pointers, and constant pointers are completely pointless, since you could just as well use absolute addressing. The stack would also be ROM, making it completely useless (except for reading 256 bytes from ROM using PLA). The 6502 was designed to have RAM on the lower part of the address space, there's no way around that.

PPU registers in ZP (as are the TIA registers in the Atari 2600) would be cool! We'd be able to transfer more data during vblank, and raster effects would be slightly easier to time. The writes could even go through to RAM so you could "read back" values written to write-only registers.


Top
 Profile  
 
PostPosted: Thu Jun 15, 2017 12:43 pm 
Offline
User avatar

Joined: Fri May 08, 2015 7:17 pm
Posts: 1869
Location: DIGDUG
Quote:
you can put your sprite buffer in ZP if you want.


I've thought about putting the OAM buffer in the stack. It's not as ridiculous as it sounds, you just need to make sure your stack is nearly empty at the point you push the buffer to the OAM. You might have to shuffle a few bytes around before and after that, and limit your # of sprites to 56. But, it might potentially free up some extra RAM.

Edit. But don't put the sprite buffer in the zero page. That would be dumb.

_________________
nesdoug.com -- blog/tutorial on programming for the NES


Top
 Profile  
 
PostPosted: Thu Jun 15, 2017 1:22 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5899
Location: Canada
dougeff wrote:
But don't put the sprite buffer in the zero page. That would be dumb.

At the cost of tremendous inconvenience you could save up to 256 cycles per frame on the STAs. ;)

Though maybe if the sprite tile X/Y was also each game object's internal X/Y coordinate there's a a lot more access where you can save by operating on the in place. Could be pertinent in a game where everything is a single 8x8 sprite tile?

(It was not a serious suggestion though.)

dougeff wrote:
I've thought about putting the OAM buffer in the stack.

Sort of interesting to think of the stack and OAM buffer as a temporary space that you don't need all the time. If you do your sprites last before waiting on the NMI, seems like that would be somewhat doable. Temporarily shifting out some of the stack before the DMA would be a little fussy, and timing would be strict, but sure it could actually be a good use especially if your RAM budget is really tight.


Top
 Profile  
 
PostPosted: Thu Jun 15, 2017 1:43 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19353
Location: NE Indiana, USA (NTSC)
I think Hot Seat Harry by Memblers puts its display list in zero page, but then a 1K game is simple enough to 1. need it and 2. be able to get away with it.


Top
 Profile  
 
PostPosted: Thu Jun 15, 2017 1:49 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10169
Location: Rio de Janeiro - Brazil
dougeff wrote:
But don't put the sprite buffer in the zero page. That would be dumb.

I think using the stack is way dumber. If you use ZP, at least you can reliably make the Y coordinate >= 239 to hide unused sprites, and use the remaining 3 bytes of each sprite freely. If you use the stack page, however, setting the Y coordinate will be much harder, since normal stack usage will constantly temper with the Y coordinates of unused sprites.

I fail to see why you'd use either for OAM though. Indexed ZP addressing is as slow as absolute indexed addressing, so unless you're using hardcoded OAM positions (which you shouldn't do due to sprite cycling and dynamic objects), there's absolutely no speed improvement. The stack on the other hand is significantly faster to write to, at 3 cycles per byte and free indexing thanks to the stack pointer, but only if you use it sequentially from $ff down, so not particularly useful if you need more advanced sprite cycling.

If you're tight on RAM, you can always get 3 extra bytes (and 4 bits of the Y coordinate, if you need them that badly) for each OAM entry you sacrifice, no matter where the OAM page is. You can also safely use a significant portion of page 1 for other things. I often dedicate only 40 or so bytes to the actual stack.

Again, putting the OAM in page 1 is a terrible idea because the portion that's not used for sprites still need valid Y coordinates >= 239 so you don't end up with garbage sprites on the screen, and guaranteeing those valid Y coordinates is hard with the stack pointer going up and down. Even the 3 bytes pushed when an NMI happens could corrupt one of the Y coordinates. Even if you were able to do it (the NMI wouldn't corrupt the Y coordinate of OAM slot 63 if the stack was completely empty when the NMI fired), I find all the stack manipulation necessary for this to work really off-putting, and for no significant reward.


Top
 Profile  
 
PostPosted: Thu Jun 15, 2017 2:11 pm 
Offline

Joined: Mon Jan 30, 2017 5:20 pm
Posts: 303
Location: Colorado USA
Well, I wouldn't store entire nametables in zero-page, I would instead have smaller pre-determened patterns that would go together to make a level.


Top
 Profile  
 
PostPosted: Thu Jun 15, 2017 2:16 pm 
Offline

Joined: Mon Jan 30, 2017 5:20 pm
Posts: 303
Location: Colorado USA
And who in Nintendo Headquarters thought it was a good idea to have OAM be dynamic RAM? That just makes things a whole lot harder. Of course, I'd imagine there was a reason for not using Static RAM.


Top
 Profile  
 
PostPosted: Thu Jun 15, 2017 2:21 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6535
Location: Seattle
To the contrary, everything should be DRAM.

DRAM is cheaper (edit: cheaper=smaller per bit; in the 2C02 each bit of SRAM is 174% the area of each bit of DRAM), and in the NMOS technology that's used in the NES it's even lower power.

Now, why did Nintendo have a buggy DRAM controller inside the PPU? That's a valid question. But not really different from any of the other "why hardware bug" questions.


Last edited by lidnariq on Thu Jun 15, 2017 2:30 pm, edited 2 times in total.

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

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 11 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:  
cron
Powered by phpBB® Forum Software © phpBB Group