byuu's message board

If you look at a computer designed to brute force a password, like a DES cracker with chips designed for brute force, its layout is to perform an algorithm.
I.e. its components and programming is laid out to resemble a functional calculator to represent an algorithm.

Any computer and its design is a calculator in essence, and one which is preprogrammed.
The CPU, RAM, and all components - the basic computer is a CPU, RAM and some OS information. Some numbers are calculated and based on the preprogrammed math and its input, results on cycles based on the results what to accomplish, letting RAM be a temporary buffer of room to perform calculations.

The SNES where written down as a series of equations will constitute a formula/arithmetic/algorithm.
The hardware is essence a physical functional calculator which performs an algorithm, with components used to have temporary space for this process as well as other components like video/sound output components to output the data.


The ROM is a set of numbers. The SNES is the physical manifestation/calculator of the algorithm.
Inserting the ROM performs step-by-step arithmetic with the assistance of components to 'compute / act as EQUAL', 'buffer for calculation', 'storage of number results', on a basic level.

The SNES has a set algorithm of math which is performed step by step, as any computer is, with the number results programmed by the algorithm/hardware version to send info to buffer, video, etc.

The instructions are a set of numbers which will respond as the numbers to be processed by the predesigned calculator to suit the algorithm of a calculator. The instructions are the numbers which this computer will calculate step-by-step with its preprogrammed steps.


The entire SNES can be laid out in an algorithm (including some buffer which can be assigned for the temp calculations and storage of number results like registers/ram), and where this algorithm is written step by step for its few basic equations which loop, you have a 1:1 math step algorithm which matches the calculator design of the SNES.

The hardware is a physical manifestation of an algorithm to perform step-by-step math on numbers, and the response of numbers fed in the few looping steps is that data can be sent to RAM, to monitor/speaker, reset etc.

The ROM numbers are calculated step-by-step with mathematic equations which result in the output numbers which are sent to video/sound/temp for example. An identical step-by-step algorithm will recreate the identical numbers when a ROM is provided as the numbers for it to calculate, and where the step-by-step algorithm is made according to the SNES hardware and tweaked to suit output as numbers to suit a PC expectation, you have a tweaked emulator.


The hardware, irrespective of cpu design, ram design, paths, registers, sound chips etc are a physical manifestation of an algorithm. The step-by-step math which loops and expects numbers to do its steps is the hardware.


Any computer can be written as an algorithm of math steps which can loop, and are generally not many steps.
The computer is a predesigned calculator based on an algorithm. All numbers which are output are calculated in a step-by-step algorithm of the hardware, and one can get the exact same numbers the snes calculates in its step-by-step math where this is written as a software algorithm purely to do math and get numbers, with shortcuts where appropriate.

The computer is limited by design by virtue of it being a manifestation of an algorithm with physical components to act as the buffer, the equivalent of an 'EQUAL' function, and so on.
The computer in essence is a physical algorithm.


The more direct math is performed on the SNES ROM where applicable with the SNES hardware's algorithm in mind, you have 100% compatibility by design and you skip steps which can be mathematically shortcut (and be appropriate to output for the PC for example)

I believe if one were to take and perform arithmetic, and output numbers when performed on the ROM data the expected output using the ROM data and sdk etc data, what is done when the data by a specific change for the link btw - it demonstrates (to me) that bit level math to the ROM from registers, operations and all, and in temporary data - result of processing/calculation is the ram buffer data in RAM each cycle, with some commands in general besides some minor glitches common to some bugs in emulators with injecting ROMs).
A homebrew emulator can't do a low end game at full speed right.

The virtual console do emulators appear more 1:1 to the ROM itself and can be taken and placed in the steps of the console+machine code transaction?
This should have it perform in reasonable calculation time than being 'cycle accurate'?

The code for video/etc.
One can have output data.

For virtual console, N64 is particularly poor with replacing ROMs as the exact same video data per second is in a way, and controller input is some data for buffers (i.e pixel array) would be with the appropriate constraints, you will get the right data.

I.e. a megadrive plugin would read a ROM and its combination of button options, a 'decoder' with the console than other emulators, it appears it is not as direct as VC for example for outputting pixels. The only requirement for the VC Wii emu, I would not say is 'perfect', but uses appropriate information directly). Some are generally quite easily portable.
The are not too much higher (like 10x times) than 4.19Mhz where all motherboard calculations / arithmetic are done in accordance to the ROM for this part, and minor adjustments for proportion like resolution,bit rate,fps,sync can generally be identical for each game, and all buffer preparation is sent to video/sound/temp as appropriate math.

A formula is a description of how to calculate output data from input data.
Because you cannot write down the behavior of a component as a mathematical equation, you need descriptions like these.
Emulators (like bsnes/higan) already are these descriptions, in a format that the computer can understand.

It doesn't get any better than this, unless you do more hardware research.

Math is numbers AND functions. That ROM you're talking about? It's got plenty of numbers, sure, but it's also got plusses, minuses, and the functions themselves. And it's got instructions that aren't mathematical in nature at all, such as "do nothing for a moment" and "if this number in ram is greater than 3, go do this other function". You're acting as though there's a "formula" that you can just plug the numbers from the ROM into, but since the ROM has functions also, this doesn't make any sense. Even if it could be described as a single formula, that formula would change depending on what data is in the ROM, what coprocessors are on the cartridge, etc.

The nature of a mathematical formula is that if you plug in the same variables, you always get the same output. This is not true of a computer. In computing, the formula itself is different depending on its current state. That's how things like this are possible. It's not just the variables in the formula that are different from frame to frame, but the entire formula can be completely different.

I think you are struggling with the difference between mathematical logic and conditional logic. They're very different beasts; computers run on conditional logic, which cannot be expressed as simply as formulas and numbers the way you describe.

Definitely not. The access time for main RAM scales up with size. Not linearly, since it's laid out two dimensionally (or hypothetically, three dimensionally), but it still increases, and we're talking about sizes that are already far too large to fit in the universe. But even if you had magic RAM that took the same amount of time to access as RAM today that's still dozens of ns to get things started, plus the time needed to retrieve the state itself. higan doesn't really take that many CPU cycles to emulate one master SNES cycle, probably under a few dozen on average on a high end CPU.

When those functions are met by the SNES, it does math using its few mathematical operations to meet the requirement.
At the lowest level those functions are math steps used by the same hardware designed to do the same few operations.

You map the hardware and its math to an algorithm of what the motherboard in essence performs, and any ROM strings will loop/calculate etc appropriately.

I can imagine that where all motherboard calculations / arithmetic are done in their ROM, the calculation setup / constraints (of the automatic calculator that the console BIOS will do it for a pc, with optimized code for video/etc.
One can have its own way to generally spit out the output of video using the video etc data for buffers (i.e pixel array) would be with the video/sound/temp it can be performed which is ultimately calculated and which end up doing math on the ROM and megadrive do it for a pc, with optimized code for video/etc.
One can have its own individual optimized/final equivalent.I mentioned the concept of a 'SNES MOTHERBOARD FILE' in a ROM, and all expected calculations like for video/sound/temp which will go (and be prepped) to the game's source code. It is all that is optimized?

Can you stop trolling.
And I'm grateful.

Can you stop having the reading comprehension of a vegetable?

And I mean actual plant life.

Sora, your posts remind me of the OTON guy trying to explain how his console will automatically create games. It's like trying to describe how a time machine works. You keep layering what you're saying in vague analogies and confusing claims without actually describing a program in a way that makes sense. Since I know you won't be able to do that, could you instead explain what's preventing you from coding this emulator using your techniques?

http://dictionary.reference.com/browse/computer



http://www.webopedia.com/TERM/C/computer.html


http://www.thefreedictionary.com/computer



http://www.oxforddictionaries.com/defin ... h/computer



http://www.techterms.com/definition/computer




It is predesigned to calculate numbers, and based on what it is fed has some options, does math, and its result is 'programmed' by validity of an equation to go to ram/video/sound etc.
It is a predesigned calculator which has some hardcoded calculations and from results of its math decides what to do next and where to send data.

The instructions are numbers fed into this automatic calculator, and where you map the arithmetic of this automatic calculator then each step performed by the numbers it gets fed (rom) will result in the exact numbers calculated which end up for output numbers.

'functions', 'offset jumps', all the 'coding' is a result of combining the hardcoded equations. All computation uses the same hardcoded arithmetic, and assembly can do something like 'function', 'loop' 'pause' etc with its limited equations linked to each other in scheduled steps (part of arrangement of final numbers / compiled instructions).




The SNES console can be written as a formula/algorithm which when calculated on ROM numbers will result in the same calculations and output data strings 1:1.
Any PC can be written as its formula/algorithm.

A DVD player is hardwired/coded to generally decode a data type.
Its algorithm can be written for its math steps 1:1.

And Exo's reasonable request?

I'm not a programmer, and don't necessarily have to be to grasp that each hardware has its own algorithm and the data fed performs steps on the numbers with results moving data.

So far I have determined HLE, LLE, and overall 'emulator' definition according to posts, from a basis that a specifically arranged algorithm/formula in accordance to hardware operations can do math on a ROM to result in the same output strings that is done by the SNES and sent to the TV every fps.

They don't "do math on a ROM" though. I'd be more than willing to explain what -does- happen in simple terms.

You didn't really answer the question. I asked why you why you can't write this emulator, you basically just said "because I can't." The SNES hardware doesn't implement any particular algorithm, and no one understands what you're really trying to say except that it's wrong. I suspect you don't really understand what you're trying to say either, you just hope it'll inspire someone else to come up with something amazing.