Memory map and 2A03 register map

[lidnariq]

Can we be sure this for an IRQ instead of a much less interesting reset?

Looking at the picture of the die, the trace definitely would have gone to the /IRQ polysilicon:

nintendo_rp2a03_mz_mit20x_irq_traces.jpg

The red line on the left is irq_internal (from the frame IRQ and DPCM IRQ); the purple X is where they excised this timer's ability to generate an IRQ. At the bottom left (where the red line ends) is where irq_internal and irq_external are combined.


My best guess is that the 24 bits is because they thought people would use it to make an RTC, by setting it to 1789773 ( = 0x1B4F4D)

I think the bits are out of order, so I'm just going to arbitrarily reverse them. This is the opposite of the sim.

New insights: the bit written to $401F & $08 specifies whether the carry out from each bit in the counter is (Bit) or (Not bit), i.e. count up or count down. (via nodes 34 and 44)
the bits written to $401F & $11 control a 1-of-4 multiplexer (nodes 129, 134, 139, 140, 144) that appear to choose which clock source will be used. The clock sources seem to be a lot bit bizarre. though.

Writing to $401F with $40 high will cause an immediate reload. The value is gradually lost due to dynamic logic (really??)
$401F & $20 seems to hold whether there should be an automatic reload.

This seems to be a bug: the counter can't count when the value in it is nonzero: node 20 = AllBitsLow; inverted to make node 60 = AnyBitsHigh; node 60 pulls node 36 = CountEnabled low.

edit #large:

Code: Select all

 $401F: [ELAC DxxC]
         |||| ||||
         |||+----+-- Clock enable source (??)
         |||  |++--- Something as-yet undetermined
         |||  +----- 1:count up; 0:count down
         ||+-------- 1:automatic reload when counter reaches 0
         |+--------- 1:reload immediately
         +---------- 1:IRQ enabled (counts regardless)

[Myask]

Can we be sure this for an IRQ instead of a much less interesting reset?

Looking at the picture of the die, the trace definitely would have gone to the /IRQ polysilicon:

nintendo_rp2a03_mz_mit20x_irq_traces.jpg

The red line on the left is irq_internal (from the frame IRQ and DPCM IRQ); the purple X is where they excised this timer's ability to generate an IRQ. At the bottom left (where the red line ends) is where irq_internal and irq_external are combined.


My best guess is that the 24 bits is because they thought people would use it to make an RTC, by setting it to 1789773 ( = 0x1B4F4D)

I think the bits are out of order, so I'm just going to arbitrarily reverse them. This is the opposite of the sim.

New insights: the bit written to $401F & $08 specifies whether the carry out from each bit in the counter is (Bit) or (Not bit), i.e. count up or count down. (via nodes 34 and 44)
the bits written to $401F & $11 control a 1-of-4 multiplexer (nodes 129, 134, 139, 140, 144) that appear to choose which clock source will be used. The clock sources seem to be a lot bit bizarre. though.

Writing to $401F with $40 high will cause an immediate reload. The value is gradually lost due to dynamic logic (really??)
$401F & $20 seems to hold whether there should be an automatic reload.

This seems to be a bug: the counter can't count when the value in it is nonzero: node 20 = AllBitsLow; inverted to make node 60 = AnyBitsHigh; node 60 pulls node 36 = CountEnabled low.

edit #large:

Code: Select all

 $401F: [ELAC DxxC]
         |||| ||||
         |||+----+-- Clock enable source (??)
         |||  |++--- Something as-yet undetermined
         |||  +----- 1:count up; 0:count down
         ||+-------- 1:automatic reload when counter reaches 0
         |+--------- 1:reload immediately
         +---------- 1:IRQ enabled (counts regardless)

So pretty much every bit is inverted and backwards from what you're expecting? Fascinating.

[lidnariq]

So pretty much every bit is inverted and backwards from what you're expecting?

Backwards, yes... not inverted. (Well, spatially inverted. Not logically.)

All 24 bits are like this:

mysterycounter.png

(I've erased some of the metal and polysilicon for clarity) They really liked their transmission gates in this era.

It's a synchronous up/down counter. Carry out indicates whether the next more significant bit should toggle on the next φ0. It always flows from top to bottom; at the end of each 8 bits there's a big hook that goes to the next one. Carry out from the last bit doesn't go anywhere (node 307).

——

From left to right, the columns in 2a03dead are: I/O buffers to 2A03-internal data bus; 8 LSBs of counter, 8 middle bits of counter; 8 MSBs of counter; control logic; 8 bits of ... broken prescaler? I guess I can fix that:

The control bits ($11) seem to be:
* $00 = 1/8th prescaler (not ÷16 ??)
* $01 = Count rising edges on JOY2
* $10 = 1/128th prescaler (not ÷256 ??)
* $11 = Count falling edges on JOY2

All of these options are inscrutable:
* Why is there no smaller prescaler option?
* Why would we need to count 2³¹ cycles? That's 20 minutes. It seems Memblers was on to something?
* JOY2 is normally an output controlled by software. But even if it was an input, why would we want to be able to count a choice of rising edges or falling edges?

Requesting a load (either by writing to $401F with $40 set or the automatic reload) also clears the prescaler.

Also, I don't quite trust those exact prescalers; I think they "should" be ÷16 and ÷256 given the number of bits in-between.

——

There's two places in the control logic where things were meant to be readable, but are miswired (there's no "read from $401F" signal and it incorrectly uses the "write to $401F" signal):

Code: Select all

$401F reads: [Exxx xxxI]
              |||| ||||
              |||| |||+-- Interrupt would be requested
              |+++-+++--- special internal-timer open bus value
              +---------- Interrupt is allowed to be requested (i.e. value written to $401F & $80)

(Look at nodes 875 and 916)

Reads from $401F are detected and do acknowledge the interrupt.

——

Oh, speaking of errors, they're incorrectly generating all the "read from $401C/D/E" strobes ... detecting writes instead of reads.

There's a missing polysilicon-metal junction with node 356. It should be connected to node 60, but isn't. (in hardware. Obviously the sim doesn't have it either.)

And the $401F & $06 bits are still inscrutable ... but it appears to be some alternate function for JOY1.

$401F & $04 = directly controls JOY1. When the count becomes 0, it causes both $06 bits to invert.
$401F & $02 = doesn't appear to actually change anything, even though the latched value toggles.

I have no idea what this functionality was intended to be.

[kevtris]

Can we move this to hardware? I didn't even know this thread existed until memblers told me at work yesterday. I tried to find the thread but couldn't because it was here. I had to ask where the thread was to be able to find it. thanx.

[lidnariq]

Maybe split here ... but leave this post behind.

[mkwong98]

So are those two pages getting fixed?

[tepples]

I have added information to those pages, but I fear that my addition may distract and/or confuse novices.

[rainwarrior]

I added a stub article so that there's a central place to put this information on the Wiki, instead of scattering it in fragmented commentary throughout other articles:

http://wiki.nesdev.com/w/index.php/CPU_Test_Mode

I tried to link some of the threads where it's been talked about there, and wrote a very succinct summary for a stub, but I'd appreciate someone who is more knowledgable about it making more of an article out of it.

[Quietust]

Almost 9 years later, some discussion on Discord revealed a few notable errors in the simulator I built:

• Eight lines of poly crossed over powered diffusion in places which should not have formed transistors (visible as nodes 359+424+490+561+625+697+772+845, which now appear to go behind the silicon), causing the nearby depletion pullups to not function properly - presumably, these were of the same nature as the poly lines in the 2A03's barrel shifters (for the sweep units)
• Node 773 was missing a buried contact, so it was being divided into 3 pieces (which only made the above problem worse)
• Another buried contact elsewhere had a transistor on top of it (I forget exactly where - the segdefs+transdefs generator logged a warning about it so I just fixed it)
• Most importantly, the "missing via" to node 356 wasn't actually missing - it was actually a buried contact to a bit of silicon gated to node 60 through clk1 (which I hadn't noticed until now)

I've updated the simulator to incorporate these fixes - maybe parts of it will actually work correctly now.

Edit: turns out this was even more broken than we realized:

• The data bus direction logic was backwards - it got switched to "output" mode (i.e. pushing a value to the CPU) during all writes to $0000-$FFFF, as well as all reads outside of the designated register window
• If this had been hooked up, it would've also broken all of the APU registers because it would've been wired directly into the signal which decodes W$4000-$401F (rather than using a buffered copy of it).
• The register window wouldn't have been at $401C-$401F, but at $4000-$4003 - the address decoder had pulldowns connected to A2+A3+A4 rather than /A2+/A3+/A4
• Furthermore, since the "register enable" signal was derived from W$4000-$401F, it never would've picked up reads at all.