Jump to content
IGNORED

FPGA Based Videogame System


kevtris

Interest in an FPGA Videogame System  

682 members have voted

  1. 1. I would pay....

  2. 2. I Would Like Support for...

  3. 3. Games Should Run From...

    • SD Card / USB Memory Sticks
    • Original Cartridges
    • Hopes and Dreams
  4. 4. The Video Inteface Should be...


  • Please sign in to vote in this poll.

Recommended Posts

My personal guess about the Super NT jaibroken fw is that it is going to include some of the enhancement chips because Kevtris has at least a SA-1 custom board for reverse engeenering :

https://youtu.be/-Mk8oO6TRl4?t=3h8m50s

^^

I'm hoping if/when there's a jailbreak firmware it'll at least include the chips that are currently simulated on the SD2SNES, even if the different chips have to be shuffled off to a "second" SNES core, like is done with some of the mappers on the NT Mini NES core. SA1 and SuperFX jailbreak support would be amazing, but I understand it may not be possible. This brings to mind 2 questions I've been thinking about regarding the Super NT for awhile now:

 

1. For SA-1 and SuperFX, would it be possible to use a real cartridge equipped with these chips as a "donor cart", so to speak, to just use the real chips for processing, but load the rom from the internal "rom cart" on the FPGA? I assume this would be impossible if there is any interface between SA1 or SuperFX and the ROM on the cartridge, but i would think it would be feasible if the chips only interfaced with system RAM.

 

2. Assume unlimited FPGA space and the successful reverse engineering and implementation of all of the SNES enhancement chips onto a single FPGA core. Could some kind of crazy homebrew be written that could use all of the expansion chips?

Link to comment
Share on other sites

I'm hoping if/when there's a jailbreak firmware it'll at least include the chips that are currently simulated on the SD2SNES, even if the different chips have to be shuffled off to a "second" SNES core, like is done with some of the mappers on the NT Mini NES core. SA1 and SuperFX jailbreak support would be amazing, but I understand it may not be possible. This brings to mind 2 questions I've been thinking about regarding the Super NT for awhile now:

 

1. For SA-1 and SuperFX, would it be possible to use a real cartridge equipped with these chips as a "donor cart", so to speak, to just use the real chips for processing, but load the rom from the internal "rom cart" on the FPGA? I assume this would be impossible if there is any interface between SA1 or SuperFX and the ROM on the cartridge, but i would think it would be feasible if the chips only interfaced with system RAM.

 

2. Assume unlimited FPGA space and the successful reverse engineering and implementation of all of the SNES enhancement chips onto a single FPGA core. Could some kind of crazy homebrew be written that could use all of the expansion chips?

 

1. Donor carts, No it wouldn't be directly possible because of where the chip exists in the cart. The Mask ROM, and SRAM are always connected. At least two pinout maps out there suggest that the south end of the SA1 chip connects to the SNES bus and the north end connects to the MASK ROM along the same bus. The problem I see is that even if the ROM/SRAM is prevented from being accessed by the FPGA CPU, there is nothing stopping the SA1 from accessing it. The most likely scenario here is really to have the SD2SNES or some other flashcart emulate the chip alone if additional FPGA power is needed. But it's likely that all the chips could be emulated by the NT Mini, just not all at the same time (and that's an unlikely configuration.) So you might have to switch between "SNES+SFX","SNES+DSP's","SNES+SA1" modes or something in the same way you'd switch between a GB, SGB, GBC.

 

2. In theory yes, for practical reasons, unlikely.

 

The SuperFX chip is a RISC CPU that acts like a GPU in modern contexts. In theory you could "overclock" it.

The Cx4 chip is a DSP by Capcom

DSP1-4 are DSP's by Nintendo

S-DD1 is basically a hardware image decompression chip

S-RTC is a real time clock

SA-1 is a faster 5A22 that acts in parallel with the system CPU, hence this requires roughly the same amount of FPGA space as the main CPU

SPC7110 is another image decompression chip plus a RTC

ST010,011 and 018 are all CPU's used for AI in games, of which the latter two are only used in Shogi titles, and the 018 is out of reach for a FPGA, having CPU power closer to that of the GBA.

 

If you could access all of them at the same time, you'd jam up the expansion bus, and it's likely that something like the SA-1 and SuperFX would never be able to communicate with each other.

 

Between the SNES and the Amiga, both systems essentially were early attempts at separating the subsystems to make use of parallelism and waste less bus bandwidth. Where as on the PC at the time, absolutely everything went over a single bus, and manual configuration of addresses and IRQ's were needed. There was no parallelism. If you stuck something like a RAM expansion board into an ISA slot, during the memory test you'd get the onboard memory to test at normal speed, but as soon as it hit the expansion board it would be slowed down to the expansion bus speed, a bus that was shared with the video, sound and other things. I imagine on the SNES, if it were possible to stick something like the SuperFX and the S-DD1 on the same bus, you'd have to use the main CPU to pass data between them, thus slowing the bus bandwidth in half.

 

In theory though, it's a FPGA, you could probably overclock all the chips and the bus. But you'd never be able to get a game to work on to different versions of the JB firmware, let alone any software emulators in order to debug it.

Link to comment
Share on other sites

Just got my SFC NTT Data Controller. Works GREAT with the ColecoVision core.

Nice, I recently got 2 from amazon japan via a japanese middleman/buyer site. Now just waiting on my Raphnet adapters. My friend works at WGN and they were going to recycle all of their PVMs/BVMs and I helped him haul them out and ended up with a new in box BVM-201FU for 60 bucks, but no control box. So until i get a control box I can't use RGB on the monitor because of how sync works, but it does accept and autodetect YPbPr without the control box... once I got the necessary BNC to RCA adapters. All of these things I'm buying are causing me to buy other things.

Link to comment
Share on other sites

I'm hoping if/when there's a jailbreak firmware it'll at least include the chips that are currently simulated on the SD2SNES, even if the different chips have to be shuffled off to a "second" SNES core, like is done with some of the mappers on the NT Mini NES core. SA1 and SuperFX jailbreak support would be amazing, but I understand it may not be possible. This brings to mind 2 questions I've been thinking about regarding the Super NT for awhile now:

 

1. For SA-1 and SuperFX, would it be possible to use a real cartridge equipped with these chips as a "donor cart", so to speak, to just use the real chips for processing, but load the rom from the internal "rom cart" on the FPGA? I assume this would be impossible if there is any interface between SA1 or SuperFX and the ROM on the cartridge, but i would think it would be feasible if the chips only interfaced with system RAM.

 

2. Assume unlimited FPGA space and the successful reverse engineering and implementation of all of the SNES enhancement chips onto a single FPGA core. Could some kind of crazy homebrew be written that could use all of the expansion chips?

1) It should be possible, other devices can do it so I see no reason why a fpga couldn't replicate that. Having said that, I think that would be a last ditch way to get the chips working after everything else had failed. Fairly certain Kevtris intends to just support them outright.

2) Sure it would be possible but it will almost certainly never happen because of the power needed to do it and the effort needed to code and implement it all so someone could maybe make a game with it.

Link to comment
Share on other sites

My personal guess about the Super NT jaibroken fw is that it is going to include some of the enhancement chips because Kevtris has at least a SA-1 custom board for reverse engeenering :

https://youtu.be/-Mk8oO6TRl4?t=3h8m50s

^^

If Kevtris has something up his sleeve, he's keeping quiet about it. He very well may be sitting on Super FX and SA-1 cores, but another hurdle is if the RAM access is fast enough to interface ie a 22Mhz FX-2 CPU or even the 11Mhz FX and only slightly slower SA-1.

 

There's also a couple of potential snags with release of the jailbreak software on Super NT (not present on the NT Mini) or the Super NT core being present on a future Zimba3000.

 

For starters, if Kevtris is doing work for hire, then his SNES core would be the property of Analogue, meaning Kevtris would explicitly need to ask for permission in order to release a jailbreak firmware with the SNES core. Again, I don't see Analogue having issues with this as it would boost sales of the Super NT.

 

A bigger hurdle is Kevtris retaining rights to his own code if in fact the SNES core is considered work for hire. Generally IP created by an employee during the course of his or her employment remains the property of the company. For instance if a cartoonist working for Disney does an illustration of Mickey Mouse, he cannot turn around and sell prints of it online. So the other cores made during Kevtris' free time are presumably not property of Analogue, but the SNES core is.

 

So if Kevtris designs a "Zimba 3000" system and kickstarts it or starts production of his ultimate FPGA gaming system, the SNES core would have to be licensed from Analogue, which is unlikely for as long as the Super NT is marketed and sold by Analogue.

 

So the next best thing that could happen is the Super NT becomes the Zimba3000, playing both 8-bit and 16-bit software from a variety of consoles. I'm not sure if SNES controller port have enough pins to be reassigned for NES / Famicom carts, but most other consoles would work in theory through pin adapters, save for N64 and GBA being clocked too fast / too advanced for the FPGA.

 

By sheer pin count, Famicom have only two more pins than a full SNES slot plus expansion pins (and some of those pins are duplicate VCC/GND), but not all 58 pins may be directly reconfigurable, for instance special functions like the analog audio input pins.

 

I would definitely pay for a Genesis adapter however, should one ever be fabricated. And Atari as well.

 

For NES, well I still have the AVS but NES cores for the Super NT would be a nice gesture.

 

Wow, that was a lot of speculation on my part... :cool:

Link to comment
Share on other sites

For starters, if Kevtris is doing work for hire, then his SNES core would be the property of Analogue, meaning Kevtris would explicitly need to ask for permission in order to release a jailbreak firmware with the SNES core. Again, I don't see Analogue having issues with this as it would boost sales of the Super NT.

That is correct, but it assumes Kevtris doesn't have those rights already.

 

I personally am not predicting Kevtris intends to go through with the Z3k on his own as the Super Nt should basically make it redundant (with the exception of the N64) and simply don't see Analogue having much of a desire to strong arm him in negotiations about using code they couldn't get without him to add a massive selling point to their product. They would have neither the leverage nor the desire.

Link to comment
Share on other sites

That is correct, but it assumes Kevtris doesn't have those rights already.

 

I personally am not predicting Kevtris intends to go through with the Z3k on his own as the Super Nt should basically make it redundant (with the exception of the N64) and simply don't see Analogue having much of a desire to strong arm him in negotiations about using code they couldn't get without him to add a massive selling point to their product. They would have neither the leverage nor the desire.

I'm just wondering if Kevtris could retain ownership of the SNES core should something happen to analogue.

 

N64 FPGA won't be happening for a while yet. It WILL happen, but it will take a long time.

Link to comment
Share on other sites

I'm just wondering if Kevtris could retain ownership of the SNES core should something happen to analogue.

 

N64 FPGA won't be happening for a while yet. It WILL happen, but it will take a long time.

That is a good question and I suppose it would largely depend upon the wording of his contract. Personally though I'm predicting Analogue to do extremely well with the release of the Super Nt so I can't imagine them going anywhere.

 

Also yes, I was in no way saying I expect a N64 fpga to be happening anytime soon, I mean the snes just came out. I figure the bare minimum they would want to get out of that is 18 months or they would risk fatiguing the market even at the new low price. And Kevtris should probably take a vacation or something at some point, he's been working like a madman.

Edited by Wolf_
Link to comment
Share on other sites

Word. N64 is orders of magnitude more complex than SNES both in CPU complexity, speed, and memory.

Yea, the 18 months thing was under the assumption the product was even ready and given the time it would take to develop and that hardware capable of running it might not be cost effective it could easily be way longer than that.

Link to comment
Share on other sites

I believe the work Kevtris is doing for Analogue (NT Mini, Super NT, and future projects) is for sure, the foundation for his Zimba 3000. It is likely an intermediate to long term project. The Super NT may get a few more bells and whistles, but I don't think it is going to be the Zimba 3000. I would guess Kevin wants to design and tailor that from the ground up. He would implement the cores he would have already been paid to develope. This would likely be after his work with Analogue is done and the systems he worked on were no longer in production. I would also think that FPGA technology needs to mature a bit more and become less expensive for a feasible "all in one" system like the Zimba 3000. I guess it would be determined by the cut off point for the systems the Zimba 3000 would support.

Link to comment
Share on other sites

While software companies usually own the IP of anything you work on while working there, I think Kevtris is in a unique position to negotiate more favorable licensing. His skills and specific interest in this niche field, along with his proven track record of actually completing cores is probably rare enough that Analogue would be willing to license his core rather than owning the IP outright.

 

Also, now that Kevtris is involved with Analogue in a more official capacity, I can see them going through his other already completed cores to use as the basis for future bespoke consoles. Specifically Gameboy/Gameboy Color and Atari 2600. I would definitely buy a portable FPGA-boy with a GB/C cart slot backlit screen (perhaps at double the native resolution), and hopefully jailbreak firmware to add other portable cores like Game Gear, Supervision, Gamate, Game King etc. as well as any cores that would fit and work with the simple Gameboy style controls. The FPGA could potentially be smaller if the screen is only 480p, so less space for the scaling would be necessary.

 

We'll see what happens once the Super NT is released, regarding jailbreak firmware and Analogue's future plans. If they allow a jailbreak firmware with rom loading and ports of old cores (minus perhaps NES/Famicom, which is understandable), I think their strategy going forward is this:

 

Get the price down to mass market territory, advertise as a way to play your old carts on a modern TV, allow jailbreak features to cater to enthusiasts like us to boost sales and word of mouth. I think they can do this without cannibalizing sales of future consoles. I think they could allow the GB/GBC cores on the Super NT without cannibalizing future sales of an Analogue GB FPGA-boy, because portability and native compatibility with carts and link cables is valuable. The same goes for the NT Mini. They may decide its ok to port the NES/Famicom core to the Super NT, because native (without adapter) compatibility with original NES/Famicom controllers, accessories, cartridges, FDS etc. is valuable and not available on the Super NT. Similarly, a future Genesis core could be ported to the Super NT, even if there is an Analogue Genesis unit that has an AV in for 32X and pinouts for Sega CD units, because those features would be exclusive.

 

Basically, what I'm saying is they want to sell these things to the masses as simple ways to play their old carts with original controllers on their newfangled HDTVs. Your average person, even your average retro gamer, isn't going to care that much HOW that sausage is made and what's running under the hood. As long as they can sell enough to these average people, I don't see Analogue fully locking down each system they make to one core. I may be totally wrong but that's my prediction.

  • Like 1
Link to comment
Share on other sites

I wonder if FPGA resources could be shared between the SA-1 and the CPU. It'd require designing a new CPU, but the SA-1 runs at exactly 3x the clockspeed... If you timeshared the execution resources like the ALUs and allocated 3 units of time to the SA-1 for every 1 unit of time for the CPU... Or maybe maintained two separate register files and coarse-grained temporal multithreading...

Link to comment
Share on other sites

The serial number issue shouldn't affect operation of any other aspect of the system.

 

Per Analogue support:

"This is minor issue that our software development department is now currently addressing. It does not cause any functionality problems, however there will be a firmware update coming out soon to rectify the typo."

Link to comment
Share on other sites

I wonder if FPGA resources could be shared between the SA-1 and the CPU. It'd require designing a new CPU, but the SA-1 runs at exactly 3x the clockspeed... If you timeshared the execution resources like the ALUs and allocated 3 units of time to the SA-1 for every 1 unit of time for the CPU... Or maybe maintained two separate register files and coarse-grained temporal multithreading...

You can't just run a single core twice as fast (or quad in this case) and get two CPUs out of it. The SA-1 have address bus and registers independantly from the SNES core, so you'd need to have a totally separate state machine for each CPU. Perhaps some components could be shared but it would ultimately get in the way compared to doing separate cores. We just don't know how big the snes core is and how much free space there is for expansion hardware.

 

Give me SA-1, FX, DSP1, and maybe the Megaman chip, and I'll be happy.

Link to comment
Share on other sites

You can't just run a single core twice as fast (or quad in this case) and get two CPUs out of it. The SA-1 have address bus and registers independantly from the SNES core, so you'd need to have a totally separate state machine for each CPU. Perhaps some components could be shared but it would ultimately get in the way compared to doing separate cores. We just don't know how big the snes core is and how much free space there is for expansion hardware.

 

Give me SA-1, FX, DSP1, and maybe the Megaman chip, and I'll be happy.

 

Of course, which is why I was discussing time sharing the actual execution units at a lower level, or using a second register file for temporal multi threading (which is sort of like a simpler version of what Intel calls hyperthreading). That's how simultaneous multi threading works: you maintain two state machines and duplicate a few of the CPU components on the front-end like the dispatcher to keep the pipeline fuller. In the case of temporal multi-threading, it's a lot simpler than that, you're basically just supporting very fast context switches to get between the different execution states.

 

Why would you want to do this? Because the size of a processor on an FPGA is about the complexity of the chip, not the clockspeed. The SNES CPU and the SA-1 are very similar, so despite the SA-1 running at three times the clockspeed, it'd require a somewhat similar amount of space on the FPGA. If you could implement a single CPU and then time share it to handle executing two independent contexts (aided by the fact that the SA-1 runs at a clock multiplier of the SNES CPU), you essentially get two different chips implemented at a reduced space cost. For example, when Intel introduced hyperthreading (which much more complex than temporal multi threading), they estimated that it added roughly 5% to the die area: presumably that would also mean 5% more gates. But that's 5% more gates for double the number of simultaneous CPU contexts!

 

I've no idea how similar the SNES CPU and SA-1 are at a lower level: are the interrupts similar, is the instruction execution timing similar, etc. But if they're close enough, perhaps you could use some fancy tricks to fit both chips on a single FPGA using less than double the number of gates.

Link to comment
Share on other sites

You can't just run a single core twice as fast (or quad in this case) and get two CPUs out of it. The SA-1 have address bus and registers independantly from the SNES core, so you'd need to have a totally separate state machine for each CPU. Perhaps some components could be shared but it would ultimately get in the way compared to doing separate cores. We just don't know how big the snes core is and how much free space there is for expansion hardware.

 

Give me SA-1, FX, DSP1, and maybe the Megaman chip, and I'll be happy.

 

I agree that we do not know how big the SNES core is and what left over resources will be available for special chip emulation. From a business perspective, I would think the FPGA used in the Super NT was as inexpensive as possible to get the job done with original carts. Because of this, I don't believe there will be many resources available after the main SNES core is loaded. Unfortunately I don't think we are going to see special chip emulation without added help. I hope I am wrong about that. A guess would be to see something like a SD2SNES with custom firmware for the special chips. Ikari has already coded several SNES special chips for the SD2SNES. I'm not sure that would all be possible on the Super NT.

Edited by Sneakyturtleegg
Link to comment
Share on other sites

I agree that we do not know how big the SNES core is and what left over resources will be available for special chip emulation. From a business perspective, I would think the FPGA used in the Super NT was as inexpensive as possible to get the job done with original carts. Because of this, I don't believe there will be many resources available after the main SNES core is loaded. Unfortunately I don't think we are going to see special chip emulation without added help. I hope I am wrong about that. A guess would be to see something like a SD2SNES with custom firmware for the special chips. Ikari has already coded several SNES special chips for the SD2SNES. I'm not sure that would all be possible on the Super NT.

What's the point of paying top dollar for an SD2SNES when it can't, or doesn't currently support SA-1 and FX? Most of the others (besides the megaman one) are obscure Famicom RPGs or Strategy games. So I got an Everdrive for like 40% the price and added a DSP1.
Link to comment
Share on other sites

What's the point of paying top dollar for an SD2SNES when it can't, or doesn't currently support SA-1 and FX? Most of the others (besides the megaman one) are obscure Famicom RPGs or Strategy games. So I got an Everdrive for like 40% the price and added a DSP1.

Well, the SD2SNES supports the following chips: BS-X memory map / Satellaview base unit registers (clock), DSP1/1b, DSP2, DSP3, DSP4, ST-010, Cx4, MSU-1, S-RTC, and OBC1. It didn't support a lot of those from the beginning. It has routinely been updated and compatibility has consistently increased. Development still continues for it too. I know everyone wants SA-1 and Super FX/FX2. It may or may not happen but is possible. I really enjoy the MSU-1 and Satellaview stuff. I do understand the value of the Super everdrive, but for me, it was worth the extra money for the SD2SNES.
Link to comment
Share on other sites

 

Of course, which is why I was discussing time sharing the actual execution units at a lower level, or using a second register file for temporal multi threading (which is sort of like a simpler version of what Intel calls hyperthreading). That's how simultaneous multi threading works: you maintain two state machines and duplicate a few of the CPU components on the front-end like the dispatcher to keep the pipeline fuller. In the case of temporal multi-threading, it's a lot simpler than that, you're basically just supporting very fast context switches to get between the different execution states.

 

Why would you want to do this? Because the size of a processor on an FPGA is about the complexity of the chip, not the clockspeed. The SNES CPU and the SA-1 are very similar, so despite the SA-1 running at three times the clockspeed, it'd require a somewhat similar amount of space on the FPGA. If you could implement a single CPU and then time share it to handle executing two independent contexts (aided by the fact that the SA-1 runs at a clock multiplier of the SNES CPU), you essentially get two different chips implemented at a reduced space cost. For example, when Intel introduced hyperthreading (which much more complex than temporal multi threading), they estimated that it added roughly 5% to the die area: presumably that would also mean 5% more gates. But that's 5% more gates for double the number of simultaneous CPU contexts!

 

I've no idea how similar the SNES CPU and SA-1 are at a lower level: are the interrupts similar, is the instruction execution timing similar, etc. But if they're close enough, perhaps you could use some fancy tricks to fit both chips on a single FPGA using less than double the number of gates.

 

You wouldn't do this simply because that's not how the hardware timing works. The point of the FPGA console is to replicate the timing, and hence accuracy.

 

Just on principle, I can pretty much guarantee that the Super NT will only work with cartridges (and flash carts) out of the box. What we're all speculating on is IF it will be JB'd and when, and what do we get with that.

 

Also I think some people are make gross speculations on profit motives of Analogue. Unless they literately come out and say it, let's not put words in their mouths.

 

 

It's just as likely they can re-use the Super NT PCB for a Mega NT and just remap the cartridge pins, leaving everything else unchanged. This clearly wouldn't work to allow a SegaCD or 32X to work (it's unlikely a 32X would work just based on how it actually worked) AFAIK, the 32X just passes through the analog AV. This means that a real 32X would still require an analog TV. Otherwise the MegaNT would need to have it's own framemeister-like FPGA in it. There goes your latency. This is one of those cases where if someone really wanted to make all the Sega hardware work, they would be better off aiming for the CDX and include 32X as a bonus. Point of interest, the SH2, there is already a core out there, and runs on a Spartan 6 (j-core) with 25K logic elements. So perhaps such a device could in fact support the MD/CD and 32X with two cartridge slots, and use a USB-attached CD/DVD-ROM for real discs. Or just read correctly ripped discs off a sd-card.

 

Aside from the Genesis, they could also do "power base converter" in the same unit thus it having 3 slots. The PBC doesn't actually have any Master System hardware in it, though it can't run SG1000 games. That can be rectified. Likewise the Sega Card and Game Gear could be used on the same device either with yet another slot, or just a pin converter.

 

This is why I think putting words in Analogue's mouth about profits isn't very forward thinking. Why make 4 essentially identical devices, when you can produce one device that runs everything and only have to support one product. The fact that the NT Mini can and does run all the 8-bit games already is not going to destroy a market for a MegaNT that can play 8 and 16-bit games.

  • Like 1
Link to comment
Share on other sites

 

You wouldn't do this simply because that's not how the hardware timing works. The point of the FPGA console is to replicate the timing, and hence accuracy.

 

Just on principle, I can pretty much guarantee that the Super NT will only work with cartridges (and flash carts) out of the box. What we're all speculating on is IF it will be JB'd and when, and what do we get with that.

 

Also I think some people are make gross speculations on profit motives of Analogue. Unless they literately come out and say it, let's not put words in their mouths.

 

 

It's just as likely they can re-use the Super NT PCB for a Mega NT and just remap the cartridge pins, leaving everything else unchanged. This clearly wouldn't work to allow a SegaCD or 32X to work (it's unlikely a 32X would work just based on how it actually worked) AFAIK, the 32X just passes through the analog AV. This means that a real 32X would still require an analog TV. Otherwise the MegaNT would need to have it's own framemeister-like FPGA in it. There goes your latency. This is one of those cases where if someone really wanted to make all the Sega hardware work, they would be better off aiming for the CDX and include 32X as a bonus. Point of interest, the SH2, there is already a core out there, and runs on a Spartan 6 (j-core) with 25K logic elements. So perhaps such a device could in fact support the MD/CD and 32X with two cartridge slots, and use a USB-attached CD/DVD-ROM for real discs. Or just read correctly ripped discs off a sd-card.

 

Aside from the Genesis, they could also do "power base converter" in the same unit thus it having 3 slots. The PBC doesn't actually have any Master System hardware in it, though it can't run SG1000 games. That can be rectified. Likewise the Sega Card and Game Gear could be used on the same device either with yet another slot, or just a pin converter.

 

This is why I think putting words in Analogue's mouth about profits isn't very forward thinking. Why make 4 essentially identical devices, when you can produce one device that runs everything and only have to support one product. The fact that the NT Mini can and does run all the 8-bit games already is not going to destroy a market for a MegaNT that can play 8 and 16-bit games.

 

There is nothing about being digital or analog that implies that more latency is required to combine the two video signals. If the 32X and Genesis are genlocked and the video signals are being combined on the fly, you can do the same thing in the digital domain on a scanline-by-scanline basis.

 

 

 

Well, the SD2SNES supports the following chips: BS-X memory map / Satellaview base unit registers (clock), DSP1/1b, DSP2, DSP3, DSP4, ST-010, Cx4, MSU-1, S-RTC, and OBC1. It didn't support a lot of those from the beginning. It has routinely been updated and compatibility has consistently increased. Development still continues for it too. I know everyone wants SA-1 and Super FX/FX2. It may or may not happen but is possible. I really enjoy the MSU-1 and Satellaview stuff. I do understand the value of the Super everdrive, but for me, it was worth the extra money for the SD2SNES.

 

 

Of those chips, all of the DSP ones are supported by Everdrive, BS-X was never used for any retail cartridge (it's a satellaview mapper), Cx4 was two games, MSU-1 is for rom hacks, S-RTC is for one game, OBC1 is one game.

 

In other words, the SD2SNES supports only four retail games more than the Everdrive. I think the SD2SNES is a great solution, and it does still have future potential, but it's important not to oversell it. There is a significant cost difference, and I often see the SD2SNES being recommended to people with an implication that it supports a great many more games, when the reality is currently that it only supports 4 more games, and one of them requires a superscope anyhow.

  • Like 1
Link to comment
Share on other sites

I often see the SD2SNES being recommended to people with an implication that it supports a great many more games, when the reality is currently that it only supports 4 more games, and one of them requires a superscope anyhow.

A) It only supports 4 more retail games, as you said msu-1 is used for fan hacks and some of the soundtracks and fmv stuff that has come out for it is simply amazing (okay fmv is still fmv and looks like garbage but A Link to the Past with fmv cutscenes is just WTF). Also the Bs-X games.

B) The SD2Snes can be updated in the future to support the Sa1 and SuperFX chips.

C) The build quality of the Super ED is not as good as the SD2Snes and may shorten its own lifespan or that of your snes: https://db-electronics.ca/2017/07/05/the-dangers-of-3-3v-flash-in-retro-consoles/#Super_Everdrive

 

Overall: To anyone looking to buy a snes flashcart today I would wait for the Super Nt because it costs less than the SD2Snes on its own and has hdmi out and a bunch of amazing quality improvements and I'm 99% sure it will make the SD2Snes obsolete. If I'm wrong then I would strongly suggest the SD2Snes over the Super Everdrive because the handful of games it can support in the future alone makes up for the cost difference so the awesome fan hacks and Bs-x games are just icing on the cake.

Edited by Wolf_
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...