byuu's message board

SoraK05: Assuming, for argument's sake, that you're right about SNES CPU calls being "convertible" to native x86 CPU calls at minimal overhead... HOW DO YOU INTEND TO REPRODUCE VIDEO AND AUDIO FUNCTIONS?
Those subsystems are not part of the 65816, and have no analogue:A Hate Story in any IBM clone ever.



Because it's sixteen pages. Get with the times, man!

He already explained that. In his mind a PC knows how to display pixels in the screen, so these math functions he is talking about can fill a buffer with the correct pixels. In his mind you only need to convert the Snes opcodes to compatible x86 opcodes, and that's it, you are done. Doing that you automatically will generate the video/audio data to send to the video card and audio card, and these cards knows what to do.

In other words, he has zero knowledge about this subject.

Replies like this are enough to entertain me.

What I am referring to for emulation purposes is to take shortcuts where applicable without breaking proportion and doing chunks of steps with some timing mainly for input/output. A buildup of the numbers to send to video/audio will be done with its own coding when appropriate, and the main calculation to reach it is tweaked to suit steps for the x86.

http://fms.komkon.org/EMUL8/HOWTO.html#LABI

This is one example I came up on.
There are steps and things which can be adjusted so that it isn't necessarily 'cycle accurate' but will maintain the same proportional expectation of calculations to result in the same numbers which get collected for sending to output every synced expectation.

I'm referring to matching the math and taking shortcuts for calculating numbers and some other global adjustments to eventually get that data to where it should like monitor/sound.
Bursts can be calculated and timings in place to offer reception to input and then send numbers out with outputting.

Where basic opcodes functions are met, and virtual buffers to accommodate expected data, direct calculations and then timing for input/output including some shortcuts which maintain proportion should still be accurate and be more efficient.
It doesn't require being cycle accurate to get the same math done on the ROM and get the same output numbers for 'efficiency' purposes and for being functional.

The outputting of the calculated data isn't so relevant - it is the concrete function of doing the calculation to result in that data, with some timing for input mainly as long as all the rest is done step-by-step (tweaked).
For archival purposes the steps (and perhaps a data file to relate to hardware layout with images) would be appropriate.

Thanks for all the input, and for higan/contribution.

So now you're describing the Performance core and byuu's SMP/DSP cores for Snes9x. Congratulations, you've re-invented the wheel countless times.

I think we have ourselves some pointy haired boss material.

Shortcuts are not applicable because they DO change the results. That's kind of the problem.


How do you "buildup the numbers"?


And seems entirely unrelated to your premise.
Compiler optimization switches and "don't use C++" is WAY different than what you seem to be proposing. And won't get you a Super Nintendo emulator running on a 486(I believe you said 20 MHz was a realistic goal?).


No, because "cycle accurate" means you get the same results every emulated clock cycle that you would for a real clock cycle on real hardware. If you aren't cycle accurate, you AREN'T getting "the same numbers."
Not to mention cycle-accurate is itself inadequate. higan is subcycle accurate, because it MATTERS for the Super Nintendo.


If you cut corners, you have problems. It's that simple.


And then we can hack up a GUI interface in visual basic to track the IP and geoposition the numbers! I see now!


No, it doesn't require being cycle accurate. It requires you to be BETTER THAN CYCLE ACCURATE.


Stop. Right now. I have to ask a question for clarification.

You DO understand that the SNES' audio and video hardware is not a dumb terminal, right? That EXTENSIVE data-processing occurs in both devices? That the 65816 is not only not the ONLY processor in the system, it's also not even the most important one?
Yes? That merely speeding up emulation of the CPU will do very little for overall emulation performance? Right?

You don't believe that merely speeding up CPU emulation will cause a hundred-fold increase in emulation performance?

Chips? What are these chips you speak of? You need a motherboard file that does the math. Didn't you listen to him the 1000th time he reworded his proposal?

They are delicious treats.

Here's your challenge, people. Accept it or not.

Where is Asspull Mk I?

We don't speak of the Mk.1.

First value on the stack is always corrupted?

What kind of processor would it be without the odd glitch or two?

I don't math well. You might have heard. Anyway, you know damn well what the intent here is.