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

DataPath
Lurker
Posts: 128
Joined: Wed Jul 28, 2004 1:35 am
Contact:

Post by DataPath »

> 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.

Ok - that makes sense now - that an instruction takes a variable number of clock cycles to complete. But the length of a clock doesn't change with the instruction, just the number of clock cycles to complete.

Or do you mean to say that the SNES actually slows down the rate at which PHI2 fires depending on the memory range being accessed?

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

I mean collecting the information in those tables into a reference that might look something kind of like

Code: Select all

ADC(d,x) Add Memory to Accumulator with Carry Direct Indexed Indirect
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|1|1|0|0|0|0|1|          d            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

A = A + mem[mem[X + D + d]] + C
Sets status codes N, V, Z, C
The operand address is always in Bank 0.
Takes 6-8 cycles to complete
I suppose it's just the tables in the doc, presented glossary style instead of in tables.
neviksti
Lurker
Posts: 122
Joined: Thu Jul 29, 2004 6:15 am

Post by neviksti »

DataPath wrote:Or do you mean to say that the SNES actually slows down the rate at which PHI2 fires depending on the memory range being accessed?
Yes. That's the idea.
byuu

Post by byuu »

I think I understand the timing now.
So say we use: lda $7e0123, m=1. That's 5 cycles, 30 master cycles. But since you're accessing slow memory, it really takes 32 master cycles.
So then if you have: lda $004000, m=1, it would take 6 cycles, or 36 master cycles? I would suppose by the same hand that lda $004000, m=0 would result in: 4 base cycles (24 master), + 2 memory reads from xslow region (+12 * 2 memory), = 48 master, = 8 cpu cycles?
Or are you saying that even though it takes 48 master cycles, it only takes away 6 cpu cycles (e.g. from the 8192 cycles available to vblank period)?

It sounds like you mean the SNES will *think* only 6 cycles have passed, regardless if the operation really took 36 or 48 master cycles. If that's the case, then why would one emulate the internal cpu clock speed, since things like being in vblank would obviously have to go by the true timing in master clock cycles?
neviksti
Lurker
Posts: 122
Joined: Thu Jul 29, 2004 6:15 am

Post by neviksti »

byuusan wrote:It sounds like you mean the SNES will *think* only 6 cycles have passed, regardless if the operation really took 36 or 48 master cycles. If that's the case, then why would one emulate the internal cpu clock speed, since things like being in vblank would obviously have to go by the true timing in master clock cycles?
That's how I understand it (doesn't mean it's correct obviously).
When writing the core, zsknight probably didn't know these details that we do now... and unfortunately there don't appear to be any active devs left that feel comfortable adjusting the core. (For all I know it's already been adjusted. During pagefault's active time, I remember him talking about a big "timing rewrite" which I think he finished. Not sure what all it involved though.)
DataPath
Lurker
Posts: 128
Joined: Wed Jul 28, 2004 1:35 am
Contact:

Post by DataPath »

Come to think of it, that makes sense, because the processor is run off one of the 2 clock signals used to operate the SRAM. So the clock runs at a certain higher speed when there are no memory access, then it slows down the two phases of the clock, PHI1 and PHI2, during a memory access, and after the memory access has completed, you run it back up to full speed.

I think you have the right of it, neviksti.
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: > 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).
Yep. Check this out too: http://nsrt.edgeemu.com/INFO/chip-pix/SGB.JPG
The SRAM is wired up to be used as main DMG RAM.
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
Kagerato
Lurker
Posts: 153
Joined: Mon Aug 09, 2004 1:40 am
Contact:

Post by Kagerato »

Just out of curiosity, what game is that?
byuu

Post by byuu »

That's not a game, it's a Super Gameboy.
They probably wired it like that to get extra RAM, since they obviously didn't need to save data on the cart. It's still creepy, however...

By the way, I hate to ask this here, but does anyone know of a way to do decimal addition in c, without requiring 20 lines of code? e.g. when P.d is set and you add, such as: lda #$0009 : clc : adc #$0001 -> = #$0010.
I need this for the 65816 cpu core I'm writing. The best I can think of is to split off all 4 nibbles, and add them together one by one... but that would probably end up being between 20-30 times slower than just using assembly-level decimal addition.

Edit: This is what I have presently:

Code: Select all

//ex: word a = 0x62bf, word b = 0x4c38
byte tbl[16] = {
  0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07,
  0x08, 0x09, 0x10, 0x11, 0x12, 0x13, 0x14, 0x15
};

r = ((tbl[(a)       & 15] + tbl[(b)       & 15])      ) +
    ((tbl[(a >>  4) & 15] + tbl[(b >>  4) & 15]) <<  4) +
    ((tbl[(a >>  8) & 15] + tbl[(b >>  8) & 15]) <<  8) +
    ((tbl[(a >> 12) & 15] + tbl[(b >> 12) & 15]) << 12);
if(r > 0x9fff)r -= 0xa000; //ex: r = 0x155d
Which turns 0x62bf + 0x4c38 into 0x155d, which is the same in ZSNES. I'm curious if ZSNES has this right, it seems odd that the highest nibble would wrap around (final result is 155d instead of the expected b55d), but the lower nibbles would not (the lowest nibble is d, instead of the expected 1563).
Last edited by byuu on Sun Oct 17, 2004 10:38 pm, edited 4 times in total.
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:That's not a game, it's a Super Gameboy.
They probably wired it like that to get extra RAM
Not extra RAM. The SGB needs work RAM just like a standard DMG.
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 »

Ah, DMG is what they called early Gameboy revisions. Gotcha.
Nach
ZSNES Developer
ZSNES Developer
Posts: 3904
Joined: Tue Jul 27, 2004 10:54 pm
Location: Solar powered park bench
Contact:

Post by Nach »

Yes.

Image
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
grinvader
ZSNES Shake Shake Prinny
Posts: 5632
Joined: Wed Jul 28, 2004 4:15 pm
Location: PAL50, dood !

Post by grinvader »

I've just read your article, byuusan, and have a comment to add.

Two of the pictures are 'How Star Ocean should look when the S-DD1 chip is gone.' and 'Enix's Star Ocean as it appears in ZSNES without graphic packs to fake lack of S-DD1 emulation.'
The screens have nothing in common, proving a bad emulation step somewhere. That's how I understood this comparison.

I am one of the few guys around the world crazy enough to play star ocean really early. I'm not exactly sure (it's been a while) so I still have to backup this post with solid proof, but at earlier releases, when S-DD1 graphic packs were neither supported nor available, running SO in zsnes gave a result very close to the first picture.

I'll try and make a pic as soon as possible, with a little luck I should have it up in a few hours.

My point is - the difference between the two pictures is only a side effect of the graphic packs loading code. Which is, I agree about that, not real emulation...
I guess I just nitpicked on your article, but I thought this point was important enough to be cleared.
皆黙って俺について来い!!

Code: Select all

<jmr> bsnes has the most accurate wiki page but it takes forever to load (or something)
Pantheon: Gideon Zhi | CaitSith2 | Nach | kode54
byuu

Post by byuu »

Thanks, I'm aware of this. One picture was before ZSNES had the graphics pack capability, the graphics looked garbled because they were still technically compressed. The second picture shows how they looked when ZSNES expected a graphics pack but couldn't find one. It ended up showing solid blocks instead.
Kagerato
Lurker
Posts: 153
Joined: Mon Aug 09, 2004 1:40 am
Contact:

Post by Kagerato »

byuusan wrote:That's not a game, it's a Super Gameboy.
Wow. I figured the acronym was something quite obvious, but hadn't a clue it was a device I owned.
grinvader
ZSNES Shake Shake Prinny
Posts: 5632
Joined: Wed Jul 28, 2004 4:15 pm
Location: PAL50, dood !

Post by grinvader »

byuusan wrote:Thanks, I'm aware of this. One picture was before ZSNES had the graphics pack capability, the graphics looked garbled because they were still technically compressed. The second picture shows how they looked when ZSNES expected a graphics pack but couldn't find one. It ended up showing solid blocks instead.
Oh, ok. Case closed, I guess.
皆黙って俺について来い!!

Code: Select all

<jmr> bsnes has the most accurate wiki page but it takes forever to load (or something)
Pantheon: Gideon Zhi | CaitSith2 | Nach | kode54
Nach
ZSNES Developer
ZSNES Developer
Posts: 3904
Joined: Tue Jul 27, 2004 10:54 pm
Location: Solar powered park bench
Contact:

Post by Nach »

grinvader wrote:
byuusan wrote:Thanks, I'm aware of this. One picture was before ZSNES had the graphics pack capability, the graphics looked garbled because they were still technically compressed. The second picture shows how they looked when ZSNES expected a graphics pack but couldn't find one. It ended up showing solid blocks instead.
Oh, ok. Case closed, I guess.
Far from closed, we all must remember that some games are better without decompression or packs.

http://www.geocities.com/joecool22us/video.htm

Cookie for the person who figures out how I made it garbled then blocky.
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
kammedo
Rookie
Posts: 11
Joined: Mon Oct 18, 2004 5:26 pm

Hunger

Post by kammedo »

byuusan wrote:After this, I set A to 0xDEAD, X to 0xBEEF, Y to 0x0123,
Oh man all that $B33F is getting me hungry.......
PKFAIRY
Cosmic Chaos
Posts: 26
Joined: Wed Jul 28, 2004 2:59 pm
Location: Moonside
Contact:

Post by PKFAIRY »

Nach wrote:
grinvader wrote:
byuusan wrote:Thanks, I'm aware of this. One picture was before ZSNES had the graphics pack capability, the graphics looked garbled because they were still technically compressed. The second picture shows how they looked when ZSNES expected a graphics pack but couldn't find one. It ended up showing solid blocks instead.
Oh, ok. Case closed, I guess.
Far from closed, we all must remember that some games are better without decompression or packs.

http://www.geocities.com/joecool22us/video.htm

Cookie for the person who figures out how I made it garbled then blocky.
My guess is SFA2 and you referenced incomplete gfx packs?
Anyway, Welcome kammedo, enjoy the pdf ;)
*poof*
Nach
ZSNES Developer
ZSNES Developer
Posts: 3904
Joined: Tue Jul 27, 2004 10:54 pm
Location: Solar powered park bench
Contact:

Post by Nach »

PKFAIRY wrote: My guess is SFA2 and you referenced incomplete gfx packs?
Not even close.
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
PKFAIRY
Cosmic Chaos
Posts: 26
Joined: Wed Jul 28, 2004 2:59 pm
Location: Moonside
Contact:

Post by PKFAIRY »

didnt think so but it could be done that way ^^;... im pretty sure anyway... couldn't it?
*poof*
Nach
ZSNES Developer
ZSNES Developer
Posts: 3904
Joined: Tue Jul 27, 2004 10:54 pm
Location: Solar powered park bench
Contact:

Post by Nach »

Don't think so.
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
Jonas Quinn
ZSNES Developer
ZSNES Developer
Posts: 115
Joined: Thu Jul 29, 2004 9:51 pm
Location: Germany

Post by Jonas Quinn »

Nach wrote:
PKFAIRY wrote: My guess is SFA2 and you referenced incomplete gfx packs?
Not even close.
I think that you played SFA2 without the gfx packs and that you disabled all layers expect the sprite layer.
Nach
ZSNES Developer
ZSNES Developer
Posts: 3904
Joined: Tue Jul 27, 2004 10:54 pm
Location: Solar powered park bench
Contact:

Post by Nach »

Jonas Quinn wrote:
Nach wrote:
PKFAIRY wrote: My guess is SFA2 and you referenced incomplete gfx packs?
Not even close.
I think that you played SFA2 without the gfx packs and that you disabled all layers expect the sprite layer.
That doesn't explain why Ryu and Akuma first looked like garbage, then became clear and blocky.
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
Nightcrawler
Romhacking God
Posts: 922
Joined: Wed Jul 28, 2004 11:27 pm
Contact:

Post by Nightcrawler »

I wanted to add a bit of information to this topic. I brought this up a year or so ago i think, but it fell on deaf ears.

It seems the scroll registers are incorrectly initialized in ZSNES.
When run on the real SNES you must initialize them to 0 yourself or your static screen will not come up and will be scrolling insanely in both directions.

This MAY be due to the copier though since the copier menu has a scrolling background for loading a program.

Has anyone else seen this happen? If you don't initialize the scroll registers and bring an image up on the screen, what happens?
[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 »

That's most likely your copier. I can't imagine why it would keep scrolling though if it was the BIOS that was doing it initially, unless it left an HDMA channel on. Try using:

Code: Select all

lda #$00 : sta $420c
And see if that stops it from moving around.

As far as initial states, I can't say since I have a copier and no flash cart as well, but I have noticed some weird things when I missed a register or two initializing my intros. Also, using the priority bit on your tilemap when only BG1 is on makes the screen totally freak out sometimes.
Post Reply