Hardware accurate cart storage and emulation

Archived bsnes development news, feature requests and bug reports. Forum is now located at http://board.byuu.org/
Locked
tetsuo55
Regular
Posts: 307
Joined: Sat Mar 04, 2006 3:17 pm

Hardware accurate cart storage and emulation

Post by tetsuo55 »

Trying to get some facts straight here, at first this thread is aimed purely at snes-carts, please forgive for using the mess/mame format but that currenty the most clear to me.

So how does a cartidge work, here is what i think:

Physically: The cart is connected to the cart-port, basically its just a bunch of pins that connect internally to other stuff
Emulated: The emulated console should expect those pins to connect(that would also give us the posibility to start the snes with no game in it, however useless that may be)

Physcially: The cart has a bunch of wires running to several chips, some of them are roms, i think the game roms are behind a memory mapper which redirects any incoming reads. i am not sure if the added chips are behind, infront or parallel to the memory mapper
NOTE! if my idea about the memory mapper is correct(as nintendo devs where free to use any combination of roms for the same data) that means that rom data does not have to be split up to be accurate
Emulated: the emulator would have a cart emulator, the mapper file would explain how the cart needs to be assembled phyisically. (physicaly it would look like an empty pcb when no game is loaded). The same datafile would tell the emulator to add another port, in this case the socket for a SuperFX chip, it would do the same for sram.


If what i just typed is true then:
-The actual current rom images are already hardware-accurate if they are headerless and unhacked.
-a small change to byuu's current pcb file suggestion would be enough to create an accurate datafile for the snes platform.

This would happen as soon as i load a cart:

Code: Select all

Emulator starts up cart-builder
*.pcb file tells cart-builder where to map the rom regions and sram regions
*.pcb file tells cart-builder that another port is availble, and that it should be filled with a special cpu(or whatnot)
Cart-Builder inserts fully built cart into the snes cart-port
Snes emulator Powers on itself and if mapped, any cpu's on the cart
if done correctly this would represent a very accurate emulation of the built in special chips dont u think?
The snes only talks to the pins, the cart does things among itself.

things would be no different for any other hardware, BS-X, Super Game Boy, they would just be more complex to map and open up more ports.
Last edited by tetsuo55 on Wed Jul 30, 2008 9:33 pm, edited 1 time in total.
creaothceann
Seen it all
Posts: 2302
Joined: Mon Jan 03, 2005 5:04 pm
Location: Germany
Contact:

Re: Hardware accurate cart storage and emulation

Post by creaothceann »

tetsuo55 wrote:the rom file itself would explain how the cart needs to be assembled phyisically
Typo? The ROM file should contain only the content of the ROM chips...
vSNES | Delphi 10 BPLs
bsnes launcher with recent files list
tetsuo55
Regular
Posts: 307
Joined: Sat Mar 04, 2006 3:17 pm

Post by tetsuo55 »

Nice catch! i edited my post to correct it
tetsuo55
Regular
Posts: 307
Joined: Sat Mar 04, 2006 3:17 pm

Post by tetsuo55 »

I was thinking about it a little more.

The Container should have everything that the real snes card had inside it.

In that case here is the layout:

Code: Select all

[Container]folder or zip
{
 [Game data]data.bin or software.dat
 [PCB description file]nameofpcb.pcb or xml.xml
 [Sram]Save.srm or 128k.sav
} 
The .pcb file would contain the information about add on special chips
The SRAM chip was inside the cart so should also be inside the container.

One simply places the container in a zip file to take it along, then the savegame automatically comes with it. The empty save file should be pre-formatted correctly like on real hardware and should thus not be a 0byte file made with notepad
Rashidi
Trooper
Posts: 515
Joined: Fri Aug 18, 2006 2:45 pm

Post by Rashidi »

tetsuo55 wrote:I was thinking about it a little more.

The Container should have everything that the real snes card had inside it.

In that case here is the layout:

Code: Select all

[Container]folder or zip
{
 [Game data]data.bin or software.dat
 [PCB description file]nameofpcb.pcb or xml.xml
 [Sram]Save.srm or 128k.sav
} 
i think .UNF format on NES Rom-scene already do something like that (except for the .sav part), but ...
henke37
Lurker
Posts: 152
Joined: Tue Apr 10, 2007 4:30 pm
Location: Sweden
Contact:

Post by henke37 »

I say, whatever the format is, it needs to account for the case where some parts are only accessible thought another part. The mario chip being my stock example.
FitzRoy
Veteran
Posts: 861
Joined: Wed Aug 04, 2004 5:43 pm
Location: Sloop

Post by FitzRoy »

Although I'm not sure what this thread has to do with bsnes per se, I'm concerned that you want to restrict SRAM to one area. Are you aware that the coprocessors are still within the emulator despite being on the "cartridge." Are you also aware that the cartridge is still made up of fundamentally separate parts which are soldered together? A rom chip soldered to a pcb is equivalent to a gerbil duct-taped to my face.

If I understood what neviksti said earlier, there is no concern about where the files are stored on the hard drive so long as they are interfacing with each other when loaded. The pcb format will bend reality slightly, but only because a truly representative pcb would not be able to "talk" with the coprocessors or whatever unless they, too, were made external. And I'm pretty sure that's highly impractical since every emulator would essentially have to band together and agree on a universal type and implementation of that code, and the very existence of multiple emulators for the system hardware itself proves how impossible (and undesirable) that is.
tetsuo55
Regular
Posts: 307
Joined: Sat Mar 04, 2006 3:17 pm

Post by tetsuo55 »

your right in thinking the thread might not belong here per-se but, byuu is focused on accurate/documented emulation, and we all know cart storage is part of that.

I'm fully aware of the special chips(co-processors)

The way i see it is:

Emulator emulates all the base snes unit hardware
Additionally in a seperate thread, the snes emulates any special chip when needed

These come toghether through the cart emulator. this emulator is also part of the main emulator.

so 3 process threads in total.

Of these three its only logical that all the processors are emulated/stored in the emulator itself.

To make the cart as accurate as possible the .pcb file needs tell the "cart emulator" where to map the "files" representing the write/read chips and additionally where and how to connect the co-processor
creaothceann
Seen it all
Posts: 2302
Joined: Mon Jan 03, 2005 5:04 pm
Location: Germany
Contact:

Post by creaothceann »

Minor point: No need to talk about threads since they are not suited for SNES emulation.
vSNES | Delphi 10 BPLs
bsnes launcher with recent files list
henke37
Lurker
Posts: 152
Joined: Tue Apr 10, 2007 4:30 pm
Location: Sweden
Contact:

Post by henke37 »

Unless you are a madman and writes your own cooperative threading system. :mrgreen:
Locked