FPGA SNES source (srg320)

[cacophony]

I don't see this mentioned and thought it would be of interest:
https://github.com/srg320/FpgaSnes

Here's a video demonstrating the work:
https://www.youtube.com/watch?v=eyYawriH1cQ

[Sorgelig]

Interesting!
Is there any topics on other forum to read about it?
I'm curious how much it's completed before start to port it.

[Sorgelig]

quick observation shows it needs 256KB of SRAM + CART memory.
SRAM fits into BRAM and CART into SDRAM (may be even in DDR3). So, from this point of view it fits to MiSTer without problems.

[cacophony]

Interesting!
Is there any topics on other forum to read about it?
I'm curious how much it's completed before start to port it.

The only mention I've seen is this comment from ElectronAsh on Discord:
"That SNES core looks amazing so far, just from seeing it pass the tests on the vid, and how well-written the code is.
All of the mappers and audio stuff is there, too."

If I find any info on it I'll let you know

[kitrinx]

Seems another video of this core surfaced:

https://www.youtube.com/watch?v=utPfWlOyGag

[brNX]

Seems another video of this core surfaced:

https://www.youtube.com/watch?v=utPfWlOyGag

Looks promising, I wonder if it was written from scratch?

[Sorgelig]

according to second video it's pretty much mature and worth porting.
I will work on it.
Just need some final moments on Genesis and add some features to VIP scaler.

[Dubon]

Wait a second. Srg320... thats you right SoRGelig?

[Sorgelig]

Haha, good try.
But it's not me. And i don't like VHDL, actually

[NegSol]

Wow! Amazing move. I honestly cannot believe this came out of nowhere. There are not many comments in the source beside the bare minimum. Still great gift for the community. Many thanks to srg320.

[warham]

came across this if its useful at all. Looks like the work on the core is a fellow that goes by "Magno" from Spain and one in the Ukraine SRG320.
https://forums.nesdev.com/viewtopic.php ... 18#p228918

[cacophony]

A few new pieces of info:

DSP support
https://www.youtube.com/watch?v=bTyh4jQPKqA

CX4 support
https://www.youtube.com/watch?v=nh7rs3kaoVE

SDD1 support
https://www.youtube.com/watch?v=H9WVWyqP9uk

It looks like srg320 has some posting history on nesdev:
https://forums.nesdev.com/memberlist.ph ... 163776c092

posts:
https://forums.nesdev.com/search.php?au ... 9&sr=posts

[Edgg]

Awsome news!!, although I was wondering.. what about those cartridges like 'Yoshi`s Islands' that have custom chips inside that do process task in some level?
It will be able to run those properly?

[Chol]

Yoshi's Island requires Super FX. In theory the necessary code could be fetched from https://github.com/mrehkopf/sd2snes/tre ... op/verilog.

[Edgg]

That´s Great!

[Dubon]

Just a headsup, an early build has been posted on discord

Just been speaking to ElectroNash and he's said it is OK to share this here.

Before anybody tries it though, as you can see from this video from a few days ago, it does run really well on the original FPGA but it is very new to the DE10-Nano so at the moment there is very little that actually works on the MiSTer implementation at what does load may not work very well at all.

**Super Mario World** seems to run well for me but you may have to try loading it more than once to get it to start up.

**THAT IS NOT AN ISSUE WITH THE ORIGINAL CORE**, it's just that it's going to take time for the people who are working on the MiSTer version to equal that standard, it's just going to need patience and time from us.

This is **VERY** early on this hardware, as you can, it runs really well on the original FPGA hardware but it will take time and effort to equal what you see in this video.
https://www.youtube.com/watch?v=utPfWlOyGag&t=718s

Video
https://m.youtube.com/watch?v=hFuQ8Fyrz ... =mv-google


I anyone want to try it head to discord

[brNX]

Just a headsup, an early build has been posted on discord

Just been speaking to ElectroNash and he's said it is OK to share this here.

Before anybody tries it though, as you can see from this video from a few days ago, it does run really well on the original FPGA but it is very new to the DE10-Nano so at the moment there is very little that actually works on the MiSTer implementation at what does load may not work very well at all.

**Super Mario World** seems to run well for me but you may have to try loading it more than once to get it to start up.

**THAT IS NOT AN ISSUE WITH THE ORIGINAL CORE**, it's just that it's going to take time for the people who are working on the MiSTer version to equal that standard, it's just going to need patience and time from us.

This is **VERY** early on this hardware, as you can, it runs really well on the original FPGA hardware but it will take time and effort to equal what you see in this video.
https://www.youtube.com/watch?v=utPfWlOyGag&t=718s

Video
https://m.youtube.com/watch?v=hFuQ8Fyrz ... =mv-google


I anyone want to try it head to discord

Is there a public repo (github) where the port is being done ?

Cheers

[Dubon]

Check the forks. jeebs and electronash are mister devs.

[brNX]

Check the forks. jeebs and electronash are mister devs.

Thanks, found it https://github.com/Kitrinx/SNES_MiSTer

[Sorgelig]

I don't know if these devs want to move the core to MiSTer-devel group and continue it as an official port.
They didn't open the issue tracker, so i have no chance to ask this on github.

I can make my own port or fork their code and continue from where they are.
So, it's up to them.

[kitrinx]

Go ahead and fork, and thank you

[Sorgelig]

I've just tried to compile your port and it works! Great job on porting!
The code needs some rework as it has many async clocks so may have instability.
I've loaded Super R-Type (R-Type is one of my favorite shmup game) and was very impressed! The quality of graphics is outstanding! Backgrounds are correct, sprites are correct. So, this core looks promising!

where is that guy chasing the $400K for his SNES core?

[OzOnE]

@Sorgelig - you've no idea how much it means to me that you approve of the work.

I was going to ask you on Faceplant about it soon.

As you know, I've struggled with getting anything ported to MiSTer before, and I thought my attempt atm is a bit of a "kludge", but hey, it loads the ROMs, right? lol

I know that it's constantly sending a Read request all the while CART_SRAM_CE_N is low atm, and I don't know if there is a problem there with the way it might not always "catch" the read, depending on when the core is bought out of reset, and which phase the SNES_CE counter is in?

But yep, the core looks very well-written, but does have timing issues with some builds. @kitrinx, @GreyRogue, @Vitor and others have been helping a lot with getting the rest working.

I know the timing constraints and async stuff is really tricky, though, so it would be great if you could help with that.

I added a 64KB on-chip RAM on it for the Backup RAM, but Vitor said that a few games apparently even use up to 128KB.

I doubt it's very many games that need quite that much, though?
Some games like Donkey Kong Country actually check the size of the Backup SRAM, and show a copy protection error if it's wrong, hence it will still need a mask for the BRAM address, based on when the auto-detect stuff is added.

They have been working on adding auto-detection of LoROM / HiROM / other mappers, and the Backup SRAM size, which would allow a lot more games to work without manual config.

I found that if I used the 21 MHz clock for the SPC (now CLK_24M on main), it seemed to get a reliable compile more often. I guess because Quartus won't be struggling so much with the async clocks?

I ended up translating main.vhd to main.v yesterday, as I just couldn't handle trying to work with VHDL any more.
I noticed you did something similar for genesis.v as well recently. lol :p

I was wondering if you think we should just put the instantiations for the SNES core, mapper, and other custom chips directly into SNES.sv, or whether it's good to have the top-level in main.v for all of that, to keep SNES.sv neater?

My mouse support thing isn't working yet, and the OSD option for that often keeps changing to Mouse by default, as I don't recall what that status bit was originally for? I used the NES core as the basis for porting.

Also, I think we could just merge the CART_SRAM and CART_SRAM2 busses into one, since the real carts obviously only have the one main bus any for sharing between the cart ROM and Backup SRAM.

The WSRAM_BLE_N and BLH_N signals aren't even used now, since the author was originally using a 16-bit wide SRAM for that, and it only needs 8-bit.

The audio RAM (ASRAM_ADDR) is 21-bits wide as well, but it only needs to access 64KB for that.

Oh, and the video syncs were a nightmare to get right, and still need tweaking. @kitrinx and I couldn't quite figure out what the exact values should be, so we spent hours messing with the "Sources and Probes" thing on Quartus to get it "close enough". lol

Obviously the HDMI scaler works quite well anyway, as it just uses the FRAME signal as DE.

The video syncs don't currently adjust themselves for PAL mode, btw.


What else? Erm - I don't know if the on-chip RAM blocks could use a slower clock, rather than the full 21 MHz, but it seems to all work OK anyway?

(it could be causing multiple writes to the same locations maybe?)

The joypad spoofer logic I just cobbled together very quickly, but it seems to work OK.
I tried removing "posedge JOY_STRB" from the sensitivity lists, thinking that it would all be synchronous to JOY1_CLK, but yeah, that just broke it.

I didn't use the original audio I2S signals at all, as I don't recall if there was already a decoder block for that on MiSTer, so I just routed the signals directly from the SPC core.


Oh yeah, and X_OUT / Y_OUT are definitely not ideal to use for sync generation, as they do some weird counting.
H_CNT and V_CNT are the real counters.


Thanks again for you work on MiSTer. I can't believe how far it's come in just the past few months.

The SNES core really is the icing on the cake now for a lot of people. That covers pretty much all of the popular consoles of the 16-bit era.

I'm hoping to do more work on my Capcom CPS core soon. I used Jotego's wonderful jt51 YM core, and it's sounding great so far. This is all running on MiSTer, btw...

https://drive.google.com/file/d/1MNxVg5 ... sp=sharing

(plus my own MSM6295 ADPCM core.)


I think I've probably bombarded you with enough info now. hehe

Regards,
OzOnE / ElectronAsh.

[brNX]

@kitrinx, @GreyRogue, @Vitor and @OzOnE

thanks for the work you've done on porting this, one of my favourite consoles.

I probably don't have to point you to this https://github.com/mrehkopf/sd2snes/blo ... /src/smc.c but will do it anyway if you've missed it.
The sd2snes uses an ARM microcontroller to run this code after loading the ROM to the PSRAM to configure the Mapper type.

[Sorgelig]

I didn't dig too deep yet. I see most chips aren't used now cause i see several internal PLLs but didn't see them in compilation report. So "fun" things are awaiting

I will probably remove the ability to save backup RAM for now. Currently it's just complicating the port. I plan to change the SDRAM controller and may be even try DDR3. Later, when core will be ready, the backup saving will be added again. GreyRogue is already master in this

CART_SRAM and CART_SRAM2 should be definitely merged, just need to rewrite the decoding logic.
BRAM should use the same clock as logic accessing it. It doesn't need to be bound to exactly 21MHz.
I2S will be removed as LCD was - they are implementation specific and should be used in top-level independently from core.