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.
Hardware setup:- The entire SNES is hooked up to my TLA715 logic analyzer for investigation purposes. I have attached some images below for you to check out. My TLA715 supports up to 256 simultaneous channels @ 250MHz sample rate with a 64M sample buffer depth.
- I've primarily been using the SD2SNES for running my own custom test ROMs in addition to original carts for the most popular games.
- I'm using a Cyclone 4 FPGA, specifically the Terasic DE2-115 board.
Logic blocks that are completed:- S-SMP and S-DSP - I completed this some time ago. As far as I know it's the most accurate FPGA-based APU core ever created. I ran my Verilog implementation against Blargg's C-based APU core using an automated script for all 35,000+ SPCs on snesmusic.org and my Verilog implementation matched Blargg's output bit for bit.
- S-CPU 65816 - This is 100% complete and fully verified. I used SystemVerilog Assertions (SVAs) and a formal equivalence tool to verify proper behavior of every combination of internal register, opcode, and addressing mode on every microcycle. I wrote over 3,200 SVAs by hand from scratch for the formal equivalence checking. For those of you who don't know what formal equivalence checking is you can google it - but essentially it will literally create a formal proof which states that no matter what combination of inputs are given to a particular logic block that said logic block will never violate a particular assertion. If anyone is really interested I suppose I could show you what a simple assertion looks like, but without understanding the syntax it would be pretty useless. My 65816 core is probably the most accurate hardware implementation of an 816 ever created aside from the original ASIC. The CPU is fully microcoded for all instructions so it is very resource efficient.
- 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, but the HDMA was an
incredibly huge complicated pain in the ass. The way HDMA interacts with MDMA (stalling in-progress MDMAs or killing them), the multiple modes of operation, corner cases, etc, etc, etc. Suffice it to say, it sucked! There are probably a few clock cycle differences here an there in my HDMA implementation versus a real SNES but I got tired of working on it - I do intend on going back and fixing them but for now I wanted to move on to get some graphics working. It's at least 98% accurate which is good enough for me for now.
- S-CPU Dynamic Clocking - The ability for the S-CPU to dynamically switch between 1.79M/2.68M/3.58M depending on IO cycle, memory region, control register settings is 100% complete.
- S-CPU Joypad/Auto-Joypad interface is 100% complete.
- S-PPU1/2 Register files and Bus-B interfaces are 100% done.
- S-PPU1/2 VRAM/OAM/CGRAM interfaces are 100% done.
- S-PPU graphics background/sprites = 1% (i.e. one) done. Haha. I've only just spent a few hours on this so far. You can see the very buggy initial results for mode 0 in the video below.
- S-WRAM - Both A-bus and B-bus interfaces are 100% complete and verified.
- Standalone FPGA-based affine transformation and perspective projection (i.e. mode 7) implementation is complete. I made this just to see if I could do it and it turned out to be super cool and I learned a lot. The code will be extremely useful and portable to the mode 7 logic in the SNES. I am 100% confident in implementing mode 7 once I get to that point. I've provided a video link to a demo of this code.
Miscellaneous items:- Created over 30 original test ROMs with pass/fail conditions. Approximately 8 of those test ROMs (about half are HDMA tests) will only pass on my VeriSNES and a real SNES, no other emulators can pass them including bsnes/higan with accuracy profile - this is primarily thanks to my logic analyzer setup where I can see everything happening on a per clock-cycle basis. This might sound cool but it has actually made development quite a bit more difficult since I can no longer rely on BSNES/Higan for the accuracy I need when comparing tracelogs (for one example). Instead I'm basically forced to use my logic analyzer for almost everything...but in the end I suppose that's probably better anyway.
- I'm actually able to load and run nearly every single game that I test out (as long as it doesn't require a special enhancement chip). Even though I have no graphics output I can still hear the attractors/demos running (since my APU core is 100% complete). I can even interact with the games using the joypad, for example in SMW I can press the start button, select a level, jump around, collect coins, kill enemies, etc I just can't see anything. Lol. I actually also played LoZ blind while running a software emulator simultaneously and matching button presses. I was actually able to get all the way to the dungeon where Link meets his father and picks up the sword - at that point I just stopped playing but it was super fun to do!
- I've captured 100s upon 100s of GBytes of logic analyzer traces covering nearly every aspect of the SNES hardware and its behavior including odd corner cases and other esoteric behaviors.
- I am actually implementing each of the S-PPU chips individually just as they are implemented in the original SNES as opposed to one combined humongous PPU1+PPU2 blob of logic. This forces me to critically think about exactly how the two PPUs are communicating with each other in order complete a particular task.
Next to be implemented:- Most common video/background modes, then sprites.
- I started with Mode 0 because it was the simplest and most straight forward so I'll probably finish that off first and then move on to Mode 1.
YouTube videos for your viewing pleasure:Introduction to the VeriSNES (w/ first ever graphics output!) -
https://www.youtube.com/watch?v=sRVRcXRQkGAFPGA-based Affine Transformation and Perspective Projection (SNES Mode 7) Demo -
https://www.youtube.com/watch?v=e6UhJ3qV2aITimelapse of MDMA Verilog Implementation for FPGA-based SNES -
https://www.youtube.com/watch?v=Yo0t6hAjARUTimelapse of HDMA Verilog Implementation for FPGA-based SNES -
https://www.youtube.com/watch?v=YcNFs0r1oz8Request: If anyone has any clues or ideas whatsoever what is causing the Bad Apple demo to run so slowly I would love to hear them. I'm hoping it's as simple as just being some register/feature I haven't implemented yet which is causing the issue. Remember that this is a hardware emulator, not software, so it's not an issue with the VeriSNES slowing down under load or anything - hardware always runs at a constant rate regardless of what it's doing. Here is a link to the exact time index where I start the Bad Apple demo.That's all for now!
On the whole, congrats and best of luck in the future with your project!
Quote:
- S-SMP and S-DSP - I completed this some time ago. As far as I know it's the most accurate FPGA-based APU core ever created. I ran my Verilog implementation against Blargg's C-based APU core using an automated script for all 35,000+ SPCs on snesmusic.org and my Verilog implementation matched Blargg's output bit for bit.
Then it's probably
very wrong, because although blargg's DSP is basically perfect in the digital realm, his SMP has several very severe issues. To the point where even with 50+ hacks, Snes9X had serious SMP regressions upon using it. A big part of the recent release was replacing his SMP core with mine.
(The only imperfection in the DSP core is that the DSP mute flag controls an analog component that sits beyond the output of the digital audio, and is done after mixing in the cartridge and expansion port audio. As a result, the effect is neither immediate nor instantaneous.)
Quote:
- Created over 30 original test ROMs with pass/fail conditions. Approximately 8 of those test ROMs (about half are HDMA tests) will only pass on my VeriSNES and a real SNES, no other emulators can pass them including bsnes/higan with accuracy profile - this is primarily thanks to my logic analyzer setup where I can see everything happening on a per clock-cycle basis. This might sound cool but it has actually made development quite a bit more difficult since I can no longer rely on BSNES/Higan for the accuracy I need when comparing tracelogs (for one example). Instead I'm basically forced to use my logic analyzer for almost everything...but in the end I suppose that's probably better anyway.
I sincerely hope you'll share them, along with some basic notes on what's going on. I'll be happy to try and pass all of your tests :D
I would be very surprised to learn of bugs that exist outside of the PPU per-cycle timing conditions. Especially the HDMA ... I even know about an edge case where if you have HDMA indirect enabled on the last channel, once HDMA terminates for the rest of the frame, it skips loading one of the address reload bytes and leaves the low byte in the high byte and zeroes out the low byte. That is some extremely obsessive attention to detail. And of course, I was the one that clocked out all of the CPU<>DMA clock synchronization stuff, the HDMA init trigger position changing between CPU revision 1 and 2, etc.
I would actually love to work with you to ensure you
can use higan to debug things against your real hardware logic analyzer logs. I'm especially very interested in doing this for the PPU, because that's something where I can't work out the timings from test ROMs alone.
I think we worked well together with the HQ2x simplification in the past. And I'm certain I could return the favor by explaining the PPU operation as best I can to you while you work on that part of your implementation.
byuu wrote:
Then it's probably very wrong, because although blargg's DSP is basically perfect in the digital realm, his SMP has several very severe issues. To the point where even with 50+ hacks, Snes9X had serious SMP regressions upon using it. A big part of the recent release was replacing his SMP core with mine.
It's unlikely that it's very wrong. I should have mentioned that I fixed well over 20 different bugs in both the SMP and DSP cores (moreso in the SMP as you say) based on my logic analyzer observations. So it's not Blargg's original source. I think I sent about half of the fixes to Blargg via email but didn't seem interested in fixing them at the time so eventually I stopped bothering to send them. :/ But Blargg was a great help to me when I was learning about the APU logic and helped me out a lot with understanding the C code.
byuu wrote:
I even know about an edge case where if you have HDMA indirect enabled on the last channel, once HDMA terminates for the rest of the frame, it skips loading one of the address reload bytes and leaves the low byte in the high byte and zeroes out the low byte.
Yeah, I've got that implemented already as observed on the logic analyzer. It's one of the absolute weirdest things that I've ever seen. I spent 30min trying to work out on paper how in the heck the HDMA controller could have possibly been designed to have that behavior and couldn't come up with anything.
It makes absolutely no sense whatsoever.byuu wrote:
I would actually love to work with you to ensure you can use higan to debug things against your real hardware logic analyzer logs. I'm especially very interested in doing this for the PPU, because that's something where I can't work out the timings from test ROMs alone.
I think we worked well together with the HQ2x simplification in the past. And I'm certain I could return the favor by explaining the PPU operation as best I can to you while you work on that part of your implementation.
Yeah, that sounds cool for sure. But first I want to knock out some more of the graphics logic cause I'm so excited to work on it - FINALLY!
Quote:
I should have mentioned that I fixed well over 20 different bugs in both the SMP and DSP cores (moreso in the SMP as you say) based on my logic analyzer observations.
Ooooh, okay. My apologies then.
Quote:
I think I sent about half of the fixes to Blargg via email but didn't seem interested in fixing them at the time so eventually I stopped bothering to send them. :/
Yeah, he unfortunately fell off the radar it seems. Along with TRAC, anomie, neviksti, and most of the true MVPs of the SNES emulation community.
At any rate, this is the first I'm hearing of test ROMs you have that I'm not passing.
So please let me stress that SNES emulation is my magnum opus in life. I've worked on many emulators simply because I've hit the limits of what I could do through my software testing.
I will
always be extremely interested in working with you or anyone polite to fix bugs in bsnes/higan as promptly as possible and will prioritize it above all my other projects :D
Also, if you want, I can tell you about some hardware edge cases you're probably unaware of that will ruin your month, heheh ;)
Quote:
It makes absolutely no sense whatsoever.
Yep. That's the SNES in a nutshell.
No matter what I try, I can
never predict how the SNES will actually behave. Even with all I know about how crazy it behaves, and trying to predict crazy things in return ... somehow, someway, the SNES
always manages to surprise me. Each and every time.
Quote:
Yeah, that sounds cool for sure. But first I want to knock out some more of the graphics logic cause I'm so excited to work on it - FINALLY!
Alright then, as soon as you're ready, please reach out to me when you can, especially about those test ROMs. I'm very excited to take a look at them, but I won't rush you. Have fun with the start of the PPU :)
byuu wrote:
A big part of the recent release was replacing his SMP core with mine.
Do you have a list or a revision log of the various bugs that you fixed in the SMP? I'm wondering if I can dig up my SVN revision logs for the fixes that I made to Blargg's SMP and compare them against your list. And/or maybe gmail still has the emails I sent to Blargg in my message history/archive...
Unfortunately, no. I didn't fix up his core, I simply rewrote a new one from scratch based on knowledge gained from my own emulator's core. BearOso then optimized out the cycle switch cases to merge those that lacked side-effects (and thus didn't need to synchronize with the CPU.)
Do you plan to make this public once it reaches some state of completion, or are you keeping it private for a product that you plan to sell?
This looks like a match made in heaven.
Ill be looking forward to seeing the progression of this project, and hopefully a final product I can purchase one day.
I'm not trying to derail this topic, but I couldn't help but think while reading this new topic, you appear to have the knowledge and resources to implement some of the special chips not available for the SD2SNES yet.
Just saying.
Looks like an interesting project. Just looking at how enthusiastic you guys are about the snes is worth reading
tepples wrote:
Do you plan to make this public once it reaches some state of completion, or are you keeping it private for a product that you plan to sell?
I would love for this community to have open source hardware
.. However I understand and respect the author's decision either way. There has been a closed sourced SNES FPGA variant shown in the past. Early this year I was working on the 65816 in verilog hoping to throw it on github but haven't got around to finishing it yet.
great project either way!
tepples wrote:
Do you plan to make this public once it reaches some state of completion, or are you keeping it private for a product that you plan to sell?
I definitely have no plans on selling any products. All of my FPGA projects I do purely for three reasons: 1) It's something I enjoy. 2) It improves my FPGA design skills and keeps existing skills sharp. 3) I get to learn new things that I wouldn't have learned otherwise. As far as making it public I probably wouldn't have any issue with that if I could be sure that some company/person wasn't going to steal the code and use it to make money - but let's face it, that's probably exactly what would happen.
Most importantly, I have no understanding of the legal issues surrounding the release of free cloned Nintendo hardware, cloned WDC processors (816 core), or cloned Sony processors (SPC700). That's a headache that I wouldn't want to deal with.
marvelus10 wrote:
I'm not trying to derail this topic, but I couldn't help but think while reading this new topic, you appear to have the knowledge and resources to implement some of the special chips not available for the SD2SNES yet.
I wouldn't be totally opposed to that as long as the source code was protected somehow (see previous comments) - the simplest way to do this would be to provide ikari with a pre-synthesized netlist of the enhancement chip logic targetted to his device which he could then integrate into his full design. The primary issue is that the SD2SNES uses a much older FPGA and the tools that support that chip don't support SystemVerilog only Verilog. So I would need to massage the code a little to only use Verilog keywords. This wouldn't be a huge effort but it's something that would need to be done before I could even synthesize, for example, the 65816 for that older FPGA.
defparam wrote:
I would love for this community to have open source hardware
As far as I understand all of the SD2SNES FPGA code is open source. As well as ludde's FPGA NES, that's open source and is up on github.
Presumably all relevant patents would have expired at least 5 years ago.
If you ever make it, I'll buy it. $200-300 USD would be a good range for it. Please make it happen, please!.
Oh, and adding SA-1 and SFX/2 support to the SD2snes would be heroic of you, if you ever decide to tackle it.
byuu wrote:
I sincerely hope you'll share them, along with some basic notes on what's going on.
Sorry for delayed response. I actually answered this question on #nesdev when kevtris asked me so I think I got wires mixed up in my brain like I had already answered this question - except an answer on #nesdev doesn't help people that are only on the forums.
The answer is yes, I will be sharing them. But I don't have an ETA on when this will be. I will need to clean up the code and most likely provide annotated logic analyzer traces so people even understand what's going on. That will take time and right now I want to spend time on super fun graphics logic!!!!
Do you have any of the HDMA/DMA test ROMs that you made that you could share as well?
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.
Quote:
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:
Quote:
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?
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:
Quote:
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.
> 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.ziphttp://byuu.cinnamonpirate.com/temp/hdma_midframe.zipBut 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
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.
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
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!
This project looks pretty cool!
byuu wrote:
The HDMA ones would have been here:
http://byuu.cinnamonpirate.com/temp/test_hdma.ziphttp://byuu.cinnamonpirate.com/temp/hdma_midframe.zipBut 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.
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?
PROTIP: You can upload zipfiles smaller than 2 MB as an attachment.
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...
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.
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.
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.
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.
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-oEnjoy!
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. ><
Attachment:
bf_flip_none.png [ 851.86 KiB | Viewed 4642 times ]
Attachment:
bf_flip_h.png [ 826.68 KiB | Viewed 4642 times ]
Attachment:
bf_flip_hv.png [ 812.45 KiB | Viewed 4642 times ]
jwdonal wrote:
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. ><
But then we wouldn't get to see how the PPU actually works, which I think is what that video demonstrates.
Kismet wrote:
But then we wouldn't get to see how the PPU actually works, which I think is what that video demonstrates.
Agree.
Nice to see that my old SNES stuff came to some use. The scrolltext in the VGM player uses 16x16 pixel tiles (with BG0's tile size being changed mid-screen using HDMA), but I guess you already knew that.
Also, cool project. I certainly hope that this could eventually lead to something like the AVS, even if it's someone else doing the productification.
mic_ wrote:
Nice to see that my old SNES stuff came to some use. The scrolltext in the VGM player uses 16x16 pixel tiles (with BG0's tile size being changed mid-screen using HDMA), but I guess you already knew that.
Nope, didn't know that. Now I know what feature I'm missing for it. Thanks!
Awesome progress so far! I'm really excited to see how things go with this, especially once you've got sprites implemented.
Keep up the good work!
Here's the latest progress update:
https://www.youtube.com/watch?v=6yXCgfyMJZoIn this update:
- Background Modes 0-5
- Coarse/Fine Vertical Scrolling
- Coarse Horizontal Scrolling
- 2/4-Screen Mirroring
Enjoy!
Here's the latest progress update. Short video - demos the addition of fine horizontal scrolling.
https://www.youtube.com/watch?v=26N--5H1PM0
jwdonal wrote:
Here's the latest progress update. Short video - demos the addition of fine horizontal scrolling.
https://www.youtube.com/watch?v=26N--5H1PM0It is really interesting how the fine scrolling is used for wavy effects.
Here's a new timelapse video of implementing background modes 0/1.
https://www.youtube.com/watch?v=fTSo530DxGEThis will probably be my last timelapse video for the VeriSNES. While they're pretty cool (at least I think anyway) they're kind of a hassle and I'd rather spend the extra time writing code than producing timelapse videos. Heh.
Kismet wrote:
jwdonal wrote:
Here's the latest progress update. Short video - demos the addition of fine horizontal scrolling.
https://www.youtube.com/watch?v=26N--5H1PM0It is really interesting how the fine scrolling is used for wavy effects.
You've never done wavy effects on a raster based console before?
Here's another video - subscreens and brightness control:
https://youtu.be/6Qc7DbihXiwIf anyone is interested in helping me out I would love to hear any ideas on what the heck might be going on with the weird bug in LoZ @ 6:11.
I love how hung up you got on that...
The problem isn't you, it's the people who (haphazardly) made the game. There is actually a blank tile and a color palette entry that mirrors color 0. In fact, there are multiple of them: (the color of the blank tiles don't necessarily have the same value, but some of them do. Also, the first palette entry of that one palette can't show anywhere, but it's not black like the rest of them.)
Attachment:
Vram.png [ 28.18 KiB | Viewed 3934 times ]
Attachment:
Cgram.png [ 1.64 KiB | Viewed 3934 times ]
Oh yeah, I looked, and all the BG layers are using 8x8 tiles for the tilemap, so there's absolutely no reason for duplicated tiles. Cgram is also a complete mess.
That's interesting. So if I understand you it seems like this problem actually will be fixed after I implement the color add/sub feature.
Yup. It was pretty fun learning how big of a mess Legend of Zelda a Link to the Past was though!
Thank you very much for the insight on that Espozo! I'm also super impressed with how quickly you figured that out.
First, Merry Christmas!
Second, new progress video is now available! Added support for 16x16 tile sizes for backgrounds!
https://youtu.be/kTT9v355Z4I
jwdonal wrote:
First, Merry Christmas!
Second, new progress video is now available! Added support for 16x16 tile sizes for backgrounds!
https://youtu.be/kTT9v355Z4Iis this like the avs is this a hdmi snes but based on the snes jr rgb but maybe better?
^^
I think if you'd bothered to read the first post in this thread that question would be answered already.
It's an FPGA SNES system, being designed from scratch. It has nothing to do with any RGB mods, but it is similar in concept to the AVS (which is also an FPGA system).
New progress video. Enjoy!
https://youtu.be/LNrlmb6excwIn this video:
- Mode 5
- True Hires
- Pseudo-Hires
- Overscan
- Interlace
Note: Regarding my comments on Secret of Mana, I learned after I made the video that Secret of Mana uses direct color mode which I don't have implemented yet. So that explains at least some of the graphics weirdness. It also uses Mode 7 in the intro sequence which is why half of the screen is missing during part of the intro.
Thanks again to tepples for helping me with understanding the weirdness of mode 5!
The "smushed" background on the Mode 0 screen is because the test normally displays a row of sprites both with and without sprite interlace (bit 1 of $2133). Enabling this also requires setting the normal interlace bit (bit 0), but this bit is only supposed to double the number of visible background lines in modes 5 and 6.
Revenant wrote:
The "smushed" background on the Mode 0 screen is because the test normally displays a row of sprites both with and without sprite interlace (bit 1 of $2133). Enabling this also requires setting the normal interlace bit (bit 0), but this bit is only supposed to double the number of visible background lines in modes 5 and 6.
Awesome! Thanks for the tip. Much appreciated.
Now if I can ever get to working on sprites...haha. Nintendo really threw the kitchen sink (or two) at this sytem. So many features
Thanks for the videos. Its great seeing the progress.
How does the SNES actually output the 512 Hires mode? It outputs 341 dots per scanline which normally has 256 active pixels and I haven't been able to find how it can output 512 pixels per scanline.
Each pixel is 4 master clocks long. In hi-res mode, it instead outputs each pixel for two master clocks.
So that means it outputs 682 dots per scanline in Hires mode right? Does the pixelclock get increased in Hires mode from 5 to 10MHz to be able to do that?
Another way to view it is that the background video output is
DDR (double data rate) in hi-res mode, changing on both rising and falling edges of the pixel clock. The sprite pixel still changes once every dot (4 master clocks).
Hello all,
I haven't posted an update in a while but don't worry I've been hard at work! Here is the latest progress update demo:
https://youtu.be/1gNflzKp49oIn this video:
- Background Modes 2/4/6
- Offset Per Tile Logic
- 8x8 Multiply, 16x8 Multiply, 16/8 Divide
- 2 major bug fixes (1 graphical, 1 related to MDMA)
- Other misc
Enjoy!
I had a request for a Tetris Attack demo for offset per tile mode. Here it is!
https://youtu.be/hYb4REKBHZIEnjoy!
I'm really excited to see that somebody could make true one of my dreams since 2006... A full SNES in a FPGA!! I always wanted to make something like this on my own, but using VHDL and Xilinx devices (I have got more than 15 years experience with both), and even started a similiar project in 2010, although my first module was a CVBS encoder which outputs FI-modulated PAL and NTSC signals. After that, I started to study the PPU, but it was far too complicated than expected, so I dropped.
By the way, are you planing to add some tweaks to improve SNES performance? I mean, it could be nice to have an "accuracy profile" and a "performance profile" in order to have a beefed-up SNES, but still compatible: faster WRAM access, DMA at full speed (i.e., at the maximum clock frequency your system works), FIFO-buffered byte transfers between CPU and APU for faster sample transfer, expanded VRAM size...
Hope we all can see this amazing project completed!
Performance enhancements would certainly be possible since the hardware is fully programmable but the real question is what games would use them? The answer is none - at least not any official ones anyway. So while it's a cool thing to think about, there would really be no point in doing it.
jwdonal wrote:
Performance enhancements would certainly be possible since the hardware is fully programmable but the real question is what games would use them? The answer is none - at least not any official ones anyway. So while it's a cool thing to think about, there would really be no point in doing it.
That's not exactly true: Treasure Hunter G has a DMA queue which allows some DMA transfers be delayed to next NMI if there is no more VBlank time left. If DMA could execute faster than the original SNES, then we could measure improves in all games than implements such a queue (I guess THG isn't the only one).
And the same with FIFO-buffered accesses to $2140/41/42 to send samples to APU. Most games use
this scheme to send samples, so buffering acceses could reduce the latency to the most: each time SNES CPU puts a byte into $2140, it is buffered so it is acknowledged inmediately from the APU (FIFO) side. This, again, reduces CPU load and increased performance could be measured.
Besides, it could be used for new homebrew development, which would be nice
Interesting... didn't know about those.
Certainly for some games that are horribly slow, like StarFox for example, some performance improvements that could be optionally enabled/disabled would be worth looking into.
Next progress update.
Mode 7...'nuff said.
https://youtu.be/c8r58jAwWRw
Question?
Since the 65816 doesn't have the NMOS vs CMOS issues we have on other devices and the SNES uses a stock 65816. Why not just use a modern 65816 chip they you can get for $9 from WDC, and free up space on the FPGA, or shrink the FPGA to save costs? You might be able to fit two 65816s on the board and then put the SA-1 extras in the gap in the FPGA to emulate the SA-1 modes.
Oziphantom wrote:
Question?
Since the 65816 doesn't have the NMOS vs CMOS issues we have on other devices and the SNES uses a stock 65816. Why not just use a modern 65816 chip they you can get for $9 from WDC, and free up space on the FPGA, or shrink the FPGA to save costs? You might be able to fit two 65816s on the board and then put the SA-1 extras in the gap in the FPGA to emulate the SA-1 modes.
I suspect it's a combination of:
1. That defeats the purpose of emulating it accurately (what bugs may have been fixed in a new core?, What bugs need to exist?)
2. Voltage issues.
3. If you license the actual CPU core used in the SNES, you make the project's legality questionable since licensed cores can't be redistributed (NDA contract and all.) At least one previous FPGA-SNES attempt by another party used licensed a WDC core.
(All patents on SNES hardware should have expired between 2011 and 2014)
But for now he's developing it on a $600 FPGA development board. If at some point someone wants to try building a SNES using a mixture of old and new parts, they could try that, but you're basically looking at multiple problems that need to be solved before it even gets there, that's why it makes more sense to just build the CPU core to spec in the first place on the FPGA.
There are different goals when you want to emulate the device accurately, versus cheaply. Cheap is why you get clones that damage your cartridges and don't work with expansion chip games.
* The SNES has some kind of memory-mapped multiply-divide, which means that likely complicates using an off-the-shelf 65816, but someone who actually knows how it works would know better
It wouldn't matter, as the Super NES also has a DMA unit. Both are memory mapped I/O, and both would need to be in a custom memory controller in any clone, whether the 65816 is integrated or not.
Yeah, the
S-CPU has a lot of custom stuff on it. I assume you could mod a standard 65816 into a 5A22 via FPGA wizardry, but it seems like it might be better to just do the whole thing on the FPGA.
The extra stuff is analogous to a
memory controller hub. I agree that it's probably more convenient when assembling the system to put everything, including the 65816, into the FPGA. But assuming compatible voltages, you can use a discrete 65816 during development and then just reimplement the memory controller part in the FPGA until you finish cloning the 65816.
A strange new source file for the VeriSNES just appeared on my computer...what on Earth could it mean??
Attachment:
spr_fetch.PNG [ 1.71 KiB | Viewed 3097 times ]
jwdonal wrote:
A strange new source file for the VeriSNES just appeared on my computer...what on Earth could it mean??
Attachment:
spr_fetch.PNG
You programmed it up in a coke-induced frenzy, passed out on the keyboard, and you don't remember a bit of it this morning?
I guess Coke makes Sprite in more than one way.
330 mL - Photo by Emilian Robert Vicol
jwdonal wrote:
A strange new source file for the VeriSNES just appeared on my computer...what on Earth could it mean??
Attachment:
spr_fetch.PNG
Honestly, I have no idea why you're so excited about adding lemon-lime flavored soft drinks into your FPGA SNES.
7-Up just makes no sense to put on an FPGA.
syboxez wrote:
7-Up just makes no sense to put on an FPGA.
They wanted to experiment with
bubble memory.
(I'll see myself out)
syboxez wrote:
7-Up just makes no sense to put on an FPGA.
David Perry disagreed
jwdonal wrote:
A strange new source file for the VeriSNES just appeared on my computer...what on Earth could it mean??
Attachment:
spr_fetch.PNG
Pun aside, I'm guessing you have a new routine that fetches the sprite data from VRAM and OAM to hardware timing standards (at least what you could measure).
KungFuFurby wrote:
Pun aside, I'm guessing you have a new routine that fetches the sprite data from VRAM and OAM to hardware timing standards (at least what you could measure).
Ding ding ding. We have a winner!
Hello everybody!! I've got some sprite progress to share with you. This is my first crack at implementing the sprite logic. I've done no verification on the code at all. I just threw some code together based on what I understood and synthesized it to see what would happen. Enjoy! (Just don't expect too much...haha.)
Very first attempt:
https://www.youtube.com/watch?v=_OoYBRM2aO8Second attempt with 1 quick major bug fix that I found:
https://www.youtube.com/watch?v=n-DwnZRvxf4
Looking good. Do you know why you're getting those sprite columns that fill the entire screen? Seems to only happen for some sprites.. Perhaps related to the sprite size?
mic_ wrote:
Looking good. Do you know why you're getting those sprite columns that fill the entire screen? Seems to only happen for some sprites.. Perhaps related to the sprite size?
Yes, I know why it's happening now. There are actually 2 separate reasons that it's happening. I fixed one of those problems. I'm going to fix the other one next.
Here's an update video with the 1 major bug fix. Enjoy!
https://www.youtube.com/watch?v=mxAAdJ5riXE
jwdonal wrote:
mic_ wrote:
Looking good. Do you know why you're getting those sprite columns that fill the entire screen? Seems to only happen for some sprites.. Perhaps related to the sprite size?
Yes, I know why it's happening now. There are actually 2 separate reasons that it's happening. I fixed one of those problems. I'm going to fix the other one next.
Here's an update video with the 1 major bug fix. Enjoy!
https://www.youtube.com/watch?v=mxAAdJ5riXEAwesome to see the progress here. Games are playable now!
Hello all!! I've got a MAJOR sprite improvement video for you! In fact, sprites are so good now that I probably won't do anymore sprite update videos!
https://www.youtube.com/watch?v=5raMtSn9b68WARNING: Apologies in advance for what a total dork I sound like throughout the video but I was sooooooooooo excited to be able to play all these games after so many *years* of developing the VeriSNES. So please forgive the shouting for joy in some places.
Haha, yeah, you certainly are giddy. But it's the result of your own hard work, so you're entitled to make whatever noises you want. ;-D
ccovell wrote:
Haha, yeah, you certainly are giddy. But it's the result of your own hard work, so you're entitled to make whatever noises you want. ;-D
I'm pretty certain Link's not-powered-up sword really does just look that dumb.
lidnariq wrote:
I'm pretty certain Link's not-powered-up sword really does just look that dumb.
Wow, you are totally right. I never noticed that before. In any case, good to know it's not a bug!! Lol
Excellent work. I also totally know how you feel watching the video. When you accomplish something, sometimes that's the best feeling in the world. Keep it up!
Erockbrox wrote:
Excellent work. I also totally know how you feel watching the video. When you accomplish something, sometimes that's the best feeling in the world. Keep it up!
Thanks!
Getting close to another milestone!!!
Attachment:
burn_in_test_result.png [ 549.75 KiB | Viewed 2631 times ]
Once I finish with sprites I'm going to attack that HV Timer issue with NO MERCY!
I'm done with sprite logic implementation...for now. Here's a final gameplay demo:
https://youtu.be/hg4AATPeNDMCya!
This is coming along great. Definitely one of the projects I'm #1 excited for this year.
This looks amazing so far. Can't wait to see more of it.
This thread has been a joy to follow. Very exciting stuff!
Thanks for the kudos everyone! Still actively working on it!
I'm starting to just barely encroach on the accuracy barrier where I'm having to modify the timing of various signals in order to get things "just right". So development is slowing down a bit. Want to fix one more timing inaccuracy before I work on windowing and color math.
jwdonal wrote:
Thanks for the kudos everyone! Still actively working on it!
I'm starting to just barely encroach on the accuracy barrier where I'm having to modify the timing of various signals in order to get things "just right". So development is slowing down a bit. Want to fix one more timing inaccuracy before I work on windowing and color math.
sounds like you're close to finished are you adding hdmi to it?
creaothceann wrote:
HDMA isn't enough?
Not if the monitors available to you don't display the S-PPU's output correctly and promptly. Some refuse to recognize the nonstandard 240p signal entirely. Some deinterlace it as if it were 480i. Some delay it by several frames. Some have no S-Video input, without which one must fall back to composite with its color bleeding and edge artifacts.
tepples wrote:
creaothceann wrote:
HDMA isn't enough?
Not if the monitors available to you don't display the S-PPU's output correctly and promptly. Some refuse to recognize the nonstandard 240p signal entirely. Some deinterlace it as if it were 480i. Some delay it by several frames. Some have no S-Video input, without which one must fall back to composite with its color bleeding and edge artifacts.
creaothceann was making a joke about the similarity in names.
Hello friends!! It's been a while! But I have something very special to share with you!
A MAJOR MILESTONE!
https://www.youtube.com/watch?v=jllSzM24zxcI'll let the video speak for itself!
Cya!
As promised in my last video here is Part 1 (of 3) of my next official graphics update videos!
https://www.youtube.com/watch?v=RuZ7T5cB2EkEnjoy!
And without further ado, here is part 3 (of 3):
https://www.youtube.com/watch?v=GulyOa2D81AEnjoy!
And one more. This is the latest (highest quality) Bad Apple Demo running on my FPGA SNES.
https://www.youtube.com/watch?v=9UQby3WLI-oThis will be the last progress update video for a while.
Enjoy!
Some thoughts on the games you mentioned having input problems in the second video:
- SMAS SMB1 waits for $4212.0 to be cleared, then writes zero to $4016, but then reads input from $4218+ instead
- Donkey Kong Country and Equinox write zero to $4016 during screen transitions for some reason, but otherwise don't use it
- Super Bomberman uses auto joypad read but also uses $4016/4017 afterwards, probably for multitap support
- Zoop also does reads and writes with $4016 at some point but I don't know what for.
I suspect that writing to $4016 is messing up auto joypad read somehow.
Thank you very much for that info! I'll look into that right now!
EDIT: If I can get inputs working on those games it would definitely be worth doing another update video.
jwdonal wrote:
And one more. This is the latest (highest quality) Bad Apple Demo running on my FPGA SNES.
https://www.youtube.com/watch?v=9UQby3WLI-oThis will be the last progress update video for a while.
Enjoy!
Is it supposed to have extreme reverb/echo? Or is that the recording or youtube or something else?
Yeah, the echo/reverb is quite prominent. That's how it actually sounds. I tend to like how it sounds so I guess I never really thought about it much.
Revenant wrote:
I suspect that writing to $4016 is messing up auto joypad read somehow.
Your assessment was right on! All of those games are working now! Thanks a lot! Here is another update video demonstrating those games.
https://www.youtube.com/watch?v=y138gA-EddMEnjoy!
Except for the occasional glitch like the background of SMB All Stars and the lack of transparency in Secret of Mana and F-Zero, it is increasingly hard to believe that there is no genuine Nintendo hardware being used beyond a gamepad (an SD2SNES is being used for games). FPGAs have come a long way indeed.
Can you capture in 60fps? Watching 30fps is really choppy, even 720p/60 is better.
The trouble with high motion on YouTube is that it doesn't serve high-motion in 480p or smaller. You have to self-host in order to make 60 fps available to viewers with displays smaller than 1280x720 or CPUs not fast enough to decode 56 Mpx/s, such as my 1024x600 pixel Atom netbook or a 1024x768 pixel Android tablet. I did the math a few days ago, and self-hosting 1.5 Mbps SD video on AWS S3 costs about $1 per thousand viewer minutes.
Great Hierophant wrote:
Can you capture in 60fps? Watching 30fps is really choppy, even 720p/60 is better.
I have no way of recording in 60fps I don't think. Either way the file size would be way too big for me to deal with and the uploads would take forever (and they already take several hours as is). Also, most of my videos are actually only 25fps in order to save on file size over 30fps. These videos aren't really meant for ultra HD viewing of SNES games, they're just meant to show people the general progress and new features that I add over time. Cya!
jwdonal wrote:
Great Hierophant wrote:
Can you capture in 60fps? Watching 30fps is really choppy, even 720p/60 is better.
I have no way of recording in 60fps I don't think. Either way the file size would be way too big for me to deal with and the uploads would take forever (and they already take several hours as is). Also, most of my videos are actually only 25fps in order to save on file size over 30fps. These videos aren't really meant for ultra HD viewing of SNES games, they're just meant to show people the general progress and new features that I add over time. Cya!
Hmm... If you are capturing it with a SA7160 (eg Micomsoft SC-512N1-L), you can capture it at 60fps. Most of the external USB devices are just fixed h.264 encoders and are not high quality in the least.
Basically the only way to get high quality video/audio onto youtube requires capturing directly to 50mbit h.264 and then uploading that to youtube. Youtube will wreck anything that isn't at least 720p.
Even when I've uploaded dosbox footage to youtube, the minimum you have to do is a 3x integer upscale to avoid becoming "360p" footage. Since it looks like you're capturing 1080p30 from what appears to be a desktop capture, I'm not sure you can really get away with 1080p60 unless you maybe leverage the GPU of the system.
But GPU encoders tend to trade off speed as well, though tend to be better than USB devices. If you can get them to work at all.
jwdonal wrote:
Yeah, the echo/reverb is quite prominent. That's how it actually sounds. I tend to like how it sounds so I guess I never really thought about it much.
Really? I don't consider myself extremely picky about audio but it sounds horrible. The source here:
https://www.youtube.com/watch?v=UkgK8eUdpAo sounds much better. Of course I know you're just showing a demo that isn't yours. I thought there was a SNES Bad Apple demo that sounded better than that. It's so much echo it's like it's distorted or something.
But you've made great progress on your SNES FPGA clone. From your latest videos it seems like Windowing and Color Math will really help out with some of the games that currently have graphical issues.
I only have experience capturing analog composite and s-video. I capture game video at 720x480i @ 30fps, deinterlace it to 720x240p @60fps, then scale it to 878x720p @60fps (with horizontal borders to 1280 to preserve aspect ratio). The file sizes tend to get large when taking the video uncompressed, it is probably 1GB/minute.
Now if you are capturing digital video, 1024x720p/60fps (with borders to 1280) would be the best way to go if you don't have a 1080p/60fps source or capture device. Given we are talking about 256x224 @ 15-bit color upscaled graphics most of the time on the SNES, a codec like DOSBox's ZMBV should drastically cut down the file size.
Great Hierophant wrote:
I only have experience capturing analog composite and s-video. I capture game video at 720x480i @ 30fps, deinterlace it to 720x240p @60fps, then scale it to 878x720p @60fps (with horizontal borders to 1280 to preserve aspect ratio). The file sizes tend to get large when taking the video uncompressed, it is probably 1GB/minute.
Now if you are capturing digital video, 1024x720p/60fps (with borders to 1280) would be the best way to go if you don't have a 1080p/60fps source or capture device. Given we are talking about 256x224 @ 15-bit color upscaled graphics most of the time on the SNES, a codec like DOSBox's ZMBV should drastically cut down the file size.
Pillarbars are bad practice. This is because if you view it on a device like an iPad it will wind up window-boxed.
Mainly if you are capturing from an analog source, you capture with a lossy codec because the analog noise compresses better with a light lossy codec. If you are recording from a completely digital source (eg an emulator, or HDMI/DVI) then you need to capture using a lossless codec, of which ZMBV is only good as the CPU speed of one core. You CAN however upload ZMBV directly to Youtube, but you need to have key frames every 5-10 seconds to ensure it can be seeked. A lot of testing with ZMBV suggests you can get away with at most 720p with ZMBV, after that, google's on-the-fly transcoding process can't keep up. The key thing to remember is that ZMBV in DOSBOX's key attribute is that it delta-frames not only the visual data, but the palette as well on 8-bit color. The SNES requires 16-bit color and delta frames using ZMBV.
Hence, if you are trying to create the smallest seekable, lossless, file ZMBV probably the only option that works for 2D games. 3D games are better off going straight to h.264/AVC or VP8/WebM because a lossless compression only benefits the HUD of the game.
I put the pillarbars there for two reasons, the first is to enforce a proper aspect ratio. The second is to tell Youtube that I am sending it 720p/60fps and want to have it display that framerate. When Youtube first began supporting 60fps, I think I had to do that to make the service support the higher framerate.
DOSBox's default color encoding encodes 8 bits for Red, 8 bits for Green & 8 bits for Blue. The default display mode is VGA, which uses 6-bits for each color component. So 16-bit color cannot fully capture all the palette choices a VGA card could use, hence 24-bit.
This looks fantastic. I too have the DE-115. Would you be willing to share the binary image for testing?
Also, I don't know if you've seen the Japanese guy who seems to have been working on something similar for a long time. I've reached out to him a few weeks ago but go no response.
http://pgate1.at-ninja.jp/SNES_on_FPGA/Ps I've previously ported a ZX spectrum fpga project to the DE2-115 so have a little experience with this stuff, but nothing like your insane skills.
Steddyman wrote:
This looks fantastic. I too have the DE-115. Would you be willing to share the binary image for testing?
Possibly. I will likely need play testers to find bugs for me. There are just way too many games to test and play through every single one of them. But that wouldn't be until after I finished the entire design and done my own final bug testing - which is still a ways out. At a minimum I'm going to do 100% play-throughs of SMW, SM, and LoZ. I'll probably throw a few others in there as well. My standard regression testing will be MUCH easier once I add Game Genie support, but I promised myself I wouldn't work on any other accessories/peripherals until the core system is done - I tend to fall down rabbit holes when I start working on miscellaneous feature additions. XD
Ok great. Just let me know when you are ready.
jwdonal wrote:
Possibly. I will likely need play testers to find bugs for me. There are just way too many games to test and play through every single one of them. But that wouldn't be until after I finished the entire design and done my own final bug testing - which is still a ways out. At a minimum I'm going to do 100% play-throughs of SMW, SM, and LoZ. I'll probably throw a few others in there as well. My standard regression testing will be MUCH easier once I add Game Genie support, but I promised myself I wouldn't work on any other accessories/peripherals until the core system is done - I tend to fall down rabbit holes when I start working on miscellaneous feature additions. XD
Could you not add a cartridge port and use a real Game Genie/Pro Action Replay/SD2SNES?
Or just apply the Game Genie codes to the ROM images.
syboxez wrote:
Could you not add a cartridge port and use a real Game Genie/Pro Action Replay/SD2SNES?
Sure, but that would require my making a custom board first. Right now I'm developing on a COTS board.
MottZilla wrote:
Or just apply the Game Genie codes to the ROM images.
Yes, I did that once. It was a little annoying/tedious to do by hand (especially if you want several codes enabled) so I stopped doing it. It would be cool if there was a utility that did it for you.
UPDATE: I just checked and it seems like these utilities already exist.
I'll look into this more...not sure if there is a standard (i.e. most popular) one that most people use for patching SNES ROMs?
jwdonal wrote:
UPDATE: I just checked and it seems like these utilities already exist.
I'll look into this more...not sure if there is a standard (i.e. most popular) one that most people use for patching SNES ROMs?
Historically IPS was the dominant format and I'm sure there's still new translations/hacks released as IPS only.
XDelta and BPS have certainly gained traction in the last decade or so, and I'm sure you can find patches in UPS and PPF format if you dig around enough...
jwdonal wrote:
UPDATE: I just checked and it seems like these utilities already exist.
I'll look into this more...not sure if there is a standard (i.e. most popular) one that most people use for patching SNES ROMs?
Dunno about standard, but uCON64 (
http://ucon64.sourceforge.net/) did the job for me when I needed to permanently apply a Game Genie code.
Hello all! I've got another graphics progress update for you! This time I demonstrate windowing and color math!
https://www.youtube.com/watch?v=rf54GwhjYkwEnjoy!
Now you're playing
with power the way it's meant to be played™
Here are some things I noticed:
- Demon's Crest has a nice effect
here-
F-Zero and
SMK show transparent digits
-
Turrican 2 has some nice effects (level transition, laser)
- SMW
1 and
2 have nice windowing effects for the keys
Thanks for the tips! I'll write these down for future reference. Here are some thoughts:
creaothceann wrote:
- Demon's Crest has a nice effect
here WOW!! O.o The title animation sequence is a
beautiful demonstration of color math. I wish I had known about it before I made the video!
creaothceann wrote:
-
F-Zero and
SMK show transparent digits
I can't play SMK yet since it requires DSP-1.
creaothceann wrote:
- SMW
1 and
2 have nice windowing effects for the keys
I can't play SMW2 yet because it requires SuperFX.
Chrono Trigger also has a nice effect where it
seamlessly fades a layer from opaque to transparent.
That game uses
a lot of tricks...
Hello all!
Here's my latest progress video. This one demonstrates the mosaicing feature.
https://www.youtube.com/watch?v=FHWNQMhp0zMEnjoy!
Here's something I've always wondered about mosaic and meant to write a test program for but never got around to it: does each BG layer have its own mosaic counter, or are they all tied together? IIRC the bsnes 'accuracy' and 'compatibility' PPU implementations disagree with each other on this, and I guess no games depend on it.
Here's what I mean: Set up the clip windows so that BG1 is visible on the left half of the screen and BG2 on the right half of the screen. Using HDMA, disable mosaic at the top of the frame, enable it for BG1 on scanline n, and enable it for BG2 on scanline n+1 (without changing the mosaic size, and leaving BG1 mosaic enabled). Do the two layers' mosaic blocks line up vertically, or are they offset from each other?
Since apparently SNES consoles are known to have CPU failures, have you considered using your work to use a FPGA as a CPU replacement? Obviously a whole system replacement is great too, but I was just curious if you think a CPU replacement working with the rest of the original hardware is a possibility.
Some info:
http://projectvb.com/nss/logs.htm
Will this have SA-1 support or Super FX support?
AWJ wrote:
Here's something I've always wondered about mosaic and meant to write a test program for but never got around to it: does each BG layer have its own mosaic counter, or are they all tied together?
I would imagine there is just 1 - at least that's the way I implemented it. I mean...it might be possible that there are individual counters...but I doubt it. I don't think it's really meant to be used that way so I doubt they'd quadruple the logic required just for mosaicing. But hey, we're talking the kitchen_sink++ of consoles so maybe there is. Why not write a test ROM and find out?
MottZilla wrote:
Since apparently SNES consoles are known to have CPU failures, have you considered using your work to use a FPGA as a CPU replacement?
I wrote the code with that idea in mind. The pinouts on my chips are identical to that of the original system. The primary issue to consider would be voltage level translators.
Erockbrox wrote:
Will this have SA-1 support or Super FX support?
Yes and yes. SA-1 will be trivial at this point. SuperFX is the real prize.
Oh man if you ever do SA-1 or Super FX, hope that you can share your code so that ikari can implement those chips in the SD2SNES
jwdonal wrote:
MottZilla wrote:
Since apparently SNES consoles are known to have CPU failures, have you considered using your work to use a FPGA as a CPU replacement?
I wrote the code with that idea in mind. The pinouts on my chips are identical to that of the original system. The primary issue to consider would be voltage level translators.
Excellent. And the possibility of SA-1 or SuperFX clones is even more awesome to hear.
DarkShock wrote:
Oh man if you ever do SA-1 or Super FX, hope that you can share your code so that ikari can implement those chips in the SD2SNES
This is one of my biggest requests, I have an sd2snes and I would love to play the SA-1 games and Super FX games on it. There are also some mario hacks which are SA-1 compatible only, I would love to play these on my console and currently I have no way of playing them on a real console.
Well, it's official, I just committed and documented the last core system feature for my FPGA SNES (direct color mode).
I guess now it's time to start working on FPGA PSX.
Just kidding, now it's time to start squashing some bugs and implementing other cool features that I've been wanting to add for the longest time!
In other news, I've been giving this a lot of thought and I'm considering starting a Patreon for this project to see if I can make this thing into a marketable product. There is still a TON of work to do, but I think doing something like Patreon would at a minimum achieve to primary things:
1) See if there _really_ is as much interest in a product like this as people claim
2) Keep me motivated to continue working on this project
But before I go down that route I'd like to hear from the nesdev community what it thinks about doing something like this.
Cya!
If you are doing a Patreon, think well about the rewards.
For example, discount on the future SNES FPGA you'd sell ^_^
jwdonal wrote:
Well, it's official, I just committed and documented the last core system feature for my FPGA SNES (direct color mode).
I guess now it's time to start working on FPGA PSX.
Just kidding, now it's time to start squashing some bugs and implementing other cool features that I've been wanting to add for the longest time!
In other news, I've been giving this a lot of thought and I'm considering starting a Patreon for this project to see if I can make this thing into a marketable product. There is still a TON of work to do, but I think doing something like Patreon would at a minimum achieve to primary things:
1) See if there _really_ is as much interest in a product like this as people claim
2) Keep me motivated to continue working on this project
But before I go down that route I'd like to hear from the nesdev community what it thinks about doing something like this.
Cya!
Congratulations, excellent work! I'd absolutely back that Patreon and if you decide to do it, I'll let everyone know about it. Also, if you'd like to explore other ways of getting this made, let me know and I can make some introductions.
Zonomi wrote:
If you are doing a Patreon, think well about the rewards.
For example, discount on the future SNES FPGA you'd sell ^_^
Well, the "reward" is supporting a developer that may eventually make a product you'd like to use. I wouldn't expect anything in return after donating...but that being said, early pre-order access would be a nice perk
Erockbrox wrote:
DarkShock wrote:
Oh man if you ever do SA-1 or Super FX, hope that you can share your code so that ikari can implement those chips in the SD2SNES
This is one of my biggest requests, I have an sd2snes and I would love to play the SA-1 games and Super FX games on it. There are also some mario hacks which are SA-1 compatible only, I would love to play these on my console and currently I have no way of playing them on a real console.
Maybe that can be a Patreon tier? If you get past a certain monthly amount, you'd work with Ikari on the SuperFX stuff? That's a long shot and wishful thinking...
I've never been motivated enough to support a Patreon or Kickstarter in my life but a really high quality SNES reimplementation would do it for me.
jwdonal wrote:
Well, it's official, I just committed and documented the last core system feature for my FPGA SNES (direct color mode).
I guess now it's time to start working on FPGA PSX.
Just kidding, now it's time to start squashing some bugs and implementing other cool features that I've been wanting to add for the longest time!
In other news, I've been giving this a lot of thought and I'm considering starting a Patreon for this project to see if I can make this thing into a marketable product. There is still a TON of work to do, but I think doing something like Patreon would at a minimum achieve to primary things:
1) See if there _really_ is as much interest in a product like this as people claim
2) Keep me motivated to continue working on this project
But before I go down that route I'd like to hear from the nesdev community what it thinks about doing something like this.
Cya!
Conglaturation!
Nice to see a fully functional FPGA SNES developed.
As for interest, have you seen the AVS, NT Mini, and the MIST? I can guarantee that there will be interest in an FPGA SNES. In fact, it could be the definitive way to play SNES, as it would (theoretically) be 100% accurate unlike the 1CHIPs and also have extremely sharp video unlike the 3CHIPs. I say go for it (just make sure it has analog RGB out for us CRT users).
Bonus points for built in flash cart like the NT Mini (SD2SNES is already open source [GPL v2] so a lot of that work is done already) and even more bonus points for SA-1 and GSU support. If you do start going that route, it would be greatly appreciated if you could share that work for the SD2SNES.
In addition to what the previous poster mentioned, I have read disturbing reports that the 3-chip models are not quite as reliable as you might expect, as in chips dying.
Great Hierophant wrote:
In addition to what the previous poster mentioned, I have read disturbing reports that the 3-chip models are not quite as reliable as you might expect, as in chips dying.
Yup. I have experienced that myself with one of my 3CHIPs having a burned out VRAM chip. Haven't replaced it yet since I took the cart connector from it to repair my SNES Mini, but I probably will if I can find a new cart connector.
I've heard other reports of dead CPUs and dead PPUs, both of which are not replaceable due to its proprietary nature (aside from FPGA replacements).
Regarding the PPUs, how accurate are they/will they get? Will edge-case stuff like DMA direct colour or mid-scanline BGMODE changes work the same as on the real thing?
syboxez wrote:
aside from FPGA replacements
Exactly.
93143 wrote:
syboxez wrote:
aside from FPGA replacements
Exactly.
The only problem is that drop in FPGA replacements for SMD chips might be a bit difficult to make. Even if it were made, I'm not sure how many people would even buy those replacement parts.
If other FPGA consoles are successful then yours will be too. It's just the nature of the market and the interest people have in these old consoles.
Hi, I have registered nesdev just to answer on this thread.
I already have a ZX-UNO FPGA board (which is great as has MSX, ZX-SPECTRUM, NES and ATARI 800 cores), a Minimig board (Commodore Amiga 500 + HDD FPGA reimplementation) and others.
What we need is not yet another FPGA board (we have the MIST, FPGA Arcade, etc...) but an open source SNES implementation, so the platform can really live on forever, on any capable FPGA board.
That said, I will contribute to the Patreon *if* an open source implementation comes from it. Have doubts? Look at the ZX-UNO project and how the interest on it EXPLODED literally after the world knew of the open source nature of the project. And it was a ZX-Spectrum, imagine the situation with a SNES reimplementation.
If it's not open-source, it's not of interest really: after the supposedly custom FPGA board has ceased production, we will be in hardware shortage again, and the only ones getting money will be the damn speculators, like vultures devouring a corpse, like they always do.
So, will ot be an open-source core or a custom board with a closed firmware? In the latter case, I think we had enough and don't count on me.
Custom board with open-source core is also good: you get the money, and the world advances towards SNES hardware freedom.
The Blender 3D modeling program was proprietary until its bankrupt publisher NaN agreed to let the community buy it from them for $100,000. The money was collected over the course of the third quarter of 2002, proving the viability of Internet crowdfunding and paving the way for Kickstarter in 2009.
So how much money would be just compensation for a free software license for this project?
tepples wrote:
The Blender 3D modeling program was proprietary until its bankrupt publisher NaN agreed to let the community buy it from them for $100,000. The money was collected over the course of the third quarter of 2002, proving the viability of Internet crowdfunding and paving the way for Kickstarter in 2009.
So how much money would be just compensation for a free software license?
I think the question of how much money varies from product to product. It also depends on how much the developer values their work.
Also open source does not necessarilly mean lack of money, especially in the retro gaming community. Just look at the SD2SNES, OSSC, MIST, and the previously mentioned ZX Uno. All of those are open source projects, and none of them see a substantial loss in sales as a result. I think that making the VeriSNES open source would not impact sales of a potentially new board design that includes this core. The MIST specifically benefits greatly from being open source as they can legally distribute GPL2 and GPL3 licensed FPGA cores for many other systems, giving their product much more value for the cost.
Also (to jwdonal specifically), I'm not aware of any legal issues surrounding releasing the verilog for this project, as you used clean room reverse engineering to develop it, and the fact that there are other examples of verilog being released for other reverse engineered consoles (including Nintendo consoles) such as minimig or FPGANES with zero legal repercussions.
Open sourcing the SNES FPGA core would be a great help to the community and would truely let the SNES live on forever.
Just chiming in to say that this is wildly exciting and that I'd happily throw some money into a Patreon to help ensure that work continues on it.
I'd support this as well. I'd probably prefer a Kickstarter with a timeline for a useable product, but I am open to Patreon as well.
I will especially support the project in any way if the goal is (also) to release an open source core.
tepples wrote:
The Blender 3D modeling program was proprietary until its bankrupt publisher NaN agreed to let the community buy it from them for $100,000.
This definitely caught my attention. To be honest, I didn't even know that people did things like this. And interestingly enough, I am not totally opposed to this idea. I just want _something_ for the many kilo-hours that I've spent on this crazy kitchen sink of a console. But realistically I don't think there's enough people that would contribute to achieve the dollar amount I have in my head. Lol. But maybe I'm dead wrong about that...
tepples wrote:
So how much money would be just compensation for a free software license for this project?
So I guess this is pretty much the most important question. I've actually put a lot of thought into this and estimated the number of hours that I've spent reverse engineering and writing code for this design over the last 5-6 years. The number I came up with after looking through all my notes and my RCS commits is conservatively around 8,000hrs.
I also ran count lines of code (CLOC) on the Verilog and it came up with 83,152. *Note: These counts don't include all of the C/C++/scripts/etc that was written to actually interface with the design and upload SPCs/ROMs.
I also have to consider the fact that there are numerous other applications for an open source FPGA SNES. Think of all of the practical educational value that something like this has for high school and university students. Or applications for other dev boards or flash carts like the MIST or SD2SNES as syboxez previously stated. Not only that but software emulators could improve their own code based on my hardware logic analyzer findings and they would in turn become more accurate.
The source code for the fully verified 65816 CPU alone is immensely valuable and has many potential applications outside of just SNES. And, yes, obviously an SA-1 could be made (I will be implementing that myself eventually). The 816 is arguably the most valuable core in the entire design. It's basically what discourages most people from even bothering to implement an FPGA SNES. And I totally get that - it is mind numbingly tedious and time consuming to implement all those opcodes with all the different modes of operation and figuring out all of the corner cases with how opcodes and registers interact with each other when dynamically switching between 8/16-bit modes.
So how much is ~8,000hrs, 83k lines of FPGA-vendor-agnostic Verilog code, and the myriad possible applications worth? Well, I don't know exactly, but having worked in industry doing FPGA design for over 15yrs now I do know in general what commercial companies charge for source code for their IP cores and it's not a small figure. In fact, the figure is so far from "not small" that I think it would actually turn the average person/retro-gamer off of contributing anything to the patreon if they saw such a large amount as the goal. Or as I stated previously, maybe I'm wrong about that. I've never done anything like this before, so let me ask you guys...what do YOU think it's worth? This would actually be a useful data point for me so please have at it.
Here is the number one biggest thing to me in relation to open-sourcing the code for an FPGA SNES....I would need to make enough money from releasing it that I won't feel bad about everyone that's going to steal it to make a commercial product or use it as a marketing attractor while giving me absolutely nothing in return. And let's be honest, we all know that it doesn't matter if I assign an open source license type that prohibits commercial use -
people are going to do it anyway (chinese clone makers I'm mostly talking to you).
Note that if a source code release did actually happen I would never make any claims that the source code is 100% accurate or any nonsense like that. Personally, I don't believe that 100% accuracy will ever truly be possible until all the chips are decapped. But I would certainly continue to make improvements to the code and fix any bugs that myself or others find during testing or normal use.
--
On a slightly separate note I would definitely need help picking the right open source license for something like this. All the different license options are confusing but I'm sure there's some knowledgable people here that could help me with that.
syboxez wrote:
Also (to jwdonal specifically), I'm not aware of any legal issues surrounding releasing the verilog for this project, as you used clean room reverse engineering to develop it, and the fact that there are other examples of verilog being released for other reverse engineered consoles (including Nintendo consoles) such as minimig or FPGANES with zero legal repercussions.
Agreed. I'm not particularly worried about this. Additionally, the patents for the hardware are well more than 20yrs old at this point.
With that said however, I do think I should probably change the name to not include the "SNES" acronym. Which is a little sad because I really liked the name "VeriSNES".
But I'm not SUPER attached to it (pun intended). If I was not receiving any monies for the project I wouldn't bother changing it. But because I would be collecting funds for it I don't want Nintendo to be able to say that I'm using their console name to make money. Anyone have further thoughts on this? I've thought of a couple other names already and had several others suggest new names as well.
syboxez wrote:
Open sourcing the SNES FPGA core would be a great help to the community and would truely let the SNES live on forever.
I agree. It would be pretty awesome. I would also of course continue to work on it even after the source for the core system was released because it's something I love to work on and I still need to implement the various enhancement chips (e.g. SA-1, SuperFX, etc).
Toni wrote:
I'd support this as well. I'd probably prefer a Kickstarter with a timeline for a usable product, but I am open to Patreon as well.
Fortunately, the product is already usable as can be seen by the numerous progress update videos on my youtube channel.
Again, it's _not_perfect_ and I never claimed that it was, but it will be (or as close as possible) eventually.
--
Back to the patreon campaign...I'm very open to suggestions/recommendations regarding various tier/reward levels. I really like retrorgb's idea of having early pre-order access for a product. I would like to eventually make a PCB design for it so something like that would work out well for early pre-order access.
And as a reminder (since this is a very long post) I would still like to hear opinions from the community on what you all feel the complete Verilog source code for an SNES system would be worth in USD.
And I'd also like thoughts on the name change.
In any case, that's enough typing for now. I guess I'll get to work on creating an intro video for the patreon page!
Cya!
Back of the envelope calculation: a skilled hardware engineer might make on average 200K USD per year; divide by 52 weeks and 40 hours a week, you get around $100 an hour. So $800000, then maybe round it up to a nice square million.
Now, that number doesn't personally turn me off. But I do also suspect that's on the low side compared to the commercial IP numbers. But then, to be honest - and I mean this with absolutely zero disrespect, I think what you've done is incredible - I'm not sure if a Verilog reimplemention of a nearly 30 year old video game system is as commercially valuable as most of that IP. Chinese (and even
American) clone makers would probably rather buy cheap ARM SOAC for pennies and stick a hacked up Snes9X on it than license your core and use comparatively more expensive FPGAs - not to mention Nintendo themselves doing that with their own in-house emulators. They might (?) be lower quality, but SNES hardware reimplementations
exist and are already on their way to market as complete products; and I'd wager kevtris at Analogue is hard at work on a Super Analogue NT (if not maybe get in touch with them about licensing, tbh). WDC
already licenses 65816 Verilog soft cores and I suspect for a multitude of reasons it'd be hard to compete with them on that front.
So my intuition is that - unless you're willing to quit your day job and start a company of some kind devoted to marketing this core or products using it, selling it to the open-source community might be one of the best ways to get recompenses for it.
Caveats: I'm an outsider to the hardware world, so my speculation might be entirely off-base. And I'm an open-source fan, so I'm predisposed to find reasons for you to open-source it. And I don't know the dollar amount that you have in your head - maybe my estimate of a million is a lot higher than you're thinking! And, on the flip-side, while I'd certainly be happy to throw some money towards a million and I think it's a fair number, I don't know if there's enough people with enough money who feel that way to reach that goal.
Whatever you do though, good luck. I really can't stress enough how cool I think this project is.
I don't have money to spare but if anything I would be more than up for creating couple PCB designs that are drop in replacements for existing hardware variations.
Just wondering, how many LE's (or equivalent) does the design take currently ?
adam_smasher wrote:
So $800000, then maybe round it up to a nice square million.
Okay, so I wanted to quickly reply and say that, while I appreciate the very generous estimate, this is wayyyyyy too much.
adam_smasher wrote:
I'm not sure if a Verilog reimplemention of a nearly 30 year old video game system is as commercially valuable as most of that IP.
This is correct, which is why $1M or even $800k is way beyond what I was thinking.
I might as well just go ahead and state the number I had in my head was somewhere around $400k (or maybe a little less) before taxes. If I could get somewhere around there I'd be fine releasing it to the world along with all the C/C++ code used to interface to the board, logic analyzer traces of the system behavior, etc. I also plan on porting it to another popular Xilinx dev board that I have here and also adding HDMI support in the very near future.
Now, are there enough interested people to get to that level of funding...? I have no idea whatsoever.
adam_smasher wrote:
WDC 65816 Verilog soft cores and I suspect for a multitude of reasons it'd be hard to compete with them on that front.
Interestingly enough I spoke with Bill Mensch about this several years ago before I started working on the 816. I was very surprised to learn that their Verilog soft core was written by a student intern many years ago and he said the quality was quite poor. It sounded like they couldn't even guarantee me that it was bug free. Lol. So needless to say I doubt that they sell very many of those. XD The original 6502/816 were never written in Verilog, it was all done by hand drawn schematic. I have no doubt that WDC's real money maker's are the original ASIC masks for the 6502 and 65816.
TmEE wrote:
Just wondering, how many LE's (or equivalent) does the design take currently ?
It's currently sitting around 26,000 Altera LEs. I'll know the Xilinx "slice" equivalent in the near future once it's ported to this Xilinx board I have sitting here.
Cya!
To answer the question about licensing, might I recommend dual licensing GPLv3 with a proprietary license?
Basically what I mean by that is that anyone may use the project however they please so long as they follow the GPLv3 license (must disclose source, cannot distribute with a closed system [Tivoization], must use the same license, must not restrict modifications, DRM must not be implemented in the system, etc.), but if say, a company wants to use the core in their closed project, then they can license the core from you for a fee of your choosing. This is what many projects do, including byuu's higan (
https://byuu.org/emulation/higan/licensing).
A quick summary of the GPLv3:
https://www.gnu.org/licenses/quick-guide-gplv3.htmlAlternatively, if you would prefer an open source license with a non-commercial clause (technically not open source), then might I recommend the license that SNES9x uses (modified permissive BSD style license with non-commercial clause), along with the dual licensing mentioned before?
https://github.com/snes9xgit/snes9x/blo ... icense.txtAs for stopping Chinese clones? Sadly, I don't think that's possible, regardless of whether the source is available or not. Just look at the clone EverDrives that are out there (the EverDrive line being completely proprietary).
I don't think that work hours are a good basis for the price; at least not if the goal is to release a console, not the Verilog code. Prices are formed by market demand, and the market demand for an employed engineer is different from the market demand for an FPGA-based SNES. The price for the latter is formed by the demand for the product and the value proposition of the competition (original SNES, emulators, etc.), not by the amount of work that went into engineering the system.
That's why I like the approach Analouge took with the NT Mini. It's not just a FPGA-based system, it's also a product that comes with all the secondary features you would want from a gaming console aimed at enthusiasts: digital and analogue connections, a multitude of video and audio output options (scaling, scanlines, etc.), a nice controller, a quality enclosure, etc. In other words: a system that actually looks like a console worth a premium price, not just a PCB with an FPGA. (It's debatable if Analouge actually deserved that premium image, but apparently it worked.)
I think a price of $500 - $600 would be in the ballpark of what enough people are willing to spend for such a product, especially when the product receives enough media attention; which a proper product is much more likely to receive. Worked for Analouge. I don't see why it wouldn't work here.
I'd be willing to spend that amount on a preorder.
Or team up with Analouge...
Since you have access to all the internals, your premium console could even support save states with perfect compatibility, could it not?
syboxez wrote:
To answer the question about licensing, might I recommend...
Thanks a lot for this info. I'll look more into the links you provided.
syboxez wrote:
As for stopping Chinese clones? Sadly, I don't think that's possible
Who said anything about stopping them? They certainly can't be stopped - that's what I'm saying.
Toni wrote:
Or team up with Analouge...
Teaming up with another vendor to port code to their hardware etc is actually very time consuming. I'm more inclined to just throw the working verified code over the fence if someone wanted to buy it outright or just release the source to the community. I work a full time job plus have my own consulting business so I have very little extra time. Releasing the source would make more sense and be more valuable to the community as a whole.
calima wrote:
Since you have access to all the internals, your premium console could even support save states with perfect compatibility, could it not?
Yes, it will have save state support. It's on my (very long) to-do list. I already know how to implement it, but it's competing with at least 10 other things right now.
Now if you could somehow design a drop-in replacement motherboard for the original SNES case that runs your code and offer it as a reward for a kickstarter at a price roughly around $100, you'd probably have to think about the $2 and $3 million stretch goals.
Because let's be honest a pure source code release is not very interesting to the general public and having a pcb designed is not that much additional work compared to what you have done so far.
Designing the PCB isn't much work, but sourcing parts and getting it manufactured at scale is.
syboxez wrote:
Basically what I mean by that is that anyone may use the project however they please so long as they follow the GPLv3 license (must disclose source, cannot distribute with a closed system [Tivoization], must use the same license, must not restrict modifications, DRM must not be implemented in the system, etc.), but if say, a company wants to use the core in their closed project, then they can license the core from you for a fee of your choosing. This is what many projects do, including byuu's higan (
https://byuu.org/emulation/higan/licensing).
This didn't stop a company from selling my emulator on Steam to emulate an old game they purchased a license to, and announce plans to do so again in the future with more game titles, without following the GPL licensing terms nor paying for a license exemption. He doesn't even give a mention on the Steam store that he's using my software, let alone provide a download link from the source. In fairness, someone found out via strings dump, and after e-mailing a few times, was given the source to the client. And unlike Snes9X, it doesn't generate public outrage when my license is violated.
But ... yeah. Don't trust the GPL to protect you, unless you have that $400,000 to go to court to enforce your copyright.
syboxez wrote:
Alternatively, if you would prefer an open source license with a non-commercial clause (technically not open source), then might I recommend the license that SNES9x uses (modified permissive BSD style license with non-commercial clause), along with the dual licensing mentioned before?
https://github.com/snes9xgit/snes9x/blo ... icense.txt
Yeah, I can name about a half dozen instances where their license was ignored. Including a major company selling it on a clone system, at least one popular Android emulator stealing their work, and depending on how you look at it ... the project on Patreon bringing in over $1,000 a month for a frontend to many emulators, including non-commercial ones. But then, reasonable people may disagree with me and claim that profiting on donations for repurposing non-commercial software is okay. But I do know that if I were to ever write a non-commercial license again, I'd explicitly carve out that donations weren't allowed either.
jwdonal wrote:
I might as well just go ahead and state the number I had in my head was somewhere around $400k (or maybe a little less) before taxes.
Would you be interested in selling the test ROMs you've made separately, which are claimed to fail in higan? I continue to remain very interested in those, and would be happy to try and help provide fair compensation for your work there. A software implementation is never going to compete commercially in the same market segment with a hardware implementation, so hopefully you won't mind disclosing those one day :D
I keep getting reports of SMW Central hackers managing to trigger bugs only on hardware, and test ROMs would be a hundred times easier to work with than trying to reverse engineer whatever's happening in those full-game ROM hacks.
byuu wrote:
This didn't stop a company from selling my emulator...
<break>
Yeah, I can name about a half dozen instances where their license was ignored.
Yep, nobody cares about license/rules. It's the wild west. People just take whatever they want.
byuu wrote:
Would you be interested in selling the test ROMs you've made separately, which are claimed to fail in higan?
"Claim"? What...you don't believe me? Haha. XD That's ok. I'll be happy to include all of them in the source release along with all of my other personal notes. Another incentive to get it funded!
Releasing them right now would be ill-advised as I'm sure some other commercial vendor's developers would love to get their hands on them.
Once I reach the funding goal then I've got no issue releasing them. I assume I'd just end up posting everything on a github page.
Ultimately, it doesn't matter to me either way if the source release is funded or not. If it is great! If not, great! I'm just having fun writing the code and learning how the SNES works. But I'm not going to give away massive amounts of work for free that will be used by others for profit.
But with that said I'm willing to make a funding page since people seem to really want this stuff released. I think the biggest issue would be getting enough publicity to get a relatively niche project funded to the required level.
In any case, right now I'm just trying to decide which crowd funding site to use. I was really liking the idea of Patreon because it could support me to continue work on adding more features to the core system, fixing bugs, implementing SA-1, SuperFX, etc. But there is one very minor issue with using Patreon - from what I can tell, there is no way to to show supporters the total funding received so far over the life of the project. All values shown are monthly including the goals themselves. I mean, I could tell people how far/close we are from the goal, but there's no reason anyone should believe me so that doesn't work. It really only works if Patreon is reporting it themselves as a third party.
I had also thought maybe kickstarter or indiegogo. On those you can set a total goal, but they only run for 30/60 days. So you run into the issue of getting enough publicity for a niche project over such a short period of time. I could do what they call a "flexible funding" campaign in which you are not required to reach the entire goal in order to receive the funds. If that happened then you can just run the campaign again...but then who's to say that the second campaign would get any more funding if the first one didn't even succeed? XD
In any case, I'm having fun learning about the crowdfunding stuff. I'm just kind of chewing on which option would have the most chance of success to get the code released to make everyone happy. The more I think about releasing the code the cooler I think it will be. We could even end up having some open source hardware designs to pair with the code (e.g. drop-in replacements for the motherboard, upgraded sd2snes hardware that can handle SA-1 and SuperFX, etc). Would also be great to be working with other systems testers who could report bugs (too many games to do it all myself!). Cool stuff!
But if I get too annoyed with thinking about it or it becomes too time consuming I'll just pick up where I left off and keep plugging away at the code!
Cya!
Quote:
"Claim"? What...you don't believe me? Haha.
Oh I most certainly believe you, or else I wouldn't be trying so hard to get them ^-^ In fact, I just found a new bug in the HDMA implementation of all emulators today. However, I won't say they're definitely issues until I confirm them.
Everyone has written a test ROM with bugs before.
It's just a little disappointing having to spend time doing more hardware reverse engineering myself if you already have the answers just sitting there :|
Quote:
Releasing them right now would be ill-advised as I'm sure some other commercial vendor's developers would love to get their hands on them.
That's exactly what I suspected was the case.
It's not even that I'd release them, it's that the corrected emulation would appear in higan, and some hypothetical company could use that information I guess? I really don't think that's likely, but I can see where you're coming from at least.
That's quite unfortunate that emulation is being held back because you want roughly half a million dollars (don't we all?), but ... at least it's understandable why you're being so secretive.
Quote:
But I'm not going to give away massive amounts of work for free that will be used by others for profit.
My only real concern is if you publicly advertise "more accurate than bsnes/higan!" without providing any proof of your claims. Of course, if you did, I'd fix the issues, so ... I see why you'd be hesitant to reveal them. But I'd be pretty bummed if you took an approach like that to fund your project, especially considering all that I've done to help everyone else in the SNES emulation scene ... and yes, for free. That would be really one-sided.
Quote:
I think the biggest issue would be getting enough publicity to get a relatively niche project funded to the required level.
I don't want to be a downer here, but ... my Patreon gets around $200 a month, and I've sold exactly one commercial license for $2500. In total of 13 years, and including $2500 that I used to pay a decapper, I've brought in maybe $10000 (and spent $30000, but that's another story.)
I
really don't think the demand for an FPGA implementation is going to get you to $400000. But who knows, maybe I'm just shit at marketing :P
If you really want $400000, try emulating the Wii U or the Switch. That's working out great for Cemu ;)
Quote:
In any case, I'm having fun learning about the crowdfunding stuff.
You could also consider GoFundMe. I passed because they force you to reveal your full legal name to everyone. Same problem with Paypal. Guessing you don't mind that given your handle :)
I've no problem with you being paid for your work, so I wish you the best of luck :D
Really cool! I've followed this project for a bit and am happy to see it nearing completion (or at least initial release status.) I have a couple of questions about things you mentioned earlier.
Is the Bad Apple demo issue (that is still listed as a request in the opening post) still present? I saw a youtube video of yours where it looks like it's running fine but I wasn't sure if this was a seperate version or what.
Is this fixed?
Quote:
Once I finish with sprites I'm going to attack that HV Timer issue with NO MERCY!
Does the rain in Super Metroid work now? You mentioned it might be some kind of strange HDMA issue in your Youtube video so I'm wondering if all those kinds of issues are worked out.
Anyway congrats on your progress so far!
Extremely cool project! Watching your reports with much joy!
I wrote you a PM just now, hope to hear back from you!
On a seperate note, I read over the funding discussion and I have to say I am a bit concerned. You basically want to sell information (which is fine), but without any independent assessment or peer review, how can we know how good the information is? In my opinion, the value of information is based more on how much better it is then existing information, not how long it took you to get it. I wouldn't consider funding this at any level unless someone can independently confirm that this is an advancement over the state of the art.
Maybe as a confidence builder, you can release one test that passes on snes / verisnes but fails on emulators. Then even if it's used in other commercial projects it's not a big deal as it's only a single data point (and presumably if you are offering real advancement you have many more then just one), but people who might want to back the project can at least be confident that what you are offering is new, valuable, and real.
Apologies for the blunt tone, but I do feel that selling information needs a different tact then asking for funding for some potential future project (where the implicit assumption is that nothing may come of it.)
I just randomly found this project and I must say it is an amazing work!
jwdonal wrote:
So how much is ~8,000hrs, 83k lines of FPGA-vendor-agnostic Verilog code, and the myriad possible applications worth? [...] I would need to make enough money from releasing it that I won't feel bad about everyone that's going to steal it to make a commercial product or use it as a marketing attractor while giving me absolutely nothing in return.
8000 hours times USD 100... Quite easy math.
No, but honestly, you can't get anything like it in return. All you can get is fame and glory, plus a small donation every now and then. And yes, it will be cloned and sold. Totally unfair, but that's just how the world is. Still, not releasing it means 8000 hours for nothing. By releasing it, you will bring joy and happiness for a lot of people. How much is that worth?
How about this... Why don't you set up a kickstarter with a goal you find worthy, like USD 50000 for releasing the code as GPLv3 or whatever license you pick. Maybe some stretch goals for porting it to DE2, Mist, ZX Spectrum Next, FPGA Arcade etc. Just an idea.
Edit: Oh, and please let me know when the KS is running and I will ship in my share.
Hi there.
The way I see it is, you are a programmer. You are an engineer and a genius but you are not a retail expert or have any desire to become one. Yet you still deserve compensation for this.
In other words you are in the same situation as kevtris or ikari. In which case do what they did, they developed something great, and allied themselves with someone experienced in manufacturing and/or retail, and/or already had a system in place to turn his intellectual property into a profitable product. This is, I think, is the only real way in which people will pay, get something back in return, and you will eventually reach your well deserved 400k.
If I may offer a suggestion, should you decide to go down this path, do not ally yourself with the analogue nt team, under any circumstance. 500 dollars for a retro console is crazy and outprices a lot of potential customers. Besides, they already have kevtris who is apparently also working on a snes fpga Core.
Instead, you would do great if you ally yourself with, say, krikzz, stoneage gamer, brian parker from retroUSB, René from dbelectronics, or maybe jason rauch from gametech-us.
I will also note that before the nt mini was jailbroken unexpectedly by kevtris, the nt team was still selling their console for the same ridiculous price, and even jason and kevtris were suprised at the unsually high price of the nt mini, as they mentioned on their AVS review video.
Anyways, think about it: find a partner, proft, win-win for everyone, and the snes lives on forever.
EDIT#1: additionally, you could choose to open source the code once you reach a certain number of sales, i.e. Once you reach your 400k. Ikari has his code open source and still makes a profit with krikzz by selling his sd2snes, so it might still work for your partner.
Sorry byuu, I totally missed this reply of yours somehow...
byuu wrote:
It's not even that I'd release them, it's that the corrected emulation would appear in higan, and some hypothetical company could use that information I guess?
That's correct. I'd have no problem trusting you not to release them but since your code is open source that could be a problem.
byuu wrote:
My only real concern is if you publicly advertise "more accurate than bsnes/higan!" <snip>I'd be pretty bummed if you took an approach like that to fund your project, especially considering all that I've done to help everyone else in the SNES emulation scene ... and yes, for free.
That would be a really a-hole move. But I understand your concern as certainly somebody might do that. Fortunately I'm a nice guy.
There's no way I would talk down about any software emulators, most especially yours. After working on the console for so many years and seeing the complexity of the system you can't get to that point and have anything but total admiration for SNES emulators. I will never understand how in the heck the existing emulators are as accurate as they with doing ONLY software-based reverse-engineering. Seriously, HOW is that possible???? It was hard enough with a damn logic analyzer hooked up to every single pin of the system!!
byuu wrote:
If you really want $400000, try emulating the Wii U or the Switch. That's working out great for Cemu
Yeah, that's so epic. $21,000/month? Yeesh.
byuu wrote:
You could also consider GoFundMe.
I'm not going to lie, I didn't even bother checking their site. I thought GoFundMe was only for people who were very ill or something like that. Guess I'll check it out...
byuu wrote:
Guessing you don't mind that given your handle
Good guess. I think everyone knows my name already. Lol. It's not a big secret.
Alyosha_TAS wrote:
Is the Bad Apple demo issue (that is still listed as a request in the opening post) still present?
Yes, this was fixed a while ago.
Alyosha_TAS wrote:
Does the rain in Super Metroid work now?
No, still like that. That bug is near the top of my list of things to fix though.
It's most certainly an HDMA issue.
leonquest wrote:
The way I see it is, you are a programmer. You are an engineer and a genius but you are not a retail expert or have any desire to become one.
Except for the genius part, I think that's a pretty accurate assessment.
You see I have my own consulting business and myself and two other engineers develop and sell HDL IP cores all day long. But that is equivalent to throwing code over the fence. We don't develop PCBs and we sure as heck don't develop enclosures and all that. We are contracted to implement algorithm X, we do it, we ship it, we're done. Easy-peasy. Developing a product is far too time consuming for me right now. There aren't enough hours in the day! XD
leonquest wrote:
In other words you are in the same situation as kevtris or ikari. In which case do what they did, they developed something great, and allied themselves with someone experienced in manufacturing and/or retail, and/or already had a system in place to turn his intellectual property into a profitable product. This is, I think, is the only real way in which people will pay, get something back in return, and you will eventually reach your well deserved 400k.
I have no problems at all working with others to get the code released or into a product. The more I think about releasing the source code the cooler I think it will be because I think of all of the cools things everyone could do with it. And I could be a lot more open with exactly what's changing in the code, maybe even do some livestream programming videos. So much awesomeness is possible.
leonquest wrote:
If I may offer a suggestion, should you decide to go down this path, do not ally yourself with the analogue nt team, under any circumstance. 500 dollars for a retro console is crazy and outprices a lot of potential customers.
Yeah if they charged $500 for NES FPGA console can you imagine what they'll charge for SNES???? LOL Maybe they think of themselves as the Apple of retro gaming? I dunno. But yeah, $500 is insane.
leonquest wrote:
Instead, you would do great if you ally yourself with, say, krikzz, stoneage gamer, brian parker from retroUSB, René from dbelectronics, or maybe jason rauch from gametech-us.
I'm not opposed to any of that. Actually, someone (sorry whoever you are, don't feel like going back through all the posts to figure out who it was XD) posted an idea earlier that I could have source code release goal and then stretch goal to make some actual hardware. I thought doing that or something similar was a really cool idea.
leonquest wrote:
Actually, someone (sorry whoever you are, don't feel like going back through all the posts to figure out who it was XD) posted an idea earlier that I could have source code release goal and then stretch goal to make some actual hardware. I thought doing that or something similar was a really cool idea.
Are you referring to my post two posts above yours? I haven't read through 12 pages to see if it was already suggested.
johey wrote:
How about this... Why don't you set up a kickstarter with a goal you find worthy, like USD 50000 for releasing the code as GPLv3 or whatever license you pick. Maybe some stretch goals for porting it to DE2, Mist, ZX Spectrum Next, FPGA Arcade etc. Just an idea.
jwdonal wrote:
byuu wrote:
It's not even that I'd release them, it's that the corrected emulation would appear in higan, and some hypothetical company could use that information I guess?
That's correct. I'd have no problem trusting you not to release them but since your code is open source that could be a problem
I'm struggling to see how having that information be available would have a negative impact on VeriSNES at all. Software emulation and FPGA emulation aren't even close to the same thing, as I'm sure we all know, and I don't see how having more accurate software emulators would hurt potential sales of an FPGA SNES product.
Hey jwdonal and others, I've been following this project and others like it for quite a while now and I just wanted to introduce myself and weigh in on some of the discussion. First off, SUPER congratulations on getting VeriSNES as far as it is now - it's a major undertaking and it's clear how much work has gone into this project.
---
Now, on to the topic of cash, I think it's important to look at the core issue here: sales. While I can certainly appreciate the amount of skill and time has gone into this project, I think it's really important to the stress the fact that what you have created here is (if you want it to be) the foundation for a product. Whether you decide to make a product on your own, with partners, or whether you take this intellectual property and sell/license it to another company to create a product with, at the end of the day, in order to get this into the hands of people someone down the line has to create some kind of finished product. As such, the value of the product -- and by extension the value of your IP -- can only really be determined by estimating how many final units someone can sell and at what price.
Whether you make something 'on your own' like bunnyboy did with the AVS, or partner with someone like kevtris and Analogue did for the Nt Mini, the big question in my opinion is, "how much demand is there and at what price?". Regardless of who makes this thing, it will need to be priced in a way that is profitable yet within expectations of the market of people (like us) who are interested in these kinds of devices. You could factor your own months of work into the total cost per unit, but in the end of the day there would still be a lot of development work to do when it comes to hardware design, optional case design, etc., and these months of work would need to factored into the unit cost somehow, along with all of the other more obvious costs (parts, manufacture, shipping, etc.). But I still think that how much you charge per unit when it comes to all of the design stuff really factors into how many units you think you can sell, and what price the market would tolerate. Even if you were to just sell your core to someone else, they'd still have to buy it at a price that makes sense for the market if they were to stay in business.
Analogue may have a good reason to price their devices the way that they do, whether it's to cover higher costs, more marketing, niche market sales numbers, or a 'premium' image, I can't really fault them for that and I think they have made some cool stuff. However, I do get a sense that they are already pricing their devices pretty much at the edge of what the retro/FPGA gaming market will tolerate. I could be wrong though, as I think hardcore retro gamers are certainly willing to spend decent chunks of cash on nice devices and games in order to have a great experience.
I wonder if RetroUSB or Analogue would be forthcoming with ballpark sales numbers? It might be at least worth asking them to gauge how big (or not) this market currently is, as a rough starting point. That's all under the assumption that you're at all weighing the possibility of taking this from being a project to being a product.
I also think you have to be a bit careful about equating kickstarter interest with sales interest; I'd happily drop $300-400 tomorrow on a HDMI FPGA SNES (especially if it had some of the 'jailbreak' abilities that kevtris built into the Nt. Mini, wink wink) if it was finished and for sale, but at the same time I'd be very skeptical about dropping that same amount money on a Kickstarter for the same project. Kickstarters are never really guaranteed to succeed or live up to the promises of the creators or dreams of the public, and that says to me that when you put money into a kickstarter you better be more than willing to just completely lose it. As such, I'm much more conservative with my money on kickstarter than I am when it comes to just buying a product, and I'm sure that is true for other people as well.
---
When it comes to Open Source, I'm personally a big fan (although, not a zealot by any stretch). I honestly couldn't even list off the number of open source programs I use on a daily basis, from GNU, Linux, git, Blender, Krita, browsers, emulators, etc... Every time someone takes their hard work and shares it openly with the public, the impact is massive and the ripples can help the community give birth to some really cool new things. Obviously it'd be huge for the retro gaming community to have good, open source implementations of the SNES or other consoles. Frankly, it'd be a game changer, in my opinion.
On the other hand, I certainly don't think you're obligated to take months of your work and simply give it away for free, especially when (as you guys were saying) it can be very hard (i.e.: expensive) to enforce licenses, if not basically impossible when we're talking about certain countries. We've seen this before with certain commercial devices making use of emulators without complying with licenses, and I'm sure that it could happen again in this case. It's a very reasonable concern that I have no answer to. I think making your cores open source would severely limit your ability to cover the cost of all your development time, and it would effectively become a massive gift to the larger community. Money could still be made off FPGA gaming hardware needed to play your core and others, of course, but once the verilog/hdl is out there it's out there.
As such, I think that someone like a Kickstarter or Patreon isn't necessarily a bad idea when it comes to opening up the source code, with the caveat that I think the size of the audience for that sort of thing is pretty niche and that you might have to taper your expectations a little bit. At this point we start getting into the territory of specific cross sections of the retro gaming market who also care about open source code, and if you're hoping to make hundreds of thousands of dollars as the threshold for whether you open source your code or not, I'd be surprised if it succeeds. I'd imagine it's especially hard to sell crowdfunding users on the idea of open sourcing code/hdl, due to the fact that it's not always immediately clear what they can expect to get out of it in the end - that makes it significantly different that a kickstarter for something like a popular game sequel, in which case users have a good idea (sometimes too good) what they will eventually get.
---
Anyway, wall of text, I know. I'm just a fan of these kinds of projects who has been excitedly following your VeriSNES and anticipating one day playing an FPGA SNES. Just wanted to chime in with some thoughts.
Hi jwdonal!
I have few questions and could you please clarify:
As far I understand you do almost the same what SNES emulators do but just use FPGA for that instead a software approach?
Your hardware based emulation has better results than the current SNES emulators because of your analysis of hardware and also because you could adjust and tune your emulation?
Am I right that you are not intended to make a full hardware clone? Each single semiconductor to each FPGA gate?
To simulate SNES hardware to full extent in FPGA with 100% precision you would need to investigate the hardware in electron microscope layer by layer and after that analyze a lot of received data and convert it to FPGA code?
Thanks a lot for the clarification!
Yes, this is a clone. There aren't public micrographs of the Super NES chipset yet.
Making a super famiclone on an FPGA, even if it is as inaccurate as the final version of ZSNES, has two advantages over full software emulation: you can use authentic Game Paks with arbitrary coprocessors, and less than 0.02 ms latency on 240p or 480p out (or less than 1 ms with 720p/1080p upscaling).
Also less power consumption and (probably) less expensive than a suitable PC.
Eh, ARM boards capable of SNES emulation are about 20$, FPGA boards able to run this would be on the order of 100$ (my guess).
Likely the price won't be cheaper than a PC capable to run any SNES emulator (a PC which can do a lot of other jobs as well).
Power consumption? Maybe I am not enough environment friendly or just my electricity price 0.10 USD per kWh is not high enough to take it in account...
I really can't understand what's the point of this product comparing to the already existing disgusting ARM solutions?
It doesn't offer a full hardware clone. It won't help anyhow to create new full copies of beloved SNES.
It will be the same approximation of SNES' hardware work as SNES emulators already do for years.
Probably a bit more precise but the original SNES console will be the original SNES console.
And it's really sad. Because I really would like to make SNES to live forever.
I would like to have a full 100% hardware copy of SNES hardware.
Why not to make crowd funding for that? Why to produce another something that resembles SNES but isn't it.
Is to create 100% full hardware copy still impossible in 21 century? Or will it cost millions dollars?
Interest exists, skill maybe too, money probably can be dug up for it but it seems there's no time.
I'm all over hardware, partly for reasons Tepples has mentioned. Reimplementation that gets results that are for all intents and purposes same as original hardware is good enough for me (and many others) and when you can adjust some things to likings of oneself things get even better (i.e I absolutely don't want the blurry RGB of original hardware and I would like multiple additional options in the sound path such as zero crossings detection for volume changes and few other things). Realtime software emulator would be fine but those aren't practical for the most part, so hardware is only good way to go about it.
As a open-source project it's absolutely ok.
But to get enough(or even more) money as a crowd-founding project for that it should be much more interesting.
A too niche interest can't attract enough founders.
And it seems like you are trying to come up with reasons for the project existence than the project offers anything itself.
And it correlates well with the words that the project was intended to practice FPGA skills and just for fun.
Why not to make something like Analogue NT? Why to give false expectations and make me sad?
I really would like to have a brand new SNES with high quality video output.
I really would like to donate up to 1000 USD for such a project just to see it to be done.
I really don't want to donate even single dollar to get another chinese clone alike fake. There a lot of that ARM-based c...p for 20 dollars.
greatkreator wrote:
I really can't understand what's the point of this product comparing to the already existing disgusting ARM solutions?
[...]
I would like to have a full 100% hardware copy of SNES hardware.
FPGA hardware simulation is nothing like an ARM based emulation clone.
As far as I've understood, in the finished implementation, this will be as close to a 100% hardware copy as one could hope to get, just like the Analogue NT Mini is for NES.
If it would be so then it would really cool.
But the question is how to do that without reverse engineering?
It will be 99.98% solution but not the same. Those 0.02% will always show who is who.
As far I understand he uses the same "symptomatic" approach as emulators (not a reverse engineering approach) but just with better "tuning".
Let's see what the author will say. Without him I just guess.
greatkreator wrote:
I really can't understand what's the point of this product comparing to the already existing disgusting ARM solutions?
You need essentially zero latency to make the Super Scope or Justifier light gun work as advertised. I don't see how to do anything like that with a Raspberry Pi.
greatkreator wrote:
It doesn't offer a full hardware clone. It won't help anyhow to create new full copies of beloved SNES.
I guess people disagree on what's a "full hardware clone". This is an approximation, but it's close enough that you can build a board around it, put a cartridge in, and it'll work with everything commercial and homebrew other than contrived test ROMs, even if it uses an unanticipated coprocessor.
greatkreator wrote:
Is to create 100% full hardware copy still impossible in 21 century? Or will it cost millions dollars?
You mean something that copies the Super NES at as low a level as Visual 2A03 copies the NES? It would probably cost a few thousand dollars to decap, delayer, and micrograph a 1/1/1, 2/1/3, and 1CHIP chipset, and then trace polygons from the photographs.
I see.
It does make sense to some extent.
Yes that exactly what I dream about.
I would support such a project with a pleasure as much as I can.
Exactly 101% SNES (not something that looks like very much as SNES) will live forever.
But unfortunately I don't know whether other people would support my dream.
Maybe the majority of people are not demanding perfectionists as me and they will be ok with such a hybrid half-solution.
tepples wrote:
You need essentially zero latency to make the Super Scope or Justifier light gun work as advertised. I don't see how to do anything like that with a Raspberry Pi.
Would an exact line doubler or tripler, adding exactly one line of latency (1 / framerate * n. lines seconds) allow the super scope, justifier, or even original zapper to work correctly? In the case of a 480p line-doubled VGA output, or even 720p line-tripled output, this would be a possible path to lightgun compatibility on a slightly more modern display.
Also, what would be a good < 1 frame solution for dealing with interlaced hi-res mode? Would it be better to
a) Allow a slight wobble on the screen as the line-doubled frames are output without weaving in a buffer, at the moderate expense of vertical clarity, or
b) Switch to a 1-frame-lag buffer solution, just for interlaced mode, at the expense of needing extra memory for a framebuffer?
Alongside, maybe:
c) Force ignore the interlaced mode flag, having the output be a progressive double-strike image?
Asking for a friend.
Assuming a CRT capable of 480p CRT at twice-NTSC line rate, as opposed to 720p, 1080i, or an LCD:
Super Scope and Justifier can measure X in addition to Y. This requires the signal to be 15.7 kHz, not 31 kHz, as 31 kHz means only half of the electron beam time can be accounted for. Games could perhaps be patched to work with this, or the console might be able to do funny things with the HV latch to make it count twice as fast when outputting 480p.
Zapper should work with a doubler, as previous tests during the development of Zap Ruder have shown that it's only precise enough to detect Y, not X. But you'll need to use a CRT, use 480p, and crank up the darkening of every other scanline to 100% so that the light sensor circuit sees half the actual line frequency.
An LCD won't work. The light sensor circuit (photodiode + demodulator) can't even see light that doesn't flicker at close to 15.7 kHz. And even if an LED backlight were to flicker that fast, it probably wouldn't flicker individual lines from top to bottom the way light gun systems expect.
Nor will upscaling to a 720p CRT work very well, as 720p uses 4% vblank time (720+30 = 750 lines per field), compared to 240p's 8.4% vblank time (240+22 = 262 lines per field). This means line tripling at 720p will produce 750*60/3 = 15.0 kHz, not 15.7 kHz. This difference is why the Hi-Def NES needs to store pixels in a circular buffer. If you tried to use a Zapper with a 15.0 kHz line rate, it'd probably work with really simple games like Duck Hunt, but more complex games that measure Y position (Operation Wolf, Top Hunter, Zap Ruder) will mistrack vertically by up to 5 percent.
Interlace can be done trivially with a 100% scanlines upscaler. There's "a slight wobble" when you play it on an SDTV anyway, and it probably won't be any more apparent when you upscale.
Thank you for clarifying lightgun compatibility.
tepples wrote:
Interlace can be done trivially with a 100% scanlines upscaler. There's "a slight wobble" when you play it on an SDTV anyway, and it probably won't be any more apparent when you upscale.
While this is an easy solution, using visible scanlines (i.e. darkening one or more scanned out duplicate lines) results in a significantly darker image than the normal line-doubled one. This does solve the problem trivially, but I don't think a dark
and flickering solution is the best default one. This would solve the case nicely for people who want to use a scanline filter, however.
So, alongside that option for a scanline mode, a solution might be either
a) Allow a slight wobble on the screen as the line-doubled frames are output without weaving in a buffer, at the moderate expense of vertical clarity, or
b) Switch to a 1-frame-lag buffer solution, just for interlaced mode, at the expense of needing extra memory for a framebuffer.
Maybe both would be best, at the user's choice.
Fortunately, I made a test card of the three solutions eight years ago.
Interlacing test card (GIF at 1/3 speed to exaggerate visibility of slight wobble)Left: Weave (1-field lag); center: fields with visible scanlines; right: line-doubled fields
Top row: Unfiltered image; bottom row: image blurred vertically before interlaced display
Left and right are darkened 30% to compensate for center's loss of brightness
The right-side solution is how it would look without the scanlines, then. I think as a zero-lag solution, it is adequate, although it must be acknowledged that it is not visually ideal. Fortunately, very few games utilize the interlaced mode during gameplay.
calima wrote:
Eh, ARM boards capable of SNES emulation are about 20$, FPGA boards able to run this would be on the order of 100$ (my guess).
Likely more, if jwdonal wants to post the sizing information for what he has now, we could back-of-the-envelope figure out how much it costs to build against a few FPGA's and maybe get some theoretical bill-of-materials. There is speculative guesses based on previous sizing information from other projects (
http://pgate1.at-ninja.jp/SNES_on_FPGA/ )
Likewise, there are other solutions that haven't been explored as well. A FPGA on a PCIe card that has a console-cartridge/controller breakout box is more versatile, and could emulate the micomsoft sc-512n1-l/dvi aka SA7160 (which is already a FPGA) This card costs 400$ US. Micomsoft is also the company that makes the upscalers that people use which are also FPGA based.
Expecting a sub-99$ FPGA unit is wishful thinking, and people buying software emulators on ARM boards are being deceived. People rarely use these things as anything but toys for younger children. Hence the NES classic and presumably the SNES classic are just COTS (Cheap Off The Shelf) ARM parts. The latency tradeoff isn't nearly as bad with the Nintendo product as it is with the Pi-Pirates, but it's not a great experience either.
The key point about the light guns, I don't see any way for these games to be played with the original cartridge and light guns because these were designed for CRT's and short of OLED screen that emulates the CRT flicker, it's likely impossible, and the market is too little. Only the Wii had a controller that had the necessary electronics to do light gun games, and it used an infrared source outside the TV so that it didn't matter how big the TV was or if it was a CRT or LCD. So don't expect the games to ever come back in any form other than pirate sources on software emulators. At best, someone may figure out a way to configure a IR LED strip to emulate the 15Khz signal and use a Wiimote as the light gun.
Kismet wrote:
The key point about the light guns, I don't see any way for these games to be played with the original cartridge and light guns because these were designed for CRT's and short of OLED screen that emulates the CRT flicker, it's likely impossible, and the market is too little. Only the Wii had a controller that had the necessary electronics to do light gun games, and it used an infrared source outside the TV so that it didn't matter how big the TV was or if it was a CRT or LCD. So don't expect the games to ever come back in any form other than pirate sources on software emulators. At best, someone may figure out a way to configure a IR LED strip to emulate the 15Khz signal and use a Wiimote as the light gun.
A Wii Remote to light gun adapter exists. It just might be tricky to commercialize until 2026, when the Wii Remote patents expire. And it requires the console to continue to emit a 15.7 kHz luma signal, even if it's also producing an HD signal with completely different timing.
Kismet wrote:
Expecting a sub-99$ FPGA unit is wishful thinking, and people buying software emulators on ARM boards are being deceived. People rarely use these things as anything but toys for younger children. Hence the NES classic and presumably the SNES classic are just COTS (Cheap Off The Shelf) ARM parts. The latency tradeoff isn't nearly as bad with the Nintendo product as it is with the Pi-Pirates, but it's not a great experience either.
Many errors here:
-Maybe for hardware with the complexity found on a SNES, a sub-99$ FPGA board is wishful thinking, but for smaller systems we have the VERY decent ZX-UNO, that makes NES, Atari 800XL, MSX1, ZX-SPECTRUM, BBC-MICRO, AMSTRAD CPC and C64. It can be bought today and you can even make your own provided you have the parts and tools.
-Pi-Pitrates? Kiss my originals.
And thanks to the dispmanx and drm/kms backends, emulaton on the Pi has FAR LESS input latency than that found on the NES-MINI:
https://forums.libretro.com/t/an-input- ... ation/4407You should get better informed next time.
The principle of charity would suggest that Kismet meant precisely "Expecting a sub-99$ FPGA unit [for hardware with the complexity found on an SNES]".
Hi everybody! I have a new update video for you.
https://www.youtube.com/watch?v=7ae5iUe8diYEnjoy!
Great new video, the core is looking extremely promising. One minor issue deals with the "guards chase you" sound effect in Zelda, your FPGA's output is noticeably more metallic than the real SNES. It is as if there is a low-pass filter that may not be applied.
I don't think the SNES's low-pass filtering is very strong in the audible range (aside from the Gaussian interpolation done in mixing which functions as one for each sample), but there's aliasing all over the place in the audio of that video. Is that what it actually sounds like, jwdonal? Or is it maybe a byproduct of zero order hold resampling from 32 kHz to 44.1 kHz in the capture device or something? Or is the interpolation in mixing maybe not implemented?
Yeah, if it sounds metallic it could just be a case of bad aliasing.
Great Hierophant wrote:
Great new video, the core is looking extremely promising. One minor issue deals with the "guards chase you" sound effect in Zelda, your FPGA's output is noticeably more metallic than the real SNES. It is as if there is a low-pass filter that may not be applied.
So I briefly looked into this and I really don't hear what you're referring to. There is only a single short instance of that sound in the recording at around 9:19. I listened to the same sound effect from the following sources:
- Snes9x
- BSNES-debugger (accuracy profile)
- Real SNES using sd2snes
- My FPGA SNES
All of them sound _exactly_ identical to me and I visually inspected their waveforms in audacity as well. I see nothing strange at all. It sounds just as "metallic" on real SNES as it does everywhere else - assuming I understand what you mean by "metallic".
In any case, I'm not sure it makes sense to perform audiophile analyses on a recording that's probably been through a dozen different filters and resamplers by the time it makes it from my FPGA SNES, through my capture card, through screen recorder software, volume adjustment, mixing, video format conversion, youtube processing, etc, etc, etc, etc, etc, etc to your speakers...? O.o
jwdonal wrote:
Great Hierophant wrote:
Great new video, the core is looking extremely promising. One minor issue deals with the "guards chase you" sound effect in Zelda, your FPGA's output is noticeably more metallic than the real SNES. It is as if there is a low-pass filter that may not be applied.
So I briefly looked into this and I really don't hear what you're referring to. There is only a single short instance of that sound in the recording at around 9:19. I listened to the same sound effect from the following sources:
- Snes9x
- BSNES-debugger (accuracy profile)
- Real SNES using sd2snes
- My FPGA SNES
All of them sound _exactly_ identical to me and I visually inspected their waveforms in audacity as well. I see nothing strange at all. It sounds just as "metallic" on real SNES as it does everywhere else - assuming I understand what you mean by "metallic".
In any case, I'm not sure it makes sense to perform audiophile analyses on a recording that's probably been through a dozen different filters and resamplers by the time it makes it from my FPGA SNES, through my capture card, through screen recorder software, volume adjustment, mixing, video format conversion, youtube processing, etc, etc, etc, etc, etc, etc to your speakers...? O.o
I think that all of those are a factor. I originally tried the sound effect on my TV's built in speaker, and after reading this I tried it again, but this time using a pair of decent speakers that came bundled with an Oppo receiver. The sound was noticeably
more metallic, a little more than your Youtube video. This would make sense, the guards are supposed to be wearing metal armor that should clank.
I would be interested in buying this console when it comes out. One suggestion that I have, would be to also include an SD card slot for roms and other expansions similar to how the Analogue NT NES has an SD card slot.
Erockbrox wrote:
One suggestion that I have, would be to also include an SD card slot...
SD card interface is already working. So you're welcome.
Here are some pics of me playing VeriSNES on my 70” TV. My TV only supports 720p and 1080i – no 1080p. :-/
https://imgur.com/a/QYcja
Looks like Analogue is starting up production for their own take on an SNES FPGA clone with the Super NT. I'm curious how it will fare in comparison to the VeriSNES. Do you happen to have any ideas? They don't claim 100% compatibility, but they also don't clarify which games aren't compatible either. I'm wondering it's just the stuff that used obscure hardware peripherals like SatellaView, or Sufami Turbo games.
What's everyone here's thoughts on it?
The Analogue appears to be HDMI-only. If it supports FX games and the SD2SNES (with MSU audio), then it should be a good solution for flat-screen owners.
I'd personally prefer something with 240p support and more video output options.
Happy they're doing it.
Sad it's not open source.
Disappointed by how bland it looks. Gimme brushed metal plz
With someone else taking first mover on the market, sadly not much chance for you to get a proper payback anymore.
adam_smasher wrote:
Happy they're doing it.
Sad it's not open source.
Disappointed by how bland it looks. Gimme brushed metal plz
If it's 400$ because of brushed metal, give me a 100-200$ plastic case, please.
vanfanel wrote:
adam_smasher wrote:
Happy they're doing it.
Sad it's not open source.
Disappointed by how bland it looks. Gimme brushed metal plz
If it's 400$ because of brushed metal, give me a 100-200$ plastic case, please.
The Analogue Super Nt is $189.99 USD. The chassis is plastic, with options for SNES, SFC, matte black, and transparent.
I think we should split Super Nt discussion to a separate thread.
I was already aware about 9mo or so ago that kevtris was working on FPGA SNES. I had inside knowledge from Taber at Analogue but I told him I would keep it secret. However, even having that knowledge I kind of always thought it should have been obvious what he was working on - I mean what else would he be working on? O.o
In any case, the two consoles have entirely different goals. My goal is to get the entire SNES design and additional information open sourced. Super Nt is obviously not going to be open sourced. Lol.
More VeriSNES updates to come!
Cya!
jwdonal wrote:
I was already aware about 9mo or so ago that kevtris was working on FPGA SNES. I had inside knowledge from Taber at Analogue but I told him I would keep it secret. However, even having that knowledge I kind of always thought it should have been obvious what he was working on - I mean what else would he be working on? O.o
In any case, the two consoles have entirely different goals. My goal is to get the entire SNES design and additional information open sourced. Super Nt is obviously not going to be open sourced. Lol.
More VeriSNES updates to come!
Cya!
I put in a order for the Super NT anyway, but I still want to see how your project progresses. If you eventually release FPGA code for it, it may create an opportunity to "root" the SuperNT with it, assuming kevtris doesn't just do the same thing he did with the Analogue NT anyway.
Just make your SNES console just a little bit cheaper than the competitors and then you will win in the end. Hahaha
I'm sure you will do fine and have the communities support. Especially after all the hard work you did. It is quite an accomplishment.
Erockbrox wrote:
I'm sure you will do fine and have the communities support. Especially after all the hard work you did. It is quite an accomplishment.
Thanks for the support! Like I said, since I already knew about it nothing has changed for me. I'm just gonna keep on doing what I do! I'm happy for Kevin, he's awesome!
Erockbrox wrote:
Just make your SNES console just a little bit cheaper than the competitors and then you will win in the end. Hahaha
I'm sure you will do fine and have the communities support. Especially after all the hard work you did. It is quite an accomplishment.
One stand out feature I'd like to see is Analog Video output. It looks as those the Super NT is going to be HDMI only which is a major bummer. I know Analog Displays are obsolete now but support for them is still very nice to have as the sorts of people interested in these things are often the type to have quality CRTs in their collection of equipment.
Unless it uses HDCP (which it probably won't), you can use your analog computer monitors through an HDMI to VGA transcoder.
Presumably (?) that'd add some lag, and one of the big reasons why people would want a hard-SNES/CRT combo is to minimize lag.
As I understand it, 480p has the same timings over HDMI and VGA. This means a properly made converter would introduce less than a scanline of lag.
Would that work with the Super Scope?
Theoretically you should be able to convert each 8b10b chunk sent via TMDS over DVI/HDMI into an analog pixel with only a pixel's worth of latency. (This is what would be necessary for superscope functionality)
I have no idea if anyone does this outside of trivial demonstrations using a
HDMI deserializer and a high-speed DAC. There seems to be a certain level of laziness that just leads to people throwing things into a framebuffer (and adding latency) even when it's unnecessary.
Some of the last Sony 4:3 CRT TV's had HDMI inputs, I always keep my open for these on Craigslist and such.
93143 wrote:
Would that work with the Super Scope?
No. Unlike the Zapper, which I would expect to work on a 31 kHz CRT receiving a "100% scanlines" signal, the Super Scope is synchronized to the 5.37 MHz pixel clock, which is doubled even in 480p. You'd be able to hit only half the width of the screen, and even for that, the horizontal coordinate would be incorrect (squeezed horizontally) unless software is patched to compensate.
But in practice, whether Super Scope is a priority depends on the popularity of games that require the Super Scope. Which such games are compelling?
marvelus10 wrote:
Some of the last Sony 4:3 CRT TV's had HDMI inputs, I always keep my open for these on Craigslist and such.
Using these offers virtually no advantage over a modern HDTV, except for the potential appeal of phosphors themselves. These have image processors and scalers just the same as an HDTV, with a different output stage being the only difference.
tepples wrote:
93143 wrote:
Would that work with the Super Scope?
No. Unlike the Zapper, which I would expect to work on a 31 kHz CRT receiving a "100% scanlines" signal, the Super Scope is synchronized to the 5.37 MHz pixel clock, which is doubled even in 480p. You'd be able to hit only half the width of the screen, and even for that, the horizontal coordinate would be incorrect (squeezed horizontally) unless software is patched to compensate.
But in practice, whether Super Scope is a priority depends on the popularity of games that require the Super Scope. Which such games are compelling?
240p is part of the HDMI spec. Some HDMI -> VGA converters support 240p, and will output a 15 kHz signal. All you've got to do to get that on a PVM is use a sync combiner. At that point, I should think the Super Scope would work fine, assuming the converter didn't use a framebuffer.
The Super Scope does have some nice games, two of which are Battle Clash and the sequel Metal Combat.
I definitely think any SNES clone should output analog RGB and should be compatible with the Super Scope on a CRT. The Super Scope can be a lot of fun.
Guspaz wrote:
240p is part of the HDMI spec.
It is now but it is not a feature supported by the Super Nt. The Super Nt only does 480p, 720p, and 1080p, per their website
panzeroceania wrote:
Guspaz wrote:
240p is part of the HDMI spec.
It is now but it is not a feature supported by the Super Nt. The Super Nt only does 480p, 720p, and 1080p, per their website
Analogue is at least aware that there is a desire for it: I tweeted the request for 240p HDMI at them, and they liked it. Doesn't mean they'll do it, but they're at least aware.
Hi.
@jwdonal, what say ye about helping ikari implementing SuperFX and SA-1 on the SD2SNES?
You have the talent and already know how the main snes CPU works and have the code in FPGA form.
Sorry about hijacking.
James-F wrote:
what say ye about helping ikari implementing SuperFX and SA-1 on the SD2SNES?
Would love to. I think it makes a lot of sense, most especially if the VeriSNES is open-sourced.
James-F wrote:
Sorry about hijacking.
I don't think asking about other potential applications for the VeriSNES on the VeriSNES thread is hijacking...
--
Using this thread to talk about the Super Nt however is - so let's tighten it up people! Lol
This is fantastic to hear that you have the will to do it, this will be quite huge improvement to the value of sd2snes.
If you can/will please contact him directly, I certainly don't want to be a middle man in such grandiose historical events if they happen.
It seems to be a bit unpleasant to find out Super Nt is released...
However the fact that the both are useless fakes soothes the pain.
The battle of fakes is coming: who will be more similar to the Original?
It could be an exact hardware copy of the original but who needs it? Everyone needs a fake. Sad.
FPGA based clones are more real than the official Snes mini.
Besides, the original hardware from the 90s is not eternal but FPGA code, IS.
greatkreator wrote:
It seems to be a bit unpleasant to find out Super Nt is released...
However the fact that the both are useless fakes soothes the pain.
The battle of fakes is coming: who will be more similar to the Original?
It could be an exact hardware copy of the original but who needs it? Everyone needs a fake. Sad.
People got new TVs since 1992 and want a system that works on a contemporary flat panel display. Scaling options exist but they tend to be fairly expensive and add lag.
Snes mini is just a disgusting and deeply disappointing piece of cr..
Of course it will be absolutely ok for the majority of casual players that would like to get a bit of retro enjoyment.
But why Nintendo did release that?!... Please unrelease it back.
Create the same cool console as it was in the past but brand new + a good audio-video output + (would be really cool but not required: wireless gamepads). That's it. Profit.
Nobody told Nintendo that we already could play that cr.. without Nintendo and their "genius" invention Snes Mini very well.
If not a secret what's wrong with contemporary flat panel displays + the original console? The composite output?
greatkreator wrote:
If not a secret what's wrong with contemporary flat panel displays + the original console? The composite output?
The way modern TVs interpret 240p composite signals sucks balls, because of interlacing issues, mostly. That is, if they even support composite video anymore... Analog connections are already being abandoned by TV manufacturers.
Yes, the low resolution composite output. Most modern LCD TVs are quite poor at upscaling 240p video.
Also: it'd be great if Nintendo reissued "real" SNESs but that's just not going to happen. There just isn't a big enough market for original carts, and throwing a Linux emulator on an ARM SoC like in the SNES Mini is way way cheaper than manufacturing custom chips. So the only "real thing" we have is 20+ year old hardware that's starting to fail irreparably.
And what's the real thing anyway? The original 1/1/1 SNES? Do 1CHIPs count? SNES Jr's?
It's entirely possible that the VeriSNES/Super NT's behaviour might be closer to the 1/1/1 SNES than some later official Nintendo models. Would that make them more or less fake than an SNES Jr. that can't run Pocky & Rocky?
If an FPGA clone was based on a 1-Chip SNES would it then have a sharper picture than that of one based on the original 2 chip version?
The 1CHIP's sharper output is a result of an improved DAC (digital to analog converter) in the PPU. The DAC quality is theoretically independent of the accuracy of the S-CPU and S-PPU logic that precedes it. The silicon is fast enough nowadays that an FPGA Super NES could look as sharp as the 1CHIP even if its logic is based on that of pre-1CHIP revisions like the 1/1/1 or 2/1/3.
But DAC quality really only matters on a device that outputs 240p/480i composite, S-Video, RGB, or YPbPr, or 480p RGB or YPbPr through a line doubler. Something that outputs only HDMI needs no DAC at all.
adam_smasher wrote:
Would that make them more or less fake than an SNES Jr. that can't run Pocky & Rocky?
Pocky and Rockey, and Super Ghouls and Ghosts, both are bugs of SD2SNES where it didn't reset some DMA address like a when switching a real cartridge which requires a full power cycle.
It has been fixed in version 1.7 from April 2016.
There are indeed minor bugs and glitches with the 1Chip consoles... like an emulator.
The 1Chip is just an integrated snes on a chip, much like the new wave of snes-on-fpga are, and snes-on-fpga's have the benefit and potential to be 100% accurate to whatever revision of the real hardware the programmer chooses and firmware updated.
Moreover, adding analog video outputs is also an option.
Anyway, it is great to see jwdonal advancing with his open source VeriSNES.
I have neither of those games so I'm just writing from hearsay, but if you google around people report issues with original carts not working on 1CHIPs.
kevtris wrote:
greatkreator wrote:
It seems to be a bit unpleasant to find out Super Nt is released...
However the fact that the both are useless fakes soothes the pain.
The battle of fakes is coming: who will be more similar to the Original?
It could be an exact hardware copy of the original but who needs it? Everyone needs a fake. Sad.
People got new TVs since 1992 and want a system that works on a contemporary flat panel display. Scaling options exist but they tend to be fairly expensive and add lag.
Some people still want analog video output too. =)
Calling these things "useless fakes" just shows you have some sort of anger directed toward them. They certainly aren't useless. And I don't see how they are fake as they aren't trying to be passed off as original systems. There were actually pirate clone systems that were packaged to look like the real thing and could be called fakes. If you don't like these new FPGA consoles, then don't buy one.
Perhaps "useless" was meant in the sense that it'd be too easy to write a program that works on one of these but inadvertently fails on an authentic Super NES.
Time will tell if these systems have such issues. But unlike the original silicon these FPGA designs could always be updated to iron out issues. Hopefully they won't have such problems with accuracy. But even then it's not like the gold standard (original hardware) is going to all disappear right when these become available. But the time to develop a replacement is now, before the originals are gone.
What Nintendo should have done is released an updated hdmi snes and not the snes classic.
Thankfully we have people doing what Ninten-don't.
Yes right.
I meant exactly that.
If one makes a hardware clone it should be good.
What reason to make another hardware emulator made "by symptoms" of the work of the original console.
The symptomatic approach has already been satisfied by a lot of people.
A very good emulator but still an emulator.
The analog output is cool and I need it as well as the digital one.
By the way why not to use Retron 2 (or 3 I don't remember which one is a full hardware based clone of SNES).
Does it have any problems?
You mean "symptomatic" in the sense of
empirical evidence of accuracy through
black-box testing, correct?
As I understand it, you'd prefer a hardware clone based on
white-box methods: have S-CPU, S-PPU1, S-PPU2, S-SMP, and S-DSP decapped, photographed on each layer, and traced, and then publish the result. From this, one could derive a netlist
provably equivalent to the circuits in a Super NES Control Deck.
Yes. You understand everything absolutely right. (: almost a mind reader.
There are already a lot of software-based "black boxes" and even one hardware-based "black box" and one is coming.
It's needed at least one good "white box".
I guess it hasn't happened yet because it's too difficult to make such "white box".
It seems that's impossible to do by one person.
Looks like pirates
had already done some decapping back on the day.
But I think they really wouldn't share this information.
I would buy that information with a pleasure.
Pirates! If you are reading this please contact me.
I really want to have a good clone of SNES (not something similar to SNES's behaviour).
That's was a joke. However my words are serious.
Please feel free to contact me concerning that matter.
@kevtris: Are there any plans to jailbreak the SNES NT Mini too? That's what I am waiting to get the thing.... A confirmation on your side is enough
Is there any update to this project? I'm curious what you're planning to do now that Kevin's system is coming out.
Any chance you can help with the SD2SNES project and get more special chips programed for them?
XtraSmiley wrote:
Is there any update to this project? I'm curious what you're planning to do now that Kevin's system is coming out.
Hi! Kevin's system has no bearing on my plans. You might want to read back on the thread a bit. When I'm ready I'll be starting a crowdfunding campaign to get the entire SNES open sourced along with other goodies as well.
My consultant business is swamped with other IP dev work right now so that's taking priority, but don't worry, it'll happen!
XtraSmiley wrote:
Any chance you can help with the SD2SNES project and get more special chips programed for them?
Yeah, I'm definitely interested. I think that would be a neat project.
Cya!
Quote:
Any chance you can help with the SD2SNES project and get more special chips programed for them?
Yeah, I'm definitely interested. I think that would be a neat project.
This would be the greatest thing ever. An snes flash cart with compatibility for SA-1 and Super FX.
jwdonal wrote:
XtraSmiley wrote:
Is there any update to this project? I'm curious what you're planning to do now that Kevin's system is coming out.
Hi! Kevin's system has no bearing on my plans. You might want to read back on the thread a bit. When I'm ready I'll be starting a crowdfunding campaign to get the entire SNES open sourced along with other goodies as well.
My consultant business is swamped with other IP dev work right now so that's taking priority, but don't worry, it'll happen!
XtraSmiley wrote:
Any chance you can help with the SD2SNES project and get more special chips programed for them?
Yeah, I'm definitely interested. I think that would be a neat project.
Cya!
Thanks for the replies. I did read the whole thread, but...
You were looking to get paid for all your work on this (and I am NOT saying you shouldn't be), but now that Kevin is releasing his via a system that basically cost about $200 delivered, I'm not sure I see a way for you to make your time in "money" back on this. So, that being said, what is your plan? Are you going to release for free? Help out Buyuu with his SNES emulator? etc?
I'm not sure you'll be able to raise the kind of money you would have been able to 6 months ago, I know it sucks, but I just think that's where we are today. What are your real thoughts on that?
Thanks for offering to look into the SD2SNES. I doubt you could make a lot of money on something like that, but if that is what drives you, set up a Patreon, with the goal to make that happen. I bet that would generate some buzz.
XtraSmiley wrote:
You were looking to get paid for all your work on this (and I am NOT saying you shouldn't be), but now that Kevin is releasing his via a system that basically cost about $200 delivered, I'm not sure I see a way for you to make your time in "money" back on this. So, that being said, what is your plan?
I've told you my plan.
I'm not interested in competing with Kevin's console and I'm not interested in making a commercial product as I've said multiple times in the past. I also don't make PCBs. My private consulting company makes custom FPGA IP cores and throws them over the fence to our customers. Now granted we do work with COTS FPGA boards, but we don't make our own. Obviously I have to prioritize my (and my other contractor's) time to my paying business customers over SNES development - they pay much better. Lol.
My target audience is totally different from Analogue's closed-source, closed-hardware commercial system. If I had intended on making something like that I would have stopped working on my SNES a long time ago when I originally found out about it in December 2016 when Chris Taber contacted me. Lol. Because there is no way my company could have gotten it out the door prior to the release date that Analogue had planned - I simply don't have the man-power given all of our other contracting work. SNES can't take priority over my core business customers - that would be a pretty stupid move on my part.
My number one goal when working on this console and others is always to have fun and learn cool stuff.
Period. I don't have enough motivation to do it for any other reason.
It's amazing how much of a better FPGA designer I have become re-creating these old consoles. And Kevin is part of that too because he's taught me so much over the last many years. Hell, Kevin is so talented sometimes I think you could just stand next to him and learn purely through osmosis! XD
In any case, my point is (and I've stated this before), if the campaign is funded great, if not great. Remember that I never intended to release the source in any way/shape/form. I created the SNES for _myself_ to have fun, not for anyone else. It was someone else's idea to crowd fund and open source it, not mine.
XtraSmiley wrote:
Are you going to release for free?
I'm sure China would love that, but, no....HAHA. If they want the source they can pay for it.
XtraSmiley wrote:
Help out Byuu with his SNES emulator? etc?
Yes, I'll probably release all of my test ROMs eventually regardless.
XtraSmiley wrote:
What are your real thoughts on that?
I've given you my real thoughts. I don't think I have fake ones... XD
XtraSmiley wrote:
Thanks for offering to look into the SD2SNES. I doubt you could make a lot of money on something like that, but if that is what drives you, set up a Patreon, with the goal to make that happen. I bet that would generate some buzz.
It's not about "makin' money", it's about what's fair and not letting other's inappropriately profit from my hard work.
Cya!
Regardless, don't stop posting new videos.
Thanks for the detailed replies! OK, we can't wait to see what's next!
Wow this is amazing! I used a DE2 a few years ago for some EE courses in school and I loved the thing. Of course its been a while and I haven't used it in years but I think this could be an invaluable learning opportunity for students.
I understand the potential minefield of issues with releasing it but perhaps there is some way that you could license it to interested learners while still preventing it from being used/abused commercially.
I'm no expert but I seem to recall altera had some sort of scheme like this for their nios cores. I believe you could encrypt certain parts of the source code or use an IP core locking solution:
https://www.altera.com/solutions/partne ... ystem.htmlCheers
@jwdonal,
I think if you want to contribute to the emulation scene or SD2SNES project you just need to start a kickstarter and name your terms.
You will find that people are generous and willing to donate so you can work on the special chips in the SD2SNES while being assured that everything is fair and square by your terms.
But you have to be absolutely sure that it is possible on the current SD2SNES hardware before starting a kickstarter.
Just wanted to chime in and say that work towards an FPGA SA-1 (and others) for use on flash carts or repro carts would be amazing. I'm looking at doing homebrew that uses the SA-1 but don't want to desecrate a donation cart to get one nor would I want to release homebrew that encouraged others to do so. Would gladly patreon/kickstart/moral support such efforts
jwdonal wrote:
In any case, my point is (and I've stated this before), if the campaign is funded great, if not great. Remember that I never intended to release the source in any way/shape/form. I created the SNES for _myself_ to have fun, not for anyone else. It was someone else's idea to crowd fund and open source it, not mine.
Well I've ordered a Retro Nt, since it's a very nice looking thing, and it should be supported.
That said, I'd happily throw a contribution into the VeriSNES project also, if it means an open source release. No reason why we can't have both.
@jwdonal
Are you alive?
@idc
I (and thousands like me) want S-Video and RGB like the original for authentic experience on a CRT,,, which the Super Nt doesn't deliver.
I don't care for HDMI, I have emulators with 99.99% compatibility that look and play just as good.
James-F wrote:
@jwdonal
Are you alive?
@idc
I (and thousands like me) want S-Video and RGB like the original for authentic experience on a CRT,,, which the Super Nt doesn't deliver.
I don't care for HDMI, I have emulators with 99.99% compatibility that look and play just as good.
You kind of missed out because Analogue announced a way to do S-Video, RGB and stuff for the Super NT.
Digital signals can be downconverted to analog ones with an adapter. There's... no problem here at all with the nt design.
FitzRoy wrote:
Digital signals can be downconverted to analog ones with an adapter.
Analog signals can be upconverted to digital ones with an adapter.... like the OSSC.
In that case I don't need the Super Nt... AND have the original console AND Composite, S-Video, RGB and HDMI outputs;
Can't get more authentic and lag-free than that.
The original Super Famicoms still plentiful on ebay for a dime on a dollar (cheap).
Keep in mind that the only difference between the Super Nt and a
good emulator box (that plays cartridges) experience-wise is only the lag time.
LuigiBlood wrote:
James-F wrote:
@jwdonal
Are you alive?
@idc
I (and thousands like me) want S-Video and RGB like the original for authentic experience on a CRT,,, which the Super Nt doesn't deliver.
I don't care for HDMI, I have emulators with 99.99% compatibility that look and play just as good.
You kind of missed out because Analogue announced a way to do S-Video, RGB and stuff for the Super NT.
What announcement?
From Analogue Twitter:
https://twitter.com/analogue_co/status/ ... 1138093057Quote:
For all analog AV lovers: we've been working on something you'll like. 100% work in progress at this time, but coming together right so far.
Designed for Super Nt and future Analogue systems. A digital to analog converter that plugs into the HDMI port.
It takes proprietary digital signals from Super Nt and converts them to high quality analog signals. Outputs to same DSUB15 jack on Nt mini.
Outputs: RGB, Component, S-video, Composite, analog audio...and probably more. Same quality as Nt mini. Zero lag. Zero signal degradation.
Price will be reasonable.
James-F wrote:
Analog signals can be upconverted to digital ones with an adapter....
But then you're getting analog quality through a digital connector. You can't recreate lost information with the same success as reducing it.
Hello and congratulations for your project!
I am an EE with some experience to digital electronics but no experience to FPGAs.
As a project to start learning fpgs design i plan to recreate the snes APU.
(The reason for this particular chipset, is because i like snes music
)
My question is how do i start (besides the obvious learn Verilog/VHDL)?
I mean how this chip was exposed to the community in the first place? Was decapping and imaging used?
How did you approached writing your APU core?
Much of the APU information would have first been obtained or leaked from development documents and more information probably became available due to emulation projects. No decapping involved. If you want to create a SNES APU in a FPGA perhaps cloning the CPU of the APU module would be the first logical step.
Seems to me this project is dead.
I think you mean "this project is done" :p
Sure, I know you meant "can I buy it" but that wasn't explicitly ever something that was being offered.
And, from an external view, it seems to be quite close to finished, if not actually finished.
Hello all!
Yes, I'm still alive.
Actually...maybe too alive... The popularity of my work on the SNES has had the unintended and totally unexpected consequence of generating more contracting requests for my embedded system consulting business. We were already overloaded with requests but I've been completely overwhelmed for the last several months trying to figure out how to handle the influx of design/consulting jobs. I finally broke down and hired two additional contractors just to keep the business above water - I originally wanted to avoid this because my consulting business was never meant to be this much of a time sink, rather just some fun side work for me and a couple other friends.
It's been a crazy time as a result and on top of that one of my family members had a medical issue which wreaked all kinds of havoc in mine and my wife's schedules. On top of that my wife and I have also been in the process of negotiating a new lease agreement so we can move her private practice to a new location. Needless to say it's been a whirl wind and the last several months are mostly just a blur. 0.o
So, sorry to keep you guys in limbo. I'm hoping to get back to SNES/retro stuff in the very near future. Things are finally starting to settle down............................I hope.
Cya!
EDIT: One other thing I had wanted to mention (that I thought was kind of humorous) was that some folks at my primary job requested that I make a software emulator version of this new neuromorphic processor architecture that I designed (semi-,kinda-,sortof-related to this other project I worked on
viewtopic.php?f=5&t=14821). They primarily want the emulator because the FPGA hardware required to run the real deal is incredibly expensive and an ASIC implementation is still in the works.
When I first started working on emulation over a decade ago I never thought it would end up filling my every waking hour!
Keep up the good work!!!!
Please don't stop!
Your project is much better than Super NT.
jwdonal,
It's been a month, I know in your last post you covered how busy you have been, I hope the medical issues have cleared up, but do you have time for a small update for us? Even if the update is I'm still too busy to work on this!
Any hints on where you are going to take this project?
Hi,
this is my first post so let me preface my entire writing which could seem crude or polemical without any premise:
- First of all I hope your family member solved its medical issue: health and family first.
- Let me thank you for getting me interested in FPGA. I watched with marvel your YouTube videos the first days I discovered about FPGA in retro gaming/computing. Then the FPGA emulation bug grew strong in me and now I own a MiSTer FPGA system and a Super NT. However, all started reading about MiST and watching your videos, so… thank you very much!
- I’m a strong believer in Intellectual Property and copyright; I’m a software dev and I run my own company earning its living thanks to its IPs. So… your work, your IP, your rules! You’re totally entitled to do whatever you want with your IPs.
Having said that, let me share my opinion about the VeriSNES release, without criticism:
- Monetary value: I really believe you put many valuable high level engineering work hours in this project, and all these hours could mean big money under a contract. My point is that you did this project as a spare time hobby project, without any contract, so this is not the right way to evaluate it. You could evaluate VeriSNES as a product, but, in this historical moment, this product has no (or a really low) monetary value since all FPGA SNES demand has been satisfied by Super NT. It may be sad, but I think that the market can absorb just one FPGA SNES so the money goes to whoever handles to be the first on the market; this already happened.
- China stealing IPs. This is an unpleasant fact of life, it always happened and it will always happen both for open source and copyrighted IPs. I don’t mean we must resign to this, but not releasing IPs is not the right way to fight IP theft. See what happens almost daily with Libretro/Retroarch and Kodi; this doesn’t stop them to release all their fantastic work. Not releasing an IP for fear of IP theft is just nonsense to me.
- Lack of time. I really know this problem and I’m sympathetic with you. Open sourcing VeriSNES as is would be a solution for that. Just release it and let the community put all the bells and whistles.
It’s a real pity seeing such a great project not being released. The time for releasing it as a commercial product is gone; time will come when someone else will release an open source HDL SNES and any interest for VeriSNES will be vanished. IMHO it’s better to open source it now and gain some community love than just letting it die.
Again, having said that, I repeat:
your work, your IP, your rules! Max respect to that.
That’s my two cents.
Best regards.
Locutus73
Locutus73 wrote:
The time for releasing it as a commercial product is gone
I disagree. I think there's room in the market for more than one FPGA SNES. But of course it requires the sizable extra effort of building a finished product rather than just a prototype.
It's not an easy decision to open source something like this. Once you do it, there's no going back.
thefox wrote:
Locutus73 wrote:
The time for releasing it as a commercial product is gone
I disagree.
I gladly accept your disagreement. We’re here to discuss.
thefox wrote:
I think there's room in the market for more than one FPGA SNES. But of course it requires the sizable extra effort of building a finished product rather than just a prototype.
Mmmhh… I don’t know. I really don’t think there’s much space left for another full blown product like Super NT. Without considering all the difficulties in taking a prototype running on a dev board to a full blown product status; and then mass produce it and put it on the market. Kevtris abandoned the idea of doing all this by himself and partnered with Analogue in order to leave production issues to them. Maybe there could be space for a licensed compiled core for existing platforms like MiSTer; I don’t know, I see difficulties in license hardening; it could ask some specific hardware id (i.e. NIC mac address) to the underlying Linux, but this could be easily cracked.
I think jwdonal should also consider the possible monetary value of spontaneous donations to open source project developers. i.e. I donated to the MiSTer main dev more than I would pay for a licensed VeriSNES.
thefox wrote:
It's not an easy decision to open source something like this. Once you do it, there's no going back.
Yep, it takes courage.
But it also takes realism to see where the project is really heading (or not heading) to.
Locutus73
Having been in the open source circles for ages, most projects get very little donations, even if they actively ask for them.
calima wrote:
Having been in the open source circles for ages, most projects get very little donations, even if they actively ask for them.
True, anyway you’re right saying “most”... not all.
It depends on many factors.
Anyway, I didn’t mean “big money”, just some “thankfulness” money and much gratitude and love from the community (and the satisfaction of seeing his project evolving beyond his free time limits). I don’t think in this historical moment VeriSNES can do big money. Maybe (and I repeat maybe) one year ago, but I strongly believe not now.
And again:
his work, his IP, his rules.
It’s just sad seeing such a project going... who knows? Somewhere? In his basement’s lab? Nowhere?
Locutus73
Locutus73 wrote:
And again: his work, his IP, his rules.
If only certain ROM hackers appreciated this.
I could think of a good use for this for use in a product that isn't satisfied.
The older SNESs had pretty terrible RGB video output due to internal issues in PPU2's analog output. If possible, a device that would emulate PPU2 (and PPU1 as well if needed) that plugs into the mostly unused expansion port (assuming the necessary signals are there) that outputs HDMI and RGB would be amazing, and I'm sure lots of people would buy it. It would completely remove the need for owning a 1CHIP and you would still get the compatibility of a 3CHIP (assuming the FPGA core(s) are accurate). I think having a way to get sharper video out of a real 3CHIP console would sell quite well, especially if it was a modless solution.
An example of a similar existing product would be the Turbo Chameleon 64, which, among other things, has an FPGA implementation of the VIC-II that can output VGA:
https://www.c64-wiki.com/wiki/Turbo_Chameleon_64Being able to sell this product may give compensation, and jwdonal would be able to release source code for the FPGA core without harming sales (just be sure that verilog is somehow incompatible with the expansion port product so that Chinese clone manufacturers would have a difficult time reverse engineering it, like for example including a proprietary video scaler in the core for HDMI).
Of course, this would still require selling a product, which I'm not sure jwdonal wants to do, but it is always possible to partner with a manufacturer/retailer to get that product made, like how the SD2SNESs are made/sold.
syboxez wrote:
I think having a way to get sharper video out of a real 3CHIP console would sell quite well, especially if it was a modless solution.
If you have to use something on the expansion bus to emulate the PPUs in lieu of the original video output, you're arguably no longer getting any video out of a real 3CHIP at all. Why not just sell/buy an entire clone console at that point?
(To clarify: the only relevant signals that exist on the expansion port are the 8-bit peripheral bus and the PPU dot clock)
Revenant wrote:
If you have to use something on the expansion bus to emulate the PPUs in lieu of the original video output, you're arguably no longer getting any video out of a real 3CHIP at all. Why not just sell/buy an entire clone console at that point?
(To clarify: the only relevant signals that exist on the expansion port are the 8-bit peripheral bus and the PPU dot clock)
You'd still have a real CPU and APU in there, and people tend to like the accuracy that FPGA cores could theoretically provide (given they're implemented correctly). The Turbo Chameleon 64 is seen as a top of the line product for the C64 (likely due to its accurate emulation of the 1541 in addition to its multitude of other features, but also its VGA output), so I don't see a reason why we couldn't have a comparable top of the line product for SNES, and assuming accuracy, I don't see people minding the fact that the PPUs are emulated with an FPGA.
Also a quick look at the schematics show that all the data lines connecting the CPU and PPU1 together are available through the expansion port. Whether this would be enough to be able to replace PPU1 and PPU2 with FPGA replacements using the expansion port is unknown to me, as I do not develop hardware, but if it is, this could be a viable solution.
Assuming the price is <$100 or so, it would be a cheaper alternative to the Super NT that I'm sure people would be willing to buy (similar to how people still use the NESRGB and HiDef NES instead of just buying an NT Mini). And I don't think I need to elaborate on why cheapo clone consoles aren't a proper solution.
Hell, even the fat 1CHIPs have the same expansion port, so it might be possible to replace the integrated PPU1/PPU2 with more accurate FPGA versions, although I'm not sure how many people will want it for that purpose as the 1CHIPs already output good video (after proper attenuation).
syboxez wrote:
The older SNESs had pretty terrible RGB video output due to internal issues in PPU2's analog output.
Uh....
The original 5C78 has exactly the video bandwidth that Nintendo intended it to have. Sharp chunky pixels wouldn't have even been visible in the displays you could buy at the time.
Several SNES games explicitly took advantage of the limited bandwidth to cause color blending (e.g. Kirby's Dreamland); several Genesis games
did too.
syboxez wrote:
You'd still have a real CPU and APU in there
Honestly, those aren't The Hard Or Interesting Part.
Nevermind that S-CPUs seem to be what die the most readily anyway.
lidnariq wrote:
Uh....
The original 5C78 has exactly the video bandwidth that Nintendo intended it to have. Sharp chunky pixels wouldn't have even been visible in the displays you could buy at the time.
Several SNES games explicitly took advantage of the limited bandwidth to cause color blending (e.g. Kirby's Dreamland); several Genesis games
did too.
I don't think it's the video bandwidth that was the issue here, more the slow rise/fall times of the analog output of PPU2, which does not exist on the 1CHIPs. Color blending still doesn't happen using RGB on a 3CHIP, and I fail to see upsides to smearing the whole picture without having that. And if people want color blending, they should use composite anyway. I, for one among many others, prefer to use RGB even on games like Sonic where the developers intended the use of a composite output. This is especially the case since many developers used RGB on a PVM to develop their games, making this argument only apply to some games. Also the SNES had true transparency as a result of color math. And blending hi-res 512x224 graphics together is already possible without quality loss (see: emulators and Super NT).
I wouldn't be too sure that a blurry image was Nintendo's original intention when designing the SNES, and it is impossible to say that every game developer developed their games with the intention that the gamer would be using composite output, especially since the SNES supported S-Video and RGB.
lidnariq wrote:
Honestly, those aren't The Hard Or Interesting Part.
Nevermind that S-CPUs seem to be what die the most readily anyway.
In my experience, PPU2 seems to die the most (I have a few consoles with dead PPU2s and only 1 with a dead CPU), but that's anecdotal.
syboxez wrote:
I don't think it's the video bandwidth that was the issue here, more the slow rise/fall times of the analog output of PPU2
Those are two ways of saying the same thing.
Quote:
Color blending still doesn't happen using RGB on a 3CHIP
And no significant population had displays that could use the RGB output outside of arcades. (And ... maybe SCART users in europe? How prevalent was that?)
Quote:
I, for one among many others, prefer to use RGB
You're allowed to like things that are better than reality, big chunky pixels and all. But don't claim that they're authentic; they're every bit as fake as Eagle or 2xSaI.
Quote:
I wouldn't be too sure that a blurry image was Nintendo's original intention when designing the SNES
They did
three different revisions of PPU2 without increasing the video output bandwidth. They clearly thought it was working as intended. Given
how buggy the 1CHIP is I don't think one could reasonably argue its output was the "intended" version either.
Quote:
it is impossible to say that every game developer developed their games with the intention that the gamer would be using composite output, especially since the SNES supported S-Video and RGB.
I don't need to disprove anyone did. I just need to ask
what did the average person have? And the answer is: composite, which is already lower video bandwidth what the 5C78 emitted as RGB.
I made a page illustrating the SNES' blurry RGB, and where it happens. It is not intentional, as the PPU can slam the R/G/B to full on or to black, but transitions to an intermediate shade take a long time to settle, hence blurriness:
http://www.chrismcovell.com/gotRGB/snesblur.html
... yeah, ok, that's clearly a variable impedance as a function of the output voltage, i.e. a changing bandwidth as a function of the brightness, which there's really no way to justify.
Sorry.
lidnariq wrote:
And ... maybe SCART users in europe? How prevalent was that?
I'm from Italy and I don't remember any TV without SCART since I was a kid (look at my nickname for guessing how old I am).
My first use of SCART was with a Philips TV and my C64 in the 80s. Here a RGB SCART cable was the first mandatory accessory (ok, I know it's an oxymoron) to buy with any old console and computer.
Locutus73
lidnariq wrote:
And no significant population had displays that could use the RGB output outside of arcades. (And ... maybe SCART users in europe? How prevalent was that?)
TV with SCART were mandatory in France.
And Finland as well, every TV came with SCART, and consoles shipped with SCART adapters, because not every TV had composite input. Those adapters were naturally composite -> scart, not true RGB; true RGB cables were sold everywhere.
calima wrote:
And Finland as well, every TV came with SCART, and consoles shipped with SCART adapters, because not every TV had composite input. Those adapters were naturally composite -> scart, not true RGB; true RGB cables were sold everywhere.
Yep… those little RCA to SCART adapters. They always stayed in their original unopened plastic bags here. Composite was always considered simply unwatchable.
Locutus73
Right. A while ago I'd discovered that in France, due to SECAM, their NES had to use RGB. But what I was asking was—given that SCART does, for good and ill, actually support composite—how often did the original bundled cables support RGB and/or how often did people buy the better cables.
You seem to have answered that too.
lidnariq wrote:
Right. A while ago I'd discovered that in France, due to SECAM, their NES had to use RGB.
Same exact issue with imported NTSC consoles (popular here before the online era); RGB cable was mandatory in order to see… colours.
lidnariq wrote:
But what I was asking was—given that SCART does, for good and ill, actually support composite—
I’d say for good… SCART was cool for this reason, bringing multiple connection variants on the same cable.
lidnariq wrote:
how often did the original bundled cables support RGB
I never saw one.
lidnariq wrote:
and/or how often did people buy the better cables.
I can’t exclude that casual users (i.e. kids with consoles coming from Santa) used the included CVBS cable. Gamers with some knowledge preferred the (few bucks) optional better RGB cable. Hardcore gamers, with import consoles, had to use the RGB cable in order to see any colour.
[EDIT]
You NA guys missed the joy of trying to blindly plug a SCART connector on the back of a TV doing contorsions…
Locutus73
Locutus73 wrote:
You NA guys missed the joy of trying to blindly plug a SCART connector on the back of a TV doing contorsions…
Just pick the TV up with one hand & rotate it, grab the connector with the other hand and plug it in, then slowly put the TV down again.
Nothing I have ever seen suggests that Japanese SCART was particularly widely adopted, even in the SNES days, and most NES and SNES era game development took place in Japan.
Hi,
I just came across this topic, this VeriSNES project looks awesome!
I've written some FPGA cores too, especially SEGA Genesis/Megadrive, PC-Engine/TurboGrafx-16 (both in VHDL) and Atari Jaguar (Verilog).
See my site
http://lvt.tl/ for more information, and my GitHub repos
https://github.com/TorlusIs there any way I could help, if needed ?
What about the current status of the project, especially licensing/source status (open or closed) ?
Regards,
Gregory
Those are some impressive cores! Would you consider porting them to the MiSTer project?:
https://github.com/MiSTer-devel/Main_MiSTer/wiki
retrorgb wrote:
Those are some impressive cores! Would you consider porting them to the MiSTer project?:
https://github.com/MiSTer-devel/Main_MiSTer/wikiAlready done.
Except for the Atari Jaguar where the requirements are too high.
Wow, thank you! Too bad about the Jag! I wonder if it's powerful enough to run a SNES core as well?
retrorgb wrote:
Wow, thank you! Too bad about the Jag! I wonder if it's powerful enough to run a SNES core as well?
As the Genesis/Megadrive core works, I’d say yes.
However, this will remain a supposition until I can see the source code.
retrorgb wrote:
Wow, thank you! Too bad about the Jag! I wonder if it's powerful enough to run a SNES core as well?
Yes it is. The Super NT's FPGA is approximately half the size of the one in the MiSTer, and VeriSNES has already been ported to the MiSTer:
https://www.youtube.com/watch?v=7ae5iUe8diY
jwdonal, can you reconsider releasing the source for the benefit of MiSTer and other future community driven FPGA solutions? From a preservation perspective it would be of large benefit, and you might even make some money from your goodwill if you also have a patreon account.
And with the open source SD2SNES now supporting pretty much all the desired special chip games, there could presumably be a single device FPGA solution to playing essentially all of the SNES library (as I'm sure somebody would port that code to the MiSTer).
Torlus wrote:
retrorgb wrote:
Those are some impressive cores! Would you consider porting them to the MiSTer project?:
https://github.com/MiSTer-devel/Main_MiSTer/wikiAlready done.
Except for the Atari Jaguar where the requirements are too high.
That may not be the case. There are people like ElectronAsh working on porting your Jaguar core to mister. Maybe check it out and see how it's going?