byuu's message board

To demonstrate an 'emulator' build officially and using official documentation (for the most part accurately) , and it running fine on low spec compared to other emulators without and variations on calculating the game and requiring high spec for 'accuracy'.

It is more accurate than those SEGA collections of MD games for example, retaining appropriate timing for PAL/NTSC for example and video output. Sound is also like the MD, unlike some emulators.

It is a light and 'accurate' emu officially designed than homebrew attempts which can get intensive for 'accuracy', and only one which is officially dedicated on being accurate as a 'virtual console' design.


EDIT:
I do also know that different games used different unicodes for expectations of routines and such, with room for expansion. Nintendo generally favored one, RARE another, and there were variations.
All the games which match the common unicode are the ones in general which can be injected, and few work overall as those specific emulators are generally designed to suit their game settings.

YOU ARE USING THE WORD UNICODE INCORRECTLY. IT IS A NAME, NOT A KIND OF THING.

My point is, if you can do math on the ROM data you can result in the numbers calculated for what the output will be.

You can finetune arithmetic to output just the required output data and forgo system specific things which will not be needed for a PC for example, and the calculation setup / constraints (of the automatic calculator that the console is) and its equations can be determined with mobo/os/sdk info
Like, doing math on the ROM data to get the output numbers/strings using system constraint values for equations.

That math is called lambda calculus and there's this version of it called "every machine language ever", and what people do is write interpreters for some in others and the special ones that provide the hardware abstractions you're asking for are called emulators!

Have fun with your eleven septabit large hard drive for emulating a NES game.

This motherfucker...

Fun fact: the first non-PC game I've seen that used a PC-standard text encoding was Donkey Kong Country. It used ASCII.

The total number of arithmetic equations that can be compiled according to the structure of the mobo as an executable to 'decode' a ROM of expected output strings is eleven septabit?

2^(number of bits required to cover all states) * (number of bits required to cover all states) / 1 exabyte

By far the greatest part of that will be the various RAM areas. WRAM (128KB) + VRAM (64KB) + audio RAM (64KB) = 256KB = 262144 bytes = 2097152 bits.

2^2097152 is already a number with 631306 decimal digits.

You were talking about states, not structure. For states, yes, it would be some absurd unfeasible number like that. For structure, that would be to write a normal emulator. I don't see how hard it is to understand that you are literally describing emulation in a very stupid, abstract way.

I'm seriously thinking this guy is somehow... a bot. Nothing makes sense to me, and I know a lot about SNES since I worked on reverse engineering Satellaview, BS-X and XBAND...

I am used to a computer understanding as not only a collection of 0 and 1 bits which allow for YES/NO type pulses on the PC, but it is in general designed to be like an automated calculator which when fed input can combine the input to do arithmetic, eventually to move data around and prep data like what the video numbers will be.

To me, all the data is strings which is displayed on the monitor, or speaker, and in temporary data - result of arithmetic in a predesigned calculator of numbers.


I'd say VC is the 'ideal' emulator from being written ground up using the official documentation and for its speed/accuracy.
While other emulators aim to do this, it appears it is not as direct as VC for example (which I would not say is 'perfect', but uses appropriate information directly). Some are generally 'bloated' and go through a lot to get output strings which are generally not always right from its calculations, as well as take shortcuts, or end up being very calculation intensive to resemble the exact strings.


I believe if one were to take basic mobo functions (may require documentation or reverse-engineering) and write them for the arithmetic equations they perform when the data is read, one can finetune this process to generally spit out the output strings like video/sound etc using few equations to cover the function of the motherboard in relation to what is done when the data (ROM) is fed.

I'd like to see you post your ramblings from a TI-83.
HAHAHAHAHAHAHAHAHAHAHAAHAHA!

The way I see it, ideas for improving emulation probably only have merit if the person with the idea can implement it himself. So go implement it then show us. If you can't write an emulator then you almost definitely don't know what you're talking about.

I wrote an emulator once. It emulated the Asspull Mk. II, a hypothetical little RISC that I'd come up with in my dad's CS class when he let me teach the rest of the class about masheen code. It had software interrupts to print and read lines of text, but only displayed a single one at a time

The strings used for video and sound and temp done each second as their numbers are directly related to the ROM and the arithmetics the motherboard performs.

With suitable mathematic equations performed on the ROM you will get the identical video,sound,temp numbers each second.