nesdev.com

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



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

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.

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.

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.

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.



That dammed WRAM...

8,43KB per frame could have been a reality

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.


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

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

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


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

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

I think these folks will be interested in converting this project to MISTer and the cyclone v
http://www.atari-forum.com/viewtopic.ph ... 76#p358276