byuu's message board

Hello
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?


EDIT:
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?

EDIT:
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?

So you mean an emulator would run the game code and pass the generated video & audio data to "plugins" that output it?

We already have it; that's how RetroArch and BizHawk use the bsnes core.

I edited the post:

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?


In essence, it is just a ROM calculator to read the packed ROM data and 'decode' the ROM for the required buffers of video/sound.
It is like a ROM decoder which is specifically targetting the specific ROM layout structure for getting video/sound buffers, and having some input function to progress the data sections.

Basically, a ROM decoder to get the buffers of what the RAM would have, and output these appropriately for the PC/etc based on its plugin.


EDIT:
Emulator 'plugin' - Decode ROM and its layout, with input commands, and its purpose is to calculate what RAM buffer would be for video/audio/ram.

Send that data to video/audio from platform specific plugin.

Nothing for console specific video coding, audio coding, etc - the pc would have its own appropriate plugin based on its architecture. The requirement is to decode the ROM for the expected buffer data in RAM by calculating the ROM data and its layout, with an input to progress the data calculation of ROM.

But not nearly all systems have a BIOS.

Perhaps not dumped, but each system has one.
It has the basic commands to read data, communicate to cpu/ram and to sound/video/input(controller) in general from its design and stacking expectations etc.

Where one can decode a ROM and the way it is packed, one can deduce from arithmetic of the ROM data the expected video/sound/memory data, and have responses to traverse the rom from input. This is the requirement, and the video pixels from the buffer are just sent directly to monitor for example.


It is just to get what is expected in RAM each cycle, with some input to move the data along.
RAM has the video pixels, sound pixels, and other general variable data for score/health etc.

The emulator plugin just needs to decode the ROM to get an expected RAM state each cycle for the ROM layout, and appropriate input to move the data along.

You don't seem to know what a BIOS is.

Consoles had all general commands in it.
Later on systems had their own upgradable OS data which is where this kind of data is stored instead with a BIOS used to basically bootstrap it.

A means to translate/decode a ROM and its data and layout to get a RAM state per cycle is the only requirement?
The RAM data will have video pixels, sound data, and other game specific data.

I'm gonna let someone smarter than me take over explaining why you're wrong.

I'm open.
As far as I understand, a ROM is a collection of bytes which when read by the console BIOS will do appropriate calculations to suit the hardware.
Video pixel data is the same, in general, irrespective of platform as is sound or other temporary game data.
16 bit video pixels is 65536 possibilities for a colour in a grid - the bits would map to any general monitor.

The requirement is a means to read a ROM to get the state of the RAM which has the video pixels, sound data, other data, and just put that data directly to a monitor/speaker for example.
It is the same pixels, and the programming for the means it gets to the console video output is unnecessary - the only requirement is the calculation for the pixels themselves according to the ROM layout, or sound data etc - in short, calculation to get a ram state with that data.

Sorry, Kawa, but I rather drool on your avatar.

The SNES has no BIOS. The first thing it runs is the cartridge ROM on the bare metal. Every routines/commands had to be done from scratch or were used from the SDK that includes them INSIDE the game.

I can pack a ROM of the same game in an alternate layout to suit calculations appropriate to a console, like a SNES/MD ROM.

The video pixels calculated and which end up in the video buffer, and sound, and other game specific memory is the only requirement. That data can be put directly to a monitor/speaker/temp space to be read.

The emulator just requires calculating the ROM and the way it is packed to get that data which would be in the ram buffer of the video pixels, sound data, temp data, and have those strings just used, with input calculated to move the data along?

Specific coding of the cpu archicture/commands, video output coding, etc is irrelevant - just a means to calculate the ROM and its packing to get the video pixel buffer per cycle, sound buffer, temporary memory buffer and the input commands to move the rom calculation along?

Here's what we've considered on IRC:
» A bootstrap program is a small piece of firmware (software-on-a-chip) that prepares a system for use and ultimately jumps to the game code. Examples include the logo scroller on the original GameBoy and the idle loader on the SNES' SPC-700.
» A BIOS or Basic Input/Output System is a set of low-level routines implemented in firmware that provide basic services. Examples include the GBA's support routines like LZ77UnpackVRAM.
» A Gameboy game can reasonably expect the system to be in a predictable state on startup, because the bootstrap has cleared it before launch.
» A SNES game has to initialize everything itself, because there's no bootstrap.
» A SNES game must provide all routines to get things done by itself. There is no built-in data decompression routine like on the GBA, for example.
» All a SNES does is jump directly to the init vector of the game and leave it to it's own devices, while its sound chip idly sits and waits for the signal.
» You are an ill-informed, sad little person and if you persist, you WILL be mocked.

Thank you.

All hardware has commands to load things - if a SNES is just hardwired to accept all startup data from the cartridge, fine.
The SDK will contain the necessary commands to relay data along.

The only requirement for the pc/etc is the video pixel data, sound data, temp data per cycle and is generally the purpose of the emulator - to calculate the ROM and its packing (like a console ROM decoder) to get what the buffer would be with some commands in general to determine what the buffer would be.

The ram buffer for a MD/SNES game of pixels would generally be identical - their determination is calculated differently, and any other calculations/commands to send those pixels to video is irrelevant - the requirement is the ram buffer for the video array of pixels (which would be common) and any other expected buffer strings.

A bare bone decoder to calculate steps required to get to the point of the ram buffer of the data is required, and those strings can be taken and placed in the pc appropriately?
Some basic instruction data suitable to the ROM requirement to get there is where system-specific decoding code is done?

I don't see much of a point beyond some calculations on a rom in accordance to general instructions which can be mapped in a calculator to be used on a ROM to get to the point of what the ram buffer would be with the video/sound/temp etc array/strings.

Sorry but what you say doesn't make any sense whatsoever. Are you using Google Translate?


The SNES CPU (65C816) starts in emulation mode (6502, i.e. like in a NES). It simply reads a 2-byte pointer address from $FFFE (which is mapped to the ROM chip(s) on the cartridge), and program control jumps to that pointer's destination. There are no "commands to load things" - the CPU just reads from memory addresses.


The SDK (a set of books, programs and specialized hardware) is used only for developing games. Finished SNES games might have copied a few lines of code from the manual, if at all.


You can't "calculate a ROM". A ROM is a block of read-only memory. Maybe you mean "execute the opcode stream (instructions) in a ROM".
No idea about "packing".
"console ROM decoder" - A ROM doesn't need to be decoded, unless you mean the CPU interpreting the opcodes.
What buffer?