It is currently Tue Dec 18, 2018 5:57 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 255 posts ]  Go to page Previous  1 ... 12, 13, 14, 15, 16, 17  Next
Author Message
PostPosted: Sat Dec 01, 2018 11:43 am 
Offline
User avatar

Joined: Tue Mar 22, 2016 8:27 pm
Posts: 167
Location: Minnesota, USA
Noted on the re-entrant IRQ stuff, good to know. I see where OAM DMA could be a problem. Does that take a long time? If so, I suppose that would need to be turned off for the duration of the sound to prevent audible glitches? That seems potentially crippling.

lidnariq wrote:
Quote:
$106,107 = LDA $FC
$108,109,10A = STA $5209 ; Restart or stop Hardware Timer based on $FC value
Still trashing A here.

Yeah I noticed... My bad. :?

tepples wrote:
Might it have been meant for a looping 256-entry wavetable in ROM, where the main program uses the IRQ's rate to control the playback frequency?

Sounds cool, like a Namco-163 channel without amplitude/envelope control? So a lot like the triangle channel but with custom wave shape? That would definitely be a new type of sound. I have not looked into FDS audio for potential similarities. The patent also mentions this interesting note in column 4 line 20:

MMC5 DAC Patent wrote:
The quantized data is not limited to one obtained by quantizing music played by a musical instrument or a human voice and subjecting the same to pulse code modulation (PCM). For example, the quantized data may be one prepared with a programming method by an input device such as a keyboard.

This seems to suggest that either the game itself could be written to change its DAC based on inputs (such as the controller or famicom keyboard) or a wave shape could be programmed into the game, wavetable style.

lidnariq wrote:
I think the only way you could detect completion without using A/X/Y is by detecting underflow from $8000 to $7FFF:
Code:
a: BIT $8000
INC a+1
BNZ cont
DEC a+2
BMI cont
RTI
cont: DEC $5209
LSR $5209
RTI
... and restarting the cycle-timed IRQ is even worse.
Ugly. At 12cy here, and 14cy for PHA / LDA zp / STA $5209 / PLA, it's not worth it unless you specifically want 6.4kHz (just DEC) or 12kHz (DEC and LSR).

You'd also have to structure the PCM as blocks of 256 played forward, blocks backwards. Assuming 6.4kHz and the BIT instruction's operand is in zero page, typical overhead: 18+14cy, worst case 26+14cy. (14cy being unavoidable IRQ+RTI overhead)


Very clever using the DEC $5209, that took me a few minutes to understand that one. In theory, with your same code intact, you could use the DAC interrupt to change a+1 and a+2 to trick it to end arbitrarily when the data has a $00 in it, so you don't always have to end necessarily at $7FFF.

Edit:
Considering PHA/PLA, it looks like you could save 1 cycle by doing STA/LDA into zeropage RAM instead of using the stack.


Top
 Profile  
 
PostPosted: Sat Dec 01, 2018 1:02 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7842
Location: Seattle
Ben Boldt wrote:
In theory, with your same code intact, you could use the DAC interrupt to change a+1 and a+2 to trick it to end arbitrarily when the data has a $00 in it, so you don't always have to end necessarily at $7FFF.
I mean, sure, you could poll $5010 at the end of the handler here. More time in the interrupt means less time

Quote:
Considering PHA/PLA, it looks like you could save 1 cycle by doing STA/LDA into zeropage RAM instead of using the stack.
Yeah, I forgot midway that I was assuming self-modifying code.

Tepples's comment about a wavetable synth suggests to me that maybe the ultra-lightweight version of the IRQ code could be used just like the FIFOs in the GBA / Quietust's DRIPGAME

Ultimately, though, the problem is that you can't do anything else in the memory region from $8000-$BFFF, so those banks are almost completely useless to the programmer. You have to run your entire program out of $C000-$FFFF and whatever you copy into RAM in $6000-$7FFF.


Top
 Profile  
 
PostPosted: Sat Dec 01, 2018 2:21 pm 
Offline
User avatar

Joined: Tue Mar 22, 2016 8:27 pm
Posts: 167
Location: Minnesota, USA
lidnariq wrote:
Ben Boldt wrote:
In theory, with your same code intact, you could use the DAC interrupt to change a+1 and a+2 to trick it to end arbitrarily when the data has a $00 in it, so you don't always have to end necessarily at $7FFF.
I mean, sure, you could poll $5010 at the end of the handler here. More time in the interrupt means less time

Yes, but this would be in the regular IRQ handler and not the DAC update IRQ, so it would be checking it only as often as any other IRQs occur which is much less frequent.

lidnariq wrote:
Quote:
Considering PHA/PLA, it looks like you could save 1 cycle by doing STA/LDA into zeropage RAM instead of using the stack.
Yeah, I forgot midway that I was assuming self-modifying code.

Tepples's comment about a wavetable synth suggests to me that maybe the ultra-lightweight version of the IRQ code could be used just like the FIFOs in the GBA / Quietust's DRIPGAME

Ultimately, though, the problem is that you can't do anything else in the memory region from $8000-$BFFF, so those banks are almost completely useless to the programmer. You have to run your entire program out of $C000-$FFFF and whatever you copy into RAM in $6000-$7FFF.

Yes that is a pretty big problem that the DAC read mode hogs up so much address space. I hadn't thought of that. Changing in and out of read mode within the interrupt doesn't make sense, it is more expensive than actually doing the write manually to the DAC. In fact, if it comes to that, it isn't really much benefit at all versus manual writes to the built-in DAC, nothing really helped anything... It seems that the patent is written emphasizing how this feature makes things more efficient. It doesn't really even mention any gain in sound quality. We must be missing something still. Maybe some testing of DAC read mode range vs. PRG mode is in order.

I am still poking at this source code, I think it could lead us to unexpected places by working through it.
Updated code with suggestions:
Code:
a: (@$FD)
        BIT $8000
        INC a+1
        BNE b
        INC a+2
b       ROR (skip for 11.26kHz, keep for 18.45kHz)
        STX $5209
        LDX $FC ; pull X
        RTI

IRQ_ENTRY:
        STX $FC ; push X
        LDX $5209 ; X is known to be $80 if hardware timer caused interrupt.
        BNE a
        JMP NORMAL_IRQ

NORMAL_IRQ:
        ; Check for DAC IRQ
        ; Normal IRQ stuff
        LDX $FC ; pull X
        RTI


Calculations:
Code:
Number of cycles between timer IRQ and restarting timer without ROR:
a: (@$FD)
        BIT $8000  4
        INC a+1    5
        BNE b      2
        INC a+2    5/256
b       STX $5209  4 ; Timer starts
        LDX $FC    3
        RTI        6

IRQ_ENTRY:         7
        STX $FC    3
        LDX $5209  4
        BNE a      2


Total until timer restart = 7+3+4+2+4+5+2+(5/256)+4 = 31.0195 cycles.
Number of cycles per timer IRQ, considering loading with $80(=128) + 31.0195 = 159.0195
1.79MHz / 159.0195 = 11.2565kHz

CPU usage calculation:
Total CPU cycles per second = 1,790,000
Total DAC updates per second = 11,256.5
Total CPU cycles to update DAC = 31.0195+3+6 = 40.0195
Total CPU cycles to update DAC per second = 11,256.5 * 40.0195 = 450,479.5
% CPU Usage = 450,479.5 / 1,790,000 = 25.17%

Code:
Number of cycles between timer IRQ and restarting timer [u]with[/u] ROR:
a: (@$FD)
        BIT $8000  4
        INC a+1    5
        BNE b      2
        INC a+2    5/256
b       ROR        2
        STX $5209  4 ; Timer starts
        LDX $FC    3
        RTI        6

IRQ_ENTRY:         7
        STX $FC    3
        LDX $5209  4
        BNE a      2


Total until timer restart = 7+3+4+2+4+5+2+(5/256)+2+4 = 33.0195 cycles.
Number of cycles per timer IRQ, considering loading with $40(=64) + 33.0195 = 97.0195
1.79MHz / 97.0195 = 18.4500kHz

CPU usage calculation:
Total CPU cycles per second = 1,790,000
Total DAC updates per second = 18,450
Total CPU cycles to update DAC = 33.0195+3+6 = 42.0195
Total CPU cycles to update DAC per second = 18,450 * 42.0195 = 775,259.8
% CPU Usage = 775,259.8 / 1,790,000 = 43.31%



Edit:

Using DAC Write Mode, not terribly worse than what we had and doesn't hog address space:
Code:
Number of cycles between timer IRQ and restarting timer [u]with[/u] ROR (faster sample rate):
a: (@$FD)
        ROR        2
        STX $5209  4 ; Timer restarts here
        LDX $8000  4
        STX $5011  4
        INC a+1    5
        BNE b      2
        INC a+2    5/256
b       LDX $FC    3
        RTI        6

IRQ_ENTRY:         7
        STX $FC    3
        LDX $5209  4
        BNE a      2


Total until timer restart = 7+3+4+2 + 2+4 = 22 cycles.
Number of cycles per timer IRQ, considering loading with $40(=64) + 22 = 86
1.79MHz / 86 = 20.8140kHz

CPU usage calculation:
Total CPU cycles per second = 1,790,000
Total DAC updates per second = 20,814
Total CPU cycles to update DAC = 22 + 4+4+5+2+(5/256)+3+6 = 46.0195
Total CPU cycles to update DAC per second = 20,814 * 46.0195 = 957,849.9
% CPU Usage = 957,849.9 / 1,790,000 = 53.51%


Top
 Profile  
 
PostPosted: Sat Dec 01, 2018 4:45 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7842
Location: Seattle
Careful: ROR in isolation modifies A, and you haven't saved A here.

Also, I misunderstood earlier what reads from $5209 contained (I'd misunderstood it to be the current timer value. It isn't...) So INC, DEC, and LSR are the useful instructions to use here because the register should reliably hold $80 if the interrupt is called(right??). Yielding periods of 7+6+(127,129,64) → rates of 12784, 12969, 23244 Hz ... those aren't too shabby.

The bit I had with the label "a" was specifically about modifying the operand to the instruction that reads the data for the DAC.

Managing multiple different sources of IRQs is kind of a pain on the NES, because IRQ flags clear themselves when read. It makes me personally inclined to say that it's not worth it.

If we assume a mixing FIFO, the fastest anything we could manage would be
Code:
 
IRQ:
  INC $5209 ; 6cy, converts 0x80 (IRQ enabled) to 0x81 (period 129+6+7)
addressinginstruction: BIT $8000
  INC addressinginstruction+1
  RTI
but the main mixing code would need to refill it at 103Hz, which is too fast to be useful in a normal 60Hz world.


Top
 Profile  
 
PostPosted: Sat Dec 01, 2018 5:40 pm 
Offline
User avatar

Joined: Tue Mar 22, 2016 8:27 pm
Posts: 167
Location: Minnesota, USA
lidnariq wrote:
Careful: ROR in isolation modifies A, and you haven't saved A here.

Oh crap, nice catch. I shouldn't have switched over to using X I guess.

lidnariq wrote:
Also, I misunderstood earlier what reads from $5209 contained (I'd misunderstood it to be the current timer value. It isn't...) So INC, DEC, and LSR are the useful instructions to use here because the register should reliably hold $80 if the interrupt is called(right??). Yielding periods of 7+6+(127,129,64) → rates of 12784, 12969, 23244 Hz ... those aren't too shabby.

I am a little stuck how to use INC/DEC/LSR on the timer IRQ flag. By doing those instructions, you acknowledge the IRQ and restart the timer with your shifted/dec'd value all in one go, that is super awesome. But I think you have to check the flag first so you can skip the whole timer restart and DAC update if it wasn't set.

lidnariq wrote:
The bit I had with the label "a" was specifically about modifying the operand to the instruction that reads the data for the DAC.

Managing multiple different sources of IRQs is kind of a pain on the NES, because IRQ flags clear themselves when read. It makes me personally inclined to say that it's not worth it.

I can agree with that mentality. For example, I would not entertain the idea of self-writing code like this where I work. I would have the company get a nicer micro and avoid the risk of such a crazy approach. But with this, we get what we get and there might be necessary evils... At least in this case, we might be able to hash out a robust method of handling multiple IRQs and then just sort of forget about it and let it do its thing. Until it comes back to bite us of course! I do get what you are saying.

lidnariq wrote:
If we assume a mixing FIFO, the fastest anything we could manage would be
Code:
 
IRQ:
  INC $5209 ; 6cy, converts 0x80 (IRQ enabled) to 0x81 (period 129+6+7)
addressinginstruction: BIT $8000
  INC addressinginstruction+1
  RTI
but the main mixing code would need to refill it at 103Hz, which is too fast to be useful in a normal 60Hz world.

Per my previous comment, I think that works if the timer is the only IRQ, or if spurious extra DAC updates are acceptable when other IRQs occur. In this case, you would get 1 extra DAC update before it was due, and then you would restart the timer with value $01, which causes 1 additional DAC update almost right away again. I am not sure what this would sound like -- it might be acceptable. We would have to try it and see what it sound like.


Top
 Profile  
 
PostPosted: Sat Dec 01, 2018 6:46 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7842
Location: Seattle
Ben Boldt wrote:
I am a little stuck how to use INC/DEC/LSR on the timer IRQ flag. By doing those instructions, you acknowledge the IRQ and restart the timer with your shifted/dec'd value all in one go, that is super awesome. But I think you have to check the flag first so you can skip the whole timer restart and DAC update if it wasn't set.
lidnariq wrote:
It makes me personally inclined to say that it's not worth [having an interrupt handler that handles multiple IRQ sources at the same time].
I mean, that's all there is to it. You build a robust heavy-weight system that can handle a bunch of different interrupt sources (although, in practice, a "bunch" may be "two" because only MMC5's cycle and scanline IRQs seem to be useful here), or you build something lightweight and don't let yourself use all the features simultaneously.

So if by definition, the only IRQ you're using is the cycle IRQ, you don't need to check on it ... and you also know that a useful value will be there for a RMW instruction.

You may also be able to decide to start off by checking $5204 and leave the desired value in $5209 ... if those specific values were useful.

Quote:
I am not sure what this would sound like -- it might be acceptable. We would have to try it and see what it sound like.
Well, while OAM DMA is going, you lose 513 or 514 cycles regardless, during which the IRQ just doesn't get handled. The only real choice is to accept the audio glitches, or not use sprites.


Top
 Profile  
 
PostPosted: Sat Dec 01, 2018 7:35 pm 
Offline
User avatar

Joined: Tue Mar 22, 2016 8:27 pm
Posts: 167
Location: Minnesota, USA
lidnariq wrote:
Well, while OAM DMA is going, you lose 513 or 514 cycles regardless, during which the IRQ just doesn't get handled. The only real choice is to accept the audio glitches, or not use sprites.

I would say that a 513/514 cycle delay would not be acceptable unfortunately unless you use it to play an explosion sound effect or something that would naturally contain glitches like that. I don't like to admit it but this DAC does seem pretty hopeless.


Top
 Profile  
 
PostPosted: Sat Dec 01, 2018 8:27 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7842
Location: Seattle
A previous thread asking about streaming sound via the 2A03's DAC led me to generate this simulation. Memblers had previously made hardware that did exactly this (streaming sound to the 2A03's DAC using interrupts) and shared some recordings from that system as well.

It's clearly bad, but I'm not convinced it's incontrovertibly bad.


Top
 Profile  
 
PostPosted: Sun Dec 02, 2018 11:44 am 
Offline
User avatar

Joined: Tue Mar 22, 2016 8:27 pm
Posts: 167
Location: Minnesota, USA
So, with what we know about MMC5 versus using the 2A03 DAC, these are the advantages of MMC5:
  • 8-bit DAC instead of 7-bit - slight quality improvement
  • Linear DAC - slight quality improvement
  • DMC can still run at the same time - could be useful, not sure
  • DAC read mode, which has very slight benefits and major drawbacks
  • Invokes unrealistic pipe dreams

And the MMC5 hardware timer IRQ would have equal benefits to either DAC, so that doesn't really count.

I think someone wanted a patent on their resume and didn't really give a crap whether it was useful or not, especially supported by the bogus statements in column 9 lines 3-18. That is my latest theory and it is frustrating.


Top
 Profile  
 
PostPosted: Sun Dec 02, 2018 12:40 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7842
Location: Seattle
I don't think the MMC5's features are about the patent—you'll notice that the JP filing date is months after we know they'd started manufacturing. Something staking out an IP claim for its own sake does that in the other order.

To me, it feels like trying to make lemonade out of a lemon.

I do find myself wondering why they didn't provide the ability to use the MMC5-internal RAM as a FIFO for the DAC, though.


Top
 Profile  
 
PostPosted: Sun Dec 02, 2018 1:32 pm 
Offline
User avatar

Joined: Tue Mar 22, 2016 8:27 pm
Posts: 167
Location: Minnesota, USA
I was thinking of a way to search for more writable registers. I had tried before to measure the current drawn by the MMC5 with my scope while writing to different registers. I did see lots of modifications to the current, especially at transitions, but thinking about it more, I had several errors in the way I connected it. I was using a low-side current sense resistor, meaning I put a resistor in series with GND and read the voltage across it. I had left my ceramics in place on the MMC5 breakout board, so I would not have seen the full spikes at each transition. I am thinking, I need a high-side current sense, all capacitors on the power supply side of the current sense. I can put my scope into AC mode to read from GND to outside the current sense resistor to see how big the current spike is at each transition. I can't read the DC current with a high-side current sense though unless I do something with an op-amp or a low-voltage diff-probe. I was thinking I would try it again with a better setup and check to see if I can find any patterns comparing known registers vs. non-existing registers. Also, alternating between $00 and $FF writes vs. writing the same value repeatedly, if that could be seen in the current. I am sure that there is stuff running and gates and multiplexers, etc, changing no matter where you write. But maybe it draws slightly more current as signals go more places if it is a valid register -- that is a theory that may or may not be true or measurable with my equipment.

I did not have luck last time but I think I should try again with a better setup.


Top
 Profile  
 
PostPosted: Mon Dec 03, 2018 5:41 pm 
Offline
User avatar

Joined: Tue Mar 22, 2016 8:27 pm
Posts: 167
Location: Minnesota, USA
I think it is time to move on from the DAC for a while. Looking at the big picture of the patent, it really focuses on read mode -- that is what they are patenting. They show it in comparison to write mode. I think that it is possible that there could be other ways of using the DAC that didn't pertain to explaining read mode. I don't think all hope is lost, but I also think it is time to move on to different things in the MMC5.

I got my setup running tonight that can look at the change in current drawn by the MMC5. I connected the MMC5 VCC only to a 10-ohm resistor, then on the other side of that resistor, tantalum and ceramic to GND, very close by. I then probed my scope from MMC5 VCC to GND and put it into AC coupled mode. It looks marvelous. I believe that this would be doing a repeated read of address $0000 in the scope shot, that is what my fast dsPIC-based setup does when it is idle now. Will work on expanding this to repeated writes of known registers tonight, in search of level shifts and how steep those oscillations go, hopefully correlating to something that can give us more clues. A good chance this will lead nowhere but you never know!

Attachment:
tek00037.png
tek00037.png [ 26.94 KiB | Viewed 1422 times ]


Edit:
I am sorry to report, but I did not find anything correlating VCC current to valid addresses after spending all night trying different things. The most obvious test was to set a valid address (I chose $5000), CPU R/W = 0, data bus = $00, and toggle M2. Basically write $00 to $5000 repeatedly. Then compare this to address $6000 (invalid). I could find no differences at all in levels or oscillation shapes. Though my scope channel monitoring the current is in AC coupled mode, for the purpose of centering the waveform and letting me vertically zoom way in on it, the AC coupled time coefficient is WAY slower than this horizontal zoom level so I am actually able to measure relative current levels at different states of the test. They were the same as well.

I tried another test setting everything stationary and then just toggling CPU R/W. $5000 vs. $6000. Tried that test with M2 always high and M2 always low. Nothing found.

I tried the first test again, but between each M2 toggle, change invert the data bus, $FF/$00. These tests all made differences, but had identical results comparing $5000 to $6000.

I tried alternating between writing to $5000 and $6000 and other registers. This created varied results because I am toggling different numbers of address bits, so that test did not produce usable results. I guess I am sort of out of ideas now with this experiment, there aren't that many sequences to do these things in and all disturbances to the VCC current have looked absolutely the same to me whether the address is valid or not.

Ideas:
- I only read the current of VCC. I am not sure if there would be another place to probe current, such as CPU R/W. That seems a little doubtful to me.
- The way I probed is as tight as could be and works great. I am using 500MHz bandwidth on the scope. I do not believe that could be improved.
- Maybe toggling M2 way faster than normal (i.e. 100 MHz) to stack up switching losses within the MMC5, making normal operations take more current? Sounds like that could break it or give unreliable results
- Decap the MMC5 :P

Do you guys have any insight or ideas that can coax this thing to reveal itself? Think analog and abnormal modes of operation. Anything I might have done wrong? Could my digital inputs be feeding the VCC, and I am not actually getting all of my current through the resistor where I am looking at it? Looking for brainstorming right now, there are no bad ideas, everything is accepted.

Edit 2:
More poking at it today, I tried setting MMC5 VCC to 5.4V, my logic's VCC to 4.6V to make sure none of my logic ended up higher than the MMC5 VCC to possibly feed it. I turned bandwidth limitation on and off. I tried using my scope's 512 sample average. Since my test is very stable, the average works great to dial in a little more precision, but still no patterns found.

All in all, I have discovered from these tests that my little level shifting FET circuit for each address pin is slow to rise because it does not have a strong enough pull-up resistor. That is useful and will improve my high-speed setup. Progress was made after all.

AND just as I wrote that, sitting here on the couch at home, I remember that these little FET circuits invert, and so all of these tests have been using the wrong addresses. I was taking the 16-bit address, inverting just A15 for /ROMSEL. I should have inverted A0-A14 and NOT inverted A15 for /ROMSEL. Will try again tomorrow. Will create a C macro so as not to make this mistake again.

Edit 3:
#define MACRO_CPU_ADDRESS(X) ((X) ^ 0x7FFF)


Top
 Profile  
 
PostPosted: Tue Dec 04, 2018 9:22 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7842
Location: Seattle
Bunch of random thoughts:

#1 I think the MMC5 is NMOS, so you've got a significant DC bias to extract a signal from
#2 You're talking about measuring the difference in charging current of a small handful of transistors, probably total capacitance on the order of fF. ( For example, the power consumption of a PIC16F84 can be pretty accurately modeled as an 83pF capacitor being charged and discharged repeatedly) Measuring this is going to require a lot more than a 10 ohm resistor.
#3 I'd be worried about losing signal in that 32MHz oscillation your 'scope trace. Ringing makes it hard to see anything else going on, and there's no intrinsic reason the ringing has to be there.


Top
 Profile  
 
PostPosted: Wed Dec 05, 2018 12:36 am 
Offline
User avatar

Joined: Tue Mar 22, 2016 8:27 pm
Posts: 167
Location: Minnesota, USA
lidnariq wrote:
#1 I think the MMC5 is NMOS, so you've got a significant DC bias to extract a signal from

Would you explain this more? The signal I am looking at has 5V of DC bias, but I don't think I understand what you mean by NMOS bias.
Code:
                    n/c: AVcc X         -----------------------------+-- +4.6V
            10 Ohm       _____|______   |   ___________           ___|__
+5.4V --+---/\/\/--O-----|          |   v   |         |-----------|Lin |
        |          ^     |          |-------|         |  3.3V     |Reg.|
  tant ---       Scope   |   MMC5   |-------|  dsPIC  |           |____|
  2.2u ---     AC-couple |          |-------|         |              |
 +0.1u  |          v     |          |-------|         |              |
  GND --+----------O---+-|__________|       |_________|-+------------+-- GND
                       |________________________________|


lidnariq wrote:
#2 You're talking about measuring the difference in charging current of a small handful of transistors, probably total capacitance on the order of fF. ( For example, the power consumption of a PIC16F84 can be pretty accurately modeled as an 83pF capacitor being charged and discharged repeatedly) Measuring this is going to require a lot more than a 10 ohm resistor.

I can definitely experiment changing the resistor to a larger value. I didn't want 5V to dip too far so I chose a small value. The DC current drawn by the MMC5 changes measurably when I change CPU R/W with data bus floating.

lidnariq wrote:
#3 I'd be worried about losing signal in that 32MHz oscillation your 'scope trace. Ringing makes it hard to see anything else going on, and there's no intrinsic reason the ringing has to be there.

Do you think I should add cap across where the scope is connected? I thought I might lose fine details that might occur if I had any cap where I am measuring, that is why I have the ringing there intentionally. I removed a 0.1u ceramic surface mount cap I had put on the bottom side of the breakout board for this very reason. In my testing, I was actually measuring the peak of the ring at full bandwidth for any slight differences. It jumps around very slightly, amazing how stable and repeatable it is. I measured with re-triggering or with averaging to get a statistically good sample size to zero-in exactly on a particular level, which in my tests with all invalid addresses, proved very consistent. :)

I could try adding some cap and increasing my resistor. If the signal is on the order of charging fF (which I do not doubt is the case), adding even 1pF (i.e. my probe itself) would probably destroy it. But what the heck, I will try anyway. The very best we can hope for is clues from this type of test, and that is exactly what I will keep looking for with your suggestions.


Top
 Profile  
 
PostPosted: Wed Dec 05, 2018 1:08 am 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7842
Location: Seattle
Ben Boldt wrote:
Would you explain this more? The signal I am looking at has 5V of DC bias, but I don't think I understand what you mean by NMOS bias.
NMOS draws static power, so there's a constant voltage drop across your current sense resistor. Theoretically this is canceled out by your scope being AC coupled, I guess.

Quote:
I can definitely experiment changing the resistor to a larger value. I didn't want 5V to dip too far so I chose a small value. The DC current drawn by the MMC5 changes measurably when I change CPU R/W with data bus floating.
I'd be inclined to try an inductor. Changes in the current through it theoretically should show up larger that just the voltage change across a current sense resistor. ... of course, it could also break everything.

Quote:
Do you think I should add cap across where the scope is connected?
I think you want to know what's causing it. The power supply should be as firm as possible before you go into the current sense resistor so that you can get a useful measurement. This is really about managing signal-to-noise ratios. Oscilloscopes often only have an 8 bit ADC, so at the analog stage you need to get unwanted signals down to ... well, at least not a lot louder than your wanted signal.

Quote:
I thought I might lose fine details that might occur if I had any cap where I am measuring, that is why I have the ringing there intentionally.
While it's likely that the bypass cap would conceal the fine details ... it's also likely that the ringing is an order of magnitude or more larger than your actual signal. (10Ω, 100mV scale -> 10mA scale? almost guaranteed right now)

By the way, what's static and dynamic MMC5 current consumption? i.e. everything fixed, M2 low, PPU/RD+/WR high ... vs M2 oscillating ... vs PPU A13&/RD oscillating?


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 255 posts ]  Go to page Previous  1 ... 12, 13, 14, 15, 16, 17  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: Google Adsense [Bot] and 3 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:  
Powered by phpBB® Forum Software © phpBB Group