alex

Members
  • Posts

    395
  • Joined

  • Last visited

  • Days Won

    12

alex last won the day on July 13 2015

alex had the most liked content!

Profile Information

  • Gender
    Not Telling

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

alex's Achievements

Newbie

Newbie (1/14)

  • One Month Later Rare
  • One Year In Rare
  • Week One Done Rare

Recent Badges

21

Reputation

  1. alex

    Boo

    Looks and sounds fantastic, good work there! I’ve been taking a little break from my project as I came down with tonsillitis and been feeling very sore and drained. Also the weather’s been very depressing as we head well into autumn, it’s been foggy all day every day for over a week now from morning till evening. I feel like I’m living in the Silent Hill movie. Overall it looks pretty cool but I haven’t seen the sun in a while and I miss it.
  2. alex

    Boo

    I know what you mean. I have an Arty board that I bought two years ago but haven’t used it yet. The closest I’ve been to Örebro is Eskilstuna which is where my sambo’s mom lives. PS the 1942 arcade game is now complete, works on Pipistrello. You can get if from my GitHub in link above.
  3. alex

    Boo

    Wow that sounds like a lot of work, well done. Do you publish your sources for these kind of projects (do you have a repository somewhere, like I do on github) ? I see the Pipistrello 2.0 has been discontinued, too bad, I think it was a great dev board and I still use mine due to the size of the LX45 and the built in sound/HDMI connectors. Have fun in Sweden, I live in Kalmar but I work in Mönsterås.
  4. alex

    Boo

    Hi Vlait! Big things mate, I met someone special and about two years ago I decided to move to the other side of the planet to be with her. So I quit my job, sold my house and everything I owned and moved to Sweden with nothing but a suitcase I've been living in Sweden ever since with my amazing Swedish woman who speaks perfect English (so yeah, not a catfish after all). Took a bit of time to get accustomed to the Swedish language, get a job, get a drivers licence all over again from scratch because the Swedes won't convert a NZ drivers licence to Swedish but they will quite happily convert a Japanese one... pretty loopy. The best think about Sweden is IKEA ?, no no I joke, It's the meatballs. But seriously, best thing about Sweden is the people, they're pretty great and the country has some great culture. The worst thing about Sweden is the goddamned ads for gambling. You can't watch TV or listen to radio without having 3 to 4 stupid ads in every ad break about the same 5 or 6 shitty online casinos that promise you easy money. It's so infuriating. So anyway, family life can be pretty hectic but lately I've had some time to get back into the hobby and drifted back to FPGA stuff. Our apartment isn't such that I can have my man cave full of equipment like I used to, but with FPGA stuff all I need is a small corner with a laptop. I'm just now putting the finishing touches on the 1942 arcade game which is what I've been working on lately. Sorting out some sprite issues and will do a final push to github in the next few days, then that game is done. Then I have another project in mind which is something I've wanted to do for a while but I've been scared to touch it because it's a bit of a monster compared to the games I've done so far and likely a very long term project. Lots of custom chips, lots of memory (maybe too much for an FPGA), fancy audio with FM and speech synthesis, 68010 CPU, etc, I don't even know if I'll be able to finish it once started, but I plan to make a fair effort into it and if I fail, maybe someone better than me can continue it. Here's a hint:
  5. alex

    Boo

    Hey guys, It's been a while since I was last here so I thought I'd pop in and say hi to all the old timers I used to know. I wonder how many of them are still here poking around, trying to beat them FPGA gates into submission A
  6. Download the template attached to this post and save it as an XML extension file. Download FT_PROG 2.8.2.0 - EEPROM Programming Utility then run it with your FPGA board attached. Scan the bus (magnifying glass icon) and locate in the tree the one with the blank eeprom. Then right click on it and choose apply template from file and browse to where you save this template. Program the board (lightining icon). Before programming (or even after) and if you know what you're doing, you can go through the various options and change to suit you. For example if you don't like the name I picked you can make your own, you can choose to generate a serial number, etc. Until Jack provides an official template, feel free to use this, Papilio_Pro.txt
  7. As great as the famous C64 SID chip is, it is not the only way to produce great music and sound effects. There is another category of sound chips based on frequency modulation (FM) synthesis. A very popular choice, mainly in Japanese arcades and consoles as well as some keyboard synthesizers / pianos, is the Yamaha YM2151. This is in fact one of several chips in the family of OPL, OPN, OPM and OPS chips. These acronyms indicate how many oscillators per channel the chip contains but they all fall in the wider family of FM synthesis chips. The YM2151 (and others in its category) do not output analog sound, instead they output digital data over a serial channel. This typically goes to a separate D/A chip like a YM3012 stereo DAC or a YM3014 mono DAC. The YM2151 and its companion DACs are available for purchase on ebay for just $3 each so the enthusiast can experiment with them without considerable cost. The fact that the chip does not have an integrated D/A and requires additional external components might be considered a drag by some, but in this particular instance, for someone like me, the fact that the chip outputs digital data is actually a bonus since that output can be fed back into an FPGA (without going through a D/A and A/D conversion) and further processed numerically. To be honest, the idea for this mini project came to me after browsing though various schematics of arcade games. I came across a high res scan of a schema for the arcade version of Double Dragon This was one of those rare schemas that are clean and legible but also just real easy to follow (despite it being over 20 pages), it's just a pleasure to look at and it just makes sense. The signals that cross pages are also very easy to follow because the designer labeled them not just with the page they connect to but the coordinates on that page as well. This is one of these games that have a separate sound board, complete with its own CPU. The interface from the game board to the sound board is via a simple 8 bit port with a single strobe (write) signal. I had the feeling I could just implement most of this sound board on a FPGA and then simply drive the external YM2151 chip with the signals produced by this sound board implementation. Wiring all the external chips on a prototyping board is not really that hard, below is the basic schema that needs to be followed. This schema is a composite after cutting/pasting parts from different pages of the original schema to illustrate just the YM2151 connections to the D/A and audio amps. View attachment: YM2151_schema_snd.png So in order to implement the sound board on a FPGA I need to figure out how the main game communicates with the sound board. Focusing on the main game CPU is the wrong approach here though, this is like taking the long way to get somewhere, the right thing to do is look at the sound board CPU and see how it needs to be "tickled". Here is the schema with irrelevant bits taken out. View attachment: YM2151_schema_adec.png The data latch IC17 is written to by pulsing the signal line *3806 low then high. This clocks in the value from the DB data bus into the IC17 latch. In parallel however, the signal *3809 also clocks the flip-flop IC39. Because the D input is tied high, the pulse on its clock line cause the D input to be latched to the Q output (not shown) and its complement /Q at pin 9, meaning /Q goes low whenever the clock (line *3806) rises. This cause the active low /IRQ line to the 6809 CPU IC49 to go low triggering an interrupt. Disassembling the sound ROM we see that the CPU vector table contains: ROM:FFF0 fdb start ; RSVDROM:FFF2 fdb start ; SWI1ROM:FFF4 fdb start ; SWI2ROM:FFF6 fdb vec_FIRQ ; FIRQROM:FFF8 fdb vec_IRQ ; IRQROM:FFFA fdb start ; SWIROM:FFFC fdb start ; NMIROM:FFFE fdb start ; RST So following the IRQ vector we get to: ROM:880D vec_IRQ: ; DATA XREF: ROM:FFF8oROM:880D lda $1000ROM:8810 cmpa byte_2 ; if same as currently playing melodyROM:8812 beq locret_881A ; exitROM:8814 ldb byte_0ROM:8816 bne loc_881BROM:8818ROM:8818 loc_8818: ; CODE XREF: ROM:881DjROM:8818 ; ROM:8823jROM:8818 sta byte_A ; store index of melody to playROM:881AROM:881A locret_881A: ; CODE XREF: ROM:8812jROM:881A rti Simple stuff so far. When the IRQ vector is called it reads address $1000 and ignoring some of the bits in the middle, it stores that value to byte_A (RAM address $000A) and exits the interrupt handler via the RTI instruction. The reason we ignore some of the code in the middle is because I've already analysed it for you and I can tell you it's not relevant for our discussion. So why does the IRQ handler read address $1000? Well if we lay out the address lines as A15, A14, ... A1, A0 then $1000 is binary 0001 0000 0000 0000 on the corresponding address lines. So the top 5 address lines A15,14,13,12,11 are 00010 when reading from address $1000. Looking at the schema we see these lines are connected to address decoder IC79 (pin 5 on that IC is not labeled in this cut down schema but tracing it on the real schematic shows it going to A15 on the CPU). IC79 is a 3-to-8 decoder meaning the 3 bit binary signal presented to its inputs 1, 2 and 3 is decoded so the corresponding output 0 through 7 goes low. Pins 5 and 6 are active low chip enables (meaning they must be low for the chip to do its job). So when the CPU places address $1000 on the address bus, the chip sees 00010 on its pins 5,4,3,2,1, meaning the two enables are enabled (low) and the remaining binary data 010 represents decimal number 2, so output 2 goes low. This output goes to our familiar flip-flop active low clear input. When the clear input is activated by a low signal the flip-flop clears its state, so the Q output (not shown) goes low (cleared) and its complement /Q goes high. So the operation is now clear, whenever the *3806 signal goes low then high, the DB is latched into IC17 (which goes to the CPU data lines through another buffer to avoid contentions with other stuff on the data bus) and an IRQ is triggered. The CPU stops whatever it is doing and services the IRQ by executing the IRQ routine which clears the IRQ signal by reading address $1000 and storing the DB data from the IC17 latch into the CPU internal memory at address $000A. This is pretty cool because I can now go to MAME and set a breakpoint at the sound CPU address $880D and every time an IRQ occurs, I can see what value was being written. Using this trick I can see that the following values cause the following things to happen. $FF clears/stops any melody sound currently playing$FE clears/stops any sound effect currently playing$01 through roughly $30 play different effects or melodies on the YM2151$80 through ?? play different sound effects but not through YM2151. The sound effects triggered with values > $80 do not use the YM2151 but instead play these effects through separate DAC chips IC80, IC81 and associated circuitry consisting of discrete programmable counters and digital comparators (the relevant schema for these is not shown anywhere in this post). There are in fact two identical circuit duplicated so two effects can be played simultaneously. I won't show an analysis of the circuitry for the effects but roughly it works like this. Each channel has a 64KB ROM with sound effects stored inside. The CPU writes to the programmable counters to preset them with the starting address in the ROM and also to the digital comparators with the end address in ROM of the sound effect. The counters start counting up from the programmed address until the end address is reached at which point the programmable comparators issue a reset to stop the sound playing and the counters stop counting. For example the CPU can preset $1234 into the counters and $2345 into the comparators and the ROM would be presented with addresses $1234, $1235, $1236, ... up to $2345 on it's address bus then the address would freeze there. The ROM output is connected to the DAC chip causing the value from the ROM data bus to be turned to analog sound into the speakers. The address counters are clocked with a presumably low clock which it seems is generated by the DAC chips, probably a few KHz. More to follow... EDIT: Any code for this project will be available here. So far I have added there the full schematic of the sound board, all three pages into one image for convenience. My development hardware will be a Papilio Plus with an Arcade Mega Shield (plus any external chips of course).
  8. Well done Kosak, It is my hope that this forum will have more posts from people showcasing their projects step by step as they are developed covering both successes and failures, or showing their troubleshooting techniques. Then we can all pitch in with ideas. I attempted to do this with my latest Roboton posts, though given the lack of responses, perhaps it was too hard for people to follow or they may even have found the posts annoying and just skipped them 1) What I do for all my projects is create a special directory which I usually call "build" but any name will do. This directory can only be specified when creating a new project and I haven't found a way to change it through the GUI afterwards. If you already have created the project then open the .xise project file with a text editor and search for "working directory" which will contain just an empty string in quotes like so "", change that to "build" and save it. The next time you open the project it will ask you if you want to create this directory and answer yes. From now on, all the junk during the build will end up in this directory. I think there was a while ago a post or perhaps an article on the papilio page discussing this, The recommended way to create a project directory structure was along these lines: root / +-build +-doc +-source +-tools Where "build" is the directory I mentioned above, "doc" contains project documentation, datasheets, useful references, etc, "source" (or "src" or "hdl" if you prefer contain the HDL source code of your project then "tools" can contain useful scripts for building parts of your project such as binary to VHDL converters to create ROM files or any other scripts or executables needed for your project. 2) You're right, even if your case statemnt covers all possible cases, you still get a warning during synthesis unless you have an "others" case (durrr!). If you just need "others" as a filler that does nothing I usually use "when others => null;" 3) Nothing wrong with that. Usually you do this if you're going to re-use that piece of code several times, then you turn it into a separate module. You can now include that module file into other projects that need a hex to 7seg decoder.
  9. OK all sorted now, code is here if someone wants to take it for a spin. It turned out to be some weirdness with the StarsOFF and VSync signals having become inverted at some point. As far as I can tell, the starfield is scrolling as it should, all sounds are there and the gameplay seems faithful to the original as expected, I haven't seen any other glitches that would be of concern.
  10. Interesting... the video circuitry is producing correct video which is combined with the output from the stars generator module via a video mixer. It seems the stars module is producing this checkered pattern which is then mixed with the game video. At first glance, in the stars module, chips A1 and B2 form a 14bit shift register which in conjunction with xor gate 3B and flops 2D forms a PRNG used to generate digital noise. Every time the low 8 bits of this PRNG are all set, this checkered noise pattern is sent out and mixed with the video which explains why it's occurring so... randomly. Not sure why yet, I'll have to check it against the schematic, but it's after 2am so I'm of to ZZzzz...
  11. Something else I came across, there seems to be an annoying flicker at random intervals in the Galaxian game, it looks a bit like a checkered pattern. I run the game through the simulator with the Black Hole ROMs and managed to capture the event on frame 12 after power on. In the picture below frame 11 is normal, frame 12 has the pattern then the next frame is back to normal. Since this only occurs for exactly one frame, it looks like a flicker, and is quite annoying after a while. Now that I can see it in the simulator, I'm hoping I can get to the bottom of it.
  12. Since I started digging though the Galaxian code yesterday, I couldn't just stop there so I ended up doing the following: The video on my monitor seemed to ride a little too high (in portrait mode) so I'd have to fiddle with the adjustments to center the picture. I got sick of doing that and replaced the scan doubler originally written by MikeJ or fpgaarcade with my own that I developed for my BombJack implementation. My scan doubler does a few things differently and more closely implements the VGA timing for the sync signals therefore the picture just ends up centered on the monitor without having to fiddle with buttons, in fact just reseting the monitor settings to factory defaults still ends up with a centered picture due to the scan doubler observing the correct front/back porch and sync signal polarity and duration. It also requires and generates composite blanking signals, see why below. In the process I also simplified the clock section and had it generate one additional 24Mhz clock which I required for my scan doubler, but more importantly that clock is required if you want to bolt on an HDMI output on the end of the scan doubler. The reason 24Mhz is required is because it is very close to the VGA standard 25.175MHz but also is an integer multiple of the 6Mhz that the game video runs at. To run an HDMI output you simply feed the scan doubler output into the DVID module that Mike Fields created. That module requires composite blanking signals as well as 24Mhz and 24*5 Mhz clocks to generate an as close as possible to VGA signal. This was tested successfully and it works. I didn't like how the top module of the project that was geared towards a Papilio board just contained all the game sub-modules. I think it is more proper to separate the game logic from the board implementation. As such the game module itself should be self contained, it should take as inputs some clocks and player controls and it should have as outputs the original video (not scan doubled) and sound. This game module can then be imported into a top level board specific module that then connects other stuff to the game module to make it work in a particular environment. Such add ons can be the scan doubler, a PS2 keyboard controller that is then converted to button presses and fed to the game module, the DACs, etc. So I went ahead and separated the game logic itself from the board specific bits and pieces. While trying to eliminate some warnings, I also ended up switching some negative logic signals to positive logic simplifying some code across several modules. Finally, some good stuff, the sound! I saw some complaints that the Galaxian was missing the right channel, sound effects. These include the ship explosion sound, the shooting sound and the background sound. Initially I looked at how the original author tried to implement this. He basically had three sampled sounds, one for each of the above sounds listed above and would just play the relevant sample as appropriate. These samples had been missing in the source and I couldn't find them on teh nets. I fired up MAME and recorded the background sound and the ship shooting sound but could not get a clean ship explosion as there are always other sound effects going on when the ship explodes. So I cheated and added a generic explosion sound effect. I down-sampled all of them to 11025Hz and added them to the game. Upon playing a test game I noticed that while the shooting and explosion sounds were OK, the background droning sound was just the static sample repeated over and over. The original Galaxian game actually plays that sound faster and faster as the game progresses adding a sense of urgency to the game play. I realized that just having this static sample would not do. I pulled out the schematic of Galaxian and had a look. The original hardware implements this sound with old fashioned 555 timer chips (no fancy sound generators here). Basically the CPU writes a 4 bit value to a 4 bit DAC implemented by latch 9M in the schematic. This is converted to an analog voltage by an 2-2R ladder and then feeds into a current mirror (transistors Q1 and Q2). This current mirror controls the first 555 timer labeled 9R. It causes it to generate a sweeping analog voltage, the sweep rate (how fast it sweeps) is controlled by the 4 bit A/D value from about once per second to ... um, really fast. This sweep voltage is fed to three other 555 chips, 8R, 8S, and 8T. Each of these is configured as an astable multivibrator and each is tuned to a different base frequency but the sweep voltage causes each of them to detune making each of them sweep across a range of frequencies. Essentially they are voltage controlled oscillators (VCOs). The outputs of these three VCOs are a set of square waves that combine together via resistors R24, R27 and R30 and are further filtered by C20, therefore this is a low pass RC filter causing the sharp sound of the square waves to be smoothed into the familiar droning Galaxian background sound. Each of the three VCOs is further controlled by lines FS1, FS2 and FS3 so each of them can be selectively enabled or disabled from producing sound. These lines were not connected in the original game source as they didn't have anything to control since the original author just played a static sample for the background. So what I did was implement a VCO module, that currently just generates a sine wave of a certain frequency based on an input value. I didn't want to bother with generating square waves and then passing them through digital filters, while that would have been a more faithful representation it adds complexity. So the VCO module it replicated three times and they are all controlled by a modulator that uses lookup tables to feed the VCOs their frequency based on the 4 bit A/D value generated by the game CPU. In practice, the game is much more realistic now with the background sound that changes cadence as the game progresses and becomes faster and faster just as the original Galaxian. The other sounds, the shooting and explosion are still just samples even though the original game implements them with discrete hardware. The explosion sound is a one bit digital noise that is passed through a low pass filter to create a the explosion noise. The fading volume of the explosion (starts loud and fades to quiet) is implemented via an analogue switch and a capacitor that discharges as the sound it played controlling the volume. The shooting sound is also a combination of a 555 timer chip 7S producing a base frequency which is modulated by the one bit digital noise after passing through an RC filter. The fading volume is also implemented by another analogue switch and capacitor. Implementing these two types of sounds in hardware is a bit challenging due to all the analogue electronics involved so for now we'll just have to put up with the two sampled sounds each consuming exactly 8KiB. I haven't uploaded the source anywhere yet as I'm still fiddling with it, if there is any interest I will share the last stable snapshot. Oh forgot to say, this of course means that other games using the Galaxian hardware will have these sounds, tested with Balck Hole so far.
  13. Anyone tried to play Galaxian recently? When I gave it a try I was getting double vision, sort of. I had two skinny copies of the video side by side. This didn't happen with the original verilog code, only the vhdl. I dug into it and noticed an error in the mc_video.vhd and I'm not sure if this was introduced when I translated the game from verilog to vhdl as I don't have that original source code any more, this is the code from gadgetfactoy github so this section -- Parts 4,5NW_45N_Q <= (W_VF_CNT + W_H_POSI) & '0';should really be -- Parts 4,5NW_45N_Q <= W_VF_CNT + W_H_POSI;Otherwise the VF counter is essentially multiplied by two (shifted left one bit).
  14. I had a copy of Lady Bug written by Arnim Laeuger, that I downloaded from fpgaarcade a long long time ago and forgot all about it. I recently came across it and I spent a little time getting it going for the Papilio. Unfortunately it won't fit on a Papilio One, it uses about 28 BRAMs and the Papilio One doesn't have any external memory and not enough internal memory. Good news is, it will fit entirely into a Papilio Pro or any Spartan 6 FPGA without needing any external RAM or ROM. Getting this ported to the Papilio was just a matter of writing a top level module to connect the ladybug machine to the various ROMs and input controls. This is the first time I've finally used a PS2 keyboard controller from here which appears to have a well written bidirectional PS2 controller. Bidirectional means that when you hit for example the caps lock key, the PS2 controller detects that and sends data back to the keyboard to turn on the caps lock LED. The key mapping I chose can be easily changed if you look in the source code and have a handy PS2 key code reference. As is, the game should be playable with the arrow keys. A small issue, if you have your monitor tilted one way to get other games like Pacman showing correctly, then Ladybug will appear upside down. If you can tilt the monitor the other way, you're all set, if however you can't and just reverse the state of the flip_screen_g variable, the screen will appear at first glance to be correctly flipped but unfortunately only the background is flipped, the sprites and key mapping are not, so, for example, Ladybug will appear to move the wrong way, won't line up with the corridors, eating the dots on one side of the screen causes the dots on the opposite side to disappear, etc. Currently three games are supported: Ladybug, Dorodon (a Ladybug like clone) and Cosmic Avenger (a Defender like clone). I haven't searched what other ROMs the original hardware supported, if any. The source code is available here. To make it all work, download the source then download and place the game ROMs into the appropriate ROMs folder. See the readme file in each folder for a list of the files and checksums you should be looking for, If you're on Windows, run the make_roms batch file in the relevant game rom folder. Game ROMs will be converted to vhdl files in the build directory. If you're on linux, there appears to be a makefile based system for creating ROMs and other files in the hex folder, seemed to work for me in MinGW, but I use Windows primarily. Once the ROM files are converted to VHDL, run the ladybug_papilio.xise project in the top directory and synthesize then upload to your board. You need a Papilio Pro with a Arcade Megawing and a PS2 keyboard in port "PS/2 B", VGA and audio connected. Enjoy!
  15. Click here for the original forum thread.