2a0x APU "TEST" features.

2a0x APU "TEST" features.
by B00daW on 2012-05-05 (#93359)

Brought to my attention by this post in the Hardware sub-forum, it seems that perhaps specific revisions of at least the 2A03 have extended APU functions by desoldering the 2a0x, bending out pin 30 -- or clipping it at the bottom and then bending it out -- and soldering a switch to it connected to both VCC and GND, and then supplying voltage to the pin. The only apparent downfall is the loss of controller inputs.

Correct me if I'm wrong but within Quietust's recent statements and hardware tests he's posted:

Quietust wrote:

Of very special note are the 4 signals at the very top for readable registers at $4018 (pulse 0 output on D0-D3 and pulse 1 output on D4-D7), $4019 (triangle output on D0-D3, noise output on D4-D7), $401A (DPCM output on D0-D6), and a writable register at $401A (set triangle position to D0-D4, and lock channel outputs using D7); all 4 of these signals have an additional enable which seems to come from the vicinity of pin 30.

So basically, it adds 3 additional APU registers; and perhaps other functions as well?

I have a few questions of curiosity and points of interest to comment upon...

1.) The READ registers could potentially be used for demoscene productions and possibly music visualization. However, are the 7 bits on $401A reading decoded DPCM and raw 7-bit PCM data; or just decoded DPCM?

2.) Why would the triangle channel have a secret 4-bit PCM mode by writing to the first four bits of $401A? Also, how does changing the position of the triangle waveform affect a currently playing frequency? Is a crude volume control possible?

3.) What exactly is the function of bit 7 of $401A if it is intermittently set off and on during a song that is played? Does it turn all channels off and on or does it freeze APU function?

4.) Is there a potential wiring scheme that could enable these functions while maintaining controller input support?

5.) Which revisions of 2a03 support the extended functions? Does the PAL 2a07 contain the same "TEST" feature set?

Some food for thought and experimentation I suppose...

by Drag on 2012-05-05 (#93377)

1) I think the "DPCM Output" "Square Output" etc is literally just the amplitude of the channel, which is being sent to the mixer. The 7 bits for DPCM would likely be whatever the DPCM counter is, and you'd see it incrementing/decrementing by 2 according to the DPCM sample being played.

2) It's not really like they planned a 4-bit PCM mode through the triangle channel, a triangle waveform conveniently cycles through all possible amplitude values, so by setting the position within the waveform, we just happen to be able to use it like a 4-bit PCM mode.

3) This one, I'm not sure. This is basically just the mute button, set this flag, and all sound will stop instantly. However, I don't know if the APU continues to function like normal while muted, but I think it would, just going over the hardware in my head really quickly.

The other points, I don't know. This is all just my speculation. It seems like this pin was literally for debugging the APU while it was in development. Why they left it in on certain models is beyond me.

by B00daW on 2012-05-05 (#93390)

Drag wrote:
1) I think the "DPCM Output" "Square Output" etc is literally just the amplitude of the channel, which is being sent to the mixer. The 7 bits for DPCM would likely be whatever the DPCM counter is, and you'd see it incrementing/decrementing by 2 according to the DPCM sample being played.

I'm basically saying that everything aside from reading $401A is pretty straight-forward. I imagine that it's the decoded DPCM's 7-bit PCM sample position. I was also wondering if $401A would mirror the written values of $4011 when read.

Re: 2a0x APU "TEST" features.
by lidnariq on 2012-05-05 (#93391)

B00daW wrote:
1.) The READ registers could potentially be used for demoscene productions and possibly music visualization. However, are the 7 bits on $401A reading decoded DPCM and raw 7-bit PCM data; or just decoded DPCM?
It is the status of the DPCM channel DAC; it's for a self testing, so it contains the results of both.

Quote:
2.) Why would the triangle channel have a secret 4-bit PCM mode by writing to the first four bits of $401A? Also, how does changing the position of the triangle waveform affect a currently playing frequency? Is a crude volume control possible?
That's an accident; the counter is a 5-bit counter that is folded into a triangle wave. By writing values from 0-15 you take advantage of the fact that the first half of this triangle wave is the identity function.

It surely does not affect the current playing frequency at all, and just results in immediately changing the position of the sample. So it'll pop and there will be no other discernible effect.

So much timed code would be necessary to achieve anything resembling volume control that the answer is effectively no.

#s 3 and #4 would be best solved by playing with Quietust's Visual 2A03, but I don't really feel like sitting down and setting up a test right now.

Quote:
5.) Which revisions of 2a03 support the extended functions? Does the PAL 2a07 contain the same "TEST" feature set?
I remember someone asserting that pin 30 on the previous revision F (without the 93-sample-cycle noise mode) does not function in this way at all and it does something else. Unfortunately, I have no idea where I read that or how to search for it.

by nitro2k01 on 2012-05-09 (#93584)

Just a crazy idea how the increased triangle control could be used: You could use it for what I would call "sparse sample playback". The new resgister would allow you to control the phase position, as well the frequency (as usual). The way this could to your advantage is by successively approximating a waveform with writes at irregular intervals. Think of it as approximating the waveform with straight line segments, where every line is given a start amplitude (phase position) and a direction (highest bit of phase position and frequency register.)

The benefit might be reduced CPU usage, although the scheduling would be a nightmare, I imagine. I don't think this idea is practical, but I thought I'd put it out there rather than letting it rot in the back of my brain.

by B00daW on 2012-05-09 (#93597)

Hrm... Very cool. I guess you could also do an easy trick with the triangle channel by reading $4019 and whenever it returns $F you restart its phase to make a saw wave. Code should be pretty cheap. You could probably do the same thing with the pulse channels to make some VRC6 or SID-ish pulses.

I wonder what kind of values the noise channel emits. Reading it could also be a nice random number generator.

by tepples on 2012-05-10 (#93608)

The noise channel probably emits nonzero when the LFSR output is in one state and zero when the output is in the other state. Only one bit at a time is available, and it isn't very random because it depends solely on the time since the channel was reset divided by the period divider. This in turn depends on the number of CPU cycles, which is predictable. It'd be easier just to use a subroutine to simulate clocking a 16-bit LFSR eight times, like Greg Cook's CRC16.

by thefox on 2012-05-10 (#93611)

It's nice to know all the hardware details, but honestly speaking, when using some esoteric feature would require hardware modification like in here, I don't see it having any real world applications.

by tepples on 2012-05-10 (#93613)

Especially when this sort of sparse sample playback (or "piecewise linear mode" as I'll call it) can be done on an unmodified NES. Make one-byte samples of value $AA (flat), $00 (decrease), and $FF (increase). Then play individual bytes after each DMC IRQ, writing the starting value of a segment to $4011 and the address of the direction to $4012.

by nitro2k01 on 2012-05-10 (#93616)

tepples: Aha! I never actually looked into how the NES's DPCM worked and I didn't realize that 1) it has controllable frequency 2) it can be loaded with an arbitrary sample. That does indeed invalidate this us for the triangle channel completely. (Not that it was very viable to begin with.)

by B00daW on 2012-05-10 (#93626)

Hardware is hardware and exploration of it can be exciting. I believe most people have performed modifications on their NES here to play imported games; or have even designed their own hardware to work around limitations without modifying the hardware.

I really do apologize for diverting the topic slightly, but when it comes to development or demoscening, many other "scenes" modify or expand the console or computer to add just a bit more RAM or a few more sound channels; sometimes even underclocking the processor.

Getting back on track, it's not even as if we're installing a 20-pin modchip into the damned thing. It is a rather child's play modification. We're also just debating a lot of speculation of this rather undocumented feature set. Also as time has told before there will be people that are interested in finding out how the hardware works, experimenting with it, making PoC demos, and then finally emulating the features.

As this was probably a feature that existed before production Nintendo or Famicom hardware was made, I'm wondering if there are any early prototype cartridges that read or write to any of these registers...

by ccovell on 2012-05-10 (#93652)

I find this totally fascinating, myself. Does anyone know of any PPU back-doors?...

by lidnariq on 2012-05-10 (#93657)

Whenever the half-prepared 2C02 gets delayered, we'll get Visual2C02 and to find out all sorts of magic.

Personally, I'm really curious what the data sent over the EXT bus is.

by thefox on 2012-05-11 (#93666)

lidnariq wrote:
Whenever the half-prepared 2C02 gets delayered, we'll get Visual2C02 and to find out all sorts of magic.

Personally, I'm really curious what the data sent over the EXT bus is.

Somebody on IRC said that the data is the palette index (index in to the palette sets) currently being rendered by the PPU. But since the bus is only 4 bits wide, it's not possible to know if the given index refers to the background or sprite palette.

As an input, the 4 bit value refers to the full 16 color background palette set. In NES the bits are grounded, so the background always uses color #0.

I have not verified this, nor was I given a source for the information so take it with a grain of salt.

by B00daW on 2012-05-16 (#93895)

For fun tonight I decided to load up all the Famicom titles from 1983 and all the test cartridge ROMs that I could find and look for read and write breaks for range $4018 through $401F. I also browsed CaH4e3's site and TCRF to make sure that I wasn't missing any extra debug features of the games.

I didn't get a single bite from my fishing for any of the games and test carts.

This leads me to wonder why any of it was left in the production model... Was Nintendo aware that Ricoh left it in? Did Ricoh design any test software?

by lidnariq on 2012-05-16 (#93907)

It would have been used on a lot check before soldering the 2A03 to the mainboard, so whatever form the test program came in, it was probably not a conventional Famicom cartridge.

Unlike the field test cartridges, where a service tech is paying attention (and can say "oh, the sound works/doesn't"), this TST interface allows the CPU itself to say "yes, everything works".

Revising the mask is a fairly expensive process (in terms of time), and while they could have changed the wire bonder to tie the TST land to ground internally in the chip and left the pin truly NC, that's not really any easier than soldering the pin low.