Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - PityOnU

Pages: [1]
FXPAK (SD2SNES) / Re: Implementing GSU Chip (SuperFX) in Verilog
« on: April 07, 2018, 08:31 PM »
other updates?

Nope *whistles*

This other thread is up to 11 pages now for some reason though. Super weird.

This thread was targeting a gate-level clone of the SuperFX chip. Development has been ceased because redguy's RTL clone is near-complete, making this effort redundant. His is also fully integrated into the sd2snes firmware already, whereas this one was still entirely independent, requiring a great deal more effort down the line to get up and running on the cart.

Some may argue that a gate-level clone is important to have for full accuracy, but the fact of the matter is that it ends up being an order of magnitude (or more) additional work for the same functionality at the end of the day. Redguy's implementation is essentially a Verilog translation of the C code in higan, which is already considered to be near 100% accuracy for the <12 games that actually used the chip, so that is definitely the way to go in this case.

Mods, feel free to close or lock this thread.

FXPAK (SD2SNES) / Re: gsu (superfx) support [work in progress]
« on: March 28, 2018, 06:36 PM »
Wow, this is truly impressive! Certainly way beyond my capabilities/time constraints.

It's amazing that you were able to run and debug this all just using a single monolithic file, using only the sd2snes JTAG port. I suppose this just goes to show the advantages of high-level versus low-level design.

Given how far this has come, I'm going to go ahead a pretty much cease development of my core. It was a fun passion project that would have benefitted myself and a lot of other people; but now that this exists and is so functional, mine is just homework for a course. As such, I've already invested more time than is necessary :P

Best of luck on your last push here! Looking forward to playing Yoshi's Island again!

FXPAK (SD2SNES) / Re: Implementing GSU Chip (SuperFX) in Verilog
« on: March 28, 2018, 06:18 AM »
Quick update for today - spent a lot of time on the plotter block. A bit of an enigma there, but I'm starting to decode it. Got the color matrix circuit (figure 7 block 206) mostly up and running, but just now realized that the SuperFX stores the framebuffer in a different format than the SNES proper. Ugh. Seems like some rewrites are in the near future...

Headed home to drown my sorrows in a nice tall glass of Mtn DewTM.

I'm happy (i'm sure lots of others are too) to donate to the cause to help buy SD2SNES/consoles/coffee/whatever

I appreciate the offer, but I have pretty much everything I need for this right now.

The biggest limitation I actually have right now is time. I won't be able to work on this again until at least this weekend, and even then I have paper deadlines coming up, which are far more critical in the grand scheme of things.

The most useful thing for me right now would be others pitching in on the project. Assuming the details of the patent are followed, any newcomers wouldn't even need to look at anything I've written so far - they could just jump in on whatever section hadn't been implemented yet. Wiring them up together afterwards is actually super easy (if tedious). If anyone out there is interested, you can be certain that you receive any credit that is due for any contributions you make.

FXPAK (SD2SNES) / Re: Implementing GSU Chip (SuperFX) in Verilog
« on: March 27, 2018, 06:33 AM »
Just another update - spent a long time working on this today. Wrapped up the register block (implementation, verification, etc.). It is up on the Github now. Didn't yet get a chance to add comments with documentation - will do it in the morning.

True, but they should probably do well in asking byuu for help, since he's already familiar with emulation of the chip, so it wouldn't hurt to ask him for directions or tips.

Eh. Good code documents itself, and in such a sense byuu has already made a ton of documentation available to the community. Between that and the patent, I'm not really sure as to what would be gained by pestering the guy.

Amazing that we went from nobody touching this to now a handful.  Obviously it might be better to have a cooperative effort, but as someone who writes some code, when I see my co-worker's, I'm often like what the hell are you doing here???

For team-based development, the work needs to be modularized and divided up between members as blocks with defined interfaces. Then everybody can work individually on their block, their way, and then recombine everything at the end. If you don't do that, you end up with different members accidentally zapping each others code sections, as they don't fully understand the madness behind then.

The biggest problem right now is that most people have begun and continued their work on this as huge, monolithic Verilog files that stretch on for hundreds or thousands of lines. Something like that would be very difficult for me to help debug, to say nothing of actually contributing useful work.

Because of the above, I've tried to keep my code blocks small, verified, and compliant to the naming conventions and interfaces outlined in the patent. If anyone would like to help contributing, feel free to just pick a figure/block that isn't done yet and go! Should be pretty easy to add your block in when you are done. Verilog is pretty easy to pick up, and the patent is US patent #5,388,841 and can be found on Google Scholar. The Xilinx ISE is available (for free) here.

FXPAK (SD2SNES) / Re: Implementing GSU Chip (SuperFX) in Verilog
« on: March 26, 2018, 08:20 AM »
Just a quick update - put a good 3-4 hours into mine today. Cleaned up the organization a bit, renamed files, added comments, etc.

Main ALU and instruction cache can be considered complete and tested (at least for now). Started work on the register bank.

I'm very glad there are others working on this - hopefully it will inspire me to work harder in the spirit of competition!

FXPAK (SD2SNES) / Re: Implementing GSU Chip (SuperFX) in Verilog
« on: March 18, 2018, 11:31 PM »
Hi PityOnYou,

It looks like one of smokemonster's twitter followers coincided with you and also wants to make sfx verilog himself.

What's more,  he would like to work with you! Do you have a twitter?

There are actually a handful of people currently working on this who have reached out to me already. At least a couple already have something up and running on the cart.

However, most of what I have seen so far has emphasized getting things running on the cart over actually designing an accurate replication of the chip. Additionally, reservations over community expectations combined with inexperience in VLSI has stopped others from making their code public domain.

To all of you out there, I highly recommend putting a lot of time and effort into verification of your design. The Xilinx ISE has a built-in simulator - you should use it. Actually putting your design on the cart should be the LAST thing you do, and should be done with the help of ikari himself. If you plan on debugging your design primarily through the cart, then you're going to have a bad time. (Seriously, this chip is WAY too complex).

I also highly encourage you all to make your code public. If you think it is messy/silly/wrong, then that's an even bigger reason to make it public. If other people can see it, then they can provide you feedback so you can fix your mistakes. Better to do it sooner rather than later.

And with those potentially incendiary remarks, I will go back to studying for my midterm.

FXPAK (SD2SNES) / Re: Implementing GSU Chip (SuperFX) in Verilog
« on: March 17, 2018, 06:29 AM »
Okay, so I just made an initial commit to my repo with the work I've done so far. It is here if anyone wants to check it out/follow the progress.

I'm trying to follow the original patent as closely as possible, so I've broken everything into blocks named the same as they are in the patent. I've also included citations for locations in the patent which discuss a specific block in the comments wherever possible. Should make it easy for people to jump into an out of if you want to contribute. I've also tried to include in the comments any assumptions I've made which weren't explicitly stated by any source.

There's not much there so far - at least in terms of what needs to be done. Fig. 4A and 4B in the patent can be considered the top level overview for this chip. I've currently only finished block 50, and have made some progress into the blocks related to the cache and cache control.

The "test_stimulus" file includes a bunch of .tcl scripts to use with ISim to verify functionality of the blocks. I've included "test" statements in each of the scripts, which should allow anyone who makes changes to the blocks to verify that they still work as originally intended (if that was the goal, of course). Commenting in these is sketchy at best.

It's been about 5 years since I've done any VLSI work, and I never used Verilog (Americans use VHDL), so I'm still kind of hashing out my coding style. It will probably continue to evolve as I work on this. Some notes on what I've come across:

  • There will needs to be some hacks if we ever want full support for this chip. The FPGA does not support the full 512Kb of RAM used by most games, so only games which use a 256Kb address space will work natively (Yoshi's Island & Star Fox, so not bad). Maybe there is some DRAM hidden elsewhere on the cart? Or maybe the embedded ARM controller can share some of its? I'm not sure.
  • The designers of this chip used a lot of latches to solve timing problems. These aren't really used anymore in modern VLSI, and definitely not in FPGA's. I might have to do some weird things with the clock to get everything working together as it was originally designed.
  • The good news is the chip has dedicated, separate clocks for the main ALU, the multiplier unit, and the memory, with the memory being the main bottleneck originally. Making these available to an FPGA would allow for some very granular overclocking which would work pretty much flawlessly (assuming games we coded as the designers expected).

That's all for now. Just reading through and understanding the patent took the better part of a week, and that was all day every day (spring break). We'll see how/if progress continues from here.

FXPAK (SD2SNES) / Re: Implementing GSU Chip (SuperFX) in Verilog
« on: March 13, 2018, 10:13 PM »
May I suggest that you have a chat with ikari, he will point you to the right direction.
Ikari may have some half cooked pie so you may not start from scratch.

I hope you're serious, this community deserves more Ph.D's working on stuff.
Who knows,, maybe in the future the credit to SuperFX support on the SD2SNES will go to Prof. PityOnU.  ;)

Ikari's own website just suggests coming here, and I completely understand that. I'm sure he gets bugged a lot by people looking to contribute, who then end up just dropping off the face of the Earth due to lack of time/skills. I don't want to be one of those annoying people, so I will wait to reach out to him until I have something worth bothering him about. Most of this work can be done completely separately from the sd2snes.

And while I was seriously considering pursuing a faculty position post-graduation, I've "seen behind the curtain" as to how academia actually works, and I really don't think it's for me. At least in my discipline - others are likely much different. That's an entirely different conversation, though.

Dev Book 2:

MARIO Patent:

Thanks for these! They are exactly what I was hoping to find. Reading through the patent right now - it is incredibly detailed and will help a lot.

Talk to ikari_01 (creator of the SD2SNES), kevtris (creator of many FPGA cores including a SNES core), and jwdonal (creator of VeriSNES and SNES-related documentation).

SNESdev is a fantastic resource for SNES:

As mentioned above, while I would very much like to talk with those guys some day (I would very much consider them "rock stars" in this area), I will wait until I have something worth bothering about. I will certainly check out that forum, though!

Best of luck!

Thanks! I will try and post here regularly with updates as to what is going on/how it's looking. I would really like to get deep into this, as it is something I am passionate about and certainly have the skills to do.

Unfortunately, the reality is that this is for a course, which at the graduate level is considered a waste of time. Most people just take classes related to their research and regurgitate their paper/WIP from that semester as the "course project" so they don't actually have to do any work. This is expected, and they all get A's.

This is something that is very much outside of my research area, so I'm already doing about 1000% more work than my advisor (boss) deems necessary, so we'll see how far I can get before I get banned from working on it.

FXPAK (SD2SNES) / Implementing GSU Chip (SuperFX) in Verilog
« on: March 12, 2018, 07:28 PM »
I'm working towards my Ph.D. in computer engineering right now, and need to so some sort of VLSI project for one of my graduate courses. I've tasked myself with implementing a working clone of the GSU/SuperFX in Verilog. This could be used in future to allow greater compatibility for sd2snes, and maybe allow for cheap reproduction carts (depending on the size of the resulting logic).

I have my development environment all set up, and am able to compile the sd2snes firmware/menu/FPGA configuration from source. I have started working on implementing the GSU based on the sparse documentation I can find, as well as what is defined within the Higan source code.

However, the chip is more complicated than I was expecting (custom ISA, pipelined, multiple, non-deterministic memory access paths, varying IPC, etc.). If anyone knows any good sources for documentation regarding the chip, I would greatly appreciate them being posted here.

Also, if anyone would like to follow my progress/assist in implementation, let me know. I need to figure out how to work git/Github so I can properly fork the original source and archive changes, and that would give me an extra little push.

Pages: [1]