custom co-processor chips like the SVP?

For anything related to cart (SRAM, SF2 mapper, audio, CD mode 1, ...)

Moderator: BigEvilCorporation

Post Reply
djcouchycouch
Very interested
Posts: 710
Joined: Sat Feb 18, 2012 2:44 am

custom co-processor chips like the SVP?

Post by djcouchycouch » Tue Oct 16, 2012 11:21 pm

unfeasible wacky idea time: Seeing lots of folks developing custom carts on the NesDev forum, has anyone ever developed a custom chip like the SVP/SuperFX chip for use in a Sega Genesis cart?

I imagine a custom chip with sprite scaling/rotation and lots of math functions. Have support in SGDK. And make Super Goplanes!

I'll go back to reality now.

Charles MacDonald
Very interested
Posts: 292
Joined: Sat Apr 21, 2007 1:14 am

Re: custom co-processor chips like the SVP?

Post by Charles MacDonald » Wed Oct 17, 2012 1:03 am

djcouchycouch wrote:unfeasible wacky idea time: Seeing lots of folks developing custom carts on the NesDev forum, has anyone ever developed a custom chip like the SVP/SuperFX chip for use in a Sega Genesis cart?

I imagine a custom chip with sprite scaling/rotation and lots of math functions. Have support in SGDK. And make Super Goplanes!

I'll go back to reality now.
It's a great idea, somebody just needs to make a Genesis cart with a huge FPGA on it and some extra RAM and then anyone could design the custom functions of their dreams. Having math support would be great, we need a true 32x32 multiply and square root. :P

One of those Neo Geo homebrew game companies added a 32-bit ARM coprocessor to the cartridge that does most of the heavy lifting of game related tasks. The 68000 just has to shuttle data which the coprocessor prepares to VRAM, and read inputs now and then. I would imagine this approach let them develop the game rapidly and write regular C code without having to worry about performance. Probably helps portability to other platforms.

Anyway, something like that would work well on the Genesis too. Though I'd hope Super Goplanes would be SCD or 32X. :D

Chilly Willy
Very interested
Posts: 2984
Joined: Fri Aug 17, 2007 9:33 pm

Post by Chilly Willy » Wed Oct 17, 2012 1:34 am

I got an extra VR cart so I could unsolder the rom to replace with a flash rom, but the info on the SVP is limited to mainly a description of the machine code. There's not even a decent assembler for it.

More interesting is the SH2 - you can buy an SH2 from DigiKey cheap, and the tools for the SH2 are pretty mature. Given it's on the 32X and Saturn, some of us are pretty familiar with it. Using a single SH2 in a MD cart would be far more handy than the SVP.

An FPGA is a good idea, but much harder to take advantage of since you have to program it at the gate level. There are very few people who work on FPGAs, while something like the SH2 could use C/C++.

TmEE co.(TM)
Very interested
Posts: 2440
Joined: Tue Dec 05, 2006 1:37 pm
Location: Estonia, Rapla City
Contact:

Post by TmEE co.(TM) » Wed Oct 17, 2012 3:35 am

This thing is called Mega Everdrive :P
Mida sa loed ? Nagunii aru ei saa ;)
http://www.tmeeco.eu
Files of all broken links and images of mine are found here : http://www.tmeeco.eu/FileDen

Charles MacDonald
Very interested
Posts: 292
Joined: Sat Apr 21, 2007 1:14 am

Post by Charles MacDonald » Wed Oct 17, 2012 4:34 am

TmEE co.(TM) wrote:This thing is called Mega Everdrive :P
Haha, okay, you got me. :D

I guess it's only a matter of time before somebody makes a SVP implementation for it or something better. Might as well program the FPGA with one of those open 68000 cores for starters for dual CPU action.

Chilly Willy
Very interested
Posts: 2984
Joined: Fri Aug 17, 2007 9:33 pm

Post by Chilly Willy » Wed Oct 17, 2012 6:56 am

Yes, the MegaEverdrive is a good FPGA cart, but like I said, it requires programming at the gate level. I should probably get one myself.

TmEE co.(TM)
Very interested
Posts: 2440
Joined: Tue Dec 05, 2006 1:37 pm
Location: Estonia, Rapla City
Contact:

Post by TmEE co.(TM) » Wed Oct 17, 2012 8:47 am

System C is quite far from gate level and I think you can use it on Altera tools
Mida sa loed ? Nagunii aru ei saa ;)
http://www.tmeeco.eu
Files of all broken links and images of mine are found here : http://www.tmeeco.eu/FileDen

djcouchycouch
Very interested
Posts: 710
Joined: Sat Feb 18, 2012 2:44 am

Post by djcouchycouch » Wed Oct 17, 2012 12:32 pm

If one wanted to manufacture a cart like that, would it be simpler, cheaper and more feasible to make one with a "standard" chip like an SH2 (or two!) or with an FPGA?

Having 32X or Saturn class performance built into the cart would be pretty nice. And I would guess that more people have stray Genesis consoles than 32Xes or Saturns. It would be fun to work with a monster of a sprite machine.

Wouldn't it also be harder to emulate and limit piracy?

TmEE co.(TM)
Very interested
Posts: 2440
Joined: Tue Dec 05, 2006 1:37 pm
Location: Estonia, Rapla City
Contact:

Post by TmEE co.(TM) » Wed Oct 17, 2012 1:14 pm

Only problem you got is VRAM bandwidth, so you can perhaps have 1000 sprites but they take 3 frames to upload to VRAM... not so good

Any complex cart will be hard(er) to pirate. Also on those a ROM alone will got a pirate nowhere and emulation is going to be very tricky aswell.
Mida sa loed ? Nagunii aru ei saa ;)
http://www.tmeeco.eu
Files of all broken links and images of mine are found here : http://www.tmeeco.eu/FileDen

djcouchycouch
Very interested
Posts: 710
Joined: Sat Feb 18, 2012 2:44 am

Post by djcouchycouch » Wed Oct 17, 2012 1:27 pm

TmEE co.(TM) wrote:Only problem you got is VRAM bandwidth, so you can perhaps have 1000 sprites but they take 3 frames to upload to VRAM... not so good
Doesn't the SVP do the rendering internally and then send the whole frame to the Genesis? (no idea how that's done, exactly) Could the custom chip be whatever it wanted (sprites hardware or 32x one-buffer-style) and then update the whole image in one shot? Or is that too slow as well?

TmEE co.(TM)
Very interested
Posts: 2440
Joined: Tue Dec 05, 2006 1:37 pm
Location: Estonia, Rapla City
Contact:

Post by TmEE co.(TM) » Wed Oct 17, 2012 2:54 pm

SVP renders the scene and then you DMA it to VRAM. In PAL the game could have been 25FPS as there is a lot more VRAM bandwidth in 50Hz than in 60Hz. The game is 15FPS only because of VRAM bandwidth limit.

Code: Select all

==================================================
*** 68K to VRAM
==================================================

Access slots :
+------------+---------+--------+
| Line width | Passive | Active |
+------------+---------+--------+
| 256 pixels |   161   |   16   |
| 320 pixels |   198   |   18   |
+------------+---------+--------+
Number of bytes that can be transferred per frame :
+----+------------+---------+---------+---------+
| Hz | Resolution | Passive | Active  |  Total  |
+----+------------+---------+---------+---------+
| 60 | 256 * 224  |   6118  |   3584  |   9702  |
|    | 320 * 224  |   7524  |   4032  |  11556  |
+----+------------+---------+---------+---------+
| 50 | 256 * 224  |  14329  |   3584  |  17913  |
|    | 320 * 224  |  17622  |   4032  |  21654  |
|    | 256 * 240  |  11753  |   3840  |  15593  |
|    | 320 * 240  |  14454  |   4320  |  18774  |
+----+------------+---------+---------+---------+
Number of tiles that can be transferred per frame :
+----+------------+---------+---------+---------+
| Hz | Resolution | Passive | Active  |  Total  |
+----+------------+---------+---------+---------+
| 60 | 256 * 224  |   191   |   112   |   303   |
|    | 320 * 224  |   235   |   126   |   361   |
+----+------------+---------+---------+---------+
| 50 | 256 * 224  |   447   |   112   |   559   |
|    | 320 * 224  |   550   |   126   |   676   |
|    | 256 * 240  |   367   |   120   |   487   |
|    | 320 * 240  |   451   |   135   |   586   |
+----+------------+---------+---------+---------+
Mida sa loed ? Nagunii aru ei saa ;)
http://www.tmeeco.eu
Files of all broken links and images of mine are found here : http://www.tmeeco.eu/FileDen

Charles MacDonald
Very interested
Posts: 292
Joined: Sat Apr 21, 2007 1:14 am

Post by Charles MacDonald » Wed Oct 17, 2012 4:04 pm

Chilly Willy wrote:Yes, the MegaEverdrive is a good FPGA cart, but like I said, it requires programming at the gate level. I should probably get one myself.
There are also a lot of "macro" designs for bigger components like CPUs and peripheral chips you can use, with minimal glue logic to tie them together. Check out opencores.org to get a taste of what's available.

Hey which SH2 is available at Digikey? I couldn't find anything. I love the SH series but it seems impossible to find anything for sale at decent prices/volumes these days.

Charles MacDonald
Very interested
Posts: 292
Joined: Sat Apr 21, 2007 1:14 am

Post by Charles MacDonald » Wed Oct 17, 2012 4:07 pm

djcouchycouch wrote:
TmEE co.(TM) wrote:Only problem you got is VRAM bandwidth, so you can perhaps have 1000 sprites but they take 3 frames to upload to VRAM... not so good
Doesn't the SVP do the rendering internally and then send the whole frame to the Genesis? (no idea how that's done, exactly) Could the custom chip be whatever it wanted (sprites hardware or 32x one-buffer-style) and then update the whole image in one shot? Or is that too slow as well?
In theory a custom design could do that, though you'd still be limited to 16 colors in the Genesis palette.

One of the arguments about augmenting a system with a FPGA is that these days you could designs something _better_ than the host system in a FPGA itself. :D

Like there's a Genesis FPGA implementation already, so you could put a Genesis in your custom cartridge's FPGA and plug that in your Genesis...

djcouchycouch
Very interested
Posts: 710
Joined: Sat Feb 18, 2012 2:44 am

Post by djcouchycouch » Wed Oct 17, 2012 5:49 pm

Charles MacDonald wrote:
djcouchycouch wrote:
TmEE co.(TM) wrote:Only problem you got is VRAM bandwidth, so you can perhaps have 1000 sprites but they take 3 frames to upload to VRAM... not so good
Doesn't the SVP do the rendering internally and then send the whole frame to the Genesis? (no idea how that's done, exactly) Could the custom chip be whatever it wanted (sprites hardware or 32x one-buffer-style) and then update the whole image in one shot? Or is that too slow as well?
In theory a custom design could do that, though you'd still be limited to 16 colors in the Genesis palette.

One of the arguments about augmenting a system with a FPGA is that these days you could designs something _better_ than the host system in a FPGA itself. :D

Like there's a Genesis FPGA implementation already, so you could put a Genesis in your custom cartridge's FPGA and plug that in your Genesis...

Wouldn't you hit the same limitation of sending data to the VDP on the host Genesis?

It seems like having a CPU on the cart wouldn't help it making the graphics better, but could run general code faster with more helper functions. Would still be useful, though.

Charles MacDonald
Very interested
Posts: 292
Joined: Sat Apr 21, 2007 1:14 am

Post by Charles MacDonald » Wed Oct 17, 2012 6:01 pm

Wouldn't you hit the same limitation of sending data to the VDP on the host Genesis?
Yeah so there's an upper limit on how much you can improve the graphics.

Unless you take the 32X route, but that's another story. :D
It seems like having a CPU on the cart wouldn't help it making the graphics better, but could run general code faster with more helper functions. Would still be useful, though.
That's right, you could offload a lot of the complex calculations (or, all of them) to the CPU in the cart, and just let the 68000 handle joysticks/VDP/Z80 communication. Sounds kinda appealing.

Post Reply