byuu's message board

Math
Take 'transistor level steps' and turn them into more direct steps (shortcuts) where applicable to have a stable representation with maintained proportion while being more direct with the calculations to speed this up.

You want to condense paths at the transistor level? You think this will make anything faster?

By the way, these are important questions:
How old are you?
Where are you from?
What language do you speak?

If you don't answer these questions, I will continue to ask them and spam the fuck out of you like you have done us.

I have attempted to propose an algorithm based on hardware movement to be done on a ROM and result in the same output numbers as those sent to video/sound/temp.

I have determined some general strategies used, and to replicate the same output numbers sent to video/sound/temp in a stable, compatible and shortest step approach where applicable.


I'm grateful for the responses, and beyond some mechanical functions, math is part of algorithm which may also contain if/or statements (in general). All functions which do things on the instruction portions of the ROM should be directly translatable and with shortcuts in an algorithm for the same output numbers sent to video/sound/temp and with 'matching compatibility' of the hardware.

SoraK05:
How old are you?
Where are you from?
What language do you speak?

Besides mechanical functions which can be a result of math, steps are mathematical and calculate the ROM data to result in numbers from the input (for video/sound/temp) and can be resembled as an algorithm.
Emulator efficiency to get numbers from a ROM in short steps and maintain compatibility from proportion isn't exactly spam.

I'm from late 80s, lived in a '3rd world country' where piracy is unfortunate, and can speak english.

What is your age?

What is the name of your country?

What is your native language?

EDITED.

Holy shit this thread.

Sora reminds me of physics lectures I went to that started off "Assume a horse running on a racetrack is a block of uniform density sliding along a frictionless surface..."

Which is to say, all the stuff she (or he) says about converting a SNES to an abstract mathematical description is 100% correct, but practically useless.

http://en.wikipedia.org/wiki/Calculator ... _computers



Beyond mechanical functions portrayed in the fashion of loops and other nested information like classes/functions, the result is a sequence of math steps.
The entire hardware can be written as an algorithm, and this can be adjusted to more directly suit the expected numbers which are fed to video/sound/temp.

Doing math with constraints on the ROM data will give the exact numbers, and where doing an entire step-by-step approach will be accurate and its calculations use a lot of steps for translation, shortcuts to skip steps and where things are common on hardware can be done while retaining proportion.


The numbers fed to video/sound/temp are all part of the ROM, and are determined through the steps of the automated (mechanical) calculator setup of the SNES. Math (and mechanical operation instructions) can reproduce the same numbers done on the ROM as an algorithm.
Thanks for the infos.


EDIT:
It accepts a specific range of data to accept from the ROM stream to begin, putting that data through a series of math steps and validations to eventually begin a process of counters and responses to the expected math, as any 'computer device'.
Game data common to platforms will generally have the same output numbers sent to video/sound/temp. The ROM contains all the numbers and in a way suitable to be automatically calculated in its steps to result in the numbers, according to the design of the automated console receiving the numbers.


I will get round to study. Otherwise, thanks for terms.

EDIT:
http://www.answers.com/topic/computer-1



EDIT:
http://simple.wikipedia.org/wiki/Assemb ... chine_Code


Something along the lines of taking the direct machine code data and converting this to x86 expectations will respond in identical math?
Doing some arithmetic and if/or etc where required for an algorithm (and relevant shortcut) to get the numbers on the ROM which go to video/sound/temp should not be very intensive and should have compatibility suitable to console design.
OOT on GC is for the most part accurate and runs.
Also, VC DOL (00000001.app) files are not specific to the game besides N64 which has some specific tweaks. I have done some research, and the only general difference in the DOL for the SNES bootable is a different one of Super Mario RPG.
Otherwise console DOL bootables are the same packaged DOL in general with tweaks for IDs and save sizes etc.

I'll study.

http://simple.wikipedia.org/wiki/Machin ... chine_code


Doesn't look like the console/hardware would do much and the rest is just doing step-by-step parts of the ROM (and internal calculation) which is where the cycles come in for automation and enough speed to have a consistent calculation of numbers for video/sound/temp per second.


Also, btw
http://simple.wikipedia.org/wiki/Instruction_set


http://simple.wikipedia.org/wiki/Logic


The 'logic' of if/or is considered part of 'math', and part of the 'math/algorithm' the hardware of the console would represent
It is a mechanical response however based on a result of a math procedure, however programmable in the 'field' of math.

You are the Gene Ray of the emulation community.

8|

Where can you see lions?

W-what's happening here?

I do not believe we still have people taking this seriously and trying to answer.

From the first post I knew this guy was a troll or a bot.

Seems to be Byuu testing his new language