james1095

Members
  • Posts

    357
  • Joined

  • Last visited

  • Days Won

    9

james1095 last won the day on April 4 2020

james1095 had the most liked content!

About james1095

  • Birthday 03/04/1979

Profile Information

  • Gender
    Male
  • Location
    Seattle, WA
  • Interests
    Engineering, electronics, mechanical tinkering, aviation, retro computing, retro gaming, hardware hacking

Recent Profile Visitors

3,675 profile views

james1095's Achievements

Newbie

Newbie (1/14)

13

Reputation

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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
  7. 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
  8. 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.
  9. 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.
  10. 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
  11. 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.
  12. 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.
  13. 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.
  14. 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
  15. 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