FPGA project

This is an archive of a topic from NESdev BBS, taken in mid-October 2019 before a server upgrade.
View original topic
FPGA project
by on (#69387)
I have a little free time again (this never happens!) and have been hoping to dust off my FPGA/HDL skills. I've been wanting to do a NES related FPGA project forever, and even started one a few years back, but like most projects it never really got off the ground.
I'm looking to see if there is any interest, since I'm likely going to need some help. I'm thinking about doing a CPU in HDL, and later on adding a PPU and APU. The whole thing must be open source, I don't want another implementation around that nobody can use.
I was also thinking that getting a collaboration on FPGA stuff is difficult because nobody owns exactly the same development system - and it's very expensive to buy new. To alleviate that I was thinking of not having a dev board at all, but to use simulation only. That way anyone with a PC can contribute - and maybe some nice developer will throw it on a dev board for us someday.
So I was thinking about using one of these tools: GHDL, Verilator, or Icarus.
Would anyone be interested in contributing to this project? Preferences on the tools above? The initial goal would be a CPU with the ability to pass Blargg's cpu tests. I'm not really crazy about going it alone, since I tend to work in spurts - and that leads to long periods of no progress.

by on (#69388)
Are there any 6502 processors on OpenCores.org?

by on (#69389)
I believe there is a 6502 core there, but it's in VHDL. I'm more interested in using Verilog.

Sounds like it would be interesting, I've been using Verilog a little (with a CPLD) and it would be interesting to be able to get a little more practice. But I've got more projects than I do time, so I doubt I could be of much help.

Simulation sounds kinda boring though, to me. :|

by on (#69393)
Sounds awesome! It'd be nice to see a PPU core done :D Especially a RGB version so we don't have to kill playchoices for them! :shock: :oops: :roll:



Hope this gets going and is fun, this sounds super epic. :)

by on (#69400)
Memblers wrote:
I believe there is a 6502 core there, but it's in VHDL. I'm more interested in using Verilog.

Sounds like it would be interesting, I've been using Verilog a little (with a CPLD) and it would be interesting to be able to get a little more practice. But I've got more projects than I do time, so I doubt I could be of much help.

Simulation sounds kinda boring though, to me. :|


I'm also into Verilog. I'd be willing to help. But I also have more projects than time. :roll:

by on (#69403)
I think it's even harder to collaborate with hardware than it is with software. There are so few limitations that preferences come out immediately. Not only does everyone have stylistic differences but will implement at different levels of abstraction, will write more or less synthesizable code and have a different thoughts on accuracy. With hardware often these differences aren't compatible. Really it will come down to whoever starts the HDL module or a lot of foundation logic will be overwritten by each contributor to suit their needs.
Re: FPGA project
by on (#69423)
teaguecl wrote:
I have a little free time again (this never happens!) and have been hoping to dust off my FPGA/HDL skills. I've been wanting to do a NES related FPGA project forever, and even started one a few years back, but like most projects it never really got off the ground.
I'm looking to see if there is any interest, since I'm likely going to need some help. I'm thinking about doing a CPU in HDL, and later on adding a PPU and APU.

I have all this in Verilog right now including an RGB-output PPU (APU still needs lots of work though only DMC is fully functional). But it is still closed source at the moment. I've got some co-workers and business associates that really want me to open source everything but I have the standard concerns about people plagiarizing my code or selling the code/netlists and making some type of profit. :-/ And of course, with all the NES-FPGA college projects that students are always emailing me about, there would certainly be some unethical "code-copying" going on. Lol. I mean, I realize there are benefits to open-sourcing as well....I just need a bit (ton?) of convincing before I'm willing to open source. I've thought about selling the source as well but then there are a ton of legal issues with that and the high probability that Nintendo would sue me. :-P

Quote:
The whole thing must be open source, I don't want another implementation around that nobody can use.

Haha, I guess I would be one of those jerks. Lol. :-P

Quote:
I was also thinking that getting a collaboration on FPGA stuff is difficult because nobody owns exactly the same development system - and it's very expensive to buy new. To alleviate that I was thinking of not having a dev board at all, but to use simulation only.

If you're just simulating the CPU by itself with some custom code and such then this is fine but as soon as you want to start simulating full games and such with the PPU/APU etc you run into major problems with simulation time. You would literally have to run a simulation for months to get enough resulting data. I have already run into this. I am already at the point where I have to use an embedded logic analyzer within the FPGA itself (e.g. Xilinx chipscope) in order to debug anything at all.

by on (#69425)
You have a RGB-PPU? I would certainly but the chip off you if you released it. Probably more though! Killing PC-10's for them to me is just too much for me. I couldn't do it. :/

by on (#69426)
I'm in the same boat as jwdonal, there are just too many concerns since it's a highly valuable project.

65024U wrote:
You have a RGB-PPU? I would certainly but the chip off you if you released it. Probably more though! Killing PC-10's for them to me is just too much for me. I couldn't do it. :/

A FPGA can't just be popped into place, it will not only take exceptional design accuracy in order to interface with real hardware, but it will take level conversion and significant support circuitry... There's no way people will use them over PC10 PPUs.

by on (#69427)
kyuusaku wrote:
65024U wrote:
You have a RGB-PPU? I would certainly but the chip off you if you released it. Probably more though! Killing PC-10's for them to me is just too much for me. I couldn't do it. :/

A FPGA can't just be popped into place, it will not only take exceptional design accuracy in order to interface with real hardware, but it will take level conversion and significant support circuitry... There's no way people will use them over PC10 PPUs.


What would be cool is if one made a board with the JAMMA interface so the FPGA could replace the whole Playchoice-10, but in a standard arcade cabinet. :)

by on (#69429)
I can't find it, but somebody already took the Williams arcade hardware for Defender or Robotron and put it on 3 chips. (Probably FPGA, but I don't recall. This was a couple years ago.) To emulate 6809E,RGB out to well gardner monitor, sound, input PIA, ROM board all in 3 is insane. I wish I could find it. :/ But hey atleast it is possible. And even the powerpak uses it in it's mapper circuitry. Maybe one day bunny will mess with this. I think adding this to the product line of RetroUSB store would be a HUGE hit with NES gamers! :D I can dream though. Seems like I do a lot of that though.
Re: FPGA project
by on (#69430)
jwdonal wrote:
I have all this in Verilog right now including an RGB-output PPU (APU still needs lots of work though only DMC is fully functional). But it is still closed source at the moment. I've got some co-workers and business associates that really want me to open source everything but I have the standard concerns about people plagiarizing my code or selling the code/netlists and making some type of profit. :-/ And of course, with all the NES-FPGA college projects that students are always emailing me about, there would certainly be some unethical "code-copying" going on. Lol. I mean, I realize there are benefits to open-sourcing as well....I just need a bit (ton?) of convincing before I'm willing to open source. I've thought about selling the source as well but then there are a ton of legal issues with that and the high probability that Nintendo would sue me. :-P

Yes, your project is one of my inspirations - you should write more on your blog :)

Quote:
The whole thing must be open source, I don't want another implementation around that nobody can use.

jwdonal wrote:
Haha, I guess I would be one of those jerks. Lol. :-P

No, I certainly wouldn't call you a jerk. Your work is yours, you have every right to do whatever you feel is best with it.

jwdonal wrote:
If you're just simulating the CPU by itself with some custom code and such then this is fine but as soon as you want to start simulating full games and such with the PPU/APU etc you run into major problems with simulation time. You would literally have to run a simulation for months to get enough resulting data. I have already run into this. I am already at the point where I have to use an embedded logic analyzer within the FPGA itself (e.g. Xilinx chipscope) in order to debug anything at all.

This is very helpful information, maybe this project isn't feasible the way I imagined it. Sure we can implement (yet another) 6502 using simulation, but if the other parts can't be done reasonably, then the whole thing becomes somewhat pointless.
Is there a cheap commodity, de-facto standard board we might be able to target? I'm thinking something equivalent to what arduino has become for microprocessors in the hobby community. The issue, and the reason I wanted to go with simulation, is that anything much more expensive than $100 and you can't get any momentum. Not many developers, and almost no users.
Re: FPGA project
by on (#69432)
teaguecl wrote:
...you should write more on your blog :)

Haha, I know! I've been a very bad boy lately. But don't worry I'm still very actively working on my NES. Right now I've been working on a Qt-based GUI interface over UART and Ethernet to the FPGA which allows you to load/verify ROMs and enter Game Genie codes, and lots of other cool stuff like CPU execution logging. I just haven't gotten the GUI to the point where I want to post screenshots yet. But I'm real close!! I will make a (huge) post very soon. :-P I've also been distracted with playing (and beating!) the PS3 game Demon's Souls - jeez, that game is freakin hard!!! It's like real old-school game hard! But I beat it! So there! Haha.

Quote:
No, I certainly wouldn't call you a jerk. Your work is yours, you have every right to do whatever you feel is best with it.

No problem, I know you weren't calling anyone a jerk - I was calling myself a jerk. Lol. Really I guess I'm a hypocrite since I learn so much from the open source community myself. So philosophically (ethically?) the question becomes why am I not contributing more back?

Interestingly enough, I just had a long in-person chat tonight with one of my colleagues (who just happens to be at a conference that I'm attending this week) from the hugely popular verification company Doulos and he has some really convincing arguments on why I should just open source the whole thing. Haha, who knows, if he keeps chipping away at me you guys might get lucky. ;) He wants to co-author (i.e. he would do the formal verification bit and I would do the design bit) some design/verification papers with me and present them at conferences such as DVCon, SNUG, DAC, etc. So it wouldn't be until I got some prior publications and authorship credit that I would release the source - this is what makes open-sourcing a more "amicable" idea to me as there would at least be some "prior art" to show that I was the original author/creator of the code.

Quote:
Is there a cheap commodity, de-facto standard board we might be able to target?

That question gets complicated because (at least with Xilinx) you run into the problem of "Okay, I have a cheap Virtex/Spartan board, now I just need to spend $2500 on the Xilinx development IDE to be able to synthesize/implement my design and target it to the FPGA." And then the $2500 doesn't even get you the add-ons like the chipscope in-circuit debugger tool and such. Lol, the "Nickel and Dime" motto is what these companies live off of.

Quote:
The issue, and the reason I wanted to go with simulation, is that anything much more expensive than $100 and you can't get any momentum.

The problem your going to have with free/cheap simulators is that they are going to be slooooooooooow. If you want a fast simulator (which believe me you do) then you need something higher-end. The Synopsys VCS simulator is (I believe and from what I hear from other colleagues) the fastest simulator currently available on the market......but a single user license also costs tens of thousands of dollars. Haha. But that's not unusual. For example, Mentor QuestaSim, Cadence, Active-HDL simulators are all pretty much priced the same. Yes, it sux.
Re: FPGA project
by on (#69437)
jwdonal wrote:
I've got some co-workers and business associates that really want me to open source everything but I have the standard concerns about people plagiarizing my code or selling the code/netlists and making some type of profit. :-/

Under most copyright licenses used for free software, "selling" is considered desirable, and "plagiarism" in the sense of failure to credit the author is an infringement. As for not getting what you believe to be your cut of the price of a properly credited copy, think of it this way: If someone starts selling computers based on a netlist that you created, and you're in the credits, you have something to put on your CV and show to future employers.

Quote:
I've thought about selling the source as well but then there are a ton of legal issues with that and the high probability that Nintendo would sue me.

The patents on the NES hardware expired roughly five years ago, and virtually all mapper patents have expired as well. If you publish the design of a computing device compatible with NES software, Nintendo would have no case, and you could probably resolve the issue pro se. But if you do plan to implement anything and sell it, I would recommend a consultation with a lawyer.
Re: FPGA project
by on (#69438)
jwdonal wrote:
Quote:
No, I certainly wouldn't call you a jerk. Your work is yours, you have every right to do whatever you feel is best with it.

No problem, I know you weren't calling anyone a jerk - I was calling myself a jerk. Lol. Really I guess I'm a hypocrite since I learn so much from the open source community myself. So philosophically (ethically?) the question becomes why am I not contributing more back?



Yes, this is the reason I haven't open sourced much of anything- I don't want someone taking my code and building some products around it, then me not getting a cut of that. There's no way to defend against this either. Sure you can sue 'em but a nobody with no money vs. some company doesn't work in the US. Whoever has the most money almost always wins (let alone can afford to sue and win).

Having said that, I don't know honestly how much worth such projects have, so maybe I'm being slightly paranoid.


Quote:
Quote:
Is there a cheap commodity, de-facto standard board we might be able to target?

That question gets complicated because (at least with Xilinx) you run into the problem of "Okay, I have a cheap Virtex/Spartan board, now I just need to spend $2500 on the Xilinx development IDE to be able to synthesize/implement my design and target it to the FPGA." And then the $2500 doesn't even get you the add-ons like the chipscope in-circuit debugger tool and such. Lol, the "Nickel and Dime" motto is what these companies live off of.


This is why you should use the Altera parts. Quartus (the dev environment) lets you target pretty large FPGAs and do in circuit signal tracing in the free version. I've been using it all along to develop my FPGA NES. There's plenty of power there to use for free. Not to mention the Altera software is worlds better than ISE webpack, IMO. Easier to use, seems more stable. ISE webpack is the sole reason I do not use xilinx parts in my projects, incidentally.


Quote:
Quote:
The issue, and the reason I wanted to go with simulation, is that anything much more expensive than $100 and you can't get any momentum.

The problem your going to have with free/cheap simulators is that they are going to be slooooooooooow. If you want a fast simulator (which believe me you do) then you need something higher-end. The Synopsys VCS simulator is (I believe and from what I hear from other colleagues) the fastest simulator currently available on the market......but a single user license also costs tens of thousands of dollars. Haha. But that's not unusual. For example, Mentor QuestaSim, Cadence, Active-HDL simulators are all pretty much priced the same. Yes, it sux.



I never understood the usefulness of simulator over a real FPGA to be honest. Once the design gets big enough, simulation gets useless. Signaltap (the on-chip logic analyzer) is insanely nice and easy to use for debugging any problems that come up. Now, I could see simulation being useful once the design got massive, however... like for chip tapeout verification and what-not, but for what amounts to hobby level projects, the simulator hasn't been too useful to me.

I will admit to designing my original 6502 core using the simulator, however :-)

though, the main reason was I didn't have any actual hardware to test on at the time.


speaking of FPGA NES' I have been spending some time rewriting it all in verilog. Originally it was in schematic capture. last night I finished converting over all the NES mappers I had implemented previously (around 200 or so) and the NES was converted and verified against the Blargg test ROMs and passed, so all that's left is some audio and cleanup before it's ready to go. (Also, I made a new dev board for the project which is alot smaller and fits in an NES cart case).
Re: FPGA project
by on (#69441)
kevtris wrote:
I don't want someone taking my code and building some products around it, then me not getting a cut of that.

Although I do understand the feeling (and would probably be worried about this myself in your situation), rationally this doesn't make much sense. In both scenarios (somebody stealing your design vs. nobody stealing your design) you don't get any money. So the thing you oppose to is someone else making money from your work, which in practice doesn't change anything for you, it's just a moral thing. And to prevent that you end up preventing people with honest intentions to benefit from your work as well (people who would pay for an accurate NES clone, for example).

I'm not saying that you guys should or shouldn't open source your projects, I'm just pointing out that this is one of those paradoxical things to think about.
Re: FPGA project
by on (#69442)
tokumaru wrote:
kevtris wrote:
I don't want someone taking my code and building some products around it, then me not getting a cut of that.

Although I do understand the feeling (and would probably be worried about this myself in your situation), rationally this doesn't make much sense. In both scenarios (somebody stealing your design vs. nobody stealing your design) you don't get any money. So the thing you oppose to is someone else making money from your work, which in practice doesn't change anything for you, it's just a moral thing. And to prevent that you end up preventing people with honest intentions to benefit from your work as well (people who would pay for an accurate NES clone, for example).

I'm not saying that you guys should or shouldn't open source your projects, I'm just pointing out that this is one of those paradoxical things to think about.


Actually this time I *do* plan on trying to get it manufactured, and to open the hardware and some code as a development system aimed at making FPGA consoles.

If I sold it, cost would be around $180 or so (possibly cheaper), along with my bitstreams for the various FPGA stuff I designed (like the NES core) and a set of developer documents/files that have pre-made interfaces for SDRAM and stuff.

The idea being, someone could program their own console or other thing on it, and then share the bitstream with others (or open source their code, etc). Think of it kinda like a PowerPak but for CONSOLES :-)

After this FPGA NES is done, I was going to start work on another one, but I am not sure which. I have FPGA console cores mostly done for the following systems: C64, gameboy, atari 8 bit, and colecovision/sms. When I say "mostly", I mean the CPU + audio + bankswitching is 100% done, and fully debugged. I used these bits in my FPGA chiptune synthesizer. The only thing needed to get them finished as full blown consoles is just video.

The hardware I came up with this time is very compact- it's the same size as an NES cartridge PCB. I designed it this way so I could use NES carts as cheap cases, with the connectors for power/video/etc sticking out the back where the cartridge would've plugged into the NES. On the front are two USB controller ports and a microSD card for the data.

Back jacks are RGB, DVI, stereo audio, feature connector (I have NES/SNES controllers plugged in here), and power. There's an 18Mbit serial SRAM on here along with 16*8M SDRAM.

It can output any video mode in any standard using some cheap ebay-available adapters. composite, s-video, RGB (all three in PAL, NTSC, and compatible modes (interlaced, etc)), then RGB in VGA rate, component, and DVI.

So far I created a digital RGB to NTSC encoder that works great as well as a true "real NES" video output encoder that produces an exact clone of the NES video levels and everything, complete with the proper dot crawl and bleedover and emphasis effects. Component is very easy to add but I don't have a monitor to test it out on and DVI hasn't been enabled yet but it's on the board. I was waiting for my micro so I could program it thru the I^2C port.

here's a picture of it.

http://blog.kevtris.org/blogfiles/IMG_2931.JPG
Re: FPGA project
by on (#69443)
kevtris wrote:
Actually this time I *do* plan on trying to get it manufactured, and to open the hardware and some code as a development system aimed at making FPGA consoles.

If I sold it, cost would be around $180 or so (possibly cheaper), along with my bitstreams for the various FPGA stuff I designed (like the NES core) and a set of developer documents/files that have pre-made interfaces for SDRAM and stuff.

If you're doing market research, I'll take one of those at nearly any price. If you're taking reservations, I'll take serial number 0001 :)
This is actually very much what I was imagining for this project, looks like once again Kev is ahead of the game! The important things (to me) are:
- the core NES pieces and mappers can be viewed/modified. This allows the community to find bugs and fix them. It also becomes permanent documentation on the behavior of the original system.
- cheap enough for any moderately serious console collector to purchase
- compatibility with modern TV's and displays. HDMI anyone?
- allows for use of original controllers (using RetroZone style connectors), or anything else. I can see wireless NES controllers being desirable.
- The "ugly stuff" can remain proprietary, allowing the vendor some ability to protect their investment. This includes all the glue that takes the CPU/APU/PPU/mappers and connects them to the outside world. Bugs in this area would have to be fixed by the vendor (aka Kevin)

Given this new information, I'd like to suspend my original message. This might be the shortest time ever for me to abandon a project! Of course, if the FPGANes never makes it to market then we'll have to re-open this discussion :(
Re: FPGA project
by on (#69444)
kevtris wrote:
So far I created a digital RGB to NTSC encoder that works great as well as a true "real NES" video output encoder that produces an exact clone of the NES video levels and everything, complete with the proper dot crawl and bleedover and emphasis effects.

Ah, I was about to ask about that! =) I think this is pretty important.

Anyway, it's nice that you actually plan on selling a product, this changes everything. I really hope you can get it released.

by on (#69445)
Best read ever. Not only RGB, But classic NES mode?!?!?! HOLY HEAVEN. :D


This seems awesome. And if your looking for something after this, maybe NeoGeo on FPGA? NeoGeo is hard to find and you'd probably pay the dev cost for a FPGA one for a normal one! :P I just think neo-geo would be cool because they're so rare. Atleast i've never seen one. :/


That NES FPGA is...wow. Fantastic. I still can't believe this just happened. I'll probably end up buying one eventually. I can't wait until this gets released. Going to add alot of RGB to my Crystalis! :D

by on (#69446)
65024U wrote:
This seems awesome. And if your looking for something after this, maybe NeoGeo on FPGA? NeoGeo is hard to find and you'd probably pay the dev cost for a FPGA one for a normal one! :P I just think neo-geo would be cool because they're so rare. Atleast i've never seen one. :/
Neo Geo will fit into many FPGA now but there's a huge difference in complexity between a 68000 core and a 6502 core. AFAIK, nobody has written a hardware accurate 68000... With all the microcode it's a huge task and challenge, I'm not sure that stuff has even been reverse engineered... There's also a memory & latency issue; Neo basically has 5x 200ns buses of different widths opposed to 2x 8-bit in the NES and it's hard to meet the timing requirements with a single SDRAM, regardless of how fast. Anyway, a real Neo Geo home console is <$200 and an arcade board (MVS) is <$100 and they aren't as rare as one might think.

by on (#69447)
Thats true, and I do understand that it's hard to re-make a chip with FPGA's, it's just that I have no doubt kev and everyone could do it if it interested them. I just was saying, if anything, I think that would be the coolest.


I ran across a page with a FPGA system of some kind....I think it was for arcade games or something, but it was to be build and sold and users made the game and it looked pretty cool and sounded very interesting. Let me provide a link.....

http://www.fpgaarcade.com/


It seems like they have a 68K running with a FPGA add on from the April 28th 2010 update.

by on (#69448)
I'd much rather see the limited resources people have put to use improving the NES situation, rather than being spread thin in an attempt to emulate everything.

by on (#69449)
Yeah but a guild to build-your-own-RGB-PPU-and-6502 kit with a 500x500 breadboard wouldn't be that great of an addition to the NES aftermarket products.....but I will say this, it'd be way too cool for me not to get. :P

by on (#69451)
blargg wrote:
I'd much rather see the limited resources people have put to use improving the NES situation, rather than being spread thin in an attempt to emulate everything.


Curious, what exactly in the "NES situation" needs improving? Not that I disagree with the premise but I was curious what exactly you think should be a priority.

Personally I'd like to see a truely hardware accurate clone of the NES/Famicom.

by on (#69454)
blargg wrote:
I'd much rather see the limited resources people have put to use improving the NES situation, rather than being spread thin in an attempt to emulate everything.


I'm also curious what a list of things that could be done to improve the NES situation might look like. I started my project with the idea that it would eventually improve the NES situation, but my idea of the NES situation at the time was self-centered [I wanted to improve *my* own situation WRT NES development ability].

Personally I'd love to see a completely accurate software simulation [and of course a completed NESICIDE]. In my dream-like state that I attempt to refer to as my reality, the 2A03 and 2C02 chips have been decapped, photographed, and completely analyzed--and given to the community for everyone to use.

Yes I am aware of the Virtual6502 which is gigantic cool...but it of course doesn't have any of the APU. A decapped 6581 looks incredibly complicated for just the 3 channels it has...I'm really curious how the APU fits in the 2A03. Surely the BCD isn't *that* big of a portion of the die?

by on (#69455)
It's not about things that need improving, just improving things that can be improved. Off the top of my head:

* High-quality tutorials
* A lot more work on the Wiki
* Programming libraries
* More test ROMs

My idea of quality is pretty high (I rarely meet it either). I think a lot of documentation and tutorials are poor, not just for the NES, but anything. I desire to have things that are clean, concise, and well-written for the intended audience. So I always see the NES as having plenty of room for improvement, which is all the well, because I like improving things.
Re: FPGA project
by on (#69457)
teaguecl wrote:
- compatibility with modern TV's and displays. HDMI anyone?

HDMI is complicated and probably involves a whole bunch of patent licensing. It'd also need an upscaler, as I imagine most TVs wouldn't handle a 280x240 signal. It's probably not even necessary because the NES composite video signal is compatible with every TV and VCR that I've tried it on, as well as a DVD recorder. I've run into issues with one SD DVR, but that could be fixed by adding an interlace mode that more faithfully meets the NTSC timing specification:
  • Stall the CPU and most of the PPU (but not the color generator) by three master clock cycles in each hblank, making each line 341.25 dots long instead of 341. This changes the dot crawl pattern from 3-line to 2-line.
  • In every other field, display the post-render scanline (line 240) twice. The Dendy console's PPU displays 51 of these to make games designed for NTSC timing work on 50 Hz PAL, and games work with 51, so surely games would with with two.
  • Make the other field's vsync signals a half scanline later.
blargg wrote:
Off the top of my head:

* A lot more work on the Wiki

Feel free to spray constructive criticism across talk pages, and I'll try to address issues that you raise.
Re: FPGA project
by on (#69462)
tepples wrote:
teaguecl wrote:
- compatibility with modern TV's and displays. HDMI anyone?

HDMI is complicated and probably involves a whole bunch of patent licensing.
Fortunately it's just DVI. The only complications come from HDCP, which as a transmitter you can ignore.

Quote:
stuff about NTSC compatibility
Oh, augh, please no. Just upscale it to 480p and stop there -- when I look at 240p content displayed as 480i even with a good interlacer it looks awful. A lot of things in NES games have been designed to be exactly one pixel high, and if it jitters vertically as a 480i signal implies it looks terrible.
Re: FPGA project
by on (#69466)
tepples wrote:
blargg wrote:
Off the top of my head:
* A lot more work on the Wiki

Feel free to spray constructive criticism across talk pages, and I'll try to address issues that you raise.

I wouldn't have mentioned unless someone asked, because the task of even evaluating things is a lot of work in itself. I must admit, I was impressed with all the work done on the Wiki during my absence from earlier this year.
Re: FPGA project
by on (#69469)
teaguecl wrote:
kevtris wrote:
Actually this time I *do* plan on trying to get it manufactured, and to open the hardware and some code as a development system aimed at making FPGA consoles.

If I sold it, cost would be around $180 or so (possibly cheaper), along with my bitstreams for the various FPGA stuff I designed (like the NES core) and a set of developer documents/files that have pre-made interfaces for SDRAM and stuff.


If you're doing market research, I'll take one of those at nearly any price. If you're taking reservations, I'll take serial number 0001 :)
This is actually very much what I was imagining for this project, looks like once again Kev is ahead of the game! The important things (to me) are:
- the core NES pieces and mappers can be viewed/modified. This allows the community to find bugs and fix them. It also becomes permanent documentation on the behavior of the original system.



I wouldn't release the source code for the NES part until X units sold, then I would open source the entire thing. That was the main plan anywayz. Without an installed userbase it's not so wise to open source it I don't think. 'course this gets into the whole chicken and egg problem a bit maybe.

Quote:

- cheap enough for any moderately serious console collector to purchase
- compatibility with modern TV's and displays. HDMI anyone?
- allows for use of original controllers (using RetroZone style connectors), or anything else. I can see wireless NES controllers being desirable.
- The "ugly stuff" can remain proprietary, allowing the vendor some ability to protect their investment. This includes all the glue that takes the CPU/APU/PPU/mappers and connects them to the outside world. Bugs in this area would have to be fixed by the vendor (aka Kevin)



I think it's pretty much bug free now. I spent a stupid amount of time getting the accuracy as high as possible. It's pretty much 100% accurate as far as every game I can run on it. I will be testing the entire goodnes set on it again (yes I did this before) soon to shake out the remaining bugs.

Right now, I am using SNES controllers plugged into the expansion port. I made the adapter using cheap-o SNES extension cables I bought on ebay. But yeah I figured people would use retroports if they wanted a "turnkey" solution and just plug 'em into the USB. Incidentally, I made an NES controller adapter along with the SNES one which is fully compatible with all NES peripherals too.

Quote:
Given this new information, I'd like to suspend my original message. This might be the shortest time ever for me to abandon a project! Of course, if the FPGANes never makes it to market then we'll have to re-open this discussion :(


This time I am really trying hard to get this manufactureable. I cost-reduced it alot without sacrificing functionality. I guess I can explain my longer-term plans for it :-)

I designed it with the SSRAM chip (which is kinda expensive) so that there is a frame buffer and some fast RAM for other systems. This will allow PAL NES on NTSC/VGA, or vice-versa. Also, this gives me enough fast RAM to do full blown SNES and genesis. I really, really want to get SNES going on an FPGA, so this hardware is designed to meet that goal.

I figure this is the best shot I have at making some kind of "FPGA thing" to sell. The hard part about it is the FPGA alone costs $42 on it, and there's not much I can do about getting that lowered. There might be a quantity discount but there doesn't seem to be.

As for HDMI, this is impossible (as is HDCP of course) unless someone wants to give me buckets of money for licenses. Though, DVI is easy to do (and DVI to HDMI cables exist. It's up to the receiver (TV) to support straight DVI over HDMI. My flat screen on my PC does this for example.)

I can't wait to get that DVI port lit up though. It's there mocking me until I turn it on and see if my PCB design is good enough! I've got a separate RGB analog DAC hooked up to it also, and have been using a DVI to RGB adapter to view the output. The idea was to allow this thing to connect to literally any display device that exists pretty much, be it RGB, composite, s-video, component, or DVI.

Tonight I will add VRC7 audio (I have a complete verilog FM core all ready to go from my synth) and that will finish off the NES mappers I think. Then it's time for alot of testing.

by on (#69470)
blargg wrote:
I'd much rather see the limited resources people have put to use improving the NES situation, rather than being spread thin in an attempt to emulate everything.


I dunno, I think spending 6 years on FPGA NES is plenty long enough. I'm ready to move to FPGA SNES and gameboy and stuff now. I started with NES because I figured it was the hardest, due to all the mappers, and the sheer quantity of games that utilize quirks in the hardware to function properly. I figure say, an FPGA coleco would take maybe 2-3 weeks to finish at this point.

by on (#69475)
Sounding awesome. Battletoads, Castlevania 3, and MMC4/6 games working with the usual MMC3? If so, that should be enough to work with every game out there! :P Especially since it will run real cart hardware so it shouldn't be too bad. Unless it is all on a cart, but then it'd be a NES Powerpak with NES included inside the cart....with a screen. And buttons. XD



Never heard of FPGA before this and now, it's like the best thing ever. Even better then PIC's and stuff! :D

by on (#69477)
65024U wrote:
but then it'd be a NES Powerpak with NES included inside the cart

If I understand correctly, this is exactly what kevtris is making.

It would be cool if it could take carts though, otherwise homebrewers might slowly lose the will to make games as original NES consoles fail, since there will be no point in releasing carts.

by on (#69478)
tokumaru wrote:
65024U wrote:
but then it'd be a NES Powerpak with NES included inside the cart

If I understand correctly, this is exactly what kevtris is making.

It would be cool if it could take carts though, otherwise homebrewers might slowly lose the will to make games as original NES consoles fail, since there will be no point in releasing carts.


I agree it would be nice to be able to plug in real carts, though I know from experience that dealing with that stupid 72 pin connector is a nightmare. Maybe some kind of expansion port that brought out those 72 signals, and leave it up to someone else to actually hook a connector to it? Personally I view this feature as a nice-to-have, I don't own (or plan to own) any carts which I don't also have dumps of.

by on (#69479)
Maybe make an adapter that looks like the NES connector inside that's just basically a square with a chunk taken out that can be used to connect games, and just make it thicker, not extend it.


Or just make a whole case new, which would be even better IMO. Include a cart slow and a CF slot if it's easy enough. Holy crap this is just sounding awesome. :D

by on (#69480)
Something like this would be nice.

by on (#69481)
Go big, or go home? :lol:


http://www.techepics.com/files/nes_hand_built_7.jpg

by on (#69492)
It is a USB host, I suppose with the right software, one could plug a CopyNES into it and download the ROM to play it. :lol:

by on (#69500)
tokumaru wrote:
65024U wrote:
but then it'd be a NES Powerpak with NES included inside the cart

If I understand correctly, this is exactly what kevtris is making.

It would be cool if it could take carts though, otherwise homebrewers might slowly lose the will to make games as original NES consoles fail, since there will be no point in releasing carts.


Correct, that's exactly what it is. It's an FPGA NES + mappers combo. There are a few reasons it doesn't take cartridges. The main one being you need alot of space and level translation logic, along with the fact that I want to do alot more than NES. Adding an NES connector would sorely limit my options.

As for an earlier question, it runs castlevania 3 perfectly, along with every other MMC5 game. All MMC3 games work flawlessly, even the most difficult ones like Klax (japanese ver). That fires 10 or 12 IRQs per frame to adjust the scrolling so that each row of tiles gets its own attributes.

Marble Madness works fine too along with Pirates and their mid-scanline bankswitching. Micromachines and its insane Hblank palette rewriting and sprite fetch pattern checking also.

Last night, I added VRC7 so now Lagrange point is 100%. Fortunately I had done it previously on my synthesizer so I could just drop in the verilog for it. So, it officially supports all expansion audio chips finally.

I was thinking that due to its small size, it'd be a prime target for making into a hand held portable system, too. Current draw shouldn't be TOO bad, and it runs on 9VDC and has switching power supplies on it which are quite efficient (there's no power wasting heatsinks). The connectors can be removed or replaced with headers for wiring it into something.

by on (#69501)
kevtris wrote:
I was thinking that due to its small size, it'd be a prime target for making into a hand held portable system, too.

And by that time, it could almost be turned into a product. But how would one add ROMs? Retrode doesn't support NES yet. Everyone who buys the system and wants to run something other than homebrew would need to buy a front-loading NES and a CopyNES board and pay someone to solder them together.

by on (#69502)
tepples wrote:
kevtris wrote:
I was thinking that due to its small size, it'd be a prime target for making into a hand held portable system, too.

And by that time, it could almost be turned into a product. But how would one add ROMs? Retrode doesn't support NES yet. Everyone who buys the system and wants to run something other than homebrew would need to buy a front-loading NES and a CopyNES board and pay someone to solder them together.


Is it really that hard to make a NES cartridge dumper? Maybe not Famicom given the huge amount of mappers, but for NES it shouldn't be a huge deal. Though the Retrode is horribly expensive itself.

by on (#69503)
Lose the sarcasm; tepples simply meant that those people following the law in the US will be limited to what he described. It's entirely reasonable to consider what legal uses a hardware device will have when considering making it into a product and opening oneself to lawsuits. You may look down on people who consider the laws, but not everyone wants to have their lives ruined. Those who don't care about the laws can easily ignore discussion of how to stay within the law, rather than making fun of it.

by on (#69504)
Although Kevin's clone is cool and all, personally I'd rather own a console that used cartridges. Then, if I wanted to play ROMs I'd use a PowerPak with it, but I would still have the option to use original cartridges if I wanted to.

I believe that many of us are into old consoles because of Nostalgia, and when you get rid of the cartridge-console interaction a lot of that classic feeling is lost, and that console will have little more to offer over a PC plugged to a TV running an emulator. All the charm is gone.

So if anyone out there has plans for a more traditional FPGA console, I suggest you don't give up just because of Kevin's console. I'm sure there's a market for both kinds of consoles.

by on (#69505)
tokumaru wrote:
Although Kevin's clone is cool and all, personally I'd rather own a console that used cartridges. Then, if I wanted to play ROMs I'd use a PowerPak with it, but I would still have the option to use original cartridges if I wanted to.

I believe that many of us are into old consoles because of Nostalgia, and when you get rid of the cartridge-console interaction a lot of that classic feeling is lost, and that console will have little more to offer over a PC plugged to a TV running an emulator. All the charm is gone.

So if anyone out there has plans for a more traditional FPGA console, I suggest you don't give up just because of Kevin's console. I'm sure there's a market for both kinds of consoles.


Yeah I kinda agree that some of the charm so to speak is the complete experience, with dirty carts and blinking screens and blowing into the connector and all. That and physically grabbing a game to play instead of just selecting it off a menu or whatever.

Though, for me personally it's also about using a real controller too. Friend and I been playing the hell out of it using regular real controllers on an NTSC monitor and it sure seems realistic enough. Maybe if you put a shoebox over the console with wires snaking out to the TV and controllers you could convince someone there was a real NES under there.

by on (#69506)
MottZilla wrote:
Is it really that hard to make a NES cartridge dumper? Maybe not Famicom given the huge amount of mappers, but for NES it shouldn't be a huge deal. Though the Retrode is horribly expensive itself.

The mappers aren't an issue, since the dumper has to be able to read and write the PRG space anyway. If we can get the hotswap technique working reliably, or figure out what prevents that (maybe the edge fingers need to connect GND/+5V first?), then a dumper can be very cheap, using the NES itself. An alternative to hotswapping is a small mod to the NES itself that allows booting to a "copynes mini" bootstrap ROM that allows control by a PC over a serial connection.

by on (#69507)
Maybe something like a game-genie (for the physical form factor)?

Has anyone ever modded the ROM on the game genie?

Game genies are on ebay fairly cheap, $5.00and up.

by on (#69513)
clueless wrote:
Maybe something like a game-genie (for the physical form factor)?

Has anyone ever modded the ROM on the game genie?

Game genies are on ebay fairly cheap, $5.00and up.

That would be pretty difficult. Don't Game Genie ROMs have a glop-top?

by on (#69514)
I'm pretty sure mine doesn't, and the PowerPak supports 5 game genie codes so apparently it's possible.

by on (#69515)
kevtris wrote:
Yeah I kinda agree that some of the charm so to speak is the complete experience, with dirty carts and blinking screens and blowing into the connector and all.

That and the bottle of isopropanol solution that I keep in the medicine cabinet for cleaning edge connectors.

Quote:
That and physically grabbing a game to play instead of just selecting it off a menu or whatever.

In that case, a menu looking like a stack of loose carts might help. Want me to draw what it might look like?

Come to think of it, it brings back memories of an old splash that I did for PocketNES years ago:
Image

Quote:
Though, for me personally it's also about using a real controller too.

Which is why I've been using an N64 controller through a USB adapter to test games that I develop for roughly a decade. The Control Pad has that distinct Nintendo feel, which I find important because third-party PC gamepads are way too biased toward the diagonals.

by on (#69517)
naI wrote:
clueless wrote:
Maybe something like a game-genie (for the physical form factor)?

Has anyone ever modded the ROM on the game genie?

Game genies are on ebay fairly cheap, $5.00and up.

That would be pretty difficult. Don't Game Genie ROMs have a glop-top?


After I posted my question I search Google Images for "nes game genie circuit board" and found this:

http://nesp.tighelory.com/images/genie.jpg
http://nesp.tighelory.com/plans_old.shtml

Maybe some Game Genies use glob-tops, but some don't.

I assume that the chip on the right is the char-rom and the chip on the left is the prog-rom + game genie frob.

Unfortunately, (and this is just a guess), it looks like the prog-rom is built into the actual frob, making it really difficult to hack.

by on (#69519)
clueless wrote:
I assume that the chip on the right is the char-rom

I thought that Game Genies didn't have CHR chips, and just generated patterns based on the addresses used to access the CHR data (hence the "blocky" interface). I'm not 100% sure though.

by on (#69525)
clueless wrote:
I assume that the chip on the right is the char-rom and the chip on the left is the prog-rom + game genie frob.

The one on the right has markings that indicate it's a ROM, with version 1.5 of the genie software.

Game Genie is a nifty idea for this dumper. I might have to try making an EPROM programmer and trying this with mine. It'd be great for getting control while any cartridge is inserted, and as a bonus, you can patch the vectors to point into RAM. ... Excellent, it's a ROM, with the same pinout as a 2732 EPROM which I've got. So I just need to get a bootloader into an EPROM and solder/desolder it in.

by on (#69526)
Lock-On technology FTW.

It'd be cool if the game select screen looked like this, which I drew last night:

Image

Sure beats the typical menu of a 12345-in-1 pirate multicart.


Why is "JALECO" in the B's?

by on (#69527)
blargg wrote:
clueless wrote:
I assume that the chip on the right is the char-rom and the chip on the left is the prog-rom + game genie frob.

The one on the right has markings that indicate it's a ROM, with version 1.5 of the genie software.

Game Genie is a nifty idea for this dumper. I might have to try making an EPROM programmer and trying this with mine. It'd be great for getting control while any cartridge is inserted, and as a bonus, you can patch the vectors to point into RAM. ... Excellent, it's a ROM, with the same pinout as a 2732 EPROM which I've got. So I just need to get a bootloader into an EPROM and solder/desolder it in.


Yeah! I had a good idea :) I wish I had time to play with me EE stuff again...

by on (#69528)
What is the feasibility of using a hacked Game Genie + a RAM cart to to homebrew testing on real hardware? You could put your serial port boot strapper into the game genie rom, and then switch the rom completely out once the game has loaded. Would this work?

I should probably get a Game Genie off of ebay before all of nesdev buys them up first :)

You could sell your GG boot rom eprom on retrousb, for those of us who can soldier but lack an eprom programmer.

by on (#69529)
That's the exact idea; bootloader on Game Genie, plug in with any cartridge, then you can load whatever code/data into the NES or cartridge's RAM and run it. This could be something that reads the cartridge ROMs, tests your own code, whatever.

I bet the EPROM could also include the normal Game Genie ROM, so that if you're holding a button on the controller when you power up, it runs the normal Genie ROM so you still have a working Game Genie usable without connection to a PC.

The main obstacles for me trying this is the lack of an EPROM programmer/eraser, and desoldering the Genie ROM. I'm quite sure it would all work.

Quote:
I should probably get a Game Genie off of ebay before all of nesdev buys them up first

And an extra 72-pin connector due to the harmful effects of the Game Genie's overly-thick circuit board.

by on (#69768)
65024U wrote:
I can't find it, but somebody already took the Williams arcade hardware for Defender or Robotron and put it on 3 chips.

I have Defender running in an FPGA. It was quite trivial. There's a glitch or 2 and no sound, but enough to demonstrate that it is possible, if not playable.
<http://pacedev.net/forums/showthread.php?t=12>

by on (#69769)
kyuusaku wrote:
Neo Geo will fit into many FPGA now but there's a huge difference in complexity between a 68000 core and a 6502 core. AFAIK, nobody has written a hardware accurate 68000... With all the microcode it's a huge task and challenge, I'm not sure that stuff has even been reverse engineered... There's also a memory & latency issue; Neo basically has 5x 200ns buses of different widths opposed to 2x 8-bit in the NES and it's hard to meet the timing requirements with a single SDRAM, regardless of how fast. Anyway, a real Neo Geo home console is <$200 and an arcade board (MVS) is <$100 and they aren't as rare as one might think.

I've started work on a NeoGeo. It's only very preliminary stuff, using the 68k core from Minimig and only has a limited number of text/tiles displayed. It boots past the self-test (had to implement the RTC) and Joy Joy Kid actually runs (on a DE1)!!! You can coin-up and start a game, but you really only get to see the text changing.

I don't think a cycle-accurate 68K is as important for the NeoGeo as it is for the NES, for example. With a more straight-forward tilemap/sprite system and async CPU bus, I suspect there's a lot less reliance on CPU instruction timings in most of the NeoGeo games.

You are correct re:problems on current FPGA boards. Obviously I never had any pretentions of getting the whole thing going on the DE1, for example. But I do (now) have access to more powerful boards, including one with a Stratix EP3SL70 AND a Cyclone EP4C16, some SRAM and DDR3 RAM, and DVI out. That will be interesting to play with. I just don't have time atm... :(
Re: FPGA project
by on (#69770)
kevtris wrote:
Also, this gives me enough fast RAM to do full blown SNES and genesis. I really, really want to get SNES going on an FPGA, so this hardware is designed to meet that goal.

I'm assuming you know that the Genesis has been done!?!

I too would absolutely *love* to do the SNES. I've been "pissing around" doing lots of little projects and porting other people's efforts to the various hardware targets I have, but not yet done a "complex" design. I also tend to get things 90% complete and move on to other projects.

Right now I'm working on finishing up a Tandy Coco 1/2 design which I hope will be my first "complete" design. The idea was to collaborate with a few others but it has turned out to be pretty much 100% my work. It's mostly there, I just need to add SD card support for IDE emulation - something I think will come in handy for other projects in the future!

Good luck, I have no doubt you or all people can do it!
Re: FPGA project
by on (#69771)
kevtris wrote:
I figure this is the best shot I have at making some kind of "FPGA thing" to sell. The hard part about it is the FPGA alone costs $42 on it, and there's not much I can do about getting that lowered. There might be a quantity discount but there doesn't seem to be.

I've been planning on producing some form of commercial FPGA-based retro product for the past 5 years. But my ambitions always outstrip the current technology / price-point trade-off that would make it commercially viable. Hence the reason I have nothing at all to show for years of "tinkering" except a bunch of relatively simple projects.

If you're considering a SNES, I'd humbly suggest you not worry about the hardware at all for now and start developing on the most powerful hardware you can lay your hands on. For one, it'll make your development job easier. And two, by the time it's ready technology will be cheaper; you can always sit on it for a bit if not. A good design will be relatively portable across hardware targets.
Re: FPGA project
by on (#69776)
tcdev wrote:
I'm working on finishing up a Tandy Coco 1/2 design [...] I just need to add SD card support for IDE emulation

If you add CF card support, you have IDE with no need for emulation.

by on (#69778)
Not to be mean but Cloud9 and Coco3 have Cf card devices, serial connections from PC->Coco, Hard drive and CF IDE-like environments and much more. Not that you doing it is a waste, it just already exists and since we have the SuperIDE with the flash card slot, too, I will say it's awesome.


And Genesis FPGA is done? Wow, thats awesome. I love the preservation of all this hardware on new materials. :D If I had money I'd totally pick it up.

by on (#69785)
tepples wrote:
Lock-On technology FTW.

It'd be cool if the game select screen looked like this, which I drew last night:

Image

Sure beats the typical menu of a 12345-in-1 pirate multicart.


Why is "JALECO" in the B's?


I really like that idea for a game menu, that's pretty nice :-)

I am not sure how the menuing is going to work yet; I figured I'd just have an overlay that the host CPU can slap on top of the active video using a 10% or 25% transparency. But the cart label idea is pretty cool I have to say.
Re: FPGA project
by on (#69786)
tcdev wrote:
kevtris wrote:
I figure this is the best shot I have at making some kind of "FPGA thing" to sell. The hard part about it is the FPGA alone costs $42 on it, and there's not much I can do about getting that lowered. There might be a quantity discount but there doesn't seem to be.

I've been planning on producing some form of commercial FPGA-based retro product for the past 5 years. But my ambitions always outstrip the current technology / price-point trade-off that would make it commercially viable. Hence the reason I have nothing at all to show for years of "tinkering" except a bunch of relatively simple projects.

If you're considering a SNES, I'd humbly suggest you not worry about the hardware at all for now and start developing on the most powerful hardware you can lay your hands on. For one, it'll make your development job easier. And two, by the time it's ready technology will be cheaper; you can always sit on it for a bit if not. A good design will be relatively portable across hardware targets.


meh. I already have the hardware designed, built and debugged for the most part. The target is fixed. Be that as it may, its abilities are pretty decent and should be plenty for SNES. 16Mbytes of RAM is plenty for the RAM/ROM emulation and the synchronous SRAM is plenty for a screen buffer, SPC700, and PPU RAM. It should be able to handle some of the expansion chips like the DSPs... probably not enough oomph for SA-1 but the SDD1 might be doable.

---
minor update:

I "finished" the NES core I think also. It supports 211 different mappers right now (that alone's around 5500 lines of verilog, cartridge audio (yes even VRC7) adds another 2500 or so. All expansion audio is implemented now (VRC6, VRC7, MMC5, FME7, N106, FDS, drip mapper audio).

The entire NES+mappers+etc took almost 700K bytes of verilog code in 68 files that I banged out in the last 2 months.

It plays all the NES games I can feed it, all the Vs. games I can feed it (yes, the gun games work with a regular zapper), and it plays NSFs with an on-screen display doohickey.

So, now that the NES part is done, the next part is the host controller that will read the USB controllers, SD card, and all that fun stuff. I don't anticipate too many problems here, I'm very familiar with SD and the USB host mode stuff doesn't seem terribly difficult with the particular CPU I chose.

Once the CPU is running I will be able to enable the DVI video sender and see if that works too.

Tomorrow my programming dongle will be here, and the CPU is already installed and I think it works. it doesn't get hot anyways so it's probably hooked up at least mostly correct. Won't be able to test until I get the programmer.
Re: FPGA project
by on (#69801)
tepples wrote:
If you add CF card support, you have IDE with no need for emulation.

I already have CF support. I just want to be able to run this on the DE1 which only has SD card.

by on (#69803)
65024U wrote:
Not to be mean but Cloud9 and Coco3 have Cf card devices, serial connections from PC->Coco, Hard drive and CF IDE-like environments and much more. Not that you doing it is a waste, it just already exists and since we have the SuperIDE with the flash card slot, too, I will say it's awesome.

I'm well versed in the Coco scene and all the products that are available.

I'm not looking to produce a product that connects to a real Coco. I'm developing an all-in-one FPGA emulation that actually emulates some of those Cloud9 products on-chip. For instance, I already emulate the SuperIDE controller, with full HDBDOS support via CF. I'm just looking to (also) use the SD card as an IDE peripheral, to use on the DE1 for example.

I have also had Drivewire running on the emulation, but only when using an external 6809. There is no cycle-accurate 6809 core available (yet), so the hand-crafted bit-bash routines in Drivewire won't quite work. Gary Becker got around that on his Coco3FPGA emulation by (IIUC) re-coding parts of the routines. As far as I'm concerned, that's cheating. I want to be able to use the "original" software.

by on (#69810)
Yeah, 6809 shouldn't be hard to cycle-emulate. It's pretty easy how instructions go together and no special ones as it seems with great documentation. Good luck with that man! A Coco FPGA would be great, too. Even with a psuedo 256 color mode? :P


I want one of these magical (and a bit expensive) FPGA thingamabobs now! lulz. Maybe I will just let all this talent make this stuff so I can buy.....yeah, that sounds better. ;) I love the random internet smart people. XD
Re: FPGA project
by on (#69811)
kevtris wrote:
meh. I already have the hardware designed, built and debugged for the most part. The target is fixed. Be that as it may, its abilities are pretty decent and should be plenty for SNES. 16Mbytes of RAM is plenty for the RAM/ROM emulation and the synchronous SRAM is plenty for a screen buffer, SPC700, and PPU RAM. It should be able to handle some of the expansion chips like the DSPs... probably not enough oomph for SA-1 but the SDD1 might be doable.

I don't know much about the SNES hardware myself. I do know that someone is working on the 65816 core for Apple IIGS emulation. No idea how far he has gotten with it though.

kevtris wrote:
I "finished" the NES core I think also.

It plays all the NES games I can feed it, all the Vs. games I can feed it (yes, the gun games work with a regular zapper), and it plays NSFs with an on-screen display doohickey.

I've always been impressed with your NES efforts since I discovered your project several years ago. I can only imagine the number of hours you have invested in this. Kudos to you.

Aside from time, the biggest problem I have is that my emulation interests are far too broad. So I start one project, and then get diverted to something else when I get to the "hard slog" part of the project. Hence the reason I have started a bunch of different cores which are "proof of concept".

kevtris wrote:
So, now that the NES part is done, the next part is the host controller that will read the USB controllers, SD card, and all that fun stuff. I don't anticipate too many problems here, I'm very familiar with SD and the USB host mode stuff doesn't seem terribly difficult with the particular CPU I chose.

Once the CPU is running I will be able to enable the DVI video sender and see if that works too.

One of the main reasons I'm interested in FPGA emulation is the ability to (easily) interface modern peripherals such as USB & SD. The one point of contention I have is that IMHO using an external CPU is "cheating" to some extent. I know that it's by far the most sensible and practical approach, but something about it just gnaws away at me. It's just the way I am.

I'm going to assume you're not using an OXU210HP USB host chip! :wink: Uggh! I'm currently about to start work on an embedded host stack and that is anything but simple. To be fair, it's meant to be a fully featured EHCI root port, and for our purposes it's probably way overkill. The cool thing is that it is on an FPGA board that I can ultimately "play" with for my retro emulations.

Did you choose a TI chip for the DVI transmitter?
Re: FPGA project
by on (#69848)
Quote:
Aside from time, the biggest problem I have is that my emulation interests are far too broad. So I start one project, and then get diverted to something else when I get to the "hard slog" part of the project. Hence the reason I have started a bunch of different cores which are "proof of concept".

kevtris wrote:
So, now that the NES part is done, the next part is the host controller that will read the USB controllers, SD card, and all that fun stuff. I don't anticipate too many problems here, I'm very familiar with SD and the USB host mode stuff doesn't seem terribly difficult with the particular CPU I chose.

Once the CPU is running I will be able to enable the DVI video sender and see if that works too.

One of the main reasons I'm interested in FPGA emulation is the ability to (easily) interface modern peripherals such as USB & SD. The one point of contention I have is that IMHO using an external CPU is "cheating" to some extent. I know that it's by far the most sensible and practical approach, but something about it just gnaws away at me. It's just the way I am.

I'm going to assume you're not using an OXU210HP USB host chip! :wink: Uggh! I'm currently about to start work on an embedded host stack and that is anything but simple. To be fair, it's meant to be a fully featured EHCI root port, and for our purposes it's probably way overkill. The cool thing is that it is on an FPGA board that I can ultimately "play" with for my retro emulations.

Did you choose a TI chip for the DVI transmitter?


Yeah it is cheating a bit, but it's kinda hard for the FPGA to load its own fusemaps off the SD card! I want to be able to reload the FPGA on the fly with different consoles and what not, so that mandates an external CPU.

The chip is pretty nice, it's a vinculum 2 and it costs around $5 in single quantities. For that, you get two USB host/peripheral ports, a 32 bit CPU, some RAM, timers, UARTs, and all that other usual microcontroller stuff. The best part is the C compiler is free, they have libraries you can use for USB and FATxx and stuff (not that I need it, I already have a complete 6502 based SD+FAT solution but without the FPGA running there's no way to use it) and the programming dongle only costs $16 or so.

On that FPGA synth I did, there was a 2nd 6502 that ran the user interface. It worked really well (6502 did FAT and SD and other stuff too) and the DMA unit built into the SD card part made music loading very fast and easy, but writing all that code in asm sucked. Life is short, time isn't infinite, so this time I really want to try writing the host controller stuff in C on a more modern CPU.

The NES core right now has an 8K on-chip BIOS that has a simple monitor and ROM/NSF loading and such, but I will eventually move most of the loading part over to the vinculum 2 CPU.

As for my DVI transmitter, yes it's a TFP410 made by TI. Hopefully that programming dongle comes today so I can get started on finishing up the timing and video modules then start on system control! And I cross my fingers that SD card, the pushbuttons and 7-seg display and USB stuff and DVI stuff will work :-)
Re: FPGA project
by on (#69861)
kevtris wrote:
The chip is pretty nice, it's a vinculum 2 and it costs around $5 in single quantities. For that, you get two USB host/peripheral ports, a 32 bit CPU, some RAM, timers, UARTs, and all that other usual microcontroller stuff.

Nice, I'll look into it. I was also eyeing off the NXP & STM parts at one point for the same purposes.

kevtris wrote:
On that FPGA synth I did, there was a 2nd 6502 that ran the user interface. It worked really well (6502 did FAT and SD and other stuff too) and the DMA unit built into the SD card part made music loading very fast and easy, but writing all that code in asm sucked.

I "borrowed" a 6502-based OSD module from another project (Vector06C?) for a few of my projects, though I didn't end up using it for anything useful.

kevtris wrote:
As for my DVI transmitter, yes it's a TFP410 made by TI.

Ah yes, know it well. Quite simple to set-up. I wrote a small state-machine that drives the opencores I2C master to initialise the chip directly from the FPGA without the need for a processor, though I assume you've connected it to your external processor...
Re: FPGA project
by on (#69862)
kevtris wrote:
On that FPGA synth I did, there was a 2nd 6502 that ran the user interface. It worked really well (6502 did FAT and SD and other stuff too) and the DMA unit built into the SD card part made music loading very fast and easy, but writing all that code in asm sucked.

Now that you mention it, I was wondering if the above-mentioned module was freely available?

The reason I ask is that I'm currently "stalled" on my Coco 1/2 project on the SD part. I need to emulate an IDE device using an SD card. My original plan was to complete an SD read/write back-end written in HDL that my colleague had started time time ago. It is using the 1-bit (non-SPI) mode.

I'm getting a little impatient and have considered using a small soft-core processor instead to do the work. I have C-source to do bit-bash SPI SD accesses that runs on the NIOS, but that's not suitable for my purposes. Something like what you've done would be ideal. So if it is open, could you please point me to it. If not, no problem.

The early Minimig design had a Z80 doing this stuff, but IIRC it was too difficult to extract just the parts I needed from the design. It was also a little "temperamental" with different SD cards from memory.
Re: FPGA project
by on (#69883)
tcdev wrote:
I need to emulate an IDE device using an SD card.


I'm probably being horrifically dense and missing something, but why not use compactflash? It already is an IDE device.

by on (#69884)
How come everyone here likes CompactFlash so much when it appears that the much more common (and cheaper!) SD cards don't look so hard to work with? The Harmony Cartridge (the Atari 2600 equivalent to the PowerPak) for example, uses SD cards for storage.

by on (#69888)
tokumaru wrote:
How come everyone here likes CompactFlash so much when it appears that the much more common (and cheaper!) SD cards don't look so hard to work with?

Until recently, the SD Association didn't publish a non-confidential specification for building a card reader; one first had to join the SD Association. And even now that the simplified spec is available, SD support still "may require a license from the SD Card Association, SD Group, SD-3C, LLC or other third parties." CF, on the other hand, can be accessed as if it were an ATA hard drive, all nice and patent-free. It also takes a bit more glue logic on the reader to make SD's 1-bit or 4-bit protocol work as fast as a CF 8-bit transfer.

Quote:
The Harmony Cartridge (the Atari 2600 equivalent to the PowerPak) for example, uses SD cards for storage.

As does the EverDrive for Sega Genesis.
Re: FPGA project
by on (#69890)
lidnariq wrote:
I'm probably being horrifically dense and missing something, but why not use compactflash? It already is an IDE device.

I'll stop short of calling you horrifically dense, but you are missing something - namely the part where I said I already have CF support but I want to target a platform (TerASIC DE1) that doesn't have CF, but has SD. :P

by on (#69891)
tokumaru wrote:
How come everyone here likes CompactFlash so much when it appears that the much more common (and cheaper!) SD cards don't look so hard to work with? The Harmony Cartridge (the Atari 2600 equivalent to the PowerPak) for example, uses SD cards for storage.

I think the point is that CF has TrueIDE mode, which makes it ideal when you have an IDE controller, or want to connect an IDE device.

As for SD being "easy to work with", that is true if you're satisfied with slower transfer rates. And to be fair, that's usually the case when you're emulating retro computers. The faster parallel interface modes are a bit more involved, and the 4-bit mode is AFAIK still not open.

In my case, I have an IDE controller but I want to hook up an SD card. Stupid? Perhaps. But there's a reason - I'm targeting a particular FPGA development board.
Re: FPGA project
by on (#69919)
tcdev wrote:
kevtris wrote:
The chip is pretty nice, it's a vinculum 2 and it costs around $5 in single quantities. For that, you get two USB host/peripheral ports, a 32 bit CPU, some RAM, timers, UARTs, and all that other usual microcontroller stuff.

Nice, I'll look into it. I was also eyeing off the NXP & STM parts at one point for the same purposes.

kevtris wrote:
On that FPGA synth I did, there was a 2nd 6502 that ran the user interface. It worked really well (6502 did FAT and SD and other stuff too) and the DMA unit built into the SD card part made music loading very fast and easy, but writing all that code in asm sucked.

I "borrowed" a 6502-based OSD module from another project (Vector06C?) for a few of my projects, though I didn't end up using it for anything useful.

kevtris wrote:
As for my DVI transmitter, yes it's a TFP410 made by TI.

Ah yes, know it well. Quite simple to set-up. I wrote a small state-machine that drives the opencores I2C master to initialise the chip directly from the FPGA without the need for a processor, though I assume you've connected it to your external processor...


I ran out of IO's on the FPGA, otherwise I would've driven it directly from the FPGA. With two RAM chips and RGB output it ate up most of the IO's.

Over 100 pins on the 240 pin FPGA are just power and ground.

Sorry, the 6502 core + SD engine and all that aren't open source. I wrote them all myself (As I did every other line of code. I don't believe in using other people's code since it's usually buggy and doesn't suit the project exactly, and would have to be either rewritten or adapted which would take as long or longer than just writing it myself. Not to mention, using other people's code is no fun, hehe)

by on (#69920)
tcdev wrote:
tokumaru wrote:
How come everyone here likes CompactFlash so much when it appears that the much more common (and cheaper!) SD cards don't look so hard to work with? The Harmony Cartridge (the Atari 2600 equivalent to the PowerPak) for example, uses SD cards for storage.

I think the point is that CF has TrueIDE mode, which makes it ideal when you have an IDE controller, or want to connect an IDE device.

As for SD being "easy to work with", that is true if you're satisfied with slower transfer rates. And to be fair, that's usually the case when you're emulating retro computers. The faster parallel interface modes are a bit more involved, and the 4-bit mode is AFAIK still not open.

In my case, I have an IDE controller but I want to hook up an SD card. Stupid? Perhaps. But there's a reason - I'm targeting a particular FPGA development board.


I dunno, my DMA unit was pulling 200-400Kbytes/sec through the SD card using SPI mode. I don't think that's TOO slow. The 6502 could never hope to achieve anything close to that, probably topping out at only 10% of that. I used a DMA unit that I could just load up with a start address and length and it would blast it at 10MHz from the card to the SDRAM. This made loading SID tunes and things practically instant. Hit the button and it loads and plays faster than you can blink.

The biggest advantage to SD for me is size and pin count. A CF card is the size of a small city and would've taken up 1/4th or more of my PCB realestate. I wanted to place a normal SD slot on it, but even that was way too big. I finally settled on microSD due to space limitations.

A 16GB microSD card cost me $25 and will hold every single thing I would ever want to run just about.

The number of pins on a CF card also sucks. Granted you don't have to hook them all up of course to your FPGA or whatever, but there's still a large number of lines to connect. It's basically hooked up like a small RAM chip. D0-7 (or D0-15) and then 3 address lines and some control signals (/RD, /WR, CE, etc).

The SD card only has a few signals in contrast. clock, data in, data out, chip enable and a card detect signal basically. FPGA IOs are a very hot commodity so saving them is important, 'cause it lets you add more cool gadgets to the device.
Re: FPGA project
by on (#69923)
kevtris wrote:
Sorry, the 6502 core + SD engine and all that aren't open source. I wrote them all myself (As I did every other line of code. I don't believe in using other people's code since it's usually buggy and doesn't suit the project exactly, and would have to be either rewritten or adapted which would take as long or longer than just writing it myself. Not to mention, using other people's code is no fun, hehe)

Heh, understood.

My colleague started on a 1-bit SD interface (clocks faster than SPI) a while back when we were looking at working on an embedded xvid player (which we got running in a soft-core processor, but the colour-space conversion was too slow - that's another story). Anyway, I was looking at the opencores SD controller recently, but thought it was way overkill for my needs; I 'borrowed' the SD device model from it for simulating my colleague's interface. After I wasn't getting anywhere with it he took a look at it, and claims that the model is "completely broken". He made a few fixes and claims it is now intialising the card properly. I've yet to start back on it... so yeah - the point of this rant is that I know where you're coming from. :(

by on (#69924)
kevtris wrote:
I dunno, my DMA unit was pulling 200-400Kbytes/sec through the SD card using SPI mode. I don't think that's TOO slow. The 6502 could never hope to achieve anything close to that, probably topping out at only 10% of that. I used a DMA unit that I could just load up with a start address and length and it would blast it at 10MHz from the card to the SDRAM.

Oh I agree completely. And I'll be hooking this up to a 4MHz Z80 and a 1.78MHz 6809 initially. So I could've gotten away with SPI, but my colleague convinced me to use his "almost working" SD interface. :roll: So here I am... It's one of those situations where once you get your mind set on something... :)

by on (#69928)
tcdev wrote:
. And I'll be hooking this up to a 4MHz Z80 and hopefully 3 MHz 6309 initially.



Fixed it for ya. :P

by on (#69929)
kevtris wrote:
I "finished" the NES core I think also. It supports 211 different mappers right now (that alone's around 5500 lines of verilog, cartridge audio (yes even VRC7) adds another 2500 or so. All expansion audio is implemented now (VRC6, VRC7, MMC5, FME7, N106, FDS, drip mapper audio).

The entire NES+mappers+etc took almost 700K bytes of verilog code in 68 files that I banged out in the last 2 months.

That's really cool. I'm not even close to where you are. Is this all still fitting in the Cyclone I with ~12K LEs? Or have you moved to a larger device? It's hard for me to compare Altera devices resource wise to Xilinx (which is what I'm using) since Altera vs. Xilinx resource terminology is very different. It looks like on your new board the Cyclone chip is a bit bigger this time around - did you move up to a Cyclone II instead? Also, (and yes I realize this may be considered NDA/proprietary/secret so I don't actually expect an answer to this, lol) what current resource utilization are you at within the cyclone with the entire CPU+PPU+APU+mappers+etc? 25%, 50%, 75%, 90%?

So from you've said it appears you've moved away from the original PIC microcontroller and replaced it with this Vinculum 2 instead. PIC is certainly very popular whereas I've never heard of the Vinculum before. PIC also has good IDE tools and lots of freely availble IP. Why did you switch away from the PIC? Was there something that you just really didn't like about it?

Also, I sent you a PM regarding a very specific CPU design question. I didn't post it here because it doesn't relate at all to this topic and don't want to get things off-track. Mind taking a peak?

Pz!

Jonathon :)

by on (#69932)
I think the main reason to go with the Vinculum 2 (it's made by FTDI, maybe better known for the FT232) is because it offers 2 USB host ports. That makes 2 NES (or any other USB) controllers usable with less parts. Indeed, with one design I'm working on with PIC32, the only thing I'm disappointed with is only having 1 USB host port (it seems there's no Microchip library for using hubs), after going through the trouble of powering it to the full specs. :)

But yeah thought I'd just mention too, that I've seen and played kevtris' console at various times through it's entire development, what's always been striking is the level of detail (including many obscure and normally unused CPU/PPU features), and the bizarre behaviors of so many different mappers and NES boards that kevtris RE'd. Playing it, the video and sound was identical to the NES, even with weirdest ROMs like Micro Machines (with it's $2003 polling).

by on (#69942)
65024U wrote:
tcdev wrote:
. And I'll be hooking this up to a 4MHz Z80 and hopefully 3 MHz 6309 initially.



Fixed it for ya. :P


Umm... ? :?

by on (#69946)
I think someone's a fan of Tandy CoCo.

by on (#69948)
tepples wrote:
I think someone's a fan of Tandy CoCo.

I gathered that much, but not sure where the 3MHz 6309 comes into it.

The stock Coco3 has a 1.78MHz 6809. A common upgrade is the 6309 for running a special version of Nitros09, but the clock speed remains the same. The only overclocking I know of for the Coco 3 is SockMaster's 4MHz mod.

So I'm a little confused by the comment?!?

by on (#69958)
I'm confused too, sorry.

by on (#69964)
Just because you can, really. And it's 6809 is more efficient in some areas, and then you can also extend your registers by a TON above that in 6309 mode. Yeah.....I have a 64KB Coco1 and a 128 Coco3....I love them. :3



All this FPGA stuff should be giving to a company that makes NOAC's for stuff to improve compatibilty or something....I'd love MMC5 NOAC games with extra sound! :D

by on (#69968)
65024U wrote:
All this FPGA stuff should be giving to a company that makes NOAC's for stuff to improve compatibilty or something....I'd love MMC5 NOAC games with extra sound! :D


That's a little hopeful for companies that make the clones. There already are accurate (precise photocopied) clones of the die (maybe not in production anymore I guess), but they'll probably go with whatever is cheapest and available.

Would be cool though if those companies had the wisdom to at least ask kevtris about it, but I don't think that "giving it" would be the right way to word it. It's a pretty huge project.

by on (#69970)
jwdonal wrote:
That's really cool. I'm not even close to where you are. Is this all still fitting in the Cyclone I with ~12K LEs? Or have you moved to a larger device? It's hard for me to compare Altera devices resource wise to Xilinx (which is what I'm using) since Altera vs. Xilinx resource terminology is very different. It looks like on your new board the Cyclone chip is a bit bigger this time around - did you move up to a Cyclone II instead? Also, (and yes I realize this may be considered NDA/proprietary/secret so I don't actually expect an answer to this, lol) what current resource utilization are you at within the cyclone with the entire CPU+PPU+APU+mappers+etc? 25%, 50%, 75%, 90%?

So from you've said it appears you've moved away from the original PIC microcontroller and replaced it with this Vinculum 2 instead. PIC is certainly very popular whereas I've never heard of the Vinculum before. PIC also has good IDE tools and lots of freely availble IP. Why did you switch away from the PIC? Was there something that you just really didn't like about it?

Also, I sent you a PM regarding a very specific CPU design question. I didn't post it here because it doesn't relate at all to this topic and don't want to get things off-track. Mind taking a peak?

Pz!

Jonathon :)


Sure I can tell ya. Right now I am using a cyclone 3 25K model, same size chip (240 pins) as the previous model, but 2x more gate-age.

It is using 65% of the device for everything, and I expect it to hit 70% when I finish the vinculum interface stuff to do system control.

It does not fit on the old FPGA any more, but it could easily be trimmed to fit if needed, though I have finished with that old hardware now and won't use it again probably.

I selected altera, because xilinx's programming environment is a huge steaming pile of poo. Buggier than a swamp in june, in #nesdev I watched people struggle with it; compiles that work but then the device doesn't, unless they downgrade the compiler.

the entire design is all verilog now, with a single top level schematic just linking 6 or so verilog top modules together (CPU, PPU, mappers, audio, video, controllers, SDRAM). All of the hardware-specific pieces are cordoned off in a single verilog "Technology" file as I called it, mainly the blockrams. This was in case the design needs to be ported, it should be possible to just replace this 1 file and it can work on another vendor's parts.

As memblers said, I changed from PIC to vinculum because I wanted 2 USB ports on it for controllers. So far I have had problems just getting the damn thing to compile and work but I got all that solved and the chip is happily lighting the segments of the LED display up in a cylon-like pattern. At this point I am going to write all the basic hardware interface doohickeys and go from there.

This vinculum chip is fairly cheap, too.

by on (#69982)
Hi All,

I really like to see the same thing happened as 1chipMSX on NES/FC.
http://en.wikipedia.org/wiki/1chipMSX
I will buy one(1chipNES) if the price is reasonable.
I can buy a clone one(NES/FC) about USD15 here for my kids to play.
The video quality is not good on LCD TV, but works fine on CRT TV.
Sometimes I play it(NES/FC) on my computer via emulator, sometimes I play it on the LCD TV via Wii NES emulator. I am very happy with the quality from emulators no matter PC or Wii version.
I have been dreaming to have a box which I can put synthesizable RTLs to emulate any arcade or console to play with it.
1chipMSX is a starting point. I would like to see if there is a standard platform for all maybe 8 bits consoles to be put in to play and to study.

BR,
Jinwar

by on (#69983)
jinwar wrote:
Hi All,

I really like to see the same thing happened as 1chipMSX on NES/FC.
http://en.wikipedia.org/wiki/1chipMSX
I will buy one(1chipNES) if the price is reasonable.
I can buy a clone one(NES/FC) about USD15 here for my kids to play.
The video quality is not good on LCD TV, but works fine on CRT TV.
Sometimes I play it(NES/FC) on my computer via emulator, sometimes I play it on the LCD TV via Wii NES emulator. I am very happy with the quality from emulators no matter PC or Wii version.
I have been dreaming to have a box which I can put synthesizable RTLs to emulate any arcade or console to play with it.
1chipMSX is a starting point. I would like to see if there is a standard platform for all maybe 8 bits consoles to be put in to play and to study.

BR,
Jinwar


You can buy a NOAC, but you can't play a lot of games. And no offence, if they do sell these, one buy won't mean much probably, especially not to get these awesome projects done faster. :3 If you like emulator, stick with it and just get a NES controller->USB device from RetroUSB. They're pretty nice.

by on (#69995)
Quote:
You can buy a NOAC


Do you mean NOAC as http://encyclopedia.thefreedictionary.com/NES+on+A+Chip

If so, actually, the clone NES/FC I bought is a NOAC.
The forum seems not allow to attach photo, otherwise I can post a pretty small PCB of that for you.
The NOAC I have actually can play a lot of NES/FC games but bad video quality on LCD TV.

by on (#70008)
Yeah but they don't have a lot of add ons and don't run all games right. They okay, but still not the real thing. :)

by on (#70012)
kevtris wrote:
Right now I am using a cyclone 3 25K model, same size chip (240 pins) as the previous model, but 2x more gate-age.

Cool! Do you find yourself using any Cyclone-III-specific technology for your NES that wasn't available in the old Cyclone-I that might prevent back-porting? I'm running into that problem with my NES with the Xilinx devices. I was originally supporting both Virtex-2 and Virtex5 but now I'm only supporting V5 because it just became too time consuming and too much of a pain to keep both versions up and running.

kevtris wrote:
I selected altera, because xilinx's programming environment is a huge steaming pile of poo. Buggier than a swamp in june, in #nesdev I watched people struggle with it; compiles that work but then the device doesn't, unless they downgrade the compiler.

I know exactly what you mean!! Stupid Xilinx!!! GRRRRR!!!!!!! And it hasn't changed one bit! Bah!! Haha, maybe I need to switch over to Altera for this....ugggh, yet another tool and technology to learn. :-/

by on (#70016)
jwdonal wrote:
Cool! Do you find yourself using any Cyclone-III-specific technology for your NES that wasn't available in the old Cyclone-I that might prevent back-porting?

I wouldn't imagine there'd be much in the NES that wouldn't be back-portable. The Cyclone III isn't very different - better PLLs and more RAM and I can't think of much else (probably I/O features & power considerations).

jwdonal wrote:
I know exactly what you mean!! Stupid Xilinx!!! GRRRRR!!!!!!! And it hasn't changed one bit! Bah!! Haha, maybe I need to switch over to Altera for this....ugggh, yet another tool and technology to learn. :-/

Another unsatisfied Xilinx user eh? I can't believe that they're still a major player with tools that suck big fat hairy dogs' balls. I've used them on occasion and I hate them with a passion. I've never met anyone who uses both that prefers Xilinx tools. And I've heard of plenty that go Altera and never look back. I urge you to make the switch - you'll never regret it!

by on (#70025)
jwdonal wrote:
kevtris wrote:
Right now I am using a cyclone 3 25K model, same size chip (240 pins) as the previous model, but 2x more gate-age.

Cool! Do you find yourself using any Cyclone-III-specific technology for your NES that wasn't available in the old Cyclone-I that might prevent back-porting? I'm running into that problem with my NES with the Xilinx devices. I was originally supporting both Virtex-2 and Virtex5 but now I'm only supporting V5 because it just became too time consuming and too much of a pain to keep both versions up and running.

kevtris wrote:
I selected altera, because xilinx's programming environment is a huge steaming pile of poo. Buggier than a swamp in june, in #nesdev I watched people struggle with it; compiles that work but then the device doesn't, unless they downgrade the compiler.

I know exactly what you mean!! Stupid Xilinx!!! GRRRRR!!!!!!! And it hasn't changed one bit! Bah!! Haha, maybe I need to switch over to Altera for this....ugggh, yet another tool and technology to learn. :-/


It directly ported over from the C1 to the C3, and could be easily backported if need be.

I put all the special vendor/chip specific stuff in a single verilog file though, so if I have to change devices/vendors/etc it should very easy to do so. Backporting to the C1 is kinda useless now since I think altera EOL'd it. I was on their page and they only show cyclone 2, 3, and 4 now.

Actually getting the NES to run on the new hardware was dead simple- it took maybe a day to fix it all up. I did use my verilog SDRAM module however, because I had to modify it for 16 bit wide RAM (to make it 8 bits wide for the NES using the byte enables and stuff). Buut, games ran first go after some minor hardware initialization stuff. Then it took about 2 months to convert it over from schematic to verilog, which let me fix a bunch of hacky stuff and bugs, and introduce some new bugs I'm sure.

Altera's dev environment is pretty easy to use though, and seems fairly bug free with regards to actually generating fusemaps and whatnot. It's really nice and I really like the code editor on it vs. other IDEs' code editors. I tried the ISE webpack (xilinx IDE) when I was considering using a xilinx part, but I ended up uninstalling it out of frustration and went with another altera part instead. Their chips might be nice but the dev software sure isn't.

(Also, I detest how xilinx uses marketing terms to describe their chip capacity. The whole "gate count" garbage isn't a very useful metric, since there's no definition of what a "Gate" really is. What I was reading awhile back is the gate count includes all the gates in the configuration and programming logic along with the "user gates". What really counts is how many complex logic blocks the chip has, which is directly related to what you get to put you design in.)

by on (#70026)
For people more familiar with CPLDs, where a macrocell roughly corresponds to one flip-flop, how many macrocells is a "complex logic block" worth?

by on (#70036)
The altera chips use Logic Elements (LEs), which are a single bit register and a 4-input LUT with a wide variety of routing options. They're packed into Logic Array Blocks (LABs) in groups of 16, which are laid out in a grid pattern on the chip.

by on (#70038)
ReaperSMS wrote:
The altera chips use Logic Elements (LEs), which are a single bit register and a 4-input LUT with a wide variety of routing options. They're packed into Logic Array Blocks (LABs) in groups of 16, which are laid out in a grid pattern on the chip.


The altera Cyclone chips use Logic Elements (LEs)... FTFY

More than a few people have written articles on comparing Altera and Xilinx logic resources. In some respects, you're comparing apples & oranges. Sometimes I swear they chose different architectures not for any technical reason, but just so they they couldn't be compared! :wink:

by on (#70040)
tcdev wrote:
I swear they chose different architectures not for any technical reason, but just so they they couldn't be compared! :wink:

I wouldn't be surprised if that was 100% correct. Seriously.

by on (#70048)
Who is the first one to start creating NES on FPGA?
kevtris or below?
http://crystal.freespace.jp/pgate1/nes/index.html
or
http://www.geocities.jp/team_zero_three ... on_minimig
or
http://cegt201.bradley.edu/projgrad/proj2006/fpganes/
or
...

Again, I will buy one if someone can sell a platform such as 1chipmsx or Minimig for reasonable price.