A small article regarding ZSNES

Strictly for discussing ZSNES development and for submitting code. You can also join us on IRC at irc.libera.chat in #zsnes.
Please, no requests here.

Moderator: ZSNES Mods

Dmog
Lurker
Posts: 192
Joined: Tue Aug 31, 2004 6:03 pm

Post by Dmog »

I'm no programmer so I can't contribute to the current discussion. The thread has turned quite technical.

Aside from one lame comment, your post hasn't illicit any flammes afaics.

I just have to say: Excellent article. I wholeheartedly agree with you. As you no doubt know, this issue has been raised in the past. Namely by Matthew Kendora and (a -few-) others. Like I've said before,I've always agreed that the right way to do emulation is to try to virtually recreate the actual hardware as close as you possibly can. That includes original hardware limitations among other things.Well, that includes -everything- that the hardware was..how it behaved, how it did -not- behave.. Basically I believe that emulation should be used as a replacement for the real (commercially dead) console/arcade/computer, as these hardwares are not immortals. Edit: Of course the end goal of emulation will always be about playing the games,but emulating correctly the hardware should always be the mean to achieve this goal.

It seem that most people fall in the "software" category. As long as the games run more or less correctly from a user's pov,everything's fine.

When the emulator fails to recreate an aspect of the original hardware because the coders just don't know any better, that's forgivable. But when the author(s) just doesn't care about accuracy because "it's fine the (inaccurate) way it is"...that's a bit of a shame.

The problem with inaccurate emulation is that it may very well create game bugs that are not apparent to most.(Maybe because no one played the game on the original hardware in the first place) We all know about the really obvious stuff, the emulation bugs that everyone complains about, but what about the subtle stuff? These suble bugs (caused by loose and inexact emulation) will always remains because no one bothered to do things the correct way. So it goes far beyond a pseudo-meta-physical compulsion to recreate every aspect of the hardware just for the sake of it...Ultimately,inaccurate emulation DO affect the games. What you end up with is games that runs -mostly- like they did on the original system. Regrettably, for most people that's good enough.


By the way, it -may- be possible that some games take advantage of this. Think about it like this: When the SNES first powers on, you check $7ffffe, if it's set to #$1337, then you know that the SNES was reset. If it's not, then you know the system was just powered on. Then you store #$1337 at $7ffffe. Now you can display, say, the company logos and all that junk upon powerup. But when you reset, rather than show all that again, you can just jump directly to the title screen. Just a thought...
(Yeah,I realise since this was posted the convertation has moved on but just for sake of putting my own 2 cents in..)

Indeed..it's not just a possibility but a plain old fact. Many games did not reset high-scores and/or options settings upon reset. I posted a thread in the old forum about this issue. I'm glad to see it's been fixed.
Last edited by Dmog on Thu Oct 14, 2004 4:27 pm, edited 1 time in total.
badinsults
"Your thread will be crushed."
Posts: 1236
Joined: Wed Jul 28, 2004 1:49 am
Location: Not in Winnipeg
Contact:

Post by badinsults »

I just read your article. I am not a programmer, but I do agree that eventually any snes emulator should have the options in place to perfectly emulate the snes hardware. However, do not make it an obsession as Matthew Kendora did. He eventually quit programming Snes9x because people would not follow his vision. The reality is, anyone who is programming for the snes should own a copier and test their stuff on the real hardware, as emulators will likely never be truely perfect unless Nintendo gives out their code.
<pagefault> i'd break up with my wife if she said FF8 was awesome
Nach
ZSNES Developer
ZSNES Developer
Posts: 3904
Joined: Tue Jul 27, 2004 10:54 pm
Location: Solar powered park bench
Contact:

Post by Nach »

The exact same checksum the NSRT header uses. You already know how much the checksum is going to offset the checksum by, and that never changes.
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
Dmog
Lurker
Posts: 192
Joined: Tue Aug 31, 2004 6:03 pm

Post by Dmog »

Evan wrote:I just read your article. I am not a programmer, but I do agree that eventually any snes emulator should have the options in place to perfectly emulate the snes hardware. However, do not make it an obsession as Matthew Kendora did. He eventually quit programming Snes9x because people would not follow his vision. The reality is, anyone who is programming for the snes should own a copier and test their stuff on the real hardware, as emulators will likely never be truely perfect unless Nintendo gives out their code.
And we all know how likely the chances of THAT happenning is...

Yeah,that'll happen...In a paralell universe in which earth is ruled by Aliens from the planet Omega37 or something...
Nightcrawler
Romhacking God
Posts: 922
Joined: Wed Jul 28, 2004 11:27 pm
Contact:

Post by Nightcrawler »

I would just like to point out that we should not expect emulator authors to be obligated to fix the emulation. Remember, this is their hobby.

I agree with what's been said here. But pretend you are a developer. You probably wouldn't appreciate people telling you what you should or should not be doing with your emulator and more importantly, your spare time.

Suggesting things is fine, but be careful on how aggressively you speak. A developer has ever right to say his/her emulator good enough and never fix another bug ever. That's their decision.



With that said, I wonder why hacks were implemented in the emulator to begin with. Rather than just sticking in the quick fix, more research should have been done to fix the cause of the problem. Sure, that's a harder job than the quick hack, but that's what should have been done.

Now.. many hacks later, there are countless emulation glitches and bugs. Many of them could have been avoided earlier on by spending more time ironing out problems in their infancy that probably ended up causing many more problems.

Instead, the attitude seemed to be stick in a hack and move on without fixing the problem. Now.. there are MANY problems and it's much harder to fix many problems as compared to ONE at a time as you get to it.
[url=http://transcorp.romhacking.net]TransCorp[/url] - Home of the Dual Orb 2, Cho Mahou Tairyku Wozz, and Emerald Dragon SFC/SNES translations.
[url=http://www.romhacking.net]ROMhacking.net[/url] - The central hub of the ROM hacking community.
Nach
ZSNES Developer
ZSNES Developer
Posts: 3904
Joined: Tue Jul 27, 2004 10:54 pm
Location: Solar powered park bench
Contact:

Post by Nach »

Nightcrawler: do realize that we had >20 hacks removed from ZSNES in the past few months.

Some of the hacks aren't exactly a hack for actual emulation. Some betas have screwed up internal headers, and instead of having a solution like an extra header with proper info, emulators detect the game and ignore the internal header info and do what should be in the internal header instead.
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
Dreamer_Nom
Rookie
Posts: 12
Joined: Sun Sep 05, 2004 1:06 am

Post by Dreamer_Nom »

[quote]Perhaps just the BSX flushes memory to 00's before executing the games?[/quote]

When you wade through the BS-X BIOS and succesfully load a game, it switches the mapping registers and jumps to the reset vector of the game. Memory is not flushed to a preset value at this junction.
byuu

Post by byuu »

Well, BS Zelda expects some of the memory to be 00's. I'm not sure where exactly. What tipped me off was the clock was locked at 85:85 (55 hex), which was the state of RAM upon power on (the game froze immediately after the world map was viewable -- there was no intro attached to this particular ROM). It could have very easily been due to one of the many hacks that have been applied to that poor ROM over time that did this as well. But as MKendora and others have said, some games expect WRAM to be initialized with certain values, and they're not always the same.
BS games have always been screwy though.

Anyway to stress again, the article wasn't about what people should do, it was about what people have done already. And there's nothing wrong with that. _Demo_ explained perfectly why the issue with VRAM is present. Fixing it now would break countless games, and given this emulator focuses on compatibility, that's not an option. I was also suggesting this is a problem for all emulators for all platforms. Hopefully, future emulators won't have the constraints of speed and compatibility, and maybe can emulate the hardware more faithfully.
Dreamer_Nom
Rookie
Posts: 12
Joined: Sun Sep 05, 2004 1:06 am

Post by Dreamer_Nom »

Initialising the $7F:FFE0-FFFF region usually eliminates BS-X time problems. If the game detects that the base unit is installed and receives a clock pulse from St. Giga, then it updates the new time at $7F:FFF9 and $7F:FFFF. But BS-X games were never meant to be loaded directly without first going through the BIOS routine. And then there's games that used SoundLink and the clock on top.
Nightcrawler
Romhacking God
Posts: 922
Joined: Wed Jul 28, 2004 11:27 pm
Contact:

Post by Nightcrawler »

Nach wrote:Nightcrawler: do realize that we had >20 hacks removed from ZSNES in the past few months.

Some of the hacks aren't exactly a hack for actual emulation. Some betas have screwed up internal headers, and instead of having a solution like an extra header with proper info, emulators detect the game and ignore the internal header info and do what should be in the internal header instead.
Yes, I have noticed that. It's MUCH better than it used to be, but it's still got a ways to go. And some of them are so general like disable HDMA to get xxx game to work. That's gonna be a tough one to remove. I think things like that should have been worked out during development rather than now after so much more has been done and added since then.
[url=http://transcorp.romhacking.net]TransCorp[/url] - Home of the Dual Orb 2, Cho Mahou Tairyku Wozz, and Emerald Dragon SFC/SNES translations.
[url=http://www.romhacking.net]ROMhacking.net[/url] - The central hub of the ROM hacking community.
neviksti
Lurker
Posts: 122
Joined: Thu Jul 29, 2004 6:15 am

Post by neviksti »

I would love for the "standard SNES program format" to be more than just the ROM. If you create something decent, people will slowly switch over. Especially if the emulators show a little complaining message before loading up "old formatted" programs. Finally emulators won't require data in the ROM that the real SNES didn't.

However, and I remember the thread where MK brought up these ideas, I strongly disagree with how the memory map is currently setup in the proposed header. One of the purposes is to be able to "fix" games without updating the emulator ... by fixing the memory map. (ie. the emulator=the console and is constant... the new "rom format" = the cartridge. If the map is wrong, fix the 'cartridge', not the emulator)

Therefore, instead of enumerating every single permutation of the memory map (and to make it easier on the developers and emu authors), handle simple stuff like ROM mirroring, SRAM placement, etc in a fairly standard way. For instance, an extension of the game doctor "chunk layouts" which are quite versatile and powerful.

THEN the enumeration is reserved for additions to this (ie one value would mean, also include DSP registers in the normal HiROM DSP locations, another value would mean include the C4 registers in the normal locations, etc). And in extreme cases, the map numbers can specify the entire map like MK originally suggested (for games that are just too out there to work correctly otherwise).

This way the map can be adjusted and corrected.
The other method of enumerating every possible memory map would just be confusing and hard to look up the correct map... and possible the correct mirroring wouldn't even be given a number yet. (Just listing all the different mirroring of the ROM for "normal" games alone would be annoying. And if you leave figuring out the mirroring to the emulator, that defeats the purpose of this header.)

Besides the memory map section, I like a lot of MK's other suggestions for the header.

Nach, would you like to work together on deciding a header specification?
(Since you write ROM tools, and handle this stuff for zsnes, I figure you will be a key player in all this.)

We can then present the result, people will suggest slight fixes, and then implement away!
Nach
ZSNES Developer
ZSNES Developer
Posts: 3904
Joined: Tue Jul 27, 2004 10:54 pm
Location: Solar powered park bench
Contact:

Post by Nach »

neviksti wrote: Nach, would you like to work together on deciding a header specification?
(Since you write ROM tools, and handle this stuff for zsnes, I figure you will be a key player in all this.)
Well, I'm quite bust at being very bogged down at the moment with work, have a lot of semi done stuff in NSRT which needs finishing, and I want to help get the next ZSNES out soon.

But asside that I might not have time to devote my energies to this like it needs, I'd love to work on this.

To start, we'd have to really see which info is required to get this moving, and if it's pracitcal or not.

Just one of the things I noticed in this old doc is that there's a size field for RAM and SRAM on the cart, when the carts either has some SRAM or no SRAM. Seems to be people at some point muddled the difference between SRAM that is battery backed and SRAM that is not battery backed.

Anyways, gripes asside, how should we go about this? Special thread here? Thread on my forum? Argue over IRC?
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
neviksti
Lurker
Posts: 122
Joined: Thu Jul 29, 2004 6:15 am

Post by neviksti »

Well, the emulators handle it differently whether it's SRAM that's battery backed, or just work RAM for a coprocessor or something. The battery backed SRAM is loaded/saved as a file, which makes sense. While the other is just discarded.

I'm not sure, but I believe there are some carts that have RAM and battery backed SRAM as two separate chips. (An FX cart maybe? not sure) It doesn't seem unreasonable to record the size of these separately since they are handled differently.

> ... how should we go about this? Special thread here? Thread on my forum? Argue over IRC?

Hmm... to keep it from becoming a never ending discussion, maybe I should just write something up and start a new thread. I can do that this weekend I believe.

People can offer suggestions, and we'll keep fiddling with it until everyone comes to some kind of concensus. I think this will work unless people can't agree on even the fundementals of the header... which hopefully won't happen. MK's already thought out a bunch, so I'll just start by adding to that. (And if no one likes my additions, we'll just scrap that and go back to his original ideas :) )
Overload
Hazed
Posts: 70
Joined: Sat Sep 18, 2004 12:47 am
Location: Australia
Contact:

Post by Overload »

Nach wrote:Nightcrawler: do realize that we had >20 hacks removed from ZSNES in the past few months.

Some of the hacks aren't exactly a hack for actual emulation. Some betas have screwed up internal headers, and instead of having a solution like an extra header with proper info, emulators detect the game and ignore the internal header info and do what should be in the internal header instead.
I don't mean to boast or anything but my emulator doesn't have any hacks whatsoever (for games that don't require special co-processors). That's why it's probably best for development. 8)
Nach
ZSNES Developer
ZSNES Developer
Posts: 3904
Joined: Tue Jul 27, 2004 10:54 pm
Location: Solar powered park bench
Contact:

Post by Nach »

neviksti wrote: I'm not sure, but I believe there are some carts that have RAM and battery backed SRAM as two separate chips. (An FX cart maybe? not sure) It doesn't seem unreasonable to record the size of these separately since they are handled differently.
Nope. Even have a pic of every single FX cart.

They're not handled differently. Some SRAMs are battery backed some aren't. Some are one size some are another. Some are mapped one way, some a different way. But they're all SRAM and told how to be handled correctly via the other fields.

That reminds me,
byuusan: you're not setting the company right.

Code: Select all

---------------------Internal ROM Info----------------------
       File: reset.smc
       Name: MEMORY DEMO ROM       Company: ? - Code: 89
     Header: None                     Bank: LoROM
Interleaved: No                       SRAM: 64 Kb
       Type: Normal + Batt             ROM: 1 Mb
    Country: Japan                   Video: NTSC
  ROM Speed: 120ns (FastROM)       Version: 1.1
   Checksum: Corrupt, Bad 0x99A5     CRC32: D6D39171
--------------------------Database--------------------------
   ROM wasn't found in the database (possible bad dump).
   You can try using -fix or -findover to see if the
   file has been slightly altered and rectifiable.
Using $33 is the sign to look for the company code in a different location.
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
Nach
ZSNES Developer
ZSNES Developer
Posts: 3904
Joined: Tue Jul 27, 2004 10:54 pm
Location: Solar powered park bench
Contact:

Post by Nach »

Overload wrote: I don't mean to boast or anything but my emulator doesn't have any hacks whatsoever (for games that don't require special co-processors). That's why it's probably best for development. 8)
Go ahead and boast, it's a well deserved boast :D
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
byuu

Post by byuu »

Funny, wasn't aware some games had SRAM that wasn't saved. I always thought the S stood for save.

I was also informed my checksum was bad... it's just a test rom x_x;
I stole the ROM header from another game and modified the fields I knew.
Speaking of which, we should make up a quick 'fake' code to indicate test roms like this. Like a 'don't index this in official ROM sets' code.

By the way, a bit offtopic: Does anyone know of a document that accurately describes interrupts (NMI/IRQ/h/v ones), when they occur precisely, and stuff like how many cycles occur per line on the screen, etc?

The 65816 developer's manual gives cycle counts for each opcode along with conditions, how does memory latency tie into this? e.g. If it always takes 5 cycles to read a 16-bit value, then what would the speed of DRAM for the requested area matter?
Nightcrawler
Romhacking God
Posts: 922
Joined: Wed Jul 28, 2004 11:27 pm
Contact:

Post by Nightcrawler »

Overload wrote:
Nach wrote:Nightcrawler: do realize that we had >20 hacks removed from ZSNES in the past few months.

Some of the hacks aren't exactly a hack for actual emulation. Some betas have screwed up internal headers, and instead of having a solution like an extra header with proper info, emulators detect the game and ignore the internal header info and do what should be in the internal header instead.
I don't mean to boast or anything but my emulator doesn't have any hacks whatsoever (for games that don't require special co-processors). That's why it's probably best for development. 8)
Yes, and I commend you for taking that approach. If you continue to develop the emulator like that, I'm fairly certain you will have one of the most accurate(If you don't already, I haven't thouroughly tested it) emulators around.

On a side note, one nice feature I would love to see in your debugger is the ability to run and/or start tracing once a particular address was read or written. For instance, start tracing when d8:3345 was first read or something to that effect. That's one of the only things I could think of that I'd want to do, that yours doesn't do.
[url=http://transcorp.romhacking.net]TransCorp[/url] - Home of the Dual Orb 2, Cho Mahou Tairyku Wozz, and Emerald Dragon SFC/SNES translations.
[url=http://www.romhacking.net]ROMhacking.net[/url] - The central hub of the ROM hacking community.
Nach
ZSNES Developer
ZSNES Developer
Posts: 3904
Joined: Tue Jul 27, 2004 10:54 pm
Location: Solar powered park bench
Contact:

Post by Nach »

byuusan wrote: Speaking of which, we should make up a quick 'fake' code to indicate test roms like this. Like a 'don't index this in official ROM sets' code.
Why in the world would you need that for?
A real official set wouldn't index something you made up like this.
Other sets created by people which like to index every possible combination of bits in a file don't really care what you have to say.
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
byuu

Post by byuu »

On a side note, one nice feature I would love to see in your debugger is the ability to run and/or start tracing once a particular address was read or written. For instance, start tracing when d8:3345 was first read or something to that effect. That's one of the only things I could think of that I'd want to do, that yours doesn't do.
You mean like this?
Nightcrawler
Romhacking God
Posts: 922
Joined: Wed Jul 28, 2004 11:27 pm
Contact:

Post by Nightcrawler »

Yup! Pretty much like that. :) Is that something you're personally workign on? I'd also like the ability to trace from that point on. Sometimes I prefer trace files to real time.

combine that with the tracing customization abilities of Slueth and you've got neat combo.

breakoints like that makes romhacking MUCH easier. You know the location of compressed data in RAM.. pop it in there and boom you've got the routine that puts it there.

You want to find a font routine, put in the ROM address where the letter is and boom there's your font routine.

You can do this with a FULL trace already, but my computer can't handle working with text files of that magnitude! You can easly generate hundreds of megabytes in seconds.
[url=http://transcorp.romhacking.net]TransCorp[/url] - Home of the Dual Orb 2, Cho Mahou Tairyku Wozz, and Emerald Dragon SFC/SNES translations.
[url=http://www.romhacking.net]ROMhacking.net[/url] - The central hub of the ROM hacking community.
byuu

Post by byuu »

Yes, this is a pet project I started on just last night. I think it's moving along very rapidly. The goals I'm aiming for are to: write better SNES documentation, being as complete as possible; learn more about how the SNES really works to improve my personal SNES code; creat a modular 65816 core that I can use in my old rom hacking tool *; possibly get something to display, promoting my status from ROM hacker to emulator author; and last but most important: to show the world how a debugger is made. Given I have so much experience with reverse-engineering software, I think I can come up with something quite amazing.

But maybe I'll get bored with it and nothing will ever come of it. Wouldn't be the first time that's happened.

Anyway as for the breakpoints: I'm also going to add a type specifier once I get VRAM/CGRAM, etc. implemented. Think of it like this: you know that a weird letter is appearing on your screen of your translation, you don't know where it is put there. Look in the PPU debugger, set the BG that tile is on, click on the mini screen in the debugger to have the exact VRAM address located and its value. Now go back before that tile appears, add a VRAM write breakpoint for that value, and run the game. The same would allow you to locate a decompression routine for any game in about 30 seconds.

As for trace logs from it. Please explain how you'd want that to work. I planned to include a button on the cpu debugger that toggles trace logging on and off, along with a text file for advanced options like append to existing log file, or create new logs for each trace. Do you want something like a trace bit, where whenever a breakpoint is triggered, it toggles the trace status on and off, maybe? I'm also going to add a 'once' flag, which will clear the breakpoint after it's hit for the first time so it doesn't get triggered again.

* - My old rom hacking tool was basically an x816 simulator. The idea was: you find the start of a decompression routine, and the end. Then you write a small C program that defines the starting registers (a, x, y, s, pc...), and a list of breakpoints. Then you call x816_run(), when you hit a breakpoint it stops, then you have access to the SNES memory. You can then dump that memory, modify it, reset the registers, whatever. The idea was basically to use the decompressor already in the ROM, rather than writing your own trying to clone it in C. This idea does work and it's how I did it for several games.
neviksti
Lurker
Posts: 122
Joined: Thu Jul 29, 2004 6:15 am

Post by neviksti »

ahhh :)
It's great to hear the chatter of SNES talk.

Good luck on the project, it sounds awesome. (Let me know if you decide to document the system better ... that would be great to have.)

> Funny, wasn't aware some games had SRAM that wasn't saved. I
> always thought the S stood for save.

The 'S' in SRAM stands for Static RAM (as opposed to DRAM, Dynamic RAM ... or as some like to joke 'Defective' RAM, since it can't really hold memory, which is why it needs that refresh cycle to be useful).

> The 65816 developer's manual gives cycle counts for each opcode
> along with conditions, how does memory latency tie into this? e.g. If it
> always takes 5 cycles to read a 16-bit value, then what would the speed
> of DRAM for the requested area matter?

The SNES has lots of 'interesting' features. In this case, it's that the main SNES CPU core isn't given a constant clock.

Each of those "instruction cycles" can actually go at different speeds depending on what area of memory is being accessed. The memory cycle time for every region of the memory is listed quite nicely in that post on the old snes9x board I gave a link to for Nach.

EDIT: Pasted here again for convenience
http://www.snes9x.com/forum/topic.asp?TOPIC_ID=7832
DataPath
Lurker
Posts: 128
Joined: Wed Jul 28, 2004 1:35 am
Contact:

Post by DataPath »

Neviksti -

I thought that the SNES CPU was clocked off the PHI2 signal, so that while each instruction may take a variable amount of time to complete, the next one wouldn't begin until the next PHI2 signal came.

That said, I'm currently taking the WDC docs and making a table of opcodes and what registers, memory locations, etc. are used and what order they are used in the process of performing the operation.

When I have something worth showing (which should be long before it's done - maybe monday) I'll put it up and someone can tell me if there are mistakes, or if I'm misunderstanding something or being stupid.
neviksti
Lurker
Posts: 122
Joined: Thu Jul 29, 2004 6:15 am

Post by neviksti »

> I thought that the SNES CPU was clocked off the PHI2 signal, so that
> while each instruction may take a variable amount of time to complete,
> the next one wouldn't begin until the next PHI2 signal came.

?? I may be misunderstanding what you are trying to say here.
Yes, different instructions may take a different number of cycles to complete.
Yes, the next cycle (not next instruction) won't occur unless PHI2 cycles (these are the clock cycles they are referring to when denoting the "time" it takes for an instruction to complete).
What byuu was commenting on is the added level of complexity, where the snes cpu clock cycle actually changes depending on what memory ranges it is accessing.

> That said, I'm currently taking the WDC docs and making a table of
> opcodes and what registers, memory locations, etc. are used and what
> order they are used in the process of performing the operation.

I may be misunderstanding again, but isn't that just table 6-7 in the pdf?
Or do you mean something else?
Post Reply