It is currently Mon Oct 22, 2018 3:20 am

All times are UTC - 7 hours



Forum rules





Post new topic Reply to topic  [ 58 posts ]  Go to page Previous  1, 2, 3, 4
Author Message
PostPosted: Thu Aug 02, 2018 2:13 pm 
Offline

Joined: Tue Aug 15, 2006 5:23 am
Posts: 193
Location: Spain
Hope this handmade timing diagram will help to explain why I don't think CPU_RD is 3 master cycles in FastROM mode:

Attachment:
File comment: STA.w $4801 timing diagram (incomplete)
STA_4801.jpg
STA_4801.jpg [ 1.03 MiB | Viewed 1692 times ]


There are 2 more CPU cycles left, but to illustrate how it works, it is sufficient.

tLATCH is latch's propagation delay from enable = '1' to output valid.
tDECOD is combinational propagation delay to decode CPU_RD from full address (bank + offset) and RWB signal.
When second read cycle starts (read $01 from ROM), CPU_RD is low, and it goes to '1' after bank latch changes its ouptut. Latch is enabled during low phase in PHI2, but new bank byte is not present in data bus until 33ns after PHI2 falling edge. Those 33ns in undeterminated state, CPU_RD is '1' again.
Maybe I missing something, but I've beeing thinking a lot on this lately and can't find any other explanation...


Top
 Profile  
 
PostPosted: Thu Aug 02, 2018 9:40 pm 
Offline

Joined: Fri Feb 16, 2018 5:52 am
Posts: 29
Location: Ukraine
According to the logical analyzer traces from this post (LISTING8.txt) CPU_RD/CPU_WR is 3/3 and 3/5 master cycles long when work CPU and 4/4 when work DMA.


Top
 Profile  
 
PostPosted: Thu Aug 02, 2018 10:33 pm 
Offline

Joined: Tue Aug 15, 2006 5:23 am
Posts: 193
Location: Spain
srg320 wrote:
According to the logical analyzer traces from this post (LISTING8.txt) CPU_RD/CPU_WR is 3/3 and 3/5 master cycles long when work CPU and 4/4 when work DMA.


Yes, but I can't tell why the differences between those logs and my timing diagram. Maybe bank latching is not done in SNES as explained in W65C816S datasheet.


Top
 Profile  
 
PostPosted: Fri Aug 03, 2018 2:17 am 
Offline

Joined: Fri Feb 16, 2018 5:52 am
Posts: 29
Location: Ukraine
magno wrote:
tDECOD is combinational propagation delay to decode CPU_RD from full address (bank + offset) and RWB signal.

Why do you think that CPU_RD is decoded from address and not just RWB? I think it something like ~(RWB & PHI2).


Top
 Profile  
 
PostPosted: Fri Aug 03, 2018 2:27 am 
Offline

Joined: Tue Aug 15, 2006 5:23 am
Posts: 193
Location: Spain
srg320 wrote:
magno wrote:
tDECOD is combinational propagation delay to decode CPU_RD from full address (bank + offset) and RWB signal.

Why do you think that CPU_RD is decoded from address and not just RWB? I think it something like ~(RWB & PHI2).


Because some instruction have an Internal Operation cycle whilst RWB is '1', so CPU_RD would go low even if no read cycle is executing.


Top
 Profile  
 
PostPosted: Fri Aug 03, 2018 2:40 am 
Offline

Joined: Fri Feb 16, 2018 5:52 am
Posts: 29
Location: Ukraine
magno wrote:
Because some instruction have an Internal Operation cycle whilst RWB is '1', so CPU_RD would go low even if no read cycle is executing.

To determine Internal Operation cycle I use VDA and VPA, maybe it wrong.


Top
 Profile  
 
PostPosted: Fri Aug 03, 2018 2:47 am 
Offline

Joined: Tue Aug 15, 2006 5:23 am
Posts: 193
Location: Spain
srg320 wrote:
magno wrote:
Because some instruction have an Internal Operation cycle whilst RWB is '1', so CPU_RD would go low even if no read cycle is executing.

To determine Internal Operation cycle I use VDA and VPA, maybe it wrong.


Non you are not wrong,, VDA and VPA are useful to determine IO cycle, but then, /CPU_RD would be decoded from RWB, PHI2, VDA and VPA, and this is a guess, not a truth... In fact, it is possible that it is that way, but I don't know.
/ROMSEL is decoded from address and bank, so maybe there is no need for /CPU_RD to be decoded from them again.


Top
 Profile  
 
PostPosted: Sat Aug 04, 2018 6:56 am 
Offline

Joined: Fri Feb 16, 2018 5:52 am
Posts: 29
Location: Ukraine
https://forums.nesdev.com/viewtopic.php?p=211643#p211643
https://forums.nesdev.com/viewtopic.php?p=189332#p189332


Top
 Profile  
 
PostPosted: Sat Aug 04, 2018 4:39 pm 
Offline
User avatar

Joined: Sat Aug 20, 2016 3:58 am
Posts: 69
93143 wrote:
It would be more exciting if there was any realistic prospect of it happening any time soon. Everybody who might contribute, including me, is busy doing other stuff.

But it's certainly fun to think about and talk about. And there is one member here who arrived harbouring the intention to port Metal Slug to the SNES, and has given it a lot of thought, even if he now feels it would be too big a task for him alone. A few other members are known to have been working on stuff that could be applicable to such a port, such as predictive animation, dynamic sprite VRAM allocation, and HDMA audio data streaming. Not to mention an FPGA implementation of the S-DD1... I can't rule out the possibility that this project may get off the ground someday.


The best part is always the theory XD

Maybe the snes has the colors, the sound, and most of the animations at a seemed rate to the original, but definitely i think it has a lack of proccessing and sprites fill rate (it only has to be seen how it works in the original neo geo game).

But there was so much legend when something did us to believe that some ports were impossible. Definitely a big number of games could fit in a snes almost at the same level than the original arcade games.

magno wrote:
Nop, a CPU cycle is 6 master clocks in FastROM, or 8 master clocks in SlowROM (not the case). The read cycle is just a portion of 1 CPU cycle.


That dammed WRAM...

8,43KB per frame could have been a reality :(


Top
 Profile  
 
PostPosted: Sat Aug 04, 2018 7:34 pm 
Offline

Joined: Fri Jul 04, 2014 9:31 pm
Posts: 966
Señor Ventura wrote:
a lack of processing

Sure, the Neo Geo had a 12 MHz 68000, and the game still had slowdown. But the game engine was not very efficient, and they had to rewrite it for Metal Slug X. Also, the SNES CPU is perhaps close to twice as efficient per clock as the 68000. A homebrew port would be heavily optimized; I'd still expect slowdown, but it might not be all that horrible.

Note that the original game is 30 fps. This means that it has about twice as much going on as a hypothetical 60 fps game would be able to manage with the same CPU load, and comparisons with existing SNES software (which is almost all 60 fps) should take this into account.

Quote:
and sprites fill rate

To be fair, the Neo Geo had to build its backgrounds out of sprites, so the overdraw advantage wasn't quite as large as it looked. And most of the bosses could easily be done with BG layers on SNES. But yes, it's likely there would be a fair amount of sprite dropout/flicker during busy segments.

We discussed the idea of a SNES Metal Slug port recently, over here: viewtopic.php?f=23&t=17374


Top
 Profile  
 
PostPosted: Sun Aug 05, 2018 7:13 am 
Offline
User avatar

Joined: Sat Aug 20, 2016 3:58 am
Posts: 69
93143 wrote:
We discussed the idea of a SNES Metal Slug port recently, over here: viewtopic.php?f=23&t=17374


Perfect, then it would be better if i respond there (sorry for the off topic, magno ^^).


Top
 Profile  
 
PostPosted: Sun Aug 12, 2018 10:05 am 
Offline

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 655
tepples wrote:
67.1 megabits, which is 64 mebibits or 64 of what the game industry called "megabits" in the mask ROM era.

That mask ROM era hasn't ended yet. As far as I know it's still absolutely common to use terms like "gigabit" or "gigabyte" for things like modern FLASH chips and SD cards, with "giga" meaning 1024^3, one reason is that chip manufacturing does somewhat require having a power of 2 for storage array. Whereas, SD cards are usually having an area reserved for automatic replacement of worn out sectors, so the available user space may appear to be less than expected, but that's unrelated to the 1000 vs 1024 thing.
Magnetic discs don't have that requirement for powers of 2, so manufacturers may often mean (1000^n) when they are saying "kilo/mega/giga" in their specifications (and for transfer rates and clock rates it's even more common to use 1000^n). Of course it would be neat to avoid that confusion, only, those new scientific units like "mebibits" are sounding a lot too much like childish language to me : /
As for myself, I would rather avoid to adopt those terms. Another approach would be defining the exact value in Hz or bytes somewhere in the introduction/specs, and then using an abbreviated value in the rest of the document; like 1234567Hz (1.2MHz), or 400h bytes (1Kbyte).

magno wrote:
Hope this handmade timing diagram will help to explain why I don't think CPU_RD is 3 master cycles in FastROM mode:

I've no idea which timings are correct... but your handmade diagrams & schematics are really pretty : )


Top
 Profile  
 
PostPosted: Sun Aug 12, 2018 2:21 pm 
Offline
User avatar

Joined: Wed Feb 13, 2008 9:10 am
Posts: 660
Location: Estonia, Rapla city (50 and 60Hz compatible :P)
Decimal bytes and bits are the exception not the rule so those should instead be bastardized. I refer to such things using e after the K/M/G/T etc. in my stuff and will not start using the i after them to refer to binary equivalents. A floppy can be 1.44MeB and some random HDD 250GeB.

_________________
http://www.tmeeco.eu


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 58 posts ]  Go to page Previous  1, 2, 3, 4

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 4 guests


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
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group