Introducing the VeriSNES (FPGA-based SNES)

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.
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Introducing the VeriSNES (FPGA-based SNES)

Post by tepples »

jwdonal wrote:- S-CPU DMA and HDMA - Both of these are complete and working very well. My logic analyzer setup was extremely useful for implementing these blocks. The MDMA implementation was pretty easy
What's this supposed to stand for? "memcpy DMA"? Because it makes me think of Ecstasy (methylenedioxymethamphetamine), under investigation as part of a PTSD treatment.
The way HDMA interacts with MDMA (stalling in-progress MDMAs or killing them)
MAOIs also interact with MDMA in a way that could be described as "killing them".

OK, now back to seriouSNESs:
Even though I have no graphics output I can still hear the attractors/demos running (since my APU core is 100% complete).
Does the S-PPU have anything remotely close to sprite 0 hit on the NES?
niconii
Posts: 219
Joined: Sun Mar 27, 2016 7:56 pm

Re: Introducing the VeriSNES (FPGA-based SNES)

Post by niconii »

tepples wrote:
jwdonal wrote:- S-CPU DMA and HDMA - Both of these are complete and working very well. My logic analyzer setup was extremely useful for implementing these blocks. The MDMA implementation was pretty easy
What's this supposed to stand for? "memcpy DMA"? Because it makes me think of Ecstasy (methylenedioxymethamphetamine), under investigation as part of a PTSD treatment.
The official name for the register that enables general purpose DMA channels is MDMAEN, in contrast to HDMAEN for HDMA. Not sure if the official docs actually mention what that stands for (AFAIK it only refers to it as "General Purpose DMA").
tepples wrote:
Even though I have no graphics output I can still hear the attractors/demos running (since my APU core is 100% complete).
Does the S-PPU have anything remotely close to sprite 0 hit on the NES?
Nope, the SNES has a proper raster interrupt (which can be mid-scanline), as well as HDMA which can automatically write data every HBlank according to a table in memory you give it.
Near
Founder of higan project
Posts: 1553
Joined: Mon Mar 27, 2006 5:23 pm

Re: Introducing the VeriSNES (FPGA-based SNES)

Post by Near »

> Sorry for delayed response.

No worries at all :)

> The answer is yes, I will be sharing them. But I don't have an ETA on when this will be.

Okay, that's fine! Please take your time.

I'm actually in the middle of a lot of cart preservation and Z80/Master System emulation stuff at the moment anyway. I would have of course put that off, but having some extra time for better test ROM notes is also good ^^'

> Do you have any of the HDMA/DMA test ROMs that you made that you could share as well?

Really sorry, but I do not have them anymore.

What happened is that every year or so, I back up my entire system onto external drives, do a clean format, and move over the files that I actually use. I left the test ROMs off, along with older bsnes versions (v001-v018), Chris' chip decapping scans (oddly I still have the Cx4 one), some important old real-life pictures, etc one time. And ... like a complete idiot, I must have formatted over the drive.

Because I've gone through every hard drive in my possession and failed to find any of the above =(

They were all really awful, though. They either showed a solid blue (pass) or solid red (fail) screen, and put the test# that failed into SRAM. Almost zero comments. And they all required 100% perfect Hcounter/Vcounter/cycle timing.

The HDMA ones would have been here:
http://byuu.cinnamonpirate.com/temp/test_hdma.zip
http://byuu.cinnamonpirate.com/temp/hdma_midframe.zip

But unfortunately, Wayback Machine didn't grab them. If anyone out there has them, feel free to share here.

Since I can't help you with my test ROMs, I'd like to return the favor any way you'd like. If you get stuck and something doesn't make sense, hit me up on PM for my contact info and I'll be happy to explain things as best I can.

> MAOIs also interact with MDMA

MAOIs interact with everything. Those things are terrifying. Only useful when taking tryptamine substances like dimethyltryptamine, as without them, they won't be psychoactive. Just fast during that window so you don't die.

> The official name for the register that enables general purpose DMA channels is MDMAEN, in contrast to HDMAEN for HDMA.

Huh, I didn't even know that o.O
Most likely, the M = memory, H = horizontal-blank
User avatar
jwdonal
Posts: 719
Joined: Sat Jun 27, 2009 11:05 pm
Location: New Mexico, USA
Contact:

Re: Introducing the VeriSNES (FPGA-based SNES)

Post by jwdonal »

tepples wrote:What's this supposed to stand for? "memcpy DMA"?
As Nicole and byuu stated the definition of MDMA is never given in the official docs (they always call it "General Purpose DMA" like Nicole said but that doesn't have an 'M' in it! haha) even though it is used in the official docs. Most likely it means Memory DMA, but I never really liked that because HDMA also performs memory transfers. In my head I always call it Main (as in primary) DMA but that's just my personal preference - which means it's worth nothing. :) Really I would prefer the acronym to be GDMA for General DMA. I think that makes the most sense.
tepples wrote:MAOIs also interact with MDMA in a way that could be described as "killing them".
Lol, tepples you're awesome.
Shonumi
Posts: 342
Joined: Sun Jan 26, 2014 9:31 am

Re: Introducing the VeriSNES (FPGA-based SNES)

Post by Shonumi »

MDMA -> Memory DMA -> Memory Direct Memory Access? Seems, err, redundant? I know next to nothing about the SNES, but I like jwdonal's thinking. "Main" DMA just clicks since it would be the "primary" DMA. At least Nintendo got their act together on the GBC and labeled stuff HDMA and GDMA :mrgreen:

Anyway, just popping in to say this looks like a really cool project. I remember seeing that HQ2x FPGA a while ago, so I'll definitely be watching this. Hope you get more graphics rendered soon!
fred
Posts: 67
Joined: Fri Dec 30, 2011 7:15 am
Location: Sweden

Re: Introducing the VeriSNES (FPGA-based SNES)

Post by fred »

This project looks pretty cool!

byuu wrote:The HDMA ones would have been here:
http://byuu.cinnamonpirate.com/temp/test_hdma.zip
http://byuu.cinnamonpirate.com/temp/hdma_midframe.zip
But unfortunately, Wayback Machine didn't grab them. If anyone out there has them, feel free to share here.
I... might have them, at least one of them. I remembered downloading a zip with various tests way back, and I even found it now. For hdma, it has test_hdma, test_hdmasync and test_hdmatiming.

Edit: added test roms as an attachment as per Tepples' suggestion.
Attachments
Test ROM.rar
(22.32 KiB) Downloaded 292 times
Last edited by fred on Thu Nov 24, 2016 11:08 am, edited 1 time in total.
Near
Founder of higan project
Posts: 1553
Joined: Mon Mar 27, 2006 5:23 pm

Re: Introducing the VeriSNES (FPGA-based SNES)

Post by Near »

Yes, those would be my HDMA tests! Thanks for saving them! :D

jwdonal, they should give a blue screen when they pass, and a red screen when they fail. Sorry they're so unbelievably terrible at being helpful as to what exactly is wrong. I never really intended for anyone else to use these, and I wrote them in 2005-2008.

A lot (but not all) of my test ROMs require perfect timing as mentioned earlier. That's because I have a function that seeks to exactly V=0,H=0; and then a function to seek by N cycles; and so I test the cycle right before and after state transitions take place.

The tests that do that will basically never pass in any other software emulators. But may well pass in yours :D

If I recall, test_nmi and test_irq were the most brutal of all test ROMs I made. Each of those had about 50 individual latching tests that went over the most insane behaviors you could imagine.

Further, I believe I failed to fully reset the SNES state on these earlier tests. So they might not show anything on bsnes/accuracy. Or maybe that's just a problem with the even older demo_* test ROMs.

Lastly, keep in mind another finding I've found. CPU revision 1 and CPU revision 2 have different trigger points for the HDMA init event. So the CPU revision of your console could play a role in things. But I think my test ROMs account for both modes?
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Introducing the VeriSNES (FPGA-based SNES)

Post by tepples »

PROTIP: You can upload zipfiles smaller than 2 MB as an attachment.
User avatar
jwdonal
Posts: 719
Joined: Sat Jun 27, 2009 11:05 pm
Location: New Mexico, USA
Contact:

Re: Introducing the VeriSNES (FPGA-based SNES)

Post by jwdonal »

byuu wrote:Further, I believe I failed to fully reset the SNES state on these earlier tests. So they might not show anything on bsnes/accuracy. Or maybe that's just a problem with the even older demo_* test ROMs.
Can you expand on this a bit more? I don't really understand exactly what you're saying...
Near
Founder of higan project
Posts: 1553
Joined: Mon Mar 27, 2006 5:23 pm

Re: Introducing the VeriSNES (FPGA-based SNES)

Post by Near »

The state of all memory and PPU registers is thoroughly randomized on initial power-on.

There's some patterning going on, and certain registers are forcibly set (eg the PPU display disable bit is definitely set), but others are left dirty or just uninitialized.

The earlier test ROMs just wrote the pass/fail color to CGRAM, turned the screen on, the BGs off, and called it a day. That worked in bsnes and on my Super UFO copier that initialized many registers through its loading BIOS.

But once bsnes/accuracy started randomizing the hell out of everything, it became obvious that to ensure a solid blue/red pass/fail screen, I needed to zero-initialize more registers. Specifically I believe the color add/sub and BG/window enable registers, but I went ahead and ran a loop to clear $2101-2133.

So because of that, my earliest test ROMs sometimes display a black screen when you load them. After a few resets, you'll get lucky with the register randomization and it works.

Note that I don't actually know which PPU register bits are initialized or not. So I randomize all but the display disable bit. I may be too aggressive compared to real hardware. But better too aggressive than too permissive.
User avatar
Reed Solomon
Posts: 7
Joined: Wed Dec 01, 2010 9:43 pm

Re: Introducing the VeriSNES (FPGA-based SNES)

Post by Reed Solomon »

jwdonal wrote:Hello all,

I'm really excited to finally share this with you. I've been working on implementing the SNES in an FPGA using Verilog HDL.
Exciting project. Hope something cool like the RetroAVS comes out of this. I've got a broken PAL SNES that I haven't bothered to repair (red light comes on with power, nothing else) , and who knows it might be easier to just keep it and simply replace the dead board with an FPGA board one day.
Kismet
Posts: 60
Joined: Wed Nov 30, 2016 9:59 pm

Re: Introducing the VeriSNES (FPGA-based SNES)

Post by Kismet »

jwdonal wrote:Hello all,

I'm really excited to finally share this with you. I've been working on implementing the SNES in an FPGA using Verilog HDL. In the past I've implemented an NES, SNES APU, HQ2X filter, etc in an FPGA so I figured full SNES was the next logical step. I've been making lots of progress and I wanted to share with you all the current state of the design.
Forum ate my original post.

I'm looking forward to this. Do you know how many logic units are currently used on the parts you've emulated so far? When complete would it fit on the MIST board (a board for emulating 16-bit game consoles/computers on a FPGA) or would it require a Cyclone IV or V board?

I think from a legal perspective I believe you're actually in the clear for everything but the PPU and CIC. The PPU doesn't contain any firmware, so as long as you haven't used any illegal information (eg leaked developer documentation) it should be fine. The PPU you make likely would work as about as good as the version of the SNES you captured data from (There are apparently two CPU's and three PPU2's according to console5 before considering the 1-chip.) The CIC is just a question of not copying the CIC firmware since Nintendo has won that battle before with the NES.

What I think should happen is if you open-source the CPU and SPC parts, there are existing open source cores for these out there already so it's worth knowing you produced accurate cores specifically designed for the SFC/SNES. I'd suggest adding a CPUID function in each core if that is viable. The PPU's I think isn't problematic so much as if you release individual FPGA versions of the chips, ASIC's could be produced.

But as for if clones would use them, I actually don't think they would. The Clones are in the market for people to play the games, they don't seem to care if they're accurate (or even last very long,) so things like the Retron 5 (a 50Mhz xilinx spartan xc3s50 FPGA and a 1.6Ghz Rockchip 3066 ARM Cortex-A9 ) and the RetroFreak (Two ARM chips , a 50Mhz nuvoton nuc220ve3an and a 1.6Ghz Rockchip 3066 ARM Cortex-A9 ) are just software emulators now. They apparently use SNES9x as their Super Nintendo emulators. The previous generation (Retro N and similar) basically just had ASIC clones. So they're not producing those anymore, and I'm not sure if that's because the parts aren't available, or if it's cheaper to just use an emulator on the ARM chip. This may be what the 50Mhz FPGA is for on Retron 5, to trick the CIC chip so that the ROM can be read. I don't own these devices, I just looked at PCB photos.

What I think there is a market for, is a high-quality FPGA-SNES Development board (with USB-C/HDMI/MHL connections for power/video) that can also be used to replace existing dead SNES PCB's with 3D printed new shells for those that are off-colored (or SFC shells that take SNES carts for those that never liked the SNES design.) I'm fairly certain there is at least enough people out there (I think you'd need at least 1000 to justify creating boards) that such a thing if it could be created for under $200 would justify the cost of producing it. Otherwise the alternative is just providing the necessary source (eg on Opencores) and just see if it grows legs and someone does it anyway. You'd want a way to at least identify what devices are made with it just so that if it's successful it can be identified from an original SNES.

The thing I'd do (just to "one more thing" any potential creditless-clones) is to implement a setup screen when no cartridge is inserted that shows what version of the FPGA source/chips is used.

But just to roll back a sec, I think for a HDMI output, there would need to be a HDMI-resolution aware PPU. VGA is fine when there are still monitors that support it, but 4K monitors do not (and we're rapidly seeing monitors with only DisplayPort/HDMI2/MHL.) The lowest resolution most HD and 4K monitors support is 640x480 which isn't a great fit for the SNES, but a 4K monitor needs a 9X multiplier , and scaling is much faster done in an ASIC on the fly than than it is running it through a pseudo S-ENC that does scaleing from the generated 240p since there is a HiRes mode that has more resolution. So I don't know if this would require a parallel PPU that performs a 1-20x scale on a pseudo-framebuffer or just copies all the draw commands using a tilemap that is scaled by the required size. At any rate this is just in the vein of "future-proofing as much as possible" since a conventional scalers in televisions/monitors tend to add too much latency and fuzziness (designed for VHS video, not video games.) TV manufacturers don't really care to test for supporting video games funny enough.

For audio, the one complication that HDMI adds is that any audio connected to the cartridge or expansion slot would need to be re-encoded digitally unless there is a way to emulate the chip that is generating the audio. So that might be an interesting thing to try for a FPGA-SNES development board, otherwise an ADC process would be required for the audio, and probably oversampling it to 48 or 96khz (32khz x3) for HDMI. 32Khz apparently might work with HDMI but hardware support is poor. Past a certain point, some things are overkill.

I'm looking forward to seeing what jwdonal produces. I recently decided to try and fix a few SNES systems and if it were possible to just create new PCB's that work with current generation TV's I think more people would be interested in just being able to play the games they have at whatever price. (The Retro N 5 and RetroFreak are just software emulators, hence the cheap price.) I'd be more than willing to figure out how to setup my own FPGA to try this, but there's not quite enough detail to know what FPGA's would work, and without a way to use it on a 4K monitor with HDMI2.0/DisplayPort/MHL connection, that means either letting the monitor scale it, or digging out a working CRT.
I come from the net. Through systems, peoples and cities to this place.
User avatar
Reed Solomon
Posts: 7
Joined: Wed Dec 01, 2010 9:43 pm

Re: Introducing the VeriSNES (FPGA-based SNES)

Post by Reed Solomon »

Too bad it'd be difficult to implement Nintendo Playstation stuff so that you could play games off CD.

Then put it in a Nintendo Playstation style case mold. :P
User avatar
jwdonal
Posts: 719
Joined: Sat Jun 27, 2009 11:05 pm
Location: New Mexico, USA
Contact:

Re: Introducing the VeriSNES (FPGA-based SNES)

Post by jwdonal »

Hello all. Next graphics progress update is posted. I haven't had much time to work on this but one small step at a time!

https://youtu.be/iio1GqIOf-o

Enjoy!
User avatar
jwdonal
Posts: 719
Joined: Sat Jun 27, 2009 11:05 pm
Location: New Mexico, USA
Contact:

Re: Introducing the VeriSNES (FPGA-based SNES)

Post by jwdonal »

H/V tile flipping has been implemented - here is a screenshot (no flipping, H-flip only, H&V-flip). Only took about 2min to do. Probably should have done it before I made the last video. Lol. ><
bf_flip_none.png
bf_flip_h.png
bf_flip_hv.png
Post Reply