SDD1 FGPA implementation

Discussion of hardware and software development for Super NES and Super Famicom. See the SNESdev wiki for more information.

Moderator: Moderators

Forum rules
  • For making cartridges of your Super NES games, see Reproduction.
magno
Posts: 193
Joined: Tue Aug 15, 2006 5:23 am
Location: Spain
Contact:

Re: SDD1 FGPA implementation

Post by magno »

Hope this handmade timing diagram will help to explain why I don't think CPU_RD is 3 master cycles in FastROM mode:
STA.w $4801 timing diagram (incomplete)
STA.w $4801 timing diagram (incomplete)
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...
srg320
Posts: 32
Joined: Fri Feb 16, 2018 5:52 am
Location: Ukraine

Re: SDD1 FGPA implementation

Post by srg320 »

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.
magno
Posts: 193
Joined: Tue Aug 15, 2006 5:23 am
Location: Spain
Contact:

Re: SDD1 FGPA implementation

Post by magno »

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.
srg320
Posts: 32
Joined: Fri Feb 16, 2018 5:52 am
Location: Ukraine

Re: SDD1 FGPA implementation

Post by srg320 »

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).
magno
Posts: 193
Joined: Tue Aug 15, 2006 5:23 am
Location: Spain
Contact:

Re: SDD1 FGPA implementation

Post by magno »

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.
srg320
Posts: 32
Joined: Fri Feb 16, 2018 5:52 am
Location: Ukraine

Re: SDD1 FGPA implementation

Post by srg320 »

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.
magno
Posts: 193
Joined: Tue Aug 15, 2006 5:23 am
Location: Spain
Contact:

Re: SDD1 FGPA implementation

Post by magno »

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.
User avatar
Señor Ventura
Posts: 233
Joined: Sat Aug 20, 2016 3:58 am

Re: SDD1 FGPA implementation

Post by Señor Ventura »

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 :(
93143
Posts: 1717
Joined: Fri Jul 04, 2014 9:31 pm

Re: SDD1 FGPA implementation

Post by 93143 »

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.
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
User avatar
Señor Ventura
Posts: 233
Joined: Sat Aug 20, 2016 3:58 am

Re: SDD1 FGPA implementation

Post by Señor Ventura »

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 ^^).
nocash
Posts: 1405
Joined: Fri Feb 24, 2012 12:09 pm
Contact:

Re: SDD1 FGPA implementation

Post by nocash »

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 : )
User avatar
TmEE
Posts: 960
Joined: Wed Feb 13, 2008 9:10 am
Location: Norway (50 and 60Hz compatible :P)
Contact:

Re: SDD1 FGPA implementation

Post by TmEE »

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.
warham
Posts: 1
Joined: Thu Nov 15, 2018 12:53 am

Re: SDD1 FGPA implementation

Post by warham »

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
Last edited by warham on Thu Nov 15, 2018 3:54 am, edited 2 times in total.
Post Reply