View unanswered posts | View active topics It is currently Tue Dec 10, 2019 1:36 am



Reply to topic  [ 105 posts ]  Go to page Previous  1, 2, 3, 4, 5  Next
A small article regarding ZSNES 
Author Message
Lurker

Joined: Wed Jul 28, 2004 1:35 am
Posts: 128
Reply with quote
Post 
> 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:
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.


Fri Oct 15, 2004 10:26 pm
Profile ICQ YIM
Lurker

Joined: Thu Jul 29, 2004 6:15 am
Posts: 122
Reply with quote
Post 
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.


Sat Oct 16, 2004 1:32 am
Profile
Reply with quote
Post 
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?


Sat Oct 16, 2004 9:25 am
Lurker

Joined: Thu Jul 29, 2004 6:15 am
Posts: 122
Reply with quote
Post 
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.)


Sat Oct 16, 2004 1:34 pm
Profile
Lurker

Joined: Wed Jul 28, 2004 1:35 am
Posts: 128
Reply with quote
Post 
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.


Sat Oct 16, 2004 3:56 pm
Profile ICQ YIM
ZSNES Developer
ZSNES Developer
User avatar

Joined: Tue Jul 27, 2004 10:54 pm
Posts: 3902
Location: Solar powered park bench
Reply with quote
Post 
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


Sun Oct 17, 2004 3:17 pm
Profile WWW
Lurker

Joined: Mon Aug 09, 2004 1:40 am
Posts: 153
Reply with quote
Post 
Just out of curiosity, what game is that?


Sun Oct 17, 2004 3:21 pm
Profile WWW
Reply with quote
Post 
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:
//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.



Sun Oct 17, 2004 3:55 pm
ZSNES Developer
ZSNES Developer
User avatar

Joined: Tue Jul 27, 2004 10:54 pm
Posts: 3902
Location: Solar powered park bench
Reply with quote
Post 
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


Sun Oct 17, 2004 4:12 pm
Profile WWW
Reply with quote
Post 
Ah, DMG is what they called early Gameboy revisions. Gotcha.


Sun Oct 17, 2004 4:21 pm
ZSNES Developer
ZSNES Developer
User avatar

Joined: Tue Jul 27, 2004 10:54 pm
Posts: 3902
Location: Solar powered park bench
Reply with quote
Post 
Yes.

Image

_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding


Sun Oct 17, 2004 4:32 pm
Profile WWW
ZSNES Shake Shake Prinny
User avatar

Joined: Wed Jul 28, 2004 4:15 pm
Posts: 5615
Location: PAL50, dood !
Reply with quote
Post 
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:
<jmr> bsnes has the most accurate wiki page but it takes forever to load (or something)

Pantheon: Gideon Zhi | CaitSith2 | Nach | kode54


Sun Oct 17, 2004 11:02 pm
Profile
Reply with quote
Post 
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.


Sun Oct 17, 2004 11:42 pm
Lurker

Joined: Mon Aug 09, 2004 1:40 am
Posts: 153
Reply with quote
Post 
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.


Sun Oct 17, 2004 11:44 pm
Profile WWW
ZSNES Shake Shake Prinny
User avatar

Joined: Wed Jul 28, 2004 4:15 pm
Posts: 5615
Location: PAL50, dood !
Reply with quote
Post 
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:
<jmr> bsnes has the most accurate wiki page but it takes forever to load (or something)

Pantheon: Gideon Zhi | CaitSith2 | Nach | kode54


Sun Oct 17, 2004 11:52 pm
Profile
ZSNES Developer
ZSNES Developer
User avatar

Joined: Tue Jul 27, 2004 10:54 pm
Posts: 3902
Location: Solar powered park bench
Reply with quote
Post 
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


Mon Oct 18, 2004 12:20 am
Profile WWW
Rookie

Joined: Mon Oct 18, 2004 5:26 pm
Posts: 11
Reply with quote
Post Hunger
byuusan wrote:
After this, I set A to 0xDEAD, X to 0xBEEF, Y to 0x0123,


Oh man all that $B33F is getting me hungry.......


Mon Oct 18, 2004 5:36 pm
Profile
Cosmic Chaos
User avatar

Joined: Wed Jul 28, 2004 2:59 pm
Posts: 26
Location: Moonside
Reply with quote
Post 
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*


Mon Oct 18, 2004 6:25 pm
Profile WWW
ZSNES Developer
ZSNES Developer
User avatar

Joined: Tue Jul 27, 2004 10:54 pm
Posts: 3902
Location: Solar powered park bench
Reply with quote
Post 
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


Mon Oct 18, 2004 6:36 pm
Profile WWW
Cosmic Chaos
User avatar

Joined: Wed Jul 28, 2004 2:59 pm
Posts: 26
Location: Moonside
Reply with quote
Post 
didnt think so but it could be done that way ^^;... im pretty sure anyway... couldn't it?

_________________
*poof*


Mon Oct 18, 2004 7:05 pm
Profile WWW
ZSNES Developer
ZSNES Developer
User avatar

Joined: Tue Jul 27, 2004 10:54 pm
Posts: 3902
Location: Solar powered park bench
Reply with quote
Post 
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


Mon Oct 18, 2004 7:38 pm
Profile WWW
ZSNES Developer
ZSNES Developer

Joined: Thu Jul 29, 2004 9:51 pm
Posts: 115
Location: Germany
Reply with quote
Post 
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.


Mon Oct 18, 2004 9:33 pm
Profile
ZSNES Developer
ZSNES Developer
User avatar

Joined: Tue Jul 27, 2004 10:54 pm
Posts: 3902
Location: Solar powered park bench
Reply with quote
Post 
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


Mon Oct 18, 2004 11:29 pm
Profile WWW
Romhacking God

Joined: Wed Jul 28, 2004 11:27 pm
Posts: 922
Reply with quote
Post 
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.


Thu Oct 21, 2004 6:42 pm
Profile WWW
Reply with quote
Post 
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:
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.


Thu Oct 21, 2004 10:12 pm
Display posts from previous:  Sort by  
Reply to topic   [ 105 posts ]  Go to page Previous  1, 2, 3, 4, 5  Next

Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group.
Designed by ST Software.