6502.org Forum Projects Code Documents Tools Forum
It is currently Sun Apr 28, 2024 10:23 pm

View unanswered posts | View active topics


Board index » 6502.org Users Forum » Programming

All times are UTC




Post new topic Reply to topic  Page 1 of 1
  [ 9 posts ] 
  Previous topic | Next topic 
Author Message
ExtendeD
PostPosted: Mon Oct 11, 2004 9:15 am 
Offline

Joined: Sun Sep 26, 2004 11:24 am
Posts: 6
I am currently trying to debug the PPU core of my NES emulator, and using the debug version of fceu, i found something strange about reading VRAM.
I thought that:
LDA #$08
STA $2006
LDA #$81
STA $2006
LDA $2007
would return in register A the byte of VRAM located at adress $881 (as specified by the two writes in register $2006). But I dumped the PPU memory and looked at address $881, and I found out that the byte returned in A with the code above was not the byte I found by hand.
Is there something I forgot (Im sure I didnt make any mistake looking at the byte located at $881 in PPU mem) with reading the PPU with register $2007?
thanks by advance ;)
Top
 Profile  
Reply with quote  
GARTHWILSON
 Post subject:
PostPosted: Mon Oct 11, 2004 2:47 pm 
Offline
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8428
Location: Southern California
Each address holds only 8 bits. You can't store a 16-bit address in one 8-bit location. Do:

Code:
     LDA   #$81   ; Put low byte of address
     STA   $26    ; in 0026
     LDA   #8     ; and high byte of address
     STA   $27    ; in 0027.
     LDA   (26)   ; Read address 881, as pointed
                  ; to by $0026 and 0027.

For an indirect, the pair of bytes that points to the address must be in zero page. Notice also that the low byte goes in the low address of a pair, and the high byte goes in the high address. This allowed the designers to make the processor faster.

Each of the instructions above takes two bytes. The LDA#'s take 2 clocks each, the STA's take 3 clocks each, and the LDA(indirect) takes 5 clocks.
Top
 Profile  
Reply with quote  
8BIT
 Post subject:
PostPosted: Mon Oct 11, 2004 2:47 pm 
Offline
User avatar

Joined: Fri Aug 30, 2002 9:02 pm
Posts: 1681
Location: Sacramento, CA
I have not used the NES before.
Have you tried this?

Code:
LDA #$81
STA $2006
LDA #$08
STA $2006
LDA $2007


Just a thought.

Daryl
Top
 Profile  
Reply with quote  
GARTHWILSON
 Post subject:
PostPosted: Mon Oct 11, 2004 2:58 pm 
Offline
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8428
Location: Southern California
If you're right Daryl, maybe you know something I don't. He used a couple of acronyms I'm not familiar with. I assumed VRAM was video RAM but not separate from the processor's own bus. In all my years of fooling with this stuff, I've never come across the term "PPU" or "fceu". But if this VRAM were some sort of IC that only takes a few addresses in the 6502's memory map but has a load of its own memory internally, I doubt you'd write to the same address for both high byte and low byte.
Top
 Profile  
Reply with quote  
ExtendeD
 Post subject:
PostPosted: Mon Oct 11, 2004 3:00 pm 
Offline

Joined: Sun Sep 26, 2004 11:24 am
Posts: 6
Hi 8BIT,
yes I have tried this code. On the NES when you write at adress $2006, the first write specifies the upper byte of the 16bits adress to access with $2007, and the second write the lower byte.
So:
LDA #$08
STA $2006
LDA #$81
STA $2006
LDA $2007

specifies that the next access to $2007 will read/write at adress $0881 of PPU (LDA $2007 -> reads the PPU adress specified with the two writes to $2006 above ($881), and stores the byte found at this location in A).
the problem is when I debugged a NES game (with a bug-free nes emulator/debuger), I found out that the byte stored in A after this piece of code wasen't the one I found at address $881 when I dumped the PPU memory at this moment.
(anyway I think you should have already programmed on the NES to answer this question :) :))
Top
 Profile  
Reply with quote  
ExtendeD
 Post subject:
PostPosted: Mon Oct 11, 2004 3:03 pm 
Offline

Joined: Sun Sep 26, 2004 11:24 am
Posts: 6
PPU -> Picture Processing Unit, a chip of the NES independed of the CPU, wich treats with display/io.
fceu -> a famous nes emulator/debugger
Top
 Profile  
Reply with quote  
BitWise
 Post subject:
PostPosted: Mon Oct 11, 2004 8:14 pm 
Offline
User avatar

Joined: Tue Mar 02, 2004 8:55 am
Posts: 996
Location: Berkshire, UK
The NESTech document warns that first read after setting the VRAM address returns invalid data.
Code:
  In a real NES, reading/writing VRAM should only be attempted during
VBlank. Many smaller ROMs have CHR-RAM for the Pattern Tables. In this
case, you won't be able to write into this memory.

  Writing to VRAM
  ---------------
  1) Write upper address byte into $2006
  2) Write lower address byte into $2006
  3) Write data into $2007. After each write, the address will auto-
     increment by 1, or 32 (if Bit #2 of $2000 is 1).

  Reading from VRAM
  -----------------
  1) Write upper address byte into $2006
  2) Write lower address byte into $2006
  3) Read data from $2007. The first read from $2007 is invalid, and
     therefore should be taken care of before actual data is read.
  4) Read data from $2007. From here on, after each read, the address will
     auto-increment by 1, or 32 (if Bit #2 of $2000 is 1).

I found the full NESTech document here http://patpend.net/technical/nes/nestech.doc.txt

_________________
Andrew Jacobs
6502 & PIC Stuff - http://www.obelisk.me.uk/
Cross-Platform 6502/65C02/65816 Macro Assembler - http://www.obelisk.me.uk/dev65/
Open Source Projects - https://github.com/andrew-jacobs
Top
 Profile  
Reply with quote  
ExtendeD
 Post subject:
PostPosted: Sun Oct 17, 2004 4:32 pm 
Offline

Joined: Sun Sep 26, 2004 11:24 am
Posts: 6
Thanks a lot BitWise, that's exactly what I was looking for :)
Top
 Profile  
Reply with quote  
Memblers
 Post subject:
PostPosted: Tue Oct 19, 2004 4:07 am 
Offline

Joined: Thu Jan 16, 2003 12:55 pm
Posts: 64
Location: Indianapolis
The data on the first read will be invalid because you're reading the (empty) buffer, after that it's fine because the buffer will be pre-loaded. What's strange though, I believe that doesn't happen when you read palette RAM (palette memory is internal to the PPU).

Also with the $2006 being a 2-write register, if it's in an unknown state you can reset it by reading $2002.

More docs on my site: http://nesdev.parodius.com
Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  Page 1 of 1
  [ 9 posts ] 

Board index » 6502.org Users Forum » Programming

All times are UTC


Who is online

Users browsing this forum: No registered users and 32 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
6502.org is an ongoing project by Mike Naberezny and contributors.