kevtris

I seem to. I got hardware done already and the user interface and I can make enclosures now, so that's a plus :-) Unfortunately it cannot be a kit in the sense of soldering stuff together, but it could certainly be sold as a PCB with the plastic case parts that you assemble yourself. The electronics are all fine pitch surface mount and little tiny resistors/caps so they can only be effectively soldered by machine in any volume. I hand solder the prototypes and it's on the edge of my soldering skillz to do. I don't know- I was going to give it a shot. It theoretically should since I support the register it uses to reset the H counter. Tonight if I get a chance I will fire the board up and test that and the 32 character test (before it went Harmony) and see if that works, too. I suspect it should since Video Life works OK. That uses a similarish weird method of displaying such a large high rez field. The Robot Tank life counter works too (this can show more than 6 tanks at time) Maybe I will make a video of various "difficult" games running. What's a good list of games? So far I can think of: cosmic ark (starfield) rabbit transit (starfield) 32 char demo video life (odd display mode) extra terrestrials boulderdash demo pitfall 2

I got two arguments against that. First is usually when I do a "collaboration" I'm the only one "collaborating" and the other person/people just kinda hang along for the ride while I do all the work. Second is the hardware and code are already done. There's not much more to do. The basic bits of the entire project are finished. About the only help I'd need is making the enclosure- I can certainly make it but I mean artistic things for when I cut the plastic. The physical mechanics of cutting the plastic and assembling it is no problem. I have that laser cutter. I already have a platform for this based on PIC32 that I am using- I was simply going to port everything over and use it pretty much as-is. If I hadn't designed that stuff in I might've gone for an ARM core instead. You'd have a hard time running harmony cart stuff on the system controller's ARM I think, too. I strive for accuracy and completeness. It's gotta be cycle accurate as possible before I will think about releasing it. I pride myself on regression testing and running everything possible to make sure there's no surprises. All those other FPGA boards you've linked to so far have had several places where their developers weren't very thorough about testing or getting it accurate. I want to avoid this if possible. When I release I strive for 100% accuracy and compatibility. The existing cores I have made, meet those goals as far as I can tell. Yes, I even ran the entire goodNES set and a few hundred personally made dumps of the most obscure games possible and they all work. The 2600 and other cores were tested thoroughly too, but thankfully it was many times easier/faster than goodNES set.

My very first FPGA videogame board I made had two "universal" DB-9 sockets that could accept ANYTHING you could plug in: atari 2600 stuff (everything), genesis, SMS, intellivision 2, and Coleco controllers. I am not sure if I supported vec controllers... I might'a. That design is pretty old now and I would have to try and find my notes on it. Yeah I know about using latches to multiplex stuff... it's just slow and inelegant though. I'd rather get a bigger FPGA with more connections. The bigger packages (physically more pins) don't cost much if any more than the QFP ones so that's good.

Yeah I wouldn't emulate its interface or anything directly, more for the special cases where games have a 3K? chunk of ARM code they can run like that 32 char demo. I already have my own version of a user interface for loading files. I'm basically going for a system + integrated flash/dev/ram cartridge. That eliminates lots of costs (cart ports, bus drivers etc). Yeppers, I have GB support mostly done if I can iron out some timing bugs in the LCD controller interface. I did a few thousand tests on it but a few minor details still remain elusive. The CPU and audio and timers part are all done as well as cart mappers since I can play .GBS files (gameboy music which includes code + data similar to .SID or .SAP files). I can make a "bogo LCD driver" that'd work just fine but wouldn't be exactly timing correct, but I'd rather do it the "right" way and have as close to exact cycle timing as possible. Haha, yeah. I mean I *could* make a system with a giant field of cartridge slots on it but I dunno if anyone would buy it. At last count I think it'd take 12 or so cart slots to run everything I currently support, hehe. 2600, GB/GBC, SMS, GG, intellivision, odyssey^2, supervision, adventure vision, NES, famicom, colecovision, sega SG1000. Yep that's 12 cartridge ports I'd need. Add in a few dozen connectors for controllers and keyboards and it gets slightly out of hand. Again sure it'd be possible to make sure a beast but it'd be huuuuuuge and take up the footprint of an Atari 5200 or so. Honestly I think such a beast would be kinda cool actually but highly impractical. The idea of having plug in doodads with the cart port / controller port is a bit saner but it would cost money to make those since they'd need enclosures and PCBs made and then assembled. There's not much shortcut for that unfortunately. I wished it was "China cheap" to get this stuff made but when you buy that $10 famicom clone from china, it's only 10 bucks because they make a zillion of them so tooling costs get spread over 100K or more units. I *am* going to most definitely use the laser cutter to make my enclosures though, I have what amounts to unlimited use of a laser cutter, so I can use it any time for as much as I want, I just gotta buy materials.

Gotcha. so you're thinking a gut-swap. Yeah I don't think I'd want to do a gut-swap on working vintage equipment. I can make a near limitless array of laser cut cases now that I have unlimited access to one. The benefit of a new case too is it can be smaller than the original. This might not be a big deal to many people but to me it's pretty nice having something real small instead of a huge honkin' thing :-) Yeah that's kinda sorta like my board. I have similar things on my board, though he cheaped out too. It doesn't have a "Real" video DAC, just some resistor ladder stuff. That's the other reason I make my own boards- I put on exactly what I want and tend not to cheap out on things like DACs for video and audio. If you're going 90% of the way, don't cheap out on the last 10% is my thinking. That one's a bit smaller, has PS/2 ports (no USB), a QFP Z80 (guess he was too lazy to make the Z80 on the FPGA or use something from opencores), and a xilinx FPGA. There two PICs on there too, one appears to handle the controllers. Looks like SRAM too for memory so you're probably going to be limited to 256K or less (suspect that's like a 128K and a 128K SRAM or something, can't quite tell). So long story short, it can run stuff with a Z80 and nothing else since one RAM is connected to the Z80 by the looks of things. I was going to be slightly crazy and look into directly emulating a harmony cart on the FPGA. I am not sure how possible this is but I was going to check into it. I support everything else right now including atarivox. The FPGA right now has no less than three CPU cores embedded in it along with the 2600 hardware. a 6502 core, a 6800 core (supercharger demo unit, loading supercharger bin files), and a PIC18F1320 core for atarivox. I support the serial EEPROM part, too, which can be loaded/saved from an SD card. The only thing I don't currently support is the harmony cart. I can easily add stuff like DPC+ but obviously running arm code would be a tad more difficult, hehe. I don't think it's an insurmountable problem however. I just don't know if I will spend the time to do it. The good thing about arm7 is that it'd give me a road to GBA on the FPGA.

What parts? The whole case, a smaller 5200 console, or something else? If it's flat and can be cut out, that's extremely easy to do. cases with depth are made out of 6 or more parts put together. Again, that's easy to do too. The third method is stacking plates cut out of 3mm or similar sheet material. Easy as well but uses up more material.

The 6502 is easily included in the FPGA. There's no benefit to not making it in the FPGA- it's the same number of pins either way (data bus / address bus in vs. data bus / address bus out). The FPGA way also eliminates the need to find 6502's which aren't being made any more. I think WDC still makes 65C02's (or maybe just 65C816's now) but those don't handle the undocumented opcodes the same way. If you wanted more pins you can go BGA on the FPGA- this will net a bunch more IOs but it also is a BGA which is harder to solder than the usual quad flat pack (QFP). I am going to eventually move to BGAs but at the moment I am still using QFPs. The biggest QFP is 240 pins and the same FPGA chip in BGA is 434 balls which is almost 2x as many connections. Lots of those are more IOs (and a bunch of power/grounds too). What kind of peripherals were you thinking, stuff like controller ports and keyboards and cart slots and stuff? If so, it's definitely doable but needs level translation since the FPGA is 3.3V maximum on its IOs and the usual things on the systems are 5V. That brought up another thing I forgot to reply about, re how to read the pots for the paddles (or 5200 analog inputs, etc). To read the pots I would most likely do it like the real system did- charging up a capacitor and monitoring the RC time constant, vs. using an ADC. This way is cheaper and is how the "real" system did it.

Just what's on the webpage. I really need to redo it but it's a huge pain :-)

Yes this'd be true if there was someone to work on it, but it seems like it'd need to be totally retooled, which means a total rewrite from scratch. Yes it can fit into anything, the PCB has to just be made to fit. Making new PCBs, at least for me of an existing thing, is quite simple, a couple day job depending on lots of factors. It would be possible to make some kind of extender doodad with the particular hardware pieces of say an Atari 400 or whathaveyou but that means one for each core. I was going to add expansion but I wasn't going to have something with that much probably. FPGA pins are scarce resources usually. Yeah, that's what's so nice about the FPGA- these can be added to the FPGA itself, so it no longer is required to use "real" chips. I did something like that on my NES core awhile back: I connected my 2600 TIA core to the NES' two square wave channels and the triangle wave (leaving noise/DPCM the same). I then made some recordings of that as I played NES music using the TIA channels. Unlike the TIA's small divider I use the full NES divider so it has a proper pitch range. This was just a 5 minute hack though so it's a bit rough around the edges, and was mainly to prove the point it could be done. Here's some examples of this: http://blog.kevtris.org/blogfiles/nes%20tia/ I quite like the two Faxanadu ones, but most of the others came out fairly decent, too.

Aesthetics aside, yes I did finish it. It has a complete menu and everything built in, so you can select a game using the menu and play it. Also, I built that a long time ago, before easy access to laser cutters, 3D printers and stuff like that. I cared more about the technical challenge than the looks. It's pretty much obsolete now, however, with the advent of my "all in one" FPGA console. Now that I *do* have access to a laser cutter, making eye pleasing casings is much, much easier. Also, that design is all through hole, so it looks massive by today's standards. These days everything I make is nearly 100% surface mount.

A quick perusal of the design shows that it was stripped down past the point of usability: * To load a new game or games into the device, you have to use a JTAG cable and the ISE webpack FPGA dev environment to load a new FPGA fusemap to it and send it the ROMs through JTAG. Why not an SD card slot? * No undocumented opcodes are supported by the 6502 core, so that means many homebrews will fail to function at all or correctly. * The video and audio "DACs" are just R2R resistor ladders which are slow and degrade audio/video quality. To save a buck they went with these crappy "DACs" which give sub-par quality outputs. Check out the screenshots to see how bad the video is. Plenty of bleed and noise in that video. Audio probably is about the same. * The site says that several TIA tricks don't work like the Cosmic Ark "star field" effect and the Supercharger don't work. There's no PAL output either. * Doesn't look like it's been touched since around 2006 according to the blog post. If they were going for the "let's see how cheap we can make a thing that plays some Atari games in as few parts as possible" then they would indeed win a prize. I looked up the Retrode and it costs $85 US. This is about the same as what I was thinking of charging for a base model system, and to use the Retrode, you'd still need a piece of hardware to run the games, and if something like that 2601 was used, a USB chip to interface it. That's all going to add up to lots more money.

Thanks much for this list. I built a similar one but it wasn't this complete. I needed to round up all the Atarivox roms to test my Atarivox emulation on my FPGA 2600.

I don't think it being closed source or open source matters to 99.9% of people buying it. The just want to play games on it. I will not open source my FPGA or microcontroller code, but as I said previously I would provide an SDK for using the board to run your own FPGA stuff. This would allow others to provide open source cores if they wish. As stated previously, I license out my cores already (CPU cores mainly but have licensed others) so they will not be open source. As it stands, it's all modular so it shouldn't be TOO tough for people to drop in other FPGA cores if they want to. You'd basically put it on the SD card and then add it to the system.cfg text file and that's all there is to it.

Yeah the problem with that is a raspberry pi, a breakout board and then plug in boards would cost lots of money. The r-pi is subsidized anyways, so what you can buy it for is not the true cost of making it. Also, as far as I can tell, the chip on it is not buyable. I cannot buy it from digikey or mouser and slap it on a board- It's only available on the r-pi board. My device would be quite small, a single board, and built using parts that can be bought from Digikey (or similar). This means I can buy parts, have boards stuffed, and then sell 'em. It does not require anyone else to produce something for it (re: custom ASICs, r-pi boards, etc). The FPGA chip on the device is designed to simulate MANY different things, and not just pigeon-holed for a single system. There's no breakout boards needed. The work for all 9 systems I listed is *done* already. Those systems are fully done, debugged, and tested, and can be loaded into the FPGA essentially at will. Making a PCB for it is the easy part. The hard part's done already. As for cost, there's very little startup cost to this- everything's off the shelf hardware and no custom ASICs need to be made or designed for it. I can make a new PCB, throw the parts on it, and away we go. The hard part is WHAT it would be, and how much hardware people would want to pay for. A "generic" 2600 with 16Mbytes of RAM, SD card slot, on-screen menu and video out (composite, HDMI/DVI, RGB, s-video, VGA) would cost around $75 in low quantities, or $50 in larger quantities. The PCB would be a bit bigger than a deck of playing cards. Probably 2 controllers only (4 would cost more), and a user port to make controller adapters for "real" controllers. A better system (the kind I would really like to make) would be: all the above, a bigger FPGA, a microcontroller (for loading new FPGA fusemaps) to allow for multiple systems. NES on down as stated earlier. Could also run lots of arcade games. This is in the $150ish range I think, Size is an NES cartridge or a tad bigger. The "best" system is all of the above, with a bigger FPGA yet, and more RAM. This would be enough oomph to emulate the 16 bit consoles (neogeo, genesis, SNES) and lots more arcade machines. This is in the $200-225 range maybe. Size would be the same as the "better" system. The costs are based on maybe 100-200 units, and if more are made the costs can go down quite a bit. 1000 range would be ideal and costs could be brought down I dunno, 30-40%? It's very hard to gauge these things. If I only make 10 of them, cost is of course higher. I just dunno if the market is there for these things. I really would hope it is, but again, no clue.

yeah the problem you run into is that most controllers like SNES ones (what I been using, actually) is the custom connectors on them. Almost all modernish (NES and on, except for genesis) use custom controller connectors of some form. Interfacing to the controllers is usually trivial (snes, N64, etc) but connecting to them is the hard part. Also, most of these controllers are not being made any more. That's why I figured USB would probably be the safest bet: you can use a modern game pad, joystick or what have you (think: mouse + keyboard inputs too for computer simulations or things like the SNES mouse which can be persuaded to work on the NES, or the famicom keyboard). SNES and other controllers can be used with USB adapters that already exist. Unfortunately USB *does* complicate matters slightly but this isn't too big of a speedbump. The other option is bluetooth controllers but that would make it more difficult for things like SNES to USB adapters to work. I think USB is probably about the best since it lets you use all new parts and adapt older controls too. As for allowing every type of 2600 peripheral, I think this is possible but it'd need a special adapter doodad. If I was making this adapter doodad it'd be a bit more general than 2600, too... allowing plugging in 2600, 7800, genesis, intv, or coleco or vectrex controllers to the same 9 pin plug. Might as well spend a little more time to handle all the cases instead of handling the cases piecemeal. I wouldn't include this functionality on the base system because it'd cost more and take up PCB room. My aim is to make the smallest doodad possible, which also makes it suitable for portable-ization by those so inclined. In that arena, smaller is definitely better.

TG-16 isn't possible, simply because of RAM bandwidth. The TG-16 has a 64K VRAM buffer and then the CPU's pretty darn fast, which would kill the bandwidth I have on my SDRAM. I could add more RAM to fix this problem but that would drive costs up. I would like to support it but it almost needs the bigger FPGA (more blockram which can handle the VRAM part without added RAM chips). Yes, the two FPGAs are compatible in the fact both could be put on the same circuit board mutually exclusive. I would most likely design the board for the extra RAM and all that, but just not populate the RAM and use the cheaper FPGA. This doesn't really cost much of anything extra and cuts down costs to get things made, since the same solder paste templates and board are used for both versions. The compiler (I use Quartus II) has built in support for upgrade/downgrade paths on the same PCB footprint. That will cost quite a bit more and be larger and clunkier. It'd be a collection of boards plugged together with cables, vs. a small PCB with everything on it, ready to go. An ASIC run costs tens of thousands of dollars or more to even get started (Probably close to 50-60K). An FPGA design costs nothing to tool up. Of course the per unit cost of an ASIC is cheaper than an FPGA, but then you have to buy 10K or more pieces (really 50-100K to get any kind of low cost per unit). The other drawback, is if there's a bug it cannot be fixed without spending another $50K. FPGAs on the other hand, are ideal for smaller runs, like what you would have on a "retro" console like this. The other benefit of the FPGA is (At least in my design) the FPGA configuration files sit on an SD card, and you can get instant upgrades or even MORE consoles by adding/changing a few files on the SD card. Every time a new console is added, one simply drops the new file on the card and away you go. This is basically what an FPGA is. It's a "blank" chip that can be programmed and reprogrammed nearly instantly to simulate nearly anything made of digital logic. Yes it can do this. Lynx is actually one of the major targets for my board I wanted to add next. For an example of size, the 2600 project takes up about 15-20% of the FPGA core, while NES (and its freight train of mappers and sound hardware) is around 90%. Odyssey^2 is a lightweight, around 30% with the speech chip stuff. Not true. Most of these designs DO have a second CPU in them as a controller. I tend to make a "65C02 microcontroller" which is a 65C02 core + 4K or so of RAM/ROM. This then operates things like data loading, or interfacing. So far it has worked very well. I also have made an 18 bit CPU called the "kevrisc" which is an optimized RISC core CPU. I expect full on screen menus and popup menus and such for this project. Right now, I have 16Mbytes of SDRAM on board that the games are loaded into. This is a basically unlimited amount of memory, especially for things like 2600. As for controllers, I was going to go for 2 USB controller ports, or 4 for slightly more money. I may keep the expansion port on the back to allow plugging in "real" controllers via adapter cables.

Yeah, I think the cheapest I could make it is to use that $12 cyclone 3 chip, some level translators, throw on a 2600 cart socket, and a DAC and call 'er a day. It could be fairly cheap, maybe a $75 price point? maybe less if quantity was higher... possibly as cheap as 50 bucks or so. Size would be the size of a deck of playing cards, or smaller if I go with a 2 sided loadout on the PCB. My 6502/6507 core is 100% exact. I support every single instruction including all the esoteric ones, all 256 opcodes are available for use. I have done extensive testing between my 6502 core and a real 6502. It's a perfect FPGA clone of the 6502, or as close as you can get. cycle timings are exactly the same as a real one, too. I *did* turn the "jam" opcodes into NOPs but I could just as easily make them lock the CPU up like on a real one. It's possible my 2600 core is not 100% exact, but I have run literally every single ROM in existence (that I have or could find, including all games, demos, protos and works in progress and test ROMs) and they all work as expected. I ran all the games on Bankzilla and did A/B tests side by side with two monitors and it was the same. I am not sure what more testing I can do. I also wrote several custom test ROMs and hooked my logic analyzer up to my 2600 to make sure things were kosher and the signals on the 2600's bus matched my FPGA (using signaltap) and they do down to the nanosecond pretty much. I put a lot of effort into the design to make sure it was as close of a match as possible. It's written in 100% verilog and I used all original code, from the CPU core to the TIA and RIOT. Video's generated in RGB and then converted to NTSC (and PAL) via more verilog, so that I can output RGB, straight composite, s-video, and component using the same 3 channel DAC. This video encoding core is one I created specifically for these FPGA projects. Yeah I already have a huge list of consoles so that's good. SNES/genesis aren't possible on the current hardware iteration and I am not sure I would sell one right away with the required FPGA since it'd cost $80 for the chip which is harder to swallow than $40, but it's possible I might be able to get a deal on it from Altera... not sure yet. I will not open my FPGA cores probably, but I *will* allow easy integration if people want to write their own, and will include an SDK for doing just this. I cannot release my cores since I have licensed the CPU and several other sub-cores in my designs. I have used them to remake older projects where the parts have gone end of life (EOL). Be that as it may, it will be easy for anyone to make their own core for playing anything they want, like arcade machines. I have not added any arcade machines simply since the bang for the buck is kinda low (game quantity vs. making the project) compared to something like the 2600. I cannot offer it as a kit, either. All that fine pitch SMD components are very hard to kit up, and even harder for someone to solder that's used to through hole. It'll be much cheaper to have the boards assembled, and then tested. Lots less frustration for the users, too IMO. Also, most of the chips have epads on the bottom that must be soldered, and doing those without a proper solder stencil and stuff is hairy on a good day. Hmm, that's interesting. Didn't know that, thanks for the heads up. (and yeah I figured if I'm going to do this, it's go big or go home. lol. I made the bankzilla "all in one" atari 2600 monster back in 1995-96, and this is the multiconsole version of it). Yes, you hit the nail on the head as to a big reason why I am doing this. Having this little tiny box sitting on the TV instead of a couple closets worth of games and consoles that are bordering on geriatric is one of my big driving factors here. I like the consoles but they are getting old, don't work as well as they used to, and frankly take up quite a big chunk of space in my house. Being able to exactly recreate the look and feel of them using new parts I can buy from Digikey or <insert electronic part company here> is very appealing to me. To show an example of how fanatical I was about accuracy, my NES core video output is an EXACT copy of a real NES' video output, to the voltage levels. I did some A/B tests on the same monitor with a video switcher, one connected to a real NES, the other to my FPGA and ran the same game on both, and reset the two at the same time. Switching back and forth you could not tell any difference. Even the information in the overscan and hblank/vblanks are identical! I really did get it down to the pixel, and then voltage level. I take pride in exactly recreating not only the hardware, but the same voltage levels and stuff that exists on the original hardware. I went through the same trouble for my 2600 core and the other cores I have done so far.

Yes, I will give it a try next time i have the hardware running (I have it set aside while I finish this synth). I suspect it will work, though. I have tried absolutely everything else and it works good. I could easily make a "new 2600" board in a few hours but I don't think there's much of a market for that. Ditto with any other classic console up to SNES or so. I've been reproducing them in the FPGA on a single "standard" board, however instead. The board looks like this: I designed it originally to fit inside an NES cartridge case for the box since it'd be small and kind of amusing, but I have since abandoned that and will go with a laser cut one on the final iteration. It's a custom design, specifically for the purpose and is not one of those usual dev boards. The connector on the back (13 pin DIN) is designed to accept real controllers via an adapter for any system (got NES, SNES, and a few others right now) A 1541 or similar could even be plugged in with an adapter for C64. How does the "frying" work? I suspected it had to do with the RIOT and CPU resets not being concurrent, since both seem to be generated separately. So something like a game's clear routine wouldn't get to function properly. Other than that, I am not too sure about how it works without doing some testing. I never got to it when I had the 2600 under the microscope awhile back. If anyone wanted to see video of this doodad running the various systems, I have a bunch of youtube videos up, viewable on my channel. https://www.youtube.com/user/kevtris?feature=mhee

Yes, I was going to have the option for TV output via RGB, composite, HDMI/DVI or component. As for how the Vec emulation worked, I was going to do a proper vector screen "emulation" like that. As for resolution, I won't output 1080 because of the bandwidth, but it shouldn't be an issue, the TV should have no problem upscaling what I output. Yes, microSD cards and an on-screen menu interface is how it works. I cannot include cartridge connectors for several reasons: one, I already run 9 consoles, so the sheer quantity of connectors would be insane. and two, ROMs are plenty good enough for it. Also, since I keep adding new stuff, I would have to keep making more and more connectors to plug into it. The final problem is many of the connectors are proprietary. You cannot go to the store (or Digikey, etc) and buy Super Nintendo connectors, or gameboy connectors, or Adventure Vision connectors (let alone an adventurevision cart!) So there's that. Even for systems like the 2600 with a standard connector, you almost need some kind of enclosure to open the shutter on them. The final problem is the sheer number of connections for say, NES (60 or so are needed) and then level translation between the 5V cartridges and 3.3V logic of the FPGA. Oh, so THAT is how they did that. I couldn't quite figure it out, other than it worked or didn't. Are there other games that do that? Thanks! Well I have an older chiptune "walkman" I made earlier that has quad SID emulation along with analog filters I made to emulate the filter in hardware. The current synth that I showed a picture of could do SID easily but needs filter emulation on the FPGA somehow, which I'd have to look into. I would really like to support SID though. The older synth supports: .SID (C64 SID) stereo, but there are actually 4 SIDs emulated at once .NSF (my NES/Famicom music) normal APU, N106, VRC6, VRC7, MMC5, FDS, Sunsoft 5B extended audio support .SAP (Atari 8 bit music) all SAP files were tested, 4 POKEYs are emulated .GBS (Gameboy sound) most GSB files worked, I found many that didn't due to bad rips. lots of those got fixed. .SGC (My SMS/Game Gear/Coleco sound file format) supports FM on SMS (YM2413) .CMF (creative music format, kinda midi like) for OPL2 .KSM (ken's labyrinth music), for OPL2 .D00 (Vibrants player) for OPL2 .WLF/apogree/ID (generic ID games music format, Wolf3D, commander keen, etc) for OPL2 .RAW (raw FM format) for OPL2 and OPL3 This current, newer one will support all of those and SPC out of the box, though SID might not have filters at first. The current one will have the following sound chips under MIDI control: (all chips are done and fully debugged/tested) NES APU, N106, VRC6, VRC7, MMC5, FDS, sunsoft 5B 4x POKEY 8x TIA channels, with full tonal range or limited "2600" range 4x SID (not sure of filters yet) generic OPL2 / OPL3 FM Gameboy sound channels 4x AY-3-8910 4x SN76489 SP0256-AL2 (speech synthesis) Again, all of these are done and tested and working 100%. I already have implemented them on various things so it's a simple matter of dropping them in.

Yes, that's mine :-) After the current project, I was going to work on a portable classic videogame system, with HDMI and composite / RGB output options. The Atari 2600 console is 100% complete and extremely accurate. I did side by side testing with every single game on the Bankzilla which is a good 90% of them. I played it on my FPGA system and the real 2600 and compared to make sure it looked and played the same. That took a long time. Supercharger support is 100% along with the demo unit, and every mapper works (bankswitch method), even DPC. I could maybe add DPC+ but no one has used it that I know of. The Compumate was added too, and atarivox can be done ON CHIP using the PIC18F core I have made. I have also made a SP0256-AL2 core which runs all the various versions of this chip (SP0256-012 in the Intellivoice, SP0256-019 + ROMs in the Odyssey The Voice, and many other non videogame chips). I daresay my FPGA 2600 is even a tad more accurate than Stella, at least on one game (Snoopy and the Red Barron- the bottom "mesas" aren't quite right in Stella compared to a real 2600). I tested all of the demos on Pouet.net for 2600 which all work flawless, too. Every homebrew I can stuff into it has worked, including all the esoteric tricks like the starfield effect and more than 6 players in a row. I used the TIA chip schematics and extensive testing on a logic analyzer with a bunch of home-made test ROMs to flush out all the esoteric edge cases to make sure accuracy was top notch. The only thing it doesn't support is paddles, but that is because I was lazy and didn't have an analog input device yet. Paddles can be added in about 5-10 minutes when I feel the need to add 'em. Atari 2600 is only the tiny tip of the iceberg, though. I set my sights much, much higher. The eventual goal is to have EVERY classic console up to the end of the 16 bit era in this box by the time I'm done. I've got a pretty good cross-section already. I want to add computers and will, but that ugly thing called a disk drive is a stopping point so far, hehe. As for the other consoles it currently runs: * NES/Famicom - 99.9% (this can never be 100%) all mappers supported, all sound chips, all games work flawless. 205 mappers supported currently * Atari 2600 100% (as previously stated) * Odyssey^2 100% + "The Voice" (I performed a reverse engineer on the video chip for this). all games run flawless * Intellivision 100% + "Intellivoice" + computer adapter (I performed reverse engineering of the STIC to do this) all games run flawless * Adventure Vision 100% - all 4 games run perfectly. spinning mirror + LED emulation. sound CPU 100% emulated * SMS/Game Gear 100% - all games run, test ROMs work perfect. YM2413 FM chip fully emulated * Colecovision 100% - all games run, including my special Coleco multicart ROM image. TMS9918a was logic analyzed and reverse engineered * Supervision 100% - all games run, sound works. I performed a 100% reverse engineering job from bare console and 1 cartridge. * Realtime mandelbrot/julia set renderer allowing full pan/zoom/adjust in real time. * Super Nintendo SPC music playing - plays SPC files with a visualizer if you like chiptunes. * Full OPL2/ OPL3 FM cores are done and were used for chiptune playing. Not finished: * Gameboy - 90% - audio + CPU done and working, video works but am still reverse engineering exact video rendering details * C64 - 90% - SID + CPU + CIAs + partial VIC done and working - used to play SID files right now, could make a full C64 in a few days slated to be added: * Atari 7800 (I have Maria schematics, and reverse engineered most of it. easy to add to existing 2600 module) * Atari 5200 (no work on ANTIC done yet, but I checked it out) * Atari Lynx (LCD isn't the best, and I would like to be able to sit back and play. implementation looks "interesting".) * Vectrex (yes, full vector CRT emulation on the FPGA. this is quite easy and not as bad as it sounds. probably will use RGB to output XYZ for oscilloscopes) * Channel F (not too hard by the looks of it, but I dunno if I will bother yet) * Videobrain (if I do channel F I will do this. I got 20 sets of the Videobrain ASICs for a few bucks, brand new so I can reverse engineer these) * Astrocade (extremely easy to add, just been lazy and haven't. I have most of the parts for this done already) in the future, but would need a larger FPGA: * SNES (already have the sound done!) * Genesis (extremely easy, once I make a 68000 core) * Neogeo (extremely easy, again need that 68K) * TG-16 (seems moderately difficult, but not terrible... could add it) * Super A'can (needs 68K, I already have the 65C02 core, and I have several super a'cans with carts for reverse engineering) As for pricing, I don't know. The FPGA costs $40 by itself, and the rest of the parts are fairly cheap, but it'd be about $250 to make I think after the LCD and battery and the circuit board and the other parts it would need. I am not sure if $250 is too much or not. I would package it in a clear plexiglass box that I make on the laser cutter, however so it should look pretty nice. The current project I'm working on is an FPGA music synthesizer that plays chiptunes (SPC, NSF, etc) and MIDI synthesizer for playing chiptunes thru MIDI, kinda like a super duper bank of chips in a box. It looks like this: The pictures don't do it justice, it's very sexay, and the pieces line up very nice and smooth. The sides aren't rough like it looks in the last picture. The portable console idea will be built using a similar design most likely, only with a different configuration of course. Most likely D pad on the left, buttons on the right and maybe some top buttons, sorta kinda Lynx-like and about the same size or even a bit smaller than the Lynx 2.

I finished the project long ago. I ended up writing another Supercharger Demo Unit ROM that actually loads the regular tape games into the simulated supercharger. Figured I already had the supercharger demo unit working, so I could just re-use that part of the project. The regular tape games are simply loaded into the address space where the Demo ROMs went, and I made a new "bios" ROM for the simulated demo unit that can load in the various loads of the multiload game (if needed) and "Rewind" the tape if need be. I thought about being smart about it and snooping the 2600's bus to figure out when the game called the SC BIOS' tape load routine again to auto-load the next load of a multiload tape but didn't get that far yet. I may yet add that. Right now you just get to play the next load or rewind to the first one.

Note that some demos like Tricade seem to rely on Stella booting in a specific bank and Harmony in the other (hence the two ROMs, AFAICT). In other words, you might want to disable such randomness for certain specific ROMs. If I were you I'd spider the VCS prods on pouet to automatically add all their MD5s to an exemption list (the F8 ones at least). I investigated this. The tricade and doctor ROMs come in two kinds: the "emulator" and "Real" versions. BOTH versions rely on the ROMs starting up in bank 1. If you start up in bank 0, the demo starts halfway through. I diff'd the two "doctor" ROMs ("emulator" and "real") and the only difference is which address is read in bank 1 to get into bank 0. The "emulator" version reads FFF8, and the "Real" version reads FFF9. Kinda interesting that the "Real" version should not work at all since it's already in bank 1, and will just result in it selecting bank 1 again then crashing. That 1 byte is the only difference between the two ROMs. When the demo switches to bank 0, it starts executing garbage code too before the actual demo code runs. I guess they got it running and didn't investigate why it ran.

Well I updated the things mentioned so far, except for the A450 and DPC+ stuff since I have not implemented them yet into my FPGA 2600. I updated the Compumate stuff, and you're right. I looked at the schematic of it I drew out and RAM's at 1800-1FFF. There's a huge chain of NAND gates used to generate its chip enable and I got 1 extra inversion in there. I can document the Gameline modem, too... but I am wonder how useful this would be. I own several and have one taken apart, and I dumped the ROM on it awhile back. I also have VHS footage somewhere of the menu and it loading and running games. Oh yeah, I should add information on how the atarivox works too. Also, does anyone have ROM images I can use to test some of these homebrew mappers? I want to make sure my FPGA implementations work, and to verify my documentation is correct. I need examples for the following: 0840 econobanking MC megacart X07 Atariage 4A50 DPC+ I will update the posted version after I add a few more things.

thanks for the welcome! Yeah, it might be runnable on there. I posted full hardware documents in the programming forum if someone wanted to give it a shot. (it's in the mappers doc)

Thanks for the welcome :-) Yeah I did run across that picture and video set in my travels, but there was no video of it up on youtube. Heck, there's not very many Supercharger videos to speak of at all. Speaking (hehe) of videos, are there any videos or MP3s of what the atarivox sounds like while playing some of the newer homebrews like Strat-o-gems or Go Fish? Also if anyone wants some videos posted on youtube of some 2600 stuff lemme know, I can run it on my FPGA and capture it and post it. I can run literally anything at this point other than Compumate and I'm working on getting that going too.