Does anyone know anything about MDR on the 65816 (or if not, on the 6502?) Anomie has theorized that the Super Nintendo's S-CPU has a memory data register:

https://wiki.superfamicom.org/open-bus

but the decay rates are unknown. I have a Siglent SDS1000X-E oscilloscope to use as a logic analyzer but don't know how to get started figuring the decay rates. I also don't know much about reading pinouts or die shots; has anyone done something like this with MDR before?

https://snes.nesdev.org/wiki/CPU_pinout



high res die shot: https://siliconpr0n.org/map/nintendo/s- ... _ns20x.jpg

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Is there a dynamic register? Or maybe just the capacitance of an undriven bus? Either way, I think the way to measure the day rate is
- write a value
- wait some time
- readback the value

The longer you wait, the more likely the value will have decayed, to below the logic threshold of the receiver.

Most likely, you'll find that 1 values will decay to 0 values, but it could be the other way around, depending on the circuit.

What might not work so well is
- write a value
- wait some time
- readback the value
- wait some more time
- readback the value
because the act of reading could refresh the bus, or disturb it in some way. Always start with a fresh write.

All of the above would be done with a 6502 program - I don't think a logic analyser is needed, if I've understood the setup correctly.

If it's a dynamic register, I think you should expect to see a decay time of the order of milliseconds - maybe 10, maybe 100, maybe more. If it's just bus capacitance then it might be down in the microseconds.

Many years back I was working for a company who were making supecomputers out of Transputers and there was a time when DRAM SIMs were in short supply, so they made their own... Amongst other things, I was writing all their test & diagnostics software, so a rig was made to test the decay characteristics of one particular type of memory module - and I did more or less that. I think they were experimenting with reducing board complexity or maximising performance, so there was no refresh hardware (Although I think the Transputer had it built in, so can't quite recall why we were doing this), so in 'normal' use the Transputer was using its high priority interrupt to refresh the RAM, but we could turn it off...

So start a loop to write a test pattern, wait some time and test it. Repeat with longer wait times to see what the longest time we could reliably wait was. The Transputer had some neat block-move instructions which made memory filling and testing relatively easy and allowed back to back read/write cycles.

I don't recall the overall outcomes of that project, but it was fun to do.

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

I'm not very familiar with the SNES, but I'd guess it's just bus capacitance too. It doesn't make sense (for that era) to add more transistors to deal with something that shouldn't happen in the first place.

A random page (https://www.copetti.org/writings/consoles/super-nintendo/) that Google gave me hypothesises
which doesn't make any sense to me.

Reading from an undriven bus will not in itself cause a crash. If you read soon enough after the bus was last driven, the last value that was on the bus will still be stored in the bus's parasitic capacitance, and you'll get that. If you wait long enough, that stored charge will drain away, and you'll get other values.

What evidence is there for an actual register, that isn't explained by simpler causes?

BTW thanks for the link to the die shot - there's a slippy map which is better for my purposes here
https://siliconpr0n.org/map/nintendo/s- ... y=8847&z=2
(by which I mean an interactive pan and zoom which doesn't push my browser too hard)

It's remarkable to see the whole 65816 core in a corner of the chip - of course we know that's what we'd see, but even so.

I think what you all are talking about is on the right track. If there is a way to measure the MDR decay rates from software without opening up the SNES case I should probably go with that instead. I don't want poke around inside hardware, not knowing what I'm doing and break vintage stuff But from what I hear it's pretty hard to break an oscilloscope. I could distribute a test ROM; that would make it very easy for other people to repeat the experiment.

As for evidence that there is an actual register John, creaothceann has pointed me to some here: https://forums.nesdev.org/viewtopic.php?t=23908

The Input Data Latch is loaded on every read cycle (probably every cycle, whether it's a read or not). The value in it never gets a chance to decay unless you've slowed the clock. If you've slowed the clock to the point where the value in this latch decays, nothing is going to work, because it gets used for almost everything.

It sounds like you're talking about the mechanism by which a read from an unmapped address will tend to return the same value as the last valid read on the same bus. You've assumed that because the value stays the same, there must be a register to hold it.
But that's not necessary. It will happen naturally through the capacitance on the bus, with no explicit register needed. If there is one, it won't be in the 65816 part of the chip - the CPU doesn't know the memory map, so it can't behave differently for mapped or unmapped addresses. It just puts out addresses and reads whatever data comes in on its data bus, regardless of how it got there.

Still, register or not, values read from unmapped locations will decay if nothing refreshes them. It is possible to measure the decay rate. And it would be better to measure it through software: any measurement device (oscilloscope, logic analyser, anything) you put on the bus is going to change the load on that signal, which will change the decay rate, which is not what you want. All a software solution has to do is charge the bus by reading a mapped location, then read an unmapped location after a delay. Keep increasing the delay until the value is different (you could use a binary search to reduce the number of iterations needed, if you have a reasonable guess for an upper bound).

I would expect the delay to depend on the temperature of the chip, among many other factors. It would be interesting to measure it shortly after switching the console on, and again after it has been running for a few hours.

(I see John has posted while I was typing. But I'll hit Submit on this anyway, jeffythedragonslayer.)

From the link in your other thread (offsite):I don't believe any 65xx CPU has a register that's involved in both read data and write data. Of course the data bus carries both, but the bus is not a register. The bus's parasitic capacitance can cause it to store data for a limited time, but the data bus is not something you'd properly refer to as a register.

I suspect you've misinterpreted creaothceann regarding the following, oddly worded remark:

It would be clearer and make more sense (and I believe it'd match creaothceann's intent) if that first phrase were reworded as follows: "The 6502 has two separate parts, which, together, do what the rumored MDR supposedly does."

He/she then names the input data latch (which handles input data only) and the data output register (which handles output data only). These registers are -- unlike the mythical MDR -- widely recognized, with no associated controversy or mystery.

In short, I think creaothceann was actually debunking the theory Anomie proposed... and I would add that I, too, find nothing convincing in what Anomie posted at that link.

-- Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html