2A03 - how to get it off the bus?

A HW newbie question. Does the 2A03 address/data lines go into Z state when the Reset line is held? Or, is there an easy way to get it off the bus to allow external hardware to upload something into the RAM, without using a bus switcher?

I'm only speculating, but I doubt they put tri-state buffers on the address lines for the sole purpose of making the address bus High-Z during reset. Visual 6502/2a03 would tell you, or a simple test could be done to see how much current the address lines source/sink current during reset. But I'm guessing the only way to get data on to RAM without hardware modification is to have the 2a03 put it there via bootloader or the likes.

I take it this means that one can snoop internal $40xx accesses.

I have this vague memory that a tristateable address bus may have been something they cut from the 6502 relative to the 6800.
http://en.wikipedia.org/wiki/MOS_Technology_6502
and http://forum.6502.org/viewtopic.php?t=392
seem to agree.

You cannot tristate the buses, only way is to do it externally... It would have been so nice if that one mode pin tristates the bus instead of turning off all the custom hardware...

While the 2A03's reset line is held down, A0-A15 + R/W + M2 are all tristated (as well as the three output signals from $4016 and the $4016/$4017 read enables). The data lines aren't explicitly tristated, but it's fairly likely that they'll be in "read" mode (and thus will effectively be tristated).

That is good info !

I recall that I've heard somewhere that 2A03 can go into tristate while the Reset is held down, but wasn't sure, that's why I'm asking.

I'm asking because I'm trying to think out an alternative way to load code into a SRAM (connected instead of PRG ROM) without using a bootloader ROM like it often done in things like HW NSF players. Using a bootloader ROM is generally fine for a finalized design, but I don't like the idea to debug software by constantly reflashing the ROM to test code during its development, so the idea is to upload code into SRAM with an external MCU, through serial interface or SD card or something.

Welcome to the world of 6502

You still can do that, look at M2, it's a hint.

Another approach is to make the "ROM" writable during development (RAM, flash with write connected) and communicate with the NES program to have it rewrite the ROM after you've tested a new iteration, before you press reset again.

But this still would require to disconnect the ROM/RAM from the console (or separate 2A03-based device) during data uploading somehow, either physically or with mux or something. I guess if I'll just cut power to the 2A03, it won't work?

Edit: Oh, you mean that 2A03 should rewrite the memory by itself. Well, that's almost the same as having boot loader ROM, as the communication program should be first uploaded into the memory somehow.

Cutting power of the chip generally does not work in digital stuff, nor is it healthy for the chip to receive input on any pin without power supply.

The misunderstanding is that the 2A03 can only be powered through its power pins; every I/O line is a potential backdoor route to powering the chip if you aren't powering it through its power pins. Even if you don't damage it, you create unpredictable power on/off cycles as the other pins change states (e.g. if all logical 0, it's unpowered, but it might power on if some are 0 and some are 1). Except in some well-defined situations, you must keep everything in a digital system powered on.

Shiru, the description of what you want sounds much like an EPROM emulator, you might want to look into those (available schematics, used ones, the only new one I know of is the Ostrich 2.0 which is $175 for 512kB). I have an old one that still serves me well when I use it (a Parallax TurboROM from 1993, I bought it over a decade ago, I haven't tried it yet with win7 but it was always fine in XP even though it used the parallel port). The downside of the one I have is that it causes a few sprites to be glitched out because of a bus conflict with sprite DMA. Doesn't seem to affect sprite zero, so it's never a fatal kind of glitch. BTW I heard from someone who used the Ostrich 2.0 on NES and didn't report sprite glitches. BTW if you made your own device, running D0-D7 through 330 ohm resistors (in series) to the NES fix that.

It's just an SRAM, with some buffers on both sides to make it accessible to either the outside world, or to the target device (ROM socket on your NES cart). Usually there is a reset output, you wire that to the NES reset, so it can release the reset after the upload (though I've pretty much never used that, I just hit the reset button myself). Cool thing is that you can use it with anything that has an EPROM socket, though I found that the Atari 2600 didn't like mine very much (output to the TV turned into like 98% noise). The one that I have, and older ones typically are have extra connectors so they can be chained together for emulating multiple ROMs.