It is currently Fri Jun 23, 2017 3:20 am

All times are UTC - 7 hours



Forum rules


Related:



Post new topic Reply to topic  [ 154 posts ]  Go to page 1, 2, 3, 4, 5 ... 11  Next
Author Message
PostPosted: Sat Dec 03, 2016 4:59 pm 
Offline
User avatar

Joined: Sat Dec 01, 2012 4:10 am
Posts: 63
As kind of a response to this thread, saying:
Quote:
[...]Is SNES homebrew dying, yet again?[...]

Would some SNES Development Hardware revive it?
I am in the process of designing Hardware, which could evenually end up to be a "modern" version of the Super NES Emulator SE (even though I can only imagine how one would have developed anything with the SE).
It was supposed to be just a BIOS for the SNES, which would allow loading games from an SD Card, dump Cartridges and SaveRAM. But I thought I can carry this much further.
Anyone have thoughts on this? I would like to hear opinions on whether this is going to be useful or not.


Top
 Profile  
 
PostPosted: Sat Dec 03, 2016 5:21 pm 
Offline

Joined: Wed May 19, 2010 6:12 pm
Posts: 2169
That will be awesome, especially if it comes with a sprite/tile editor.


Top
 Profile  
 
PostPosted: Sat Dec 03, 2016 5:37 pm 
Offline
User avatar

Joined: Sat Dec 01, 2012 4:10 am
Posts: 63
I would implement any feature thats within reach. For example i wanted to support partial SA-1 and SuperFX developement Features (if that is possible) by loading a program into the WorkRAM of a Cartridge, that should allow the processor to execute anything loaded in there. You could then write your program like that and test certain features (until there are SA-1 and SuperFX Implementations for an FPGA).
Another Feature is going to be Internet connectivity, but thats yet a far way until (though I have a ROM Downloader implemented :D).
Currently I am putting the pieces together


Top
 Profile  
 
PostPosted: Sat Dec 03, 2016 7:13 pm 
Offline
User avatar

Joined: Sun Sep 19, 2004 9:28 pm
Posts: 3192
Location: Mountain View, CA, USA
elseyf wrote:
... (even though I can only imagine how one would have developed anything with the SE). ...

This seems to be a statement implying unfamiliarity with actual ICEs. So what're your questions?


Top
 Profile  
 
PostPosted: Sat Dec 03, 2016 8:12 pm 
Offline

Joined: Mon Jul 02, 2012 7:46 am
Posts: 759
defparam is actually working on something similar, which he calls the 21FX-TL


Top
 Profile  
 
PostPosted: Sun Dec 04, 2016 1:01 am 
Offline

Joined: Wed Nov 30, 2016 9:59 pm
Posts: 52
elseyf wrote:
As kind of a response to this thread, saying:
Quote:
[...]Is SNES homebrew dying, yet again?[...]

Would some SNES Development Hardware revive it?


More than likely. I'm sure there is interest, it's just currently a rock-and-a-hard-place situation with emulating 16-bit systems (includes things like the Amiga, and 8088/80286 machines too) where acquiring working real hardware is too hard (or too expensive), but software emulation is only a close-enough approximation. One of the the other computer emulation communities that I've been to runs into the same problem where the hardware can't be emulated in software with enough precision that developing anything against the software emulator is a bit of an exercise in frustration. We can't be sure that is what the original hardware works like because not enough real hardware is in the hands of people who can reverse engineer them.

What I'd like to see is a SNES-FPGA kit that has a switch between HDMI-pixel-perfect scale (up to 8K) and Accurate (puts out 240p, use with external capture or upscaler) and can use original carts and controllers. A complete kit would need to emulate all the known chips if it doesn't have the cartridge slot, which means it may require a larger FPGA.

_________________
I come from the net. Through systems, peoples and cities to this place.


Top
 Profile  
 
PostPosted: Sun Dec 04, 2016 5:25 am 
Offline

Joined: Tue Oct 06, 2015 10:16 am
Posts: 447
As I've mentioned elsewhere, the biggest pain point in modern SNES development is the lack of a C compiler. bsnes is accurate enough to develop without emulator frustrations, using it you're fairly unlikely to hit any quirk on hw later on.


Top
 Profile  
 
PostPosted: Sun Dec 04, 2016 6:57 am 
Offline
User avatar

Joined: Sat Dec 01, 2012 4:10 am
Posts: 63
koitsu wrote:
elseyf wrote:
... (even though I can only imagine how one would have developed anything with the SE). ...

This seems to be a statement implying unfamiliarity with actual ICEs. So what're your questions?

The wiki-page did explain a good amount of things, but I actually already figured out most of what was mentioned in it. I meant the Super NES Emulator SE in specific, as there is no information whatsoever to be found, other than a scarce overview of its hardware (no software was ever seen).

Kismet wrote:
[...]What I'd like to see is a SNES-FPGA kit that has a switch between HDMI-pixel-perfect scale (up to 8K) and Accurate (puts out 240p, use with external capture or upscaler) and can use original carts and controllers. A complete kit would need to emulate all the known chips if it doesn't have the cartridge slot, which means it may require a larger FPGA.

I would love to include such an option. But there are two problems as far as I can tell:
1) The used FPGA wont be capable of driving an HDMI Signal (at least I have not found any Information, I use an Altera Cyclone II). However I could drive a VGA Signal with it, which I would assume to be enough to get a nice picture. VGA should also be fairly present on TVs and Monitors and not die any time soon (at least I hope so).
2) The PPU does not have a digital Output for composed Pixels, so in order to capture the video signal, I either have to somehow sample the analog signals from PPU2, process (upscale or anything else), then Output the analog for VGA. Or I need an FPGA PPU implementation that could mimic the PPU behavior (which is obviosly the better solution, but would require work that is not really on my TODO list).
Or maybe I am missing out on some way to get to the Pixel data?

calima wrote:
As I've mentioned elsewhere, the biggest pain point in modern SNES development is the lack of a C compiler.

What about cc65? Shouldnt that be suited for SNES development, or 65816 in general?
Quote:
bsnes is accurate enough to develop without emulator frustrations, using it you're fairly unlikely to hit any quirk on hw later on.

I figured that too, which is why I ask if there is even a need for development Hardware other than the existing Flash Cartridges.


Top
 Profile  
 
PostPosted: Sun Dec 04, 2016 7:46 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 18510
Location: NE Indiana, USA (NTSC)
A year ago, I made a list of SNESdev hurdles, some with solutions.

cc65 is for 6502, not 65816. Code produced under the assumption that a 65816 can act like a 6502 expects the data bank register to equal the program bank register, and it uses a slow software stack through 8-bit accumulator and index registers. If your object code exceeds 32K, you have to string together the different banks as completely separate programs. And there's a feeling that it's not efficient enough to make the sort of detailed action games that people expect out of the Super NES. Finally, though macros exist to make SPC700 code with 65C02 mnemonics (thanks blargg), I haven't seen anyone hook up cc65 in that way. Would tcc-65816 work?

If you want to make a 16-bit game in C, here are the first of 68,000 things you could try:
  1. Read through the first book of the Bible.
  2. Listen to a rock album that shows a Tupperware Shape-O sorting toy on the cover. (Clue: Phil Collins sang on it.)
  3. Take the Bible and the CD to your Hyundai dealer and ask about a sporty sports car.
  4. Have Xzibit put a game console in your car so your passenger can...

In case you're confused: If use of C is a sticking point, start with the Sega Genesis rather than the Super NES. To get started, try spritesmind.net.


Besides, no compiler is going to draw several megabits of sprites, background tiles, and audio waves for you. And as dougeff pointed out, a 16-bit game is going to need to look at least as good as Super Mario World.


Top
 Profile  
 
PostPosted: Sun Dec 04, 2016 8:20 am 
Offline
User avatar

Joined: Sat Dec 01, 2012 4:10 am
Posts: 63
I have mistakenly assumed ca65 compatibility would also apply to cc65.
However I have seen WDCTools is available for free, that would at least supply you with an additional IDE.
Other than that, it seems that tcc-65816 is the only open source solution available?


Top
 Profile  
 
PostPosted: Sun Dec 04, 2016 11:34 am 
Offline

Joined: Tue Oct 06, 2015 10:16 am
Posts: 447
WDC's cannot be used for commercial development, it's Windows-only, and does not support the SNES directly. The tcc port is so buggy it cannot be called a compiler.


Top
 Profile  
 
PostPosted: Sun Dec 04, 2016 12:30 pm 
Offline

Joined: Wed Nov 30, 2016 9:59 pm
Posts: 52
elseyf wrote:
Kismet wrote:
[...]What I'd like to see is a SNES-FPGA kit that has a switch between HDMI-pixel-perfect scale (up to 8K) and Accurate (puts out 240p, use with external capture or upscaler) and can use original carts and controllers. A complete kit would need to emulate all the known chips if it doesn't have the cartridge slot, which means it may require a larger FPGA.

I would love to include such an option. But there are two problems as far as I can tell:
1) The used FPGA wont be capable of driving an HDMI Signal (at least I have not found any Information, I use an Altera Cyclone II). However I could drive a VGA Signal with it, which I would assume to be enough to get a nice picture. VGA should also be fairly present on TVs and Monitors and not die any time soon (at least I hope so).
2) The PPU does not have a digital Output for composed Pixels, so in order to capture the video signal, I either have to somehow sample the analog signals from PPU2, process (upscale or anything else), then Output the analog for VGA. Or I need an FPGA PPU implementation that could mimic the PPU behavior (which is obviosly the better solution, but would require work that is not really on my TODO list).
Or maybe I am missing out on some way to get to the Pixel data?


1) You can drive HDMI directly with a FPGA, the catch is that most FPGA dev boards use a separate chip to do HDMI,VGA and Composite video thus incur latency and timing issues with the PPU. Thanks NTSC.

2) From a development perspective you'd have to emulate the PPU1 and PPU2 as it exists in hardware, and then drive a pixel doubler and HDMI output where the S-ENC/S-MIX is normally. If you are developing something to target 10 year old computer monitors and televisions, yes VGA might be fine, but that is not the direction anything is going. If you buy a 4K monitor, there is only DisplayPort, HDMI2.0/MHL or USB-C (which includes power for MHL, and HDMI 2.0 or DisplayPort alternate modes.) 4K monitors can still do VGA resolution at 640x480, but that invokes the monitor's scaler, which adds latency in pretty much every case. 4K televisions are worse in this regard as they've been deleting S-Video, VGA and YPbPr component connections, and "smartTV" add additional latency that previous models previous overlays didn't have. The video scaler's in TV's assume you're connecting something like a VHS deck where you can simply stretch the video and it doesn't make the video any worse than it was originally, and the latency is irrelevant. When you connect a video game to a TV, unless it explicitly has a game mode for that input, it typically gets stretched in ways that makes the pixels smeared.

Like I get it, on one side people would prefer an accurate pixel-perfect emulation, which requires emulating the PPU in a way that multiplies the pixels at the last stage possible. On the other hand doing so would require more complex FPGA's. See the difference between the RetroAVS(Xilnix Spartan 6) vs. Analogue Nt mini(Altera Cyclone V), where the former is $150 and the latter is $450. I'd assume a devkit system would be more like the latter with all the options.

That said the main issue with developing things for 16-bit systems is that they are not things you can just develop on a software emulator and then expect to work on real hardware or re-engineered hardware. It's not enough to go "it works", it has to "work on every version." So it's very likely any development solution ends up being two FPGA's, one that emulates the base system, and one that emulates the cartridge and any additional coprocessors, because the co-processors are not always used (and if the option to use the SA1 were always available, it's likely that it would be used, but that then limits it to people who have a cartridge with it.) If someone wants to release their homebrew SNES game, right now you have no guarantee that it works on anything but the emulator it was developed against. So it's very likely that a fully functional devkit ends up costing $1000, which puts it out of price range for just about everyone.

I'd like to see such a thing, even if it's expensive, but I think at some point it has to be evaluated for practicality. Would it be cheaper to have 4 cheaper FGPA's than one expensive FPGA? Who knows until someone tries.

In case people haven't seen it
http://pgate1.at-ninja.jp/SNES_on_FPGA/rpt_DE2-115.htm
The SFC FPGA here, 28,417 / 114,480 Logic elements for the entire SFC. Of which 13476 Logic cells are for the APU alone(11400 DSP, 1707 SPC.) 11853 For the rest of the CPU/PPU (1790 DMA, 2160 MPU, 7060 PPU1, 392 PPU2)
I've seen at least two FPGA projects online that have done HDMI with the FPGA alone, but because they require high speed transmitters, they can't just use cheap FPGA's and high resolution.

_________________
I come from the net. Through systems, peoples and cities to this place.


Last edited by Kismet on Sun Dec 04, 2016 1:34 pm, edited 2 times in total.

Top
 Profile  
 
PostPosted: Sun Dec 04, 2016 12:30 pm 
Offline

Joined: Mon Mar 27, 2006 5:23 pm
Posts: 1276
tepples wrote:
If you want to make a 16-bit game in C, here are the first of 68,000 things you could try:
  1. Read through the first book of the Bible.
  2. Listen to a rock album that shows a Tupperware Shape-O sorting toy on the cover. (Clue: Phil Collins sang on it.)
  3. Take the Bible and the CD to your Hyundai dealer and ask about luxury cars.
  4. Have Xzibit put a game console in your car so your passenger can...


Image


Top
 Profile  
 
PostPosted: Sun Dec 04, 2016 12:38 pm 
Offline
User avatar

Joined: Fri May 08, 2015 7:17 pm
Posts: 1599
Location: DIGDUG
For me, the lack of compiler is the least of my worries. I'll use ASM (ca65).

My main concerns are...
-no specific GUI tool for working with SNES graphics
-music (SPC programming)
-I had to read multiple, very large technical documents just to print "Hello World" on the screen.

But, at least we have 2 decent SNES emulators with debugging tools (thanks guys)

Oh, and I still need to buy a flash cart. RetroUSB is out of SNES PowerPaks, and Krikzz doesn't take PayPal... so I'm not sure what I'm going to do there (I don't like paying for online things with credit cards).

_________________
nesdoug.com -- blog/tutorial on programming for the NES


Top
 Profile  
 
PostPosted: Sun Dec 04, 2016 1:19 pm 
Offline

Joined: Tue May 28, 2013 5:49 am
Posts: 588
Location: Sweden
dougeff wrote:
For me, the lack of compiler is the least of my worries. I'll use ASM (ca65).

My main concerns are...
-no specific GUI tool for working with SNES graphics
-music (SPC programming)
-I had to read multiple, very large technical documents just to print "Hello World" on the screen.

Yeah if these worries could be tackled I feel like SNES homebrew scene could take off kind of like the NES one. A Snes Screen Tool and a SNES Nerdy Nights to help people get started would be great. I haven't looked into SPC programming so much yet but there at least seems to be some kind of MML for Super Mario World and lots of info about Nintendo's N-SPC engine. An open source version of N-SPC would be nice too.

Quote:
But, at least we have 2 decent SNES emulators with debugging tools (thanks guys)

Oh, and I still need to buy a flash cart. RetroUSB is out of SNES PowerPaks, and Krikzz doesn't take PayPal... so I'm not sure what I'm going to do there (I don't like paying for online things with credit cards).

I never had the Powerpak but it seems to me to be just very expensive and yet inferior to most other modern SNES flashcarts. It costs almost as much as the SD2SNES and yet it's worse than the Super Everdrive in every way. I have the SD2SNES and it's almost flawless and fully open source, but the Super Everdrive seems to be a solid and inexpensive alternative. There's a list of official resellers for Krikzz' products here (Krikzz makes and sells the SD2SNES too).


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 154 posts ]  Go to page 1, 2, 3, 4, 5 ... 11  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: Google [Bot] and 4 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group