byuu's message board

Imagine a simple little file, about yay big, contents are this:

This file is mapped onto memory location $0000, in some irrelevant way.

Our hypothetical CPU has a bunch of registers, including the Program Counter. It starts at zero, of course. When the system is started up and execution begins, a theoretically simple process starts:
1. The CPU pulls enough bytes from the location pointed at by the Program Counter to make up a full command.
2. This command causes a bunch of switches in the CPU to trigger, which have a certain effect on the registers and Status Flags.
3. The process repeats from a new, usually higher Program Counter value.

In this case, the CPU pulls an 11, which it interprets as "Load". This in turn pulls another byte, 00, which it interprets as "Load into Register 0". Two more are needed for a full command, so it pulls "00 10". This single number 0x0010 is loaded into R0. The Program Counter is now no longer zero but four. The process repeats. The CPU pulls an A0 from the location pointed at by the PC, which it interprets as "Service Request". The next byte, needed for such a thing, is pulled -- 01 -- and the final command is "Service Request - Write String."

The PC, now six, is stored away and the Write String service routine moves on to the location in R0 -- 0x0010. Actual code (of the same nature as the stuff shown above) behind the service request system does this, and that same code repeatedly reads a character and writes it to the screen until it hits a zero. "HELLO SORA!" The PC is restored from its hiding place, the Stack, and the process repeats.

Another service request is called for -- FF, which causes the system to hang, basically.

This is not math.

A DVD player being described for example.
It receives the disc input, and has its own programming, and has an output area.

It goes through math steps to 'initialize' based on math and validity operations, and then accepts the strings from the disc.
Based on the numbers fed and basic math with validity, it allows reception of more numbers and eventually begins a direct loop of decoding the numbers based on a precalculated decoder setup, sending calculated spurts of numbers according to math steps to the output area (and tv).


The entire process of what a DVD player does can be written 1:1 in math steps and loops etc in the arrangement of an algorithm.


All computers are designed in a step-by-step manner and with mathematical constraints, with hardware complimenting the process of doing basic decided math and other options like output areas for video stream/sound stream etc and input to adjust the math and do an alternate calculation.
The numbers fed can determine by the predetermined math and validity confirmation what to do such as send that number to ram, receive next numbers, and so forth by a functioning system of programmed math steps (algorithm).


All devices have their own calculation purpose and layout suiting a math algorithm arrangement, and other factors to accommodate such as design for heat, other purposes like taking calculated numbers and sending it to a tv, and expectation of steps.
As mentioned, a computer designed to brute force has its arrangement of components to suit an algorithm dedicated to math steps of brute forcing.

The same can apply to a SNES, or computer.
Its step-by-step math can be laid out in steps arranged as an algorithm.


My point is math can be done on a ROM in an algorithm to calculate the numbers that would be 1:1 to the numbers which are video/sound/temp of the game in accordance to hardware layout and its steps.

That'd be a fixed-function device. A DVD player can do exactly ONE thing. A computer can do most anything.

In fact, you didn't read shit of what I just posted, didn't you?

I wrote it, read, and posted

And a computer is designed to receive numbers based in its math calculation ability, like a SNES.

It does steps.
All the assembly steps do perform math and use temporary buffers as a mechanical function.
These can all be represented in an algorithm also accommodating buffer (which can be ram/temp).

Right, and that's what dynamic recompilers take advantage of.

*drops mic*

So I suppose the point beyond all the hype outlined in architecture which compliments heating/more functions is to get the overall math steps for that algorithm (including the buffer accommodated) to suit the step-by-step functions of the console/pc and that can be performed on the ROM stream to result in the same output numbers.

That example that writes "HELLO SORA" may have been hypothetical/illustrative, but it -is- basically how a computer works.

Meanwhile, you're starting to sound more like my Markov bullshit.

I got to dynamic recompiler

To be as accurate as possible is to determine the exact math steps (and buffer accommodated) which the motherboard does so that each ROM loaded will have 100% compatibility since it will perform the steps the motherboard does as an algorithm and not as components crunching.

Would this not be feasible for something like a GameBoy (directly), before some security things began to be introduced?
Observe traces, develop a list of all the math done around for an expected system algorithm?

It's still not math ♫

Emphasis my own


Instructions are not numbers. Instructions are not math. In fact, by separately listing math and logic, some of these definitions make quite clear that math and logic are not the same thing, no matter how many times you try to make the as-yet unsubstantiated claim otherwise. Comparative logic, the type used by computers and the core of their functionality, is based on one single concept:

if, then

The concept of an if-then statement is pure logic, and not at all math. In programming, it has to be done before any math can be done, to determine what math equations to even do.

Until you can figure out how to implement an if-then statement in pure math (hint: it can't be done), you have no meaningful argument.

As a predetermined calculator, it does calculations and then its results can have direct electrical pulses to move the mechanics and transmit pulses (for more steps to be done somewhere else).
Each step can be related to math and a buffer, and the mechanical steps for transmitting bits are accepted using math and validity, for more math.

which it isn't...

No. You are wrong. It's not math, because math still doesn't handle if-then statements.

So I'll repeat myself: Until you can figure out how to implement an if-then statement in pure math, you have no meaningful argument.

'compute' connotes something to do equations of numbers and its results, and is capable of essentially doing math.
All other mechanical automation and distribution of results is further capability based on the computation and results.