A thought occurred to me, and I wanted to know how feasible it would be.
Because an NES cart is mapped to memory directly, loading a ROM does not take any RAM necessarily.
Is is possible for a very small program, to read the uninitialized RAM and then stream it to the sound channel PCM (with ECC data), which then can be read in through a microphone in and analyzed?
If several different consoles are tested several times, it would be possible to create a heat map to give the appropriate probabilities that a specific byte would be set or unset. This data would allow a realistic initial RAM condition to be generated randomly, and would allow a given initial RAM condition to be evaluated to see if it's possible or likely.
This would probably work for the NES and SNES and would allow movies such as the FF6 rejected movie to be evaluated in a more "fair" manner.
Build a man a fire, warm him for a day,
Set a man on fire, warm him for the rest of his life.
https://wiki.nesdev.com/w/index.php/CPU_ALL#Power_up_state
byuu did read out the SNES WRAM content iirc. There are some patterns that can be observed, but nothing definite. It varies with SNES model, temperature, if the SNES was turned on before (and how long ago) etc.
byuu did read out the SNES WRAM content iirc. There are some patterns that can be observed, but nothing definite. It varies with SNES model, temperature, if the SNES was turned on before (and how long ago) etc.
It's either on the ZSNES board, or an old instance of byuu's forum, or in the old SNES9x forum (unlikely). I'm looking for it but haven't found much yet.
Many games rely on WRAM bytes set to 0x55.
https://wiki.nesdev.com/w/index.php/CPU_ALL#Power_up_state
byuu did read out the SNES WRAM content iirc. There are some patterns that can be observed, but nothing definite. It varies with SNES model, temperature, if the SNES was turned on before (and how long ago) etc.
Right, but the point isn't to get a pattern. It's to get a frequency probability for each bit, from a sample of a few thousand power-ons across several systems, so we can determine the probability of a specific power on state. And also allow emulators to generate a weighted random power-on state (or a single, most probable state) that more accurately represents a typical power on state than straight random fill with a seed, or a pattern fill.
It'd take a lot of boring, time-consuming work, but I have a Computer Engineering senior design project coming up soon, and this might be something that's applicable to that.
Build a man a fire, warm him for a day,
Set a man on fire, warm him for the rest of his life.
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
Probability of each bit is the wrong question.
You need to know the relationship of each bit. Some may be mutually exclusive at the power on state.
Please see: Wiki: Nach/MemoryInit.
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
Probability of each bit is the wrong question.
You need to know the relationship of each bit. Some may be mutually exclusive at the power on state.
Interesting. I'll also look for interbit correlation as well then. The fact that it's more interesting than a simple heatmap means it's more likely that I can convince my advisor that it's a worthwhile problem.
Build a man a fire, warm him for a day,
Set a man on fire, warm him for the rest of his life.
A program for dumping ROM through PCM already exists: TapeDump.
A modifier to make it RAM instead would not be all that hard, though I'm not sure if he's released source. as all source is bundled.
I suggest running your cart-variables that aren't in registers through on-cart RAM.
Don't forget: no interrupts nor subroutine calls until you've dumped stackpage.
A program for dumping ROM through PCM already exists: TapeDump.
A modifier to make it RAM instead would not be all that hard, though I'm not sure if he's released source.
I suggest running your cart-variables that aren't in registers through on-cart RAM.
Don't forget: no interrupts nor subroutine calls until you've dumped stackpage.
Sweet! Thanks for the resource.
Build a man a fire, warm him for a day,
Set a man on fire, warm him for the rest of his life.
