kevtris
-
Content Count
859 -
Joined
-
Last visited
-
Days Won
20
Posts posted by kevtris
-
-
First, that thing is ugly as heck, and second, did he actually finish it?
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.
-
2
-
-
Have any of you seen this based on previous work:
https://github.com/G...ee/master/A2601
Running on hardware from:
Taking existing projects and building on them I think is the way to go.
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.
For carts I think it would need an option to follow theloon's idea of using retrode although I haven't seen costs to that option on the site any ideas?
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 you can succeed with an fpga type design unless its open source - look to the minimig as an example.
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.
-
To clarify raspberry pi proposal - the idea behind my breakout board would be a mass produced board which has the common requirements of an 8-bit computer/console, the purchaser would then customise it with a carrier containing the 8bit + custom chip logic
The reason I mentioned curts flashback design is it is already available yes it would need funding but I don't think that raising the money for reproducing the asic would be that difficult on kickstarter. As I have already mentioned Jeri Ellsworth is apparently sitting on a 150K stockpile of C64DTV lets see some collaboration
Kevtris: Your ideas are great but how much would each unit cost?
Curt: Are you able to use the "Flashback" name for products or is that exclusive to Atari?
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.
-
1
-
-
Nice.
I just recently built a Uzebox, which is a modern 8-bit homebrew system which employs an NES/SNES controller interface, and it's really nice although it could use a few more games. Although they do make USB <-> retro adapters, using USB would just add an entire extra layer of complexity when you can just do two output lines and one input per Nintendo controller with zero configuration. Also, certain controllers simply don't work with USB adapters (VCS Driving, VCS Paddle, NES Zapper, SNES Mouse, etc...).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.
-
Well, now that you claim the 16-bit consoles would require a twice-as-expensive FPGA chip, it kinda makes sense that it may not be possible to do the SNES/Genesis. What about TG-16? Would that be possible with the $40 chip or would you need the larger $80 one? IMO TG-16 is kind of in between 3rd gen and 4th gen, kind of like the 5200 is in between 2nd and 3rd.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).
Also, if the $40 "Cadillac" and $80 "Rolls Royce" FPGA's are mutually compatible, you could possibly do two models, a lite and a deluxe version for people who can afford it. Again, I'm looking into this project mainly as a way to play games for systems that aren't practical for me to own due either to price, space limitations, or scarcity. I also don't plan on buying any more retro consoles for the time being. I've already jacked my bed up on cinder blocks to make extra storage space underneath it for all my game consoles/accessories because my mom doesn't want it cluttering up her house. Someday when my fiance and I get our own place (her current place is a two bedroom), we'll get a larger three bedroom house to ourselves, and she's understanding enough to let me have an entire spare bedroom for games, collectibles, and any other hobby stuff I might have.
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.
I still think cost wise it would be be better to do a hybrid retro console based on something like the raspberry pi with a breakout board and/or the retrode previously mentioned.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.
Curts flashback chip is going to be easier to re-manufacture than a new fpga design.
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.
A empty 8-bit shell which has a slot/carrier for "personality" boards could work
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.
Since this is atariage, I would say emulate the 5 main cartridge based game systems. Could the $40 fpga simulate 2600,5200,7800,xegs, and lynx? Since they are all based on 6502 variants, I would think it would make it easiest to do. The SD card slot would only add 1-2 dollars to add.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.
It wouldn't have nearly the functionality of the harmony. The harmony adds an extra processor, and all that extra ram. This would provide a possible firmware upgrade path, if desired. 4 controller ports would be needed.
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.
-
if you mean something that takes the old chips, yeah, not much market. If you mean a standalone FPGA product, I disagree. I do agree that if you are using the $40 cadillac of FPGAs then you might as well make a system that does everything (and it makes it worth the price point.) But how about something in between, with a more modest FPGA or CPLD (I.e. cheap) that just barely will do the 2600 and only the 2600? There would be a reasonable market if you can get a low- cost system and that's what this thread is about.
I will also share my concern of 100% compatibility - did you do all of the illegal instructions? I mean all 256 opcodes and their behaviors? Most batari Basic games don't work on the FB2 because they missed some that they thought nobody would use.
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.
@kevtris:
All hings aside, I've thought about it and I'm all in favor of an FPGA-based multi-clone project. Atari 2600 to SNES/Genesis and everything in between sounds awesome. I would recommend focusing on the most popular consoles such as Atari 2600, NES, SNES, Genesis, and then adding support for additional consoles in the future. If you make sure that all of the relevant mixing circuits are in place, additional projects could be added in and bugs fixed by contributing programmers.
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.
Be sure to release the design under GPU so people can make changes to it and add features. Then you have a standard build and release it as a parts "kit" or a more expensive pre-assembled option for people who can't solder.
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.
The multiconsole approach is a brilliant idea and an FPGA has the hardware to do the stuff. I recommend using a powerful FPGA even if it costs a little more, for support of the 16-bit consoles. One area I caution you about is the legal gray area of downloading ROMs that you don't own and running them on an emulator. A number of companies have attempted to release handheld emulation devices in the past and gotten into trouble with Nintendo and other companies for posting screenshots of copyrighted games in their adds.
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).
All-in-all, I would buy one of these all-in-one FPGA / Flash cart consoles just for support of the Vectrex library. If you can get the vector screen emulation working well, even if it's just at VGA resolutions, that would be great. I would love to add Vectrex to my video game library but the Vectrex consoles are becoming exceedingly rare and prone to failure. I've seen resellers trying to hock non-working consoles on eBay for $200. Sorry, that's just out of my league. I'm also running out of room for my growing library of consoles, so I feel that an all-in-one FPGA clone would be great for me to sample other game systems that I can't afford or don't have the room for. I'll still probably use the NES for NES games, and ditto for the Atari, but it will be awesome for systems I don't already own.
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.
-
I like this idea. The FPGA ones are interesting, but I suspect there's still something things that aren't 100% - I'd be interested in knowing if the 32 character kernel works correctly or not. If the firmware can be updated by the end user, and it's maintained as well as Stella, then it might not be an issue.
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.
Interesting projects here.
So I've felt that the cheapest way forward is to cannibalize parts from old systems. Save the key 3 chips and transplant them into a fresh board that does everything a piece of vintage gear should do these days.
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.
Yep - Stella emulates it. Hit BACKSPACE.
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.
-
Sounds awesome, but the option to connect it to a real TV would be nice. Do you think it's possible to do a hardware emulation of Vectrex and use an HD frame buffer to output via HDMI? Maybe trace the physical coordinates of the output "beam" into a matrix, taking the speed of the beam and the width of pixels into account when factoring the relative brightness.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.
Also, what type of interface do you plan on running to boot carts? Or are you just storing a ton of ROMs on a storage medium such as flash card (SD, etc...)? Maybe you could come up with a standard protocol to interface with a set of physical adapters based on real cartridge formats. People just pick and choose which cartridge interface adapters they wand to buy if they have real carts laying around
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.
I'm pretty sure that's because of the incomplete player/NUSIZx mid-line changes emulation, which is actually being worked on right now. I appreciate mentioning the cases where it doesn't function the same as Stella; this is testing for us too 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?
kevtris, the chiptunes player looks really cool! Any chance you'll add SID support? I have the Rockbox firmware on my audio player which plays SID's but I would love a chip tune walkman with a real SID chip. 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.
-
Also, THIS dude just made a FPGA based 2600 with Supercharger support
http://www.atariage....emo-unit-video/
Let's make a butt-load of these! Encourage, support and collaborate with people like this!
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.
-
5
-
-
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.
-
2
-
-
I would be interested in test ROMs and/or definitive results on this. Changing Stella to be more random is easy; I just want to make sure it reflects the actual machine.
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)
-
Welcome to the board Kevin.
I posted a picture and some videos of this unit almost 10 years ago.
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.
-
That's a great document. Thanks for posting!
I just had a quick read, but one thing that could also be added would be some info about the 'Super Chip', i.e. F4+SC etc. mappers.
Oh yeah, I knew I forgot something!
-
Well I finally finished my "mega" document on mappers (bankswitching) and various pieces of peripheral hardware.
In it is all the mappers I know about, and the Supercharger, Supercharger demo unit, the tape format for same, and the Compumate.
If there's anything I missed lemme know and I will add it.
-
5
-
-
That was great! Thanks for posting. Any idea of how many demo units exist?
I don't know, but it's probably around 200-300ish. The black plastic box it is in was just a stock project box with a white label stuck on the top. I have only seen two personally. One was broken, and one was working. I fixed the broken one. The problem was one of the EPROMs was bad (something was loose under the window banging around which broke a few of the bond wires). Replaced the EPROM and it worked good.
-
I noticed that there's not much information on the internet about the Supercharger demo unit. There's an old thread about it and a few pictures floating around, but not much else.
Kind of a shame since it's a slightly insane feat of coding. The demo's around 8.5 minutes long and shows off half of the Supercharger game library or so, and even lets you play two of the games for a short time.
I posted a video of it running on my FPGA Atari 2600 (the demo unit, 2600, and Supercharger are all inside the same FPGA).
The entire video's here:
http://www.youtube.com/watch?v=MKEQ0aaYXWQ
A bit of technical background for those that like that sort of thing...
The demo unit's composed of no less than 9 EPROMs (8x 2764 and a 2732), a 6805 CPU (motorola?! heresy!!), and some other miscellanious hardware. It plugs into the joystick port and the 'charger's audio cable plugs into the device.
It first loads a bootstrap through the audio cable, then it uses the joystick port to transfer data 4 bits at a time. It can load an entire 6K block of data in about 1/4th of a second.
-
3
-
-
Wellll I figured it out. The Supercharger does indeed count bus transitions. I have reproduced the Supercharger now on my FPGA hardware and used the stock BIOS to load games.
So the magic is the Supercharger waits 5 bus transitions after accessing 10xx before it will write data to the RAM. Also, the audio input only is read via bit 0 of 1ff9. The other 7 bits must be 0's or else it will not load anything.
I have written up a comprehensive document on how it all works which I will post a link to after I finish the other parts of it. A long overdue comprehensive 2600 mappers document, because nothing of the sort exists except for my very old one.
-
http://www.prismnet..../doc/sctech.txt
And another thing again...:The cycles, be sure your instructions need more cycles than 3
and less than 7, otherwise no value will be stored.
So N is 4..6.
Thanks for the reply! Yeah I saw this document, but I'm still wondering how the Supercharger "knows" what cycle is the one that makes it store the data.
There's two possible ways I can see it doing this:
* Counting CPU cycles by watching address line transitions after the read of F000-F0FF
* Looking for an "out of order" address to be accessed, within N cycles of the read to F000-F0FF
The problem with the first, is if you do not specifically read from where you wish to write at the proper cycle, it will over-write the code that's executing. Not a huge problem- the code's never supposed to do this.
The second one would watch the address lines. During execution, they should continuously increment as code runs. Within N cycles (3-7) of the read of F0xx, and an out of order access, write to the RAM. This has another problem, but I don't think it is an issue. The problem being that you cannot overwrite the next byte of memory, but I'm pretty sure this isn't an issue. Even with self modifying code it's not going to be a problem, because you don't usually write to the next location you're going to execute.
Thinking from a hardware standpoint, it's a tossup as to which is easier to implement on silicon, though the former might be a bit easier.
In either case, it's the Supercharger chip that actually performs the memory write, which I find highly amusing. It has to stuff data onto the bus and hit /WE on the RAM chips during the read cycle to turn it into a write cycle.
-
Hello, everyone. long time viewer, first time poster.
To get right to it, I have some questions about programming the Supercharger. I made an FPGA Atari 2600, and want to add the Supercharger to it. I have disassembled the BIOS for it and read everything I can find on this forum and on google.
I understand most of how it works, except for a few fine points:
To write to the control register (FFF8h) you must first access f0xxh, then FFF8h in the following sequence:
;X = value to write to the control register
lda f000h,x
lda fff8h
So the CPU cycles for this look like so:
(assuming the code is at FF00h)
1 read FF00 (BDh opcode for LDA abs,x)
2 read FF01 (00h address low)
3 read FF02 (F0h address high)
4 read F000,x
5 read FF03 (ADh opcode for LDA)
6 read FF04 (F8h address low)
7 read FF05 (F9h address high)
8 read FFF8
So, to write to the control register, the chip watches for an access to FFxxh, then watches for an access to FFF8h, within N cycles.
The first question is then, what's N? Is it related to the "Delay" value on the control register?
The next question is related to writing data to RAM. It works in a similar fashion to the above, except there's a 5? cycle delay between the two reads. i.e.:
lda f000,x
lda (zeropage),y
The lda(),y instruction takes 5 cycles to execute, so there's at least a 5 cycle delay between reading F0xxh and the read of our desired write location.
I suspect the Supercharger chip actually outputs data at this point to write to the RAM chips themselves, which is somewhat interesting.
While looking through the disassembly, however, I saw some writes to RAM that took 6 cycles, and some that took 5. The writes that take 6 have the following form:
lda f000,x
nop
lda f123
I am trying to figure out how the Supercharger can tell the two apart, and as near as I can tell, it monitors address line transitions. The above code snippet will only have 5 address transitions. The NOP's second cycle reads the NEXT opcode, but throws the byte away, then reads it again for the next LDA. This would result in just 5 bus transitions instead of 6.
How does the delay register affect this? Does it specify a straight transition count? Or is it some kind of delay line that's somewhat analog, relying on an internal RC circuit or something?
Also, how does the Supercharger read the tape audio line? Looking at the code, I'd say it watches FFF9h. They do lots of:
lda fff9
beq offset
So this tells me it returns 0/non-zero depending on the state of the audio input (low/high).
I think that's about it. I understand how to encode the audio so that the Supercharger will eat it and call it good.
Thanks for any help.
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Would you support a crowd funded, brand new, Atari 2600 console?
in Atari 2600
Posted
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.