nesdev.org

That and last time I checked (today), PayPal offered a Debit MasterCard. That might help with dealers that have integrated a payment processor other than PayPal.

But both the EverDrive and the SD2SNES are backordered at the North American dealer.

I agree 100% with your ambitions to bring home brew hardware into this community. That is also my goal as well with 21FX-TL and EP. The fact that SD2SNES was open source helped me so much and I want to keep creating new hardware and help out others. With that spirit all the hardware I make I will release it open source because I want HW developers like you and others to take the technology and keep adding on. The cart I'm making has 1MB PSRAM and an FTDI USB controller so the capabilities of internet connectivity and dynamic ROM loading should be possible. However I understand these things take time and have to be iterative and a community effort. Right now my goal is to reduce the BOM cost while reporting back info on any proof of concepts I create with this hardware. I would like to get it into developers hands at a reasonable price/assembly. I'm a bit weary about things like HDMI and feature creep as it adds too much cost and complexity in early platform designs. However as time goes on and testing goes well I think the more advance features will come. Starting simple is key.

@Kismet:
I have done some more research and it turns out I would need a better, more expensive FPGA to drive a DVI or HDMI signal. The Cyclone II does not have the required TMDS Interface, and LVDS seems to be not suited to drive TMDS. And if the FPGA had the TMDS Interface, it would allow only for a 640x480 due to speed issues.
In addition to that, in order to get "the most responsive picture" I would need to rewrite the PPU for the FPGA for direct access to the pixel information, which I did not really intend to do.

Would it be cheaper to have 4 cheaper FGPA's than one expensive FPGA? Who knows until someone tries.

I dont think this applies, because in my situation using any more amount of the same FPGA wouldnt really help the missing TMDS Interface to pop up. So Isee no point in testing this (though I would love to be disproven by some crazy EE-Tricks ).

defparam wrote:I'm a bit weary about things like HDMI and feature creep as it adds too much cost and complexity in early platform designs.

This is true. I am currently just asking for what the hardware is supposed to do for someone using it, so I know what I could add to (or remove from) the project. The current goal remains to get ROMs loading from an SD Card and dumping a Cartridge's contents, all built into the console.

calima wrote:bsnes is accurate enough to develop without emulator frustrations, using it you're fairly unlikely to hit any quirk on hw later on.

Yeah, if you're a normal, sane person trying to develop a new game from scratch within the accepted limits of the Super NES. It won't let you get away with basic screwups like writing to VRAM during active display or using 60 KB of sample data with a 240 ms echo buffer, and even fancy tricks like Air Strike Patrol's mid-scanline scroll and brightness changes or blargg's echo buffer streaming technique will work fine.

If you're not a normal, sane person who respects the accepted limits of the Super NES, you can run into edge cases that bsnes doesn't handle properly. For instance, my ongoing attempt to port a shmup from a much more advanced platform set in motion a chain of events that resulted in bsnes acquiring mid-scanline BGMODE change capability as of higan v095, but it still doesn't emulate the glitched area properly; I need to test on real hardware to see the specks that show through the sprites used to mask the garbage. And the only reason I didn't run into trouble with mid-screen OBSEL changes is that I'm doing them mid-scanline; bsnes doesn't quite handle the timing correctly during HBlank (you shouldn't be changing OBJ base addresses during HBlank anyway, and why would you want to change sprite sizes? Even so). My largely useless DMA direct colour demo is another example of the timing in bsnes being slightly funky - oddly enough it works better in v072 (since I added the DMA/PPU alignment check) than in the latest versions, but in all cases the picture is displayed one scanline late. (It's still pretty cool that it works at all; no other emulator even displays the picture.) Finally, I seem to recall having trouble with turning off forced blank during HBlank; bsnes has/had slightly more forgiving timing than real hardware, so it was easier to get a glitch-free picture with the goofy H/V counter polling loop I was using (don't do this unless you have no choice; an IRQ is generally better, as is HDMA if you can spare a channel).

In every single one of those cases, I would refuse to speculate on the behaviour of a SNES Jr. without specifically testing on one. Apparently they're a fair bit different internally. Even the ASP brightness change trick doesn't work properly...

There's also the fact that it can be very difficult to get low latency with any PC-based emulator, so tuning the controls and designing the challenges in an action game could benefit from access to real hardware. (On the flip side, tuning the game in an emulator might be a way to more accurately target the bulk of your likely audience...)

Pokun wrote:it's worse than the Super Everdrive in every way

Not if you want to load an outsize ROM. Super Everdrive only has 7 MB of flash memory. And doesn't the PowerPak load faster?

Pokun wrote:

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.

I thought about making a tutorial, but the question is what PPU configuration should be recommended? I used to think this was a good arrangement:

$0000 sprites
$2000 BG1 map
$2800 BG2 map
$3000 BG3 map
$3800 BG4 map
$4000 4bpp tile patterns
$7000 2bpp tile patterns

...but that doesn't allow for Mode-7, because Mode-7 takes up the first 32kB so this might be a better arrangement:

$0000 Mode-7
$4000 sprites
$6000 4bpp tile patterns (for ground)
$7000 2bpp tile patterns (for HUD)
$7800 BG1 map (for ground)
$7C00 BG3 map (for HUD)

For a newbie tutorial there is no need to go into Mode 7 right away, a general VRAM setup is enough. You teach how to change each VRAM base address so people can set them in a way that is most suitable for their projects, and you can go into Mode 7 in a later chapter.

Currently bazz' tutorial seems to be the best one. But he uses WLA while people here seems to prefer ca65 (including me), and he has lots of confusing WLA-specefic macros not very suitable for a newbie tutorial. It would be best to write it so that the user can easilly change the assembler to one he prefers. Also there are a ton of overcomplicated variations of the init code, and none of them seems to follow the recommendations of the official dev docs.

93143 wrote:

Pokun wrote:it's worse than the Super Everdrive in every way

Not if you want to load an outsize ROM. Super Everdrive only has 7 MB of flash memory. And doesn't the PowerPak load faster?

Oh yeah I forgot Super Everdrive uses flash which is slow, what a bummer (Famicom Everdrive is a solid product so I'm kind of assuming Super Everdrive is good too). How much memory do the Super Powerpak have?
The SD2SNES is only a bit more expensive and offers a ton of more features though (RTC, Satellaview, Cx4, MSU-1 and other cool stuff). I don't know if it loads faster than the Powerpak, but it does load about instantly (it uses 16 MB PSRAM) despite using SD, and it has USB for transfering the ROM directly from the PC.

The PowerPak can reportedly load the chipless Star Ocean hack, which is 12 MB. I can't find a reference indicating how much memory it has, but since it doesn't support any bankswitching chips and there are unlikely to ever be any bare ROMs larger than 12 MB, I suppose the answer is "enough".

Oh that much? I didn't know. Then it beats the Super Everdrive at least in that area, although Super Everdrive is still big enough for all comercial ROMs. While the SD2SNES has 16 MB for ROMs, it supposedly only currently supports 12 MB, "as there are no larger known memory maps". Hopefully though in the future it will support S-DD1 so the Star Ocean hack will become obsolete for SD2SNES users.

SD2SNES loading speed seems to be ~9MB/s.
https://sd2snes.de/blog/status

Another thing I don't like about the Powerpak is that it only supports CF cards which are getting harder to come by here, and are also quite expensive.

> In every single one of those cases, I would refuse to speculate on the behaviour of a SNES Jr. without specifically testing on one. Apparently they're a fair bit different internally. Even the ASP brightness change trick doesn't work properly...

As I've said before, I can't prove it, but my guess is higan is closer to a real SNES than the SNES Jr is.

They really made radical changes to the PPU's mid-scanline behavior. Which turns out to be fine since only ASP actually does anything with it.

People seem unwilling to group the SNES Jr into the clone category simply because it's official hardware, yet they don't seem to have that hangup with the official NES Classic device.

I don't know where people fall on the Genesis 3, but I would count that as a clone device as well.

elseyf wrote:@Kismet:
I have done some more research and it turns out I would need a better, more expensive FPGA to drive a DVI or HDMI signal. The Cyclone II does not have the required TMDS Interface, and LVDS seems to be not suited to drive TMDS. And if the FPGA had the TMDS Interface, it would allow only for a 640x480 due to speed issues.
In addition to that, in order to get "the most responsive picture" I would need to rewrite the PPU for the FPGA for direct access to the pixel information, which I did not really intend to do.

Yeah what I'm thinking of was based on the original post of a complete devkit, not just a flash cart. If the plan is just for a debug-able devcart all you really need is a way to dump the RAM so you can compare it with Higan/BSNES.

elseyf wrote:

Would it be cheaper to have 4 cheaper FGPA's than one expensive FPGA? Who knows until someone tries.

I dont think this applies, because in my situation using any more amount of the same FPGA wouldnt really help the missing TMDS Interface to pop up. So Isee no point in testing this (though I would love to be disproven by some crazy EE-Tricks ).

The Cyclone II is 90nm, so it would probably not be feasible to put too much logic on it since it would require a more expensive version to produce.

When I was doing some research on the feasibility of a SNES-FPGA, apparently the FPGA (Cyclone V, which is a 28nm chip) used by the Analogue Mini NT, is just "capable" enough for 1080p with the entire NES logic on the FPGA. A very old post by kevtris says he used about 17500 gates on a 25K Cyclone III so based on the numbers by a previous SNES FPGA project , it looks like maybe 30,000 gates would be needed for the SNES before considering cartridge and video interface. However I don't know what exactly went into the Mini NT since nobody has one (that I'm aware of.) So I am pulling the numbers from guesses. Let's assume at some point a Cyclone VI comes out in 14nm, that would allow roughly 4x as many gates in the same die area, so might actually be cheaper then to produce a FPGA SNES then. Digikey's price for a single 5CEBA4F17C8N (Cyclone V E with 49,000 logic elements) is around $50. The next FPGA up 5CEBA7F23C8N is $160 with 149500 logic elements. I think every project trying to do a SNES FPGA is using a EP4CE115 Cyclone IV E FPGA Evaluation board (DE2-115) which is $595, has 114480 LE, and the chip alone is $315. And this board only has VGA and Analog audio output.

So right now, a complete "devkit" might be a bit on the ridiculous side, but just barely. Once you add in the other chips that could be emulated like the SA1 or the Cx4, that is large additional chunks of logic that will just sit idle in a base unit that a regular SNES would not have. I suppose one needs to ask the question of what, if any, additional chips do people actually intend to use. If you're just making a dev "cart" then you only need to enable one of those, the one the developer wishes to use, which would bring the logic units down, but also require the cart FPGA to be reprogrammed for each chip. Also... if the chip exists in both the cart and the base unit, how does the base unit know to turn off it's own chip?

elseyf wrote:

defparam wrote:I'm a bit weary about things like HDMI and feature creep as it adds too much cost and complexity in early platform designs.

This is true. I am currently just asking for what the hardware is supposed to do for someone using it, so I know what I could add to (or remove from) the project. The current goal remains to get ROMs loading from an SD Card and dumping a Cartridge's contents, all built into the console.

Feature creep suggestions is how you decide which features are actually useful, and which features are wishful thinking. I think the entire thing needs to be considered as two separate but related projects.

The cartridge-side, which would be something more like a "lock-on" cart that can intercept, dump, or pass-thru the cartridge, dump the reachable system memory from the system bus, maybe replicate expansion chips if that is viable.

The console-side which would have have a way to pause-and-dump/edit the memory either back to a flash cart or to something else like USB or a SD-card. I'm not sure off-hand if that can specifically be done from a cart, but if it can be done without a FPGA-SNES that makes it that much more valuable. If the entire SNES has to be emulated, you may as well go the entire Analogue NT mini route and create both an analog path and a digital path, but you can cross the road when you get there.

Right now nobody has published code to a PPU for the SNES. Like to me, I only care about pixel-perfect scaling that bypasses the monitor scaler. I don't care for scanlines or xBRZ or any of that, and IMO it shouldn't exist in a devkit because that adds an extra thing that games need to be tested with. Someone who tests the game against scanline mode might find that it doesn't in fact it does not even remotely look that way on a real SNES even on a CRT (which is one of the things pointed out with the higan emulator, is that frequently there are things not emulated due to the timing hacks needed to make the minimum requirements a Pentium 133 (DOS ZSNES circa 1999,) not a 3Ghz i7.) I'm pretty sure all the ARM-based emulators are throwing away a lot timing information because they are substantially weaker parts than desktop systems but still more powerful than where we started when SNES emulators began. I'm pretty sure Nintendo is aware of this as well, and what we get on the Virtual Console is "close enough that QA testers didn't notice"

Like as far as what is useful, I think developers are more interested in being able to pause the CPU/PPU and then peek/poke the ram in a debugger and compare it to what happens in BSNES.

The Emulator SE (from pictures I've seen) shows three FPGA's on them which appear to be connected to the respective CPU, PPU and SPC memory buses. At least that's what it looks like. So my best guess is that the SCSI connection gives the developer a live look at the memory, and the midi output over midi (I'm assuming the red connector is a S/PDIF) is to monitor the music to see if it's playing the right notes and samples. Re-implementing all that mess probably isn't necessary and could probably be streamed over USB in some way. But more to the point, just being able to pause the SNES and dump the memory to the card would probably do the same thing. I assume the SCSI connection also allowed the SNES to do "step-into", but that could probably be done differently since a computer in 1990 would have been way to slow to have emulated the entire SNES in software, so they'd want to use the real hardware to do that.

Anyhow on the software end of things, I'm sure more software would come out if there are known good flash carts that have predictable characteristics. RAM and Flash memory do not have the same speed as Mask ROM, which is another unknown variable. So what might be fast on a software emulator becomes sluggish on a real SNES with a flash cart due to using the SRAM as workspace. It might even be reasonable to make one of the more accurate emulators be able to connect to a devkit over USB or ethernet or something.

But I'm not suggesting putting the cart before the horse, if something can't be done today, it can likely be done when the devkit parts are cheaper to obtain. I'm under no impression that the SNES would suddenly become a popular development platform, so highend features aren't likely needed when the software emulators can do most of that.

Pokun wrote:Another thing I don't like about the Powerpak is that it only supports CF cards which are getting harder to come by here, and are also quite expensive.

So buy an SD-to-CF adapter? I say this without having tried one. I should also point out that I asked bunnyboy many years ago about why he went with CF over SD (SD at the time was around/available). I don't remember the exact quote, but his explanation was that CF was a lot easier to interface with (either in the FPGA code or circuit-wise, I don't know) than SD.

@koitsu:
I can approve of the SD Card Interface not being too easy, I have a 1000 line state machine just to read the first sector of an SD Card (this includes calculating the CRC and initializing the SD Card).

byuu wrote:As I've said before, I can't prove it, but my guess is higan is closer to a real SNES than the SNES Jr is.

Is there an up-to-date list of the differences? Also to clarify, are you referring to 1CHIP consoles using S-CPUN and S-APU? There are also units using S-CPU, S-PPU1, and S-PPU2 in conjunction with the S-APU. Newer PAL consoles are also 1CHIP without them being jr., and I think I recall there are jr's that use the old 3-chip setup.

> Is there an up-to-date list of the differences?

I haven't kept one, no.

What I know of is that the PPU mid-scanline effects are very different. For instance, adjusting the brightness register seems to only barely affect the brightness for some reason.

The weird glitchiness with the SMP timers in a certain edge case are also absent.

I don't know if these issues affect the 1CHIP consoles, but my guess is that they do. All of my testing has been on 1/1/1 and early 2/1/3 systems with separate chips for each component.

I've never heard of a Jr that wasn't a 1CHIP.

93143 wrote:There's also the fact that it can be very difficult to get low latency with any PC-based emulator, so tuning the controls and designing the challenges in an action game could benefit from access to real hardware. (On the flip side, tuning the game in an emulator might be a way to more accurately target the bulk of your likely audience...)

My usb keyboard has 1ms latency. The OS overhead can be expected to be less than half a ms. Does it really matter when a frame is 16.666ms? It's slower than a SNES controller, but in any visible way?