james1095

Members
  • Posts

    357
  • Joined

  • Last visited

  • Days Won

    9

Everything posted by james1095

  1. The Papilio Pro is a great dev board, but if you want to integrate it into a game cabinet it's huge overkill, especially for a game as simple as SI. For what it's worth, I have Space Invaders running on a $13 Cyclone II FPGA board I got from ebay, using only an external EEPROM or SRAM, a pair of resistors for the video and a simple RC filter for the audio. I'm running Galaxian on the same board, but PacMan requires more ROM and the two ROM areas do not share the same bus. Asteroids and Asteroids Deluxe are also working, using a small vector monitor I built myself. Any of the Papilio boards will run SI, and most of the other Midway 8080 games ought to work with minimal effort though some used special controllers. Bomb Jack is a bit different as outlined above, but no matter what FPGA you use, you'll probably find that most arcade games are memory constrained. For example most of the classics that have been implemented in FPGA form will fit easily in the old Papilio 250 except there is not enough block memory to hold all of the ROM and RAM. By adding some ROM and/or RAM externally you can greatly expand what the FPGA can do.
  2. That's probably a reasonable way to go about it, I'm not sure I have the skills and mental energy to try right now though, I've been beating my head against a wall for weeks now trying to get this to work and I need to force myself to take a break and finish up the hardware side. If I have a complete monitor design that others can duplicate, maybe others will want to build these too and then a Papilio vector megawing could make sense. I'm not trying to compete with Gadget Factory in any way with this project, I'd love to see others jump in and take it further. FPGA based retro arcade development seems to have seriously stalled since the initial batch of games released quite a few years ago. In the meantime I'm hoping I can convince someone else to take a crack at this, it's possible that the problem will be obvious to a second set of eyes. Unfortunately outside of this forum I've found very little in the way of hobby FPGA discussion, I've tried and failed to get any of the other techie people I know interested enough to get over the very steep initial learning curve.
  3. This is driving me nuts! I spent several hours looking through the output in ISim and I still haven't figured this out. I can see it start reading from the program ROMs and it runs through a loop initializing all locations in the CPU RAM and everything looks ok there, but then somewhere along the line it ends up out in the weeds stuck in a loop writing to the same location of RAM and eventually the watchdog resets it. I played around with the vector generator in isolation and I can read and write the RAM and read the ROM in the expected memory locations and the data it returns matches the ROM images, at least the random addresses I checked. It doesn't appear to even get to a place where it tries reading the inputs (which include Halt and such) so I don't think the problem is in that area. It's just weird because Asteroids and Deluxe work fine, I may have to try those in ISim and see what that does.
  4. The simulator built into ISE is probably the most effective approach, I'm still not particularly skilled at using it though. There are a few pretty talented FPGA developers floating around here, hopefully one of them will take a peek through the code.
  5. I've ported the Lunar Lander code over to the Papilio in case someone here is able to take a crack at getting it working. I'm out of town and didn't bring my Papilio boards with me so I don't know how this behaves but it builds fine, just grab the MAME ROM and extract the files into the rom folder and run the build_roms batch script and it should build no problem, currently set up for the P1-500k. I didn't have enough IO pins to hook up the mission indicator lamps but I think enough can be freed up by disconnecting unused button inputs, otherwise a shift register could be used as IO expansion. Without a DAC it won't drive a monitor but if the X and Y outputs are active and the watchdog isn't barking then that's a good indicator that things are working. Lunar Lander Pap1.zip
  6. The Asteroids schematic is here: https://www.arcade-museum.com/manuals-videogames/A/Asteroids-sp.pdf Lunar Lander schematics can be found here: http://www.andysarcade.de/lunarlander.html
  7. I found Free Range VHDL to be an excellent book, and it's free in digital form too. Anyway back to the Lunar Lander issue, I *think* I accounted for the differences you mention. Attached are snippets of the input 0 buffers for both Asteroids and Lunar Lander. Note that Asteroids uses a 74LS251 which is a selector/multiplexer with an inverted output read on D7. Lunar Lander on the other hand uses a 74LS367 tristate buffer which is non-inverting and read on D7, D6, D2, D1 and D0, both are active when SINP0 goes low. Now for the code, here's a snippet from Asteroids: -- self test, slam, diag step, fire, hyper control_ip0_l <= "11111"; control_ip0_l(4) <= SELF_TEST_SWITCH_L; control_ip0_l(3) <= '1'; -- slam control_ip0_l(2) <= '1'; -- diag step control_ip0_l(1) <= BUTTON(4); -- fire control_ip0_l(0) <= BUTTON(5); -- shield test_l <= SELF_TEST_SWITCH_L; p_input_sel : process(c_addr, dips_p6_l, control_ip0_l, control_ip1_l, clk_3k, halt) begin control_ip0_sel <= '0'; case c_addr(2 downto 0) is when "000" => control_ip0_sel <= '1'; when "001" => control_ip0_sel <= not clk_3k; when "010" => control_ip0_sel <= not halt; when "011" => control_ip0_sel <= not control_ip0_l(0); when "100" => control_ip0_sel <= not control_ip0_l(1); when "101" => control_ip0_sel <= not control_ip0_l(2); when "110" => control_ip0_sel <= not control_ip0_l(3); when "111" => control_ip0_sel <= not control_ip0_l(4); when others => null; end case; p_cpu_data_mux : process(c_addr, ram_dout, rom_dout, vg_dout, zpage_l, pmem_l, vmem_l, sinp0_l, control_ip0_sel, sinp1_l, control_ip1_sel, dpts_l, dips_ip_sel) begin c_din <= (others => '0'); if (sinp0_l = '0') then c_din <= control_ip0_sel & "1111111"; elsif (sinp1_l = '0') then c_din <= control_ip1_sel & "1111111"; elsif (dpts_l = '0') then c_din <= "111111" & dips_ip_sel; elsif (zpage_l = '0') then c_din <= ram_dout; elsif (pmem_l = '0') then c_din <= rom_dout; elsif (vmem_l = '0') then c_din <= vg_dout; end if; end process; Note that each of the signals in the first section is inverted, accounting for the inverted output of the selector/multiplexer. Now looking at a snippet (with some irrelevant bits removed for clarity) from Lunar Lander: p_input_registers : process begin wait until rising_edge(CLK_6); -- diag step, 3khz, slam, self test, halt control_ip0_l <= "11111"; control_ip0_l(4) <= '1'; -- diag step control_ip0_l(3) <= clk_3K; -- 3 khz control_ip0_l(2) <= SELF_TEST_SWITCH_L; control_ip0_l(1) <= '1'; -- slam control_ip0_l(0) <= halt; end process; p_cpu_data_mux : process(c_addr, ram_dout, rom_dout, vg_dout, zpage_l, pmem_l, vmem_l, sinp0_l, control_ip0_l, sinp1_l, control_ip1_sel, dpts_l, potin_l, potval, dips_ip_sel) begin c_din <= (others => '0'); if (sinp0_l = '0') then c_din <= control_ip0_l(4 downto 3) & "111" & control_ip0_l(1) & control_ip0_l(2) & control_ip0_l(0); elsif (sinp1_l = '0') then c_din <= control_ip1_sel & "1111111"; elsif (dpts_l = '0') then c_din <= "111111" & dips_ip_sel; elsif (potin_l = '0') then c_din <= potval; elsif (zpage_l = '0') then c_din <= ram_dout; elsif (pmem_l = '0') then c_din <= rom_dout; elsif (vmem_l = '0') then c_din <= vg_dout; end if; end process; Note that in this case there is no intermediate step so I'm not inverting those signals, and rather than the signals being read one at a time onto bit 7 of the data bus, they are all fed simutaneously to the CPU data in when sinP0_l is low.
  8. Well here's where I am with this so far, I'm posting these in case I get hit by a bus or something, one of my pet peeves is when people show off cool projects but then never release the code, so here's the code. Currently this is set up for an Altera FPGA but it was originally written for Xilinx and I do intend to port it back to the Papilio, doing so is relatively easy. These are set up to work with the program ROMs in an external parallel EEPROM because the little EP2C5T155C8 I'm using lacks sufficient block RAM to hold all the ROMs internally but the FPGA on the Papilio boards is large enough that this is not needed. Anyway here's the state of things: Asteroids Deluxe - Fully working, no high score save yet but that was never implemented by MikeJ who originally released this on fpgaarcade.com Asteroids - Works but several of the sounds are missing which really detracts from the game. If someone wants to work on modeling the missing sound circuits that would be cool. Lunar Lander - This is not working at all yet and I'm banging my head against the wall trying to determine why. The hardware is very, very similar to that of Asteroids, more ROM, less RAM, one of the input banks is done differently, it also has an analog input for the thrust control but that shouldn't be necessary for the attract mode to run. I could really use a bit of help getting this to run at all at which point I'll work on the details. Currently I've got the watchdog disabled because otherwise the reset keeps pulsing. Trying to figure this out has distracted me from finalizing the hardware revisions and polishing up the other two games. I printed out the schematics, highlighted all the changes I could find and then methodically implemented them in the code but it's possible I missed something somewhere. Asteroids Deluxe.zip Asteroids.zip Lunar Lander.zip
  9. I just wanted to show off my latest FPGA project, this is not currently Papilio based but I'm contemplating doing a megawing for the Papilio One/Pro if there is enough interest, I don't want to manufacture it but I would open source the design. For the time being this is based on the little Altera Cyclone II boards that can be had for about $13, cheap enough to integrate into projects. I designed a daughterboard that plugs onto these and holds a triple DAC, op-amps with gain and offset adjustments for the X and Y deflection, a DC-DC converter to provide the +/-15V rails for the amps, an audio amplifier with volume control and I tossed in a I2C EEPROM with hopes of using it to emulate the EAROM that stores the high scores in Asteroids Deluxe. Initially I tried using delta-sigma DACs for the deflection as Spritesmods did with his Black Widow project but I was not happy with the result. Then I got the idea to use a VGA DAC since it's a high quality high speed 10 bit triple DAC and there was one on my DE2 dev board that I used for prototyping. It worked perfectly so I carried it over to this design. The monitor is based on a cheap 5" B&W CRT TV with the vertical winding of the deflection yoke rewound and a custom electronics, the initial deflection board was designed by Fred Kono a number of years ago but I'm working on a cleaner and more integrated solution. I've also tested this FPGA board with a G05 and a 19K6101 vector monitor in my fullsized cabinets and it drives them fine. As it stands, I've got Asteroids Deluxe working perfectly using code originally from fpgaarcade.com modified to eliminate the rasterizer and ported to my hardware. As of yesterday I also have the original Asteroids working except I have not modeled the analog circuits for many of the sounds which Deluxe replaced with a POKEY chip. If anyone is interested in helping out with this project there are a few items on the to-do list that I could use a hand with, in the process I'd be happy to post the code I have and provide all of the details for anyone who wants to replicate this to do so. Eventually my plan is to build a few miniature arcade cabinets replicating the original classic games in small desktop form. To do: - Implement missing sound effects in Asteroids, all of the control logic is there and working, still need the thump-thump, ship and saucer firing sound and saucer warble. - Implement EAROM emulation, I'm not entirely certain how feasible this is but I included an EEPROM because there was space. It's trivial to use a block RAM in place of the EAROM but that needs to be backed up to and restored from the serial EEPROM. - Get Lunar Lander working on the platform, I made an initial attempt and was not successful, I plan to give it another go. I've brought out the I2C bus on my board with thoughts of using a I2C ADC for the thrust input. - Implement Omega Race hardware, this is a much larger task since it's a completely different hardware platform. It uses the same 10 bit DACs as the Atari games and the hardware is of similar complexity. One last thing worth mentioning, these little CRT TVs are currently fairly easy to find but they are going away fast. They are essentially useless to most people since the death of analog TV but they are perfect for projects like this, a real CRT is the only way games like this look right at all, if you come across these things pick them up while you can because nobody is making CRTs anymore and they are disappearing fast.
  10. That's neat, I like it. I'd be especially pleased with an SRAM addon, or better yet SRAM/ROM although pin counts start to be an issue unless you put them on a shared bus. In all my FPGA adventures, lack of sufficient block memory has been one of the biggest limiting factors and SDRAM is next to useless for recreating vintage hardware. Jack, next time you're in Bellingham you should check out the Spark Museum if you haven't already. It's a fascinating place, I think you'd like it.
  11. There is some code on Hamster's site that uses it, it's in VHDL though which is the language used by most of the Papilio community.
  12. There is an AVR core already, I don't know about the PIC but it's certainly possible. There are some limitations though, you cannot for example implement the ADC present in many uCs within the FPGA, and the internal memory is very limited.
  13. I use KiCAD and I don't think it will import from Eagle. What I would suggest is install the free version of Eagle and use that to measure the pin spacing, or if you have a Papilio you could just measure it. They are standard 0.1 headers so all you need is the relative spacing between the two banks.
  14. I see that now, I hadn't seen the other posts until after I had replied here. I don't blame you for being annoyed, when I give away something for free I don't want to be badgered for support so someone else can sell it for money. I wouldn't expect much help unless I was at least contributing something back to the project in exchange. I've built my own version of open source hardware numerous times but I often customize it to suit my own preferences and I don't normally sell them other than maybe letting a few leftovers go at cost.
  15. Why don't you just buy one? If you want to manufacture your own, it's open source so you are free to do so, but don't expect others to provide support and do the work for you. If you are going to make them, you might at least try to make some improvements rather than simply running a batch of an existing product.
  16. There's a good chance he didn't know it was a knockoff when he purchased it, I wouldn't be so quick to blame the end user. That said, one can hardly expect official support for a knockoff product. Most of the basic examples should compile fine, but the 100k is a rather small FPGA by current standards so many of the Papilio designs that utilize block memory will likely not fit.
  17. I've soldered lots of TQFP stuff at home, even the larger 204 pin packages. The drag method Jack mentions works reasonably well, you can also use that method to tin the pads and then reflow on a hot plate or in a reflow oven to attach the part. The key is to use plenty of flux and be patient and make sure the part is exactly lined up. I then wash the board with acetone and an old toothbrush to remove all the flux and use a lighted loupe to inspect for solder bridges.
  18. My friend built a power monitor using a cheap AVR microcontroller with the internal ADC sampling the AC line and producing a graph of the current waveform. It also calculates the RMS value in real time and that's a ATMEGA88 running at 8MHz. You could use a FPGA, but that's sort of like using a sledge hammer to drive a small nail to hang a picture.
  19. This is the cost reduced version of the MA-216, lacking the Votrax SC-01a speech synthesizer chip. It is otherwise identical and will work with all ROMs intended for the MA-216 sans speech. Variants of this board were used in pinball machines Super Orbit, Royal Flush Deluxe, Amazon Hunt, Haunted House, Spirit, Krull, Goin'Nuts, Mars, Volcano, Black Hole, Devil's Dare, Rocky, Striker, Q*Bert's Quest, Caveman and video games Mad Planets, Reactor, Qbert, Krull, and Three Stooges. I posted the initial version of this several months ago, this has been cleaned up, uses the improved 6532 RIOT code I modified to have separate data in and out ports, and it includes a top level file with a PS/2 keyboard interface and decoder. It's currently set up for the Papilio One 500k with Arcade megawing but is easily customizable for other platforms. At this point I've done all of the early Gottlieb sound boards that I'm aware of and will port the rest of the Williams and Bally stuff to the Papilio. Gottlieb MA-309.zip
  20. Here's my initial release of the sound board used in all of the Williams video games and their System 6 and 7 pinball machines throughout the 80s starting with the famous Gorgar. Initially I was building upon the Robotron sound board that was released some time back but then it was getting messy so I decided to throw it all out and start from scratch. Vlait kindly wrote a CVSD decoder that emulates the HS55516 these used on the optional speech module so everything is there. "Beware, Coward!" I've included a top level file with a PS/2 keyboard interface and decoder making it easy to play around with the sound board. If one wanted to use this in a real video or pinball machine it would be very easy to write a new top level file with that in mind. This is set up for the Papilio One 500k with arcade megawing but only a few IO pins are used so this is easy to customize. I've also included a romgen script for Sinistar which can be easily customized to build VHDL ROMs of the other supported games. Keeping in mind that this is the first release, there are a few rough edges: - There are some jumpers used on these boards that differ depending on the game it's being used in. The one that needs changing most often is W2 and W3 which configure the ROM addressing. Eventually I'm thinking of setting up some boolean values that can be set but for now just comment out the removed jumper and un-comment the installed one. These settings can be found in the game manual but it's often easier to just try one and if that doesn't work swap the W2/W3 jumpers and try that. - There is no low-pass filter on the speech decoder. The real hardware uses a pair of 2nd order low pass filters in series, IIRC the first has a cutoff of around 7.5kHz and the second 3.5kHz. It sounds ok my ear but if someone wants to try implementing the filters in VHDL to get rid of the background hiss that would be cool. - Sound and speech are brought out separately to the left and right channels rather than being mixed. This made it easier for debugging and allows external filtering on the speech signal but it would be cleaner to mix it properly. - The CPU68 softcore is not cycle-accurate, I found this caused speech samples to play noticeably fast. I compensated by dropping the CPU clock from 893 kHz to 750 kHz by trial & error. I don't know if this will result in all of the sounds being correct or not, perhaps someone who has a real Sinistar machine can compare and let me know. - The keyboard decoding is incomplete and I haven't bothered to map each key to a specific sound code. To do that would require knowing exactly how many sounds implemented for each of the games that used this board and which binary numbers trigger each sound. Any key that is not decoded just passes the scancode straight through to the sound board inputs. Perhaps someone can come up with a better input method but this is good enough for playing around. I have several other Williams, Gottlieb and Bally pinball sound boards working that I will port over to the Papilio when I have time, eventually I'd like to do them all. wms_system_6_7 sound.zip
  21. There is at least one open source C64 implementation in FPGA, so that will replicate the functionality of any of the chips in that machine. It lacks the SID filters but they are implemented in the Retrocade Synth project so it should be possible to port them. As far as RAM chips, most retro computer projects use static RAM, rather than trying to exactly duplicate the original architecture.
  22. The megawing is just a passive adapter, it won't make any difference as far as loading code onto the FPGA.
  23. Are you sure you're using the right .ucf file? IIRC the anode control is active low, so yes, setting them to "1111" should result in all displays off. Check the constraints file and make sure the anode signals are routed to the correct pins for the Papilio board you have.
  24. That still seems like a pain compared to how it works in Quartus. When I want to load a hex file, I simply double click the ROM instance in the project manager and it opens in the wizard. Click through a few pages to the one that lets you assign contents and then select the hex file and click finish. Recompile and the new ROM contents are loaded, it's super easy and fairly intuitive. Xilinx ISE allows you to do something similar, but only offers the choice of .coe or .mem, which I find odd since .bin and intel hex are defacto standards that have been around for decades. There are other things I like better about ISE though, which is one reason I've been using both side by side rather than settling on one or the other. Anyway back to the sound board, my initial attempt at getting it running on the Papilio didn't work, surprising since the Robotron project I got it from was Xilinx based. I probably just made a dumb error somewhere, I'll have to play with it a bit more. I've been working on the more primitive System 4 sound board too and when I finish that I'll tackle the Bally hardware. At that point I'll have all the major early solid state pinball sound boards used up through the late 80s. The speech is the big challenge on all of the fancier ones though. Gottlieb used the SC-01a phonem speech synthesizer, Williams the CSVD decoder, and Bally used the TMS5200 LPC decoder. All of the real ICs are long out of production and hard to find/expensive and I haven't found softcores for any of them.