Hacker News new | past | comments | ask | show | jobs | submit login
Ludde's FPGA NES (fpganes.blogspot.se)
149 points by jyrki on Jan 21, 2013 | hide | past | favorite | 22 comments



Unless there's a second ludde in Gothenburg, he also wrote uTorrent and started ScummVM and OpenTTD.

http://en.wikipedia.org/wiki/Ludvig_Strigeus

Edit: He added his previous projects to his profile after I wrote this comment.


Interesting. Linking to recent discussions about the YC backed company installmonetizer:

uTorrent is kind of a good example for the 'monetize by bundling crapware' category of software, btw.. I recommend forgetting that this software existed and moving on to sensible projects.


From Wikipedia, uTorrent: > Although originally developed by Ludvig Strigeus, since December 7, 2006, the code is owned and maintained by BitTorrent, Inc.


It's the very same


Kevin Horton/Kevtris is the first person I've seen do an FPGA NES, about eight years ago, with almost complete mapper support no less: http://www.kevtris.org/Projects/console/index.html

If you click through the quaint image map it's actually a fairly detailed description of what he did. Actually, explore his whole site, Kevin was a true emulation scene legend and his projects were all wild.


I agree, his project is very cool. Kevtris is where I got the inspiration to make my own FPGA NES from. I also mentioned him, and linked to his web page, in my blog post.


Sorry, I must confess I skimmed and missed that you gave a shoutout to him. That's way awesome of you and I wasn't trying to detract from your rad project, either. FPGA consoles are totally baller, period.


welcome to HN ludde and thank you for all your projects!


I love projects like this. It's a nice clean way to preserve some old arcade history without trying to find things like, say 27C16 MOS EPROMS that still work.

A group of guys I know did a similar piece of work when creating the Ms Pac Man / Galaga 20th anniversary machine for Namco. They took the original Ms Pac schematic (Z-80 based), a board that looks like this:

http://images.cloud.worthpoint.com/wpimages/images/images1/1...

and shrunk it down to a couple of FPGAs and an EPROM:

http://imgur.com/plzWkSU


Not to be a pedant, but the NES's CPU was actually a Ricoh 2a03 processor, which was a modified MOS 6502 processor. The only difference as far as I can recall, as the author said, is that the Ricoh 2a03 lacks a binary encoded decimal mode, so on initialization you would set this status by calling `CLD` in your initialization of a game.


I'm having a hard time determining what's different in what you said from what the article said? Not trying to snark; I'm genuinely curious.

> The NES contains a Ricoh 2A03 CPU, virtually identical to the MOS 6502 CPU used in Commodore 64, but includes an on chip APU (Audio Processing Unit), while removing some CPU features such as Binary Coded Decimal arithmetic, supposedly to avoid paying patent royalties. Side by side to the CPU is a PPU (Picture Processing Unit), which is responsible for generating a 256x240 sized image.


I updated the article after seeing his remark.


There's a capstone electrical and computer engineering course at my university where the students have to complete a very similar project: http://ece545.com/F12/index.html

The NES is a popular choice, but many other game consoles and computers have been modeled as well


Regarding the mappers:

There's another project called the Powerpak, which is essentially an FPGA programmable flash cart. You can put it in your nintendo, and it will allow you to play nintendo roms stored on a CF card. What might help you about this, I think, is that the mappers are loaded dynamically off the card. So this allows the creator of it to add support for more mappers as time goes by. I don't know if this would help you, but maybe you could use this for your own project as well? After all, if your FPGA nes is the same as a normal nes, then you could use an FPGA flash cart to load all your games. At the very least, maybe looking at the mappers would help you out.

http://www.retrousb.com/product_info.php?products_id=34


I know precious little about hardware stuff and I was curious, how true an emulation does this sort of methodology produce? I remember reading this article (http://arstechnica.com/gaming/2011/08/accuracy-takes-power-o...) about the difficulties inherent in true software emulation and I was wondering if someone out there could relate the two in a way a hardware/emulation newbie could understand.


It's implemented on an FPGA, it's more-or-less recreating the original (digital) hardware. The author pointed out, implementing the original CPU instructions per the spec isn't that challenging. In my 2nd and 3rd year computer engineering courses we implement CPUs which are similar in complexity. Admittedly, getting them to run in hardware versus simulation is a bit of a hurdle sometimes.

The thing is, game designers are all about juicing functionality. If they could take advantage of something that isn't in the spec ( like the extra instructions the author mentions ), they probably did. So you have to find all the common mis-behaviours, some of which might have been side effects of analog components included in the console. Similarly, the analog hardware on your FPGA board is probably nothing like what the original console contained; the sound and video output are hard or impossible to get right.

In short, you can avoid the conditions that they discuss like deadlocks more easily in a VHDL design, but things like the colours in the video may be impossible to get right (the author points this out as well).

On a side note, I don't fully agree with the linked article's 'twice as accurate, twice as slow' hypothesis. A lot of the cases they discuss are either analog effects which are expensive to reproduce in a digital emulator, or just hardware edge cases which don't add a lot of processing overhead. Basically, recreating a quirk can be very expensive or pretty cheap computationally, and there's no reason to say they'll average out over time.


Anyone able to jump in with an explanation of the usage table at the bottom of the article?


It is the repartition of the size of the differents parts of the structure on the fpga.


people interested in this may also be interested in wiz, a high-level 8-bit 6502 / Z80 assembly language and its compiler: https://github.com/Bananattack/wiz


And here I was, thinking I was all awesome for playing Mr Do! with Mame.


I love Mr.Do! Miss playing it in my old Coleco. Oh my, I'm old.


Fucker stole my name.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: