byuu's message board

After reading both threads my theory is that it's a case of wikipedia learning. A whole lot of reading overall abstract theory, with zero practical examples. You digest all that information, and then realize that you have come up with the "new best thing". However, once the real world starts to appear the theory evolves until... Oh, it's exactly what people do now.

I guess it's also a case of everyone having good ideas. It's about being able to implement them. Don't expect other people to do it for you.

Thanks for the input.
While I am learning and studying, I am simply proposing tweaks to perhaps not have an exact 'cycle accurate' emulator and allow for some shortcuts/adjustments/tweaks while still using all the necessary instructions/bios' etc to have an emulator which should function and generally output what it should.

Also, thanks for 'asspull mk.ii'

Implement it, show us you're not full of crap and creampuffs. It's a simple enough little system.

Ok, but you are decades late. All you said are things that people thought decades ago. The state of the art in emulation are decades ahead of what you are saying. Come on, there is companies that works with emulation for decades, so you think that what you are proposing, from a guy that is a newbie, will help someone?

You need to implement a lot of code (for several years) first.....

Considering it is a 20mhz console:
http://zsnes-docs.sourceforge.net/html/readme.htm







This general expectation can be generally gained and with some extra tweaks for output as well as completing some of the missing information for parts above.
The emulator looks just about 'complete' beyond minor additions to some missing parts and some minor timing/step adjustments, running just fine and also very functional in something like MS-DOS with 233Mhz on PII.
Fixing the above to be more complete shouldn't mean jump in speed to be intense.


Something 'accurate' doesn't necessarily mean 'cycle accurate'.

For the SNES it does.

You just opened a new can of worms, mate. Don't ever call ZSNES "accurate" around these parts.

Some portions are calculated accurately with direct assembly code for games to run, as a lot of expected video/sound is - perhaps not temp and behind the scenes steps.
Beyond some behind the scenes timing/step adjustment which can generally be acknowledged without the speed getting intense (and getting other parts to 100% from the closeness to it as is) it shows that it is possible to do the chunk calculation appropriately to suit the required steps and acknowledge input/output timing.
Also letting the output be more pixellated without a filter and applying a similar method for sound can also allow for a more generic output which resembles something more 'accurate'.

The requirement shouldn't necessarily be many ghz.

Your English prose is very irritating. It's like you're condescending to us. This is why you are a troll.
Also, I don't see what new ideas you have brought to the table in all 17 pages.

What surprises me is that noone has called me out on how the Asspull's PULL opcode is another PUSH.

Guys, assembly means accuracy.
Byuu, better start over. Your emulator isn't accurate enough.

> Seta DSP 11 80%

I wonder how they kept a straight face writing that one.

The ST-011 is 48KB of uPD7725(96050) binary code, whereas the DSP-1 is 6KB of uPD7725 code. The DSP-1 HLE was around 250-300KB in C form, and that was with zero timing emulation. The ST-011 HLE was about 10KB of C code, and was only just barely enough to run the first few moves shown by the opening attract sequence.

It was more like 5% of the functionality emulated, and even then to a useless degree (in the sense that understanding the full picture would likely require rewriting all existing code anyway.) It was still an impressive feat the way DreamerNom/Feather/Lancer/z80gaiden cloned the attract sequence through analyzing the N64 version of the game and such, but it wasn't even a tiny portion of the full chess engine. But it sure as hell wasn't anywhere near 80% emulated.