Arisotura wrote:it allows both display modes, iirc you can get the native-size mode by pressing SELECT while booting a DS game, otherwise the default mode is fullscreen.
Good to know, reminds me of this wiki sentence "Like DS gamecards, holding down start+select while starting the dsmode dlplay client will disable stretching the screens." Until now I couldn't make much sense of it, because, in my experience, DS-carts don't stretch themselves... but now, I guess DS-carts-in-3DS-consoles might do so.
8bit carts on GBA did also allow stretching, including toggling that feature on/off during gameplay, but that's probably impossible with DS titles on 3DS because it would also require to toggle the touchscreen calibration points during gameplay (or unless the AIC chip could automatically scale the ADC values).
Arisotura wrote:also, speaking of the touchscreen controller thing
that thing is way interesting. I wonder if there's a way to extract the microcontroller firmware or whatever?
Yes, seeing the touch/microphone hardware changing from "A/D converter" (DS) to "fully-fledged sound studio and built-in A/D converter" (DSi) was quite interesting, if not to say scary.
I don't know if there's a firmware in it, or if it's plain logic. The 4Mbit/s SPI write speed suggests that the data goes directly into hardware registers without software processing (or it's stored in a register array, and changes are later processed by software at slower speed). There are some "slow" events (like soft-reset completion for coefficient ram, and programmed-gain reached flags), maybe that parts are handled by software, or they might be done by dma-memfill and hardware counters.
Arisotura wrote:I wondered about the miniDSP thing, but turns out the instruction set isn't public...
Yeah, getting specs or just a sample binary seems to be difficult. And, it isn't yet confirmed if the DSi/3DS is even having any DSP instruction RAM at all. As far as I remember reading that memory just returns zeroes. Though it might be actually zeroflled upon reset... I don't remember if I have ever tried to write to that memory.
Microphone (tested on DSi) (but 3DS should be very similar)
Rev-engineering that kind of hardware isn't so attractive, the incoming data is just random noise/sound, making it impossible to test if the data is correct. The things that can be tested are timings for Status Flags, IRQs, and DMA, which isn't so much fun to do, either. But I think I've now tested and solved almost all relevant stuff... and then... I can finally remove the chapter about the DSi's Unknown ARM7 Registers in gbatek : )
First of, the flowchart for (un-)muting the microphone (assuming that the Launcher had already initialized other TSC registers for things like PLL timings):
Code: Select all
TSC[0:51h]=80h ;ADC Digital Mic, on
TSC[0:52h]=00h ;ADC Digital Volume Control Fine Adjust, unmute
TSC[1:2Fh]=37h ;MIC PGA=27.5dB (eg. as used by SystemSettings/MicTest)
TSC[0:52h]=80h ;ADC Digital Volume Control Fine Adjust, mute
TSC[0:51h]=00h ;ADC Digital Mic, off
And then, ARM registers are working as...
Code: Select all
4004600h - DSi7 - MIC_CNT - Microphone Control (can be 0000E10Fh)
0-1 Data Format (0=TwiceSame, 1=SimilarAsNormal, 2=Normal, 3=None) (R/W)
2-3 Sampling Rate (0..3=F/1, F/2, F/3, F/4) (R/W)
4-7 Unused (0) (-)
8 FIFO Empty (0=No, 1=Empty) ;0 words (R)
9 FIFO Half-Full (0=No, 1=Half-Full) ;8 or more words (R)
10 FIFO Full (0=No, 1=Full) ;16 words (R)
11 FIFO Overrun (0=No, 1=Overrun/Stopped) ;more than 16 words (R)
12 Clear FIFO (0=No change, 1=Clear) ;works only if bit15 was 0 (W)
13-14 IRQ Enable (0=Off, 1=Same as 3, 2=When Full, 3=When Half-Full)(R/W)
15 Enable (0=Disable, 1=Enable) (R/W)
The Sampling Rate depends on the I2S frequency in SNDEXCNT.Bit13,
I2S=32.73kHz --> F/1=32.73kHz, F/2=16.36kHz, F/3=10.91kHz, F/4=8.18kHz
I2S=47.61kHz --> F/1=47.61kHz, F/2=23.81kHz, F/3=15.87kHz, F/4=11.90kHz
The Sampling Rate becomes zero (no data arriving) when SNDEXCNT.Bit15=0, or
when MIC_CNT.bit0-1=3, or when MIC_CNT.bit15=0, or when Overrun has occurred.
The Sample Data tends to be 0000h or FFFFh if the microphone related
TSC-registers aren't unmuted.
4004604h - DSi7 - MIC_DATA - Microphone Data (R)
0-15 Signed 16bit Data ;\16 words FIFO, aka 32 halfwords
16-31 Signed 16bit Data ;/
MIC_DATA can be read by software, or via NDMA (with startup mode 0Ch and
Blocksize 8 words).
The "TwiceSame" data format converts the incoming mono data to stereo (ie. data bit0-15 and bit16-31 will contain the same value; and, accordingly, the 16-word fifo will get full twice as fast).
The two other data formats are storing separate mono samples in bit0-15 and bit16-31. I don't know yet if the lower/upper halfword contains the first or second sample though, or maybe either one is supported... it could be tested when recording a sine- or sawtooth-wave.
So far, the data seems to be always signed 16bit. But the launcher does also contain some code for handling unsigned data, maybe there is a TSC register that can switch to unsigned mode (and, hmm, TSC[0:1Bh] seems to support non-16bit data, however that would end up on ARM side).
Overrun Caution: If data isn't read fast enough then the Overrun flag will get set, and FIFO updates will be stopped. At that point one can still read the remaining 16 words from the FIFO, but no further words will be added to the FIFO, until clearing the FIFO and Overrun flag via MIC_CNT.bit12 (which requires bit15=0 before setting bit12).
For SNDEXCNT, one new detail is that the Mute flag (whatever that is) it doesn't affect microphone. And, the I2S frequency can be changed only if SNDEXCNT.bit15 is (or was?) 0. The exact two frequencies are supposedly 33.513982MHz divided by either 400h, or 2C0h.
That SNDEXCNT stuff might be different on 3DS... I don't know know if the 3DS has an equivalent to SNDEXCNT at all... maybe one of the "CODEC" registers?
Oh, and, if I remember correctly... I think the microphone could be also routed to the Teaklite processor. That's probably still totally unknown how it works... unless wwylele has already figured out that part?