• Content count

  • Joined

  • Last visited

  • Days Won


Everything posted by james1095

  1. Ultra Tank

    I have limited visibility into how the 6502 code works, but VBlank is read by the CPU and with that disconnected the game hangs after drawing the playfield boundary and connecting it to other signals causes the whole game to run much faster so I can make an educated guess as to what it's used for. I'm sure I can figure it out, I just haven't put much effort into that particular issue yet since I had bigger fish to fry. Now that everything is implemented and the game is more or less playable I'll spend some time tying up loose ends over the weekend. One of these days I'll get around to porting this stuff to the Papilio if nobody else does. I've just grown to like working with Quartus better overall than ISE and it's much faster to compile for these little Cyclone II FPGAs I'm using, the bigger/newer chips take noticeably longer. It sure would be nice if ISE could load standard hex files into internal block memory elements the way Quartus does.
  2. Ultra Tank

    After weeks of banging my head against the wall this is coming along again. Motion objects are finally working so I implemented the collision detection and audio circuitry. I think all I need to do now is finish the player input so the game can actually be played, and then figure out why the game timer is ticking down too fast and do some general cleanup of the code. The input circuitry is a little more complex on this because they used an analog multiplexing scheme to read two joystick switches over a single wire, something that doesn't make sense to do with an FPGA that has plenty of IO and no analog. I'm not sure why this was done but I suspect they wanted to use the same harness connector and RFI filter board as their other games. I'll try to wrap this up sometime in the next week or two and then I'll post the code and start working on Sprint 4. ultratank
  3. Centipede

    I came across a release of the original arcade game Centipede by a guy named Brad Parker. It was written for the Pipistrello board and is in Verilog which is not my thing but with much effort I was able to get it running on the Papilio One board. There are a couple of bugs remaining: -- Audio is not working -- Motion objects visible in the top row where the scores are displayed, these should not be there -- When using joystick control, player 2 fire is still on player 1 joystick -- Colors don't match those in MAME, currently not sure if this is correct -- Self test causes game to freeze, may be related to vblank signal which is fed into latch K9, used in self test -- Reset doesn't actually reset the game The audio is the most serious issue, I cannot figure out why it isn't working but maybe getting another pair of eyes on the code will fix that. I've set it up to use joysticks for now but it should be straightforward to connect an arcade trackball. Original (Pipistrello) release: https://github.com/lisper/arcade-centipede If someone has a Pipistrello board and can see if any of these issues occur on that I would be interested in hearing the results. Attached is the code I've been working on, if you toss the MAME ROMs in there and run the build roms batch, it should just compile. It's currently set up for a Papilio One 500k with Arcade Megawing but it should be easy to port it to other platforms. Hopefully with a bit of polish this can get into the Papilio Arcade collection, things have been a bit stagnant on that front, I don't think any new games have been added in years. If someone has an original Centipede machine it would be great to get a comparison of the colors. I have a real board but don't have the connector I need to hook it up to a monitor at the moment. Centipede_P1.zip
  4. Ultra Tank

    Ok I see what happened, the image was missing the extension for some reason so it wasn't being recognized as an image. Should be fixed now. Last night I did some more work on this, I think all the player controls are working now but there's still the issue with the timer running too fast which needs investigation. I believe this is dependent on the VBlank signal which is read by the CPU so I'll look at the timing and see if I can figure out what's going on.
  5. Sprint 2

    Here's my source for Sprint 1 and Sprint 2. I think these are in pretty good shape now, both work great, the sound is pretty good, I haven't found any remaining bugs. A really sharp observer may notice two of the cars in Sprint 1 are gray like in Sprint 2, I have since fixed that bug so all three drone cares are black. Sprint2.zip Sprint1.zip
  6. Sprint 2

    Having wrapped up Super Breakout I focused on Sprint 2 and have that running now, I still need to implement the audio and do some testing but the game seems to be working fine. The photo doesn't really do it justice, there is a lot of moire distortion which is only an artifact of the camera interacting with the scan lines on the CRT. The cars are moving quickly so they appear blurry in the photo but everything looks good in person. These old games are small, Sprint 2 would fit easily in a P1 250k with room to spare. I'll share the code when I'm finished, or if I get tired of working on it and stall.
  7. Sprint 2

    I have the audio working now and everything is pretty much done, I do need to tweak some of the values that control the engine sound frequency but otherwise it's ready to go. I also did Sprint 1 because the hardware is almost identical. I'll post the code here soon in case anyone else wants to play with it, I have not had time to port it to the Papilio, been too busy working on more games but that should be simple, other than the ROMs and RAM the code should be platform-agnostic. The biggest challenge with actually playing the Sprint games is the controls, you need some sort of steering wheel with an optical encoder, ideally 36 pulse per revolution. You also need a gear shift, this has 3 switches for 1st, 2nd and 3rd gear, open circuit selects 4th. Super Bug is one that I considered doing at some point, the hardware is a bit different on that though, 6800 based and more closely related to Fire Truck which is another game I'd like to make. For now I'm working on some other 6502 based games, Ultra Tank first and from that I can derive Sprint 4 which is one of the first games to have color. I'm also looking at Atari Football which has an interesting scrolling playfield. Later perhaps Missile Command, it uses relatively simple hardware though it will probably require external RAM.
  8. Super Breakout preview

    This is now complete and working, source is attached. Currently this is targeted for an Altera EP2C5T144C8 mini board but porting it to the Papilio should be very easy, doing so is on my list of things to do but I think I'll take a break after debugging the last few issues with this. All it should really take is replacing the Altera PLL with a Xilinx DCM and replacing the ROMs with something Xilinx compatible. Several of them are only 4 bits wide and it seems like Romgen doesn't support that but I'm sure it could be modified. Also I intend to replace the sync and address decoder PROMs with combinatorial logic since they're such small devices that it's a bit pointless to use ROM for that application these days. For the control input I'm using one of these https://www.ebay.com/itm/new-incremental-optical-rotary-encoder-600-pulses-line-AB-two-phase-5-24V/272391186094 but if you prefer to use a pot as originally used in the game, duplicate the ramp generator and analog comparator from the the schematic in the Super Breakout manual. I've already designated some pins for that purpose and included a second paddle interface file to substitute for the one that interfaces to the encoder. To make it really authentic, some strips of colored lighting gels could be stuck to a B&W CRT as was done in the original game, or the color could be added with a bit of additional code was was done with the FPGA implementation of Space Invaders. If one wishes to use a VGA monitor instead of the original composite type, the scan doubler from Space Invaders could also be added easily enough. Super_Breakout.zip
  9. Super Breakout preview

    I've been tinkering away, working on implementing the bronze age Atari arcade game Super Breakout in VHDL. Just thought I'd show off the playfield generation subsystem which I've successfully got displaying random data I loaded in the video RAM for testing purposes. What this shows is that the video sync circuitry, playfield generator and video RAM are all working properly, next step is to add the CPU and IO subsystems. In hopes of inspiring others to implement other games, I've shared the tested working VHDL for the sync and playfield circuitry, these are used in quite a few games of that era with only minor changes needed from game to game. I've been using an Altera FPGA for development but this code should be platform agnostic, just use romgen to create ROM images. I've got a version of the sync PROM written as combinatorial logic that I'll share once I verify that the result is identical. playfield.vhd sync.vhd
  10. Super Breakout preview

    Setting up the tools is trivial compared to the actual work of recreating a game from start to finish, for anyone with access to broadband I'm not sure why this is even an issue. Super Breakout is one of the simplest arcade games I could find hardware-wise and it still has taken me tens of hours to write and debug the code but much of that time was spent wrapping my brain around how the original circuit works. There are a couple of critical aspects I took into mind when starting this out, one of which was that the manual is available with a nice clear schematic, many classic games have hand drawn schematics that are nearly illegible. In addition to the schematic, the manual had a rather good theory of operation that I was able to read to gain a deeper understanding of how the hardware works. The next criteria was that no complex ICs are used that aren't already available in HDL. In the case of Super Breakout, the 6502 microprocessor is the only such IC and the well known T65 core covers that. As far as the actual process it was just a matter of sitting down with the schematic and writing VHDL to model the various portions of the circuit and then connecting everything together in the top level file. Anyone who is curious can look at the sync generator and playfield generator code I attached to my initial post. In addition to that there is the motion object generator, CPU/memory subsystem, sound, and I/O blocks. Changing text that appears in the game is actually not trivial because it is written to the screen by the program code which was written and assembled by Atari. From a hardware standpoint the Super Breakout playfield is a matrix of 32x28 cells and displaying something in one of those cells - say the letter "B" or part of a brick is a matter of writing the byte code corresponding to the desired character into the location in RAM representing the cell you wish to display it in. The original hardware multiplexes the RAM between the CPU and display subsystem according to the state of the Phi 2 clock but I simplified things somewhat by using a dual-ported RAM instead as it's already available in the FPGA anyway. The end result is exactly the same, but I don't have to care whether the fact that the CPU is not quite cycle-accurate affects critical timing. Now having a solid understanding of how the hardware works, someone who knows 6502 assembly (I don't) could write a new game to run on the existing hardware, or even modify the hardware (since it's defined by VHDL) to change or expand its capabilities any way they wanted. For example you could copy/paste the motion object generation to add the ability to display more than 3 balls if you wanted, or you could add color, or better sound effects or anything you can think of. It would also be easy to use the video subsystems with a completely different processor since it's just a matter of writing to locations in RAM which has a port that is entirely independent of the one used by the video hardware to generate the display. Hack, slash and experiment all you want without damaging or altering original vintage hardware. I've made the code as modular as possible and I've tried to comment it sufficiently and keep it similar enough to the original design that someone can reasonably follow the schematic for Super Breakout and see what is going on in the VHDL. Given similarities from one game to another, my hope is that more and more games can be created, reusing bits and pieces, for example Sprint 2 uses exactly the same sync circuitry as Super Breakout, the playfield generator is nearly identical, the CPU/RAM/ROM is extremely similar, the motion object circuit is similar, just expanded upon. Even newer Atari games like Centipede use a similar architecture, nearly identical sync circuit, same CPU, when you start looking at schematics you start to see common themes. That shouldn't come as much of a surprise really, if you were trying to get a new game out quickly there's no sense in reinventing the wheel if an existing circuit block already does what you need.
  11. Super Breakout preview

    Further progress has been made and at this point the game is working and playable. I fixed a problem with the RAM write enable which fixed the missing border section and some other weirdness. I added some code to use an optical encoder to control the paddle rather than the potentiometer originally used. If one wanted to use a pot instead it's fairly trivial but would require an external comparator, a transistor and a few passives, I've tried to make this change as simple as possible in the code. All that remains is to polish up the code that handles the configuration dip switches and then do a bit of general tidying to make it fit for public consumption and then I'll post it. I'm actually using a small Altera board for this as I've grown to prefer Quartus over ISE but it should be trivial to port to the Papilio, I've made everything as platform-agnostic as possible. Yeah the bronze age games are primitive compared to the golden age classics but a lot of the heritage is clearly visible in later games, both from a hardware and gameplay standpoint so they are of historical significance. There is also something I find pleasing about the soft glow of a B&W CRT though I've used a small TFT monitor for much of the development simply for reasons of convenience. The thing that attracted me to Super Breakout aside from the game being relatively fun is that the hardware is very simple, the schematic is legible and the theory of operation in the manual is quite good. It's simple enough to be fairly easy to understand how it all works yet complex enough that a lot of the concepts can be carried over into newer games. Another advantage of these early games is that they will fit entirely in very small and inexpensive FPGAs which are much faster to compile for than bigger more capable parts. In between things I've also done some work on Sprint 2 and I have the playfield displaying. This means not only that the playfield generation circuit is working but the CPU is executing the code from the program ROMs and writing something sensible to the video RAM so that's the next one in the queue.
  12. Super Breakout preview

    Just an update, significant progress has been made. Over the weekend I finished up the CPU section and for the first time I got a recognizable screen for the attract mode, that's when I took the attached picture. Over the last couple evenings I've debugged the motion object generator so the balls are working and I'm able to coin up and start the game, woohoo! Fixed a few more bugs, sound works, outputs for the start button lamps and serve button LED are working. The only major part still missing is the paddle control and I've started on that, the plan is to use an encoder rather than a pot like the original so I can avoid adding external circuitry but it will be easy to connect the original pot circuitry. Then I need to finish the configuration dip switches, figure out why one block is missing out of the left border and code the watchdog timer just for completeness and then I'll post the code. This is all rather exciting as I've had a goal for a long time to recreate an arcade game rather than just porting other people's code. Next up I'll get to work on other games that use very similar hardware. Watch this space for Sprint 2, also considering Sprint 1, Atari Football, Fire Truck and other bronze age classics. If anyone has a particular game of that era that you remember liking feel free to share and I'll take it into consideration. There is a lot of collector focus on the 80s golden age games but there are some classics from the 70s B&W era that I think are under appreciated.
  13. Download Error YAVGA

    It's archived on wayback, I was able to download the source today. https://web.archive.org/web/20131110085527/http://gadgetforge.gadgetfactory.net/gf/download/frsrelease/156/524/YAVGA_Source_1.0.zip
  14. Help with Hamster Book tutorial (newbie stupid question inside)

    That's a math question rather than an FPGA question. I know that I've found read-made sine tables out there before, if math is not your thing you can probably find one already made. Another option is to just make something up using ballpark values, you don't even have to make it a sine wave, you can use the DAC to generate any arbitrary waveform you want.
  15. Computer Space

    I haven't tried this yet but it looks like it should be straightforward to port it to any of the Papilio boards. http://forums.arcade-museum.com/showthread.php?t=364662
  16. Computer Space

    I never saw one either, even today I've never seen one in person, I don't think many were made and they were old news by the time I was born. It's not exactly the greatest game but it is *the first* ever coin-op video game, it came before Pong which is widely considered the first *successful* video game but not actually the first. I haven't looked at the size of the ROM but it may fit into block memory, at least part of it. I think the best long term solution is to synthesize the sounds in HDL, I know it can be done, Asteroids, Galaxian and Space Invaders all have analog sound circuits that have been synthesized in VHDL. The schematics are hand drawn and difficult to read but it looks like the thrust sound from Asteroids could be borrowed with minimal changes and the missile sounds are not all that complex. I was able to get Computer Space running on the Cyclone II mini board I was playing with so I'll try to find time to port it to the Papilio, it should be pretty trivial. You only need two resistors to get composite video and then some buttons for the controls so it's easy to rig up even without a wing. I used a small B&W portable TV set and it looked pretty good. I think it's cool that the original game used an off the shelf B&W TV set old enough that it used vacuum tubes.
  17. There are a couple of things that bit me early on. One was a bad USB cable, brand new out of the box it had an intermittent connection. Others I've run across have insufficient current carrying capacity on the power supply lines, this can cause all sorts of weird issues. Some USB ports are inadequate in that regard as well, the Papilio pulls a fair amount of juice and can't tolerate a lot of voltage sag. The other issue I had was with programming bitfiles into the configuration ROM. You have to remember to erase the ROM first before you load a new bitfile. That shouldn't affect loading directly into the FPGA though.
  18. Back to Basics

    That's a good point. I use the Logicstart megawing quite a bit but I do wish it had a microSD card slot instead of the ADC which I've never used. If it did though someone else would be wishing it had an ADC instead of a micro SD slot. The individual wings are perhaps more versatile, however for stuff that simple I tend to just breadboard it or use various little breakout modules from China and connect them with jumper leads. I suppose what that comes down to is it's just really hard to compete with China.
  19. Back to Basics

    Taking ISE out of the loop would make the whole thing pointless though. It's an FPGA, it's never going to be *as simple* as an Arduino, the complexity is part of what makes it so powerful. There could never be enough pre-compiled bitfiles to support even a fraction of the projects out there and it would end up just another MIST/Minimig/Chameleon/Replay etc. Trying to bypass the entire development process would bypass the whole point of using an FPGA and prevent even more people from taking the time to learn. Sure ISE is not the most user friendly software out there but you have to remember that it's a complex professional tool. AutoCAD, Photoshop, 3DS Max, Altium, and other high end professional tools are also not known for being particularly user friendly but that's the price to pay for they power and versatility they offer. The licensing I agree is a bit of a pain but at least it's available for free and if dealing with Xilinx is too much trouble there are "other" places you can acquire ISE and/or a license file if you look around. A few years ago at least Xilinx would send you a free DVD if you requested, I still have one here that I use when I need to install it. Yes the download is large but with a little planning ahead it's no big deal, order your FPGA board then go start the download and go do something else. In some time it will be done and then while you wait for the hardware to arrive you can install it and familiarize yourself with the tool. It would not hurt to have a few more ready to use example projects out there but there's no point in trying to cover all bases. I wonder if a DVD-R of the ISE installer could legally be included with the Papilio boards? Depending on the volume, the cost and overhead to provide that would be relatively low, maybe offer it as an option during ordering for a small fee to cover the cost of the disc.
  20. Back to Basics

    Jack is just one guy, rather than relying on him personally to solve your problems I suggest posting individual questions for the specific problems you're having. FPGA development has a steep learning curve, it took me more than a year of struggling before I really started to get the hang of things. A lot of the errors the compiler spits out are cryptic and not very helpful, often they don't even point to the root cause but are the result of a chain of events back to an error made up higher. What errors are you seeing with the logic analyzer? What errors are you getting when you try to build the other example projects? I can't be of much help with the Zpuino because I've never used it, but SRAM is straightforward to use.
  21. Driving small TFTs

    This has been discussed in the past but recently I came across a nice little 4:3 aspect ratio QVGA TFT which is very easy to use with just about any FPGA project that produces a roughly SD-TV resolution image, ie most early arcade games and 8 bit computers. This is the LQ035NC111, an older but still fairly widely available display which uses a parallel RGB-dotclock interface that does not require any type of initialization sequence to work, shown here running PacMan from fpgaarcade. These displays are nearly perfect for this application due to the 4:3 aspect ratio and resolution conveniently close to most classic arcade games, they're commonly used in those cheap backup camera monitors from China. The modifications to the code are very simple, all you need to do is feed the 6MHz ena_6 to the DCLK pin, reset_h to the reset pin and RGB/Hsync/Vsync to their respective pins then tie the unused RGB inputs to ground. The photo looks really washed out but in reality the display looks quite nice with good color and reasonable contrast. The only small hassle is that these displays have no built in backlight driver so you need a boost converter capable of producing about 20V and driving 10-20mA for the LED string. I lashed it all up with an ebay breakout board but eventually I'll make something more permanent. The plan is to scale down the plans and build some tiny desktop arcade cabinets but it could also be used to build a handheld or desktop version of virtually any game, console, computer or other application that fits in the FPGA and produces a video signal. If anyone hooks one of these up and has difficulty getting it going I'd be happy to help. arcade tft
  22. Back to Basics

    Well one of the big advantages of open source hardware is that anyone can build more of them any time they want provided the components are still available. I see two sides to the hardware situation. On one hand it's always nice to have options, but on the other hand the FPGA development community is so small as it is and every additional platform out there creates further fragmentation. In general I would say that it's a better use of resources to work on the collection of projects that run on the FPGAs rather than creating even more competing hardware platforms. An exception to this, and one that I think Gadget Factory could really excel at is producing peripheral modules to work with the FPGA boards already out there. The Papilio wings are the obvious place to start but it may make sense to expand to some of the various little Chinese dev boards that are out there. It would be great to see more widgets in wing format complete with some example HDL to make them do something out of the box.
  23. Back to Basics

    I think there is *some* value in the schematic based entry, for a total beginner it provides a way to make the FPGA or CPLD "do something" and helps to drive home the point that you are designing hardware rather than writing a program. It's not a bad idea to do a few simple projects using the schematic, but then move on to HDL as soon as you get beyond stuff like blinking LEDs.
  24. Back to Basics

    As far as web based stuff goes the UI looks nice, but it still doesn't solve the issue that I am away from reliable (or any) internet access just often enough that I don't want to rely on it for anything that I can run locally. If a proper desktop application is available I will always use it, web based stuff is a backup that is convenient when I'm not on my own PC.
  25. New to Papilio Pro & LogicStart

    There's another great book called Free Range VHDL, I found it to be tremendously helpful once I got started. What I did was read the whole book through from cover to cover without worrying too much about soaking it all in, then I went back and started going through the examples and referring to other sections as needed.