I mentioned the concept of a 'SNES MOTHERBOARD FILE' in a way to be used as an emulator in the past, and was told to be 'this cycle accurate in general is intensive'.
I have been doing research recently into computers in general and efficiency.
From my understanding, each console/design has its own way to generally communicate to video, communicate to audio, communicate to controllers etc based on its design, communicate to memory.
This is what I think.
If one has a device, like a PC, one can generally have optimized code for displaying pixels for video, outputting sound appropriately to sound device, recognizing controller input, managing general memory.
I.e. like a plugin/engine to suit for displaying video, sound, memory, controller.
As computers/consoles handle these differently, what is common is that each have their own version of above.
Were all the above written appropriately, an 'emulator' should in essence simply be relating the output of video using the video engine specific for the platform, and sound engine etc.
I.e. an emulator should in essence be some kind of a 'translator' to relay appropriate video/sound/ram/controller functions directly to the platform specific requirement.
Were there a plugin system for a pc, with optimized code for video, sound, memory and input, an emulator 'plugin' in essence should be able to read a ROM and directly translate the appropriate pixels/sound/memory/input and do some calculations to prepare each data requirement.
I.e, an emulator 'plugin' can be a means to execute a ROM and work in conjunction to the video/sound/memory/input code, and be a standalone means to simply calculation expectations of the ROM and get the data to where it should be.
This, instead of somehow calculating expectations for cycles etc, will in essence be something like a converter between mac / windows in the sense that it is barebone calculating the rom data to feed the appropriate data to video/sound/memory/input and be much more realistic to an application in terms of processing/speed than an emulator doing complete cycles?
If all video/sound/memory/input code was done, an emulator 'plugin' in a sense should simply read a ROM, calculate to prepare expected data to feed input/output and perform?
This should have it perform in reasonable calculation time than being 'cycle accurate'?
The code for video/sound/memory/controller is already 'accurate' to the platform (pc), and the remainder is a translator to simply read a ROM and calculate data to feed those input/outputs that is optimized?
A snes 'plugin' in a sense that reads a rom and prepares the required data to feed video/sound/memory/controller that is optimized already will do this right according to data requirement?
That in essence is the only part necessary for an emulator? A translator to prep data to feed video/sound/memory/controller according to layout of ROM design? Like a ROM calculator to prep the data?
As video is generally an array of pixel data, same for sound in a way, and controller input is some data for recognizing buttons pressed/not, and memory is generally a common principle, each can have its own code.
The 'emulator' part is just to read the ROM and calculate the video array expectation and send it to the appropriate video plugin for outputting video, and sound, memory and input.
It will just be a buffer to calculate the expectations of the ROM layout to feed the appropriate input/outputs the right data.
I.e. a megadrive plugin would read a ROM and all buffer preparation is sent to the appropriate platform code for video/etc.
One can have platform specific plugins (like phone video,sound,memory,input) and the snes/megadrive plugin of calculating ROM and its layout to get appropriate data expectation is a common file?
The console specific code is just to calculate a ROM and prepare buffer for the video/sound/input/memory plugins?
There is no reason to emulate video code for example - the optimized platform code is there as video plugin for pc for example for outputting pixels. The only requirement is to calculate ROM expectation to prepare the direct pixels to output.
Each console doesn't have calculations generally different to a PC - 1+1=2 is the same thing. Each has its own commands/traces for data sending, and while these are different, this process is irrelevant.
A command to calculate data in ram for video/sound buffers is common to PC, where code/traces is different.
Where the code is optimized for the platform, the only requirement is doing a ROM calculation to get the video/sound buffer data and directly get it to the video/sound array.
The requirement is to have a means to calculate the buffer expectations of the ROM and synchronize these data buffers, and the SNES one will do it for a SNES ROM and megadrive do it for MD ROM and so forth from SNES/MD ROM layout only. i.e. calculate the ROM for all video/sound etc buffers, and emu is simply a ROM calculator to prep buffers from its design/way it is packed.
BIOS knows how to execute ROM based on how it is packed, and 'instructions' to prepare the buffers and send to output.
One just requires the 'instructions to prep buffers' only according to ROM layout for console?