• Content count

  • Joined

  • Last visited

  • Days Won


Everything posted by james1095

  1. james1095


    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
  2. james1095

    SPI to initialize TFT

    I've recently been playing with a TFT screen that has a plain RGB dot clock interface and got it working with a couple of the arcade games. I have a few small TFT displays that are capable of interfacing with the same method but they require initializing via the SPI interface to configure them to enable the RGB interface. One uses the SSD2119 chipset and a couple others are various ILI9xxx chipsets, all of which work similarly. Have any of you used one of these displays? I'm looking for a chunk of VHDL (ideally, but Verilog would work in a pinch) that will spit out a series of commands to initialize the display, anyone got something that already works? This seems like the sort of thing that would be out there but I haven't quite found what I'm looking for.
  3. james1095

    Pac Man minor video corruption

    After spending a good bit of time sorting out the required ROM images I've managed to get PacMan running on my new Papilio One with the arcade megawing. It works well for the most part and looks good, but I've noticed that during the intermission scenes there is some video corruption with lines through the large Pacman and some of the yellow pixels flickering across the top edge of the screen. Is this a bug in the VHDL that implements the game hardware or is it likely something else?
  4. james1095

    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
  5. james1095

    Papilio one 100k quick start bit file

    I'm afraid I can't be much help there, I never tried to invert the video, I've always just left it whichever way the original game was. Most arcade hardware has the ability to flip the screen for cocktail mode though so it should be a matter of just inverting whatever signal controls that in the game to flip the screen. Are you sure the monitor isn't just adjusted so that text is off the screen? I highly recommend reading Free Range VHDL http://freerangefactory.org/ It's free and was a big help to me when I was starting out. You will really need to learn VHDL (or Verilog) in order to get much out of your FPGA board, using only existing projects without being able to modify them is extremely limiting, once you know a bit of VHDL you can understand how they work and tweak things as needed.
  6. james1095

    Papilio one 100k quick start bit file

    Right click in the project hierarchy, select New Source, then select IP Core Generator and from there you can create a memory. I'm not quite sure what you need that for though, is it not already part of the project? I'm pretty sure I have Space Invaders for both of the earlier Papilio boards somewhere, it's a project that I have ported to a number of different FPGA boards I have as sort of a "Hello World" type thing as it's known working code that is fairly simple to work with.
  7. james1095

    FPGA projects

    I finally got around to making a github repository where I've started to collect my FPGA projects together in one place. https://github.com/james10952001 These are mostly arcade related although I did add a recreation of the Heathkit ET-3400 microprocessor trainer. I still have not had a chance to fix the Xilinx ISE installation on my laptop so I haven't ported any of these to the Papilio yet but doing so should be very easy, it's all as platform agnostic as possible.
  8. james1095

    SVF for C64 found, but it's in verilog...

    Sorry to bring a very old thread back to life but this looks like just what I need. I'm working on another 70s Atari arcade game called Subs and need a SVF filter for the sonar ping sound circuits, this is the only part I have not yet completed. I'm a novice when it comes to DSP techniques and until this came up I was actually not familiar with the concept of the SVF filter at all, it's an interesting concept though. Anyway what I need is a pair of filters (two separate input and output channels) bandpass with a 1kHz center frequency. The source is a decaying envelope of white noise from a LFSR which I can make any width necessary. Could somebody give me a few pointers on integrating the filter out of this project into my own and setting up the parameters? I will of course share the code for my project when I'm finished.
  9. james1095

    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.
  10. james1095

    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
  11. james1095

    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.
  12. james1095

    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
  13. james1095

    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.
  14. james1095

    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.
  15. james1095

    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
  16. james1095

    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
  17. james1095

    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.
  18. james1095

    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.
  19. james1095

    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.
  20. james1095

    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
  21. james1095

    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.
  22. james1095

    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
  23. james1095

    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.
  24. 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.
  25. james1095

    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.