Page 1 of 17 1234511 ... LastLast
Results 1 to 25 of 404

Thread: NeoVGA: Lagless, pixel-perfect line doubler for Neo-Geo MVS and AES

  1. #1
    SouthTown StreetSweeper
    mikejmoffitt's Avatar
    Join Date
    Feb 2014
    Location
    San Jose, CA

    Posts
    569

    NeoVGA: Lagless, pixel-perfect line doubler for Neo-Geo MVS and AES

    I've written about this project a little in the TV compatibility thread, and a little more on my site - it was in hackaday not long ago - but I think this community is probably the one that would understand and appreciate it the most so I think I'll do a more detailed writeup here.



    Here is a nicely scaled KoF99:


    What is NeoVGA?
    NeoVGA is an FPGA-based video scaling solution for the Neo-Geo MVS and AES systems. It implements a classic line-doubling method, which produces far less than a single millisecond of lag. Unlike many line doublers, this one operates entirely in the digital domain up until the output stage. It uses the CPU clock, which is double the Neo-Geo's pixel clock to latch in pixel data and generate its output. This means that the timings are exactly double that of the original MVS timings.

    The primary advantage over other solutions is that data is captured digitally, so there are no uneven edges from the analogue signal not being perfectly quantized to the buffer it is being captured to.



    Principles of Operation Part 1: RGB Video Timings
    The Neo-Geo video timings are similar to many other 15KHz RGB-compatible arcade and home console systems of the time. Within 1/60th of a second, a single frame of video is displayed - much like a modern monitor using DVI, HDMI, or VGA. The difference here comes from the horizontal sync rate, which in the end boils down to how many lines are being displayed. The term "15KHz RGB" refers to the fact that a new line is drawn with a frequency of 15KHz, or 15000 times per second. This number isn't exact - we can do the math to determine the true horizontal refresh rate of the Neo-Geo. While there are 224 active display lines, there are blank lines above and below the active frame area that count for the sake of timing. From Charles MacDonald's mvstech.txt we can learn that the Neo-Geo produces 264 lines per frame. 264 lines * 60 frames per second = 15840 lines per second. The horizontal sync signal exists to indicate the end of a display line, so there will be 15840 pulses per second - or 15.84KHz. That is the true horizontal refresh of the Neo-Geo. From the Neo-Geo Development Wiki is this image:


    The Neo-Geo isn't perfectly refreshing at 60Hz, either - it is a little lower, 59.18Hz. This is within tolerances of most flat panel displays, and just about every CRT monitor ever made.

    Principles Of Operation Part 2: VGA Timings
    You may ask, "It is refreshing at 60Hz, and the resolution is so low - why can't a new display handle it already?"

    There are a few reasons. The simplest is merely clerical - older JAMMA based systems, and most consoles, output their sync information (Hsync and Vsync) through a single pin called Csync, or Composite Sync. Sync information is usually active-low, often called Negative Sync. This is a misleading name - you might expect it to be at -5V at some point. What this means is that the line is a logic HIGH when inactive, and gets pulled to a logic LOW when the sync happens. These values are 5V and 0V on the Neo-Geo, specifically. The Csync line is simply Vsync and Hsync XORed together. They can be separated without too much work later on. The point here is that the VGA standard expects Hsync and Vsync to be separate already, on pins 13 and 14 respectively, of the VGA connector.

    However, even if the sync signals are split, there remains the far larger complication of the timings. A VGA monitor, by standards, will only accept a horizontal sync of ~30KHz and up (for SVGA, XGA, etc. monitors). Attempts to give it low-resolution images will typically result in nothing happening, or if it's a nicer monitor, it will say "out of range" or something like that. Sometimes you'll find an oddball monitor that will take 15KHz RGB with Csync through the VGA port, but it's not common. A great example is the Samsung 940Be. Click for a video of it running a Sega Genesis in both 240p and 480i mode. We can't rely on this, however.

    So, let's consider what it means for VGA to be rendered at 30KHz horizontal refresh. The VGA standard resolution is 640x480. As VGA is analogue, we can more or less ignore the horizontal resolution of 640, as that's really up to the device's pixel clock. A line is really just generated by a constantly moving electron beam whose intensity is modulated by the R, G, or B signal coming in at the right time. If you are unfamiliar with the principles of how a CRT monitor displays, you may find it helpful to learn about it through some research. It will help you understand modern ones too, as their timings are based on CRT timings still - even HDMI. The point is, the monitor is relatively agnostic of the horizontal resolution, though digital ones will attempt to determine the source pixel clock to quantize the pixels nicely into the pixel grid.

    We care about the 480 lines from the VGA spec. If 480 lines are displayed in the same time as our Neo-Geo's roughly 320x240 display, that means that each VGA line comes out twice as fast as a single Neo-Geo one. The term "line doubling" may become much clearer now.

    Principles Of Operation Part 3: Line Buffering
    Most scaling devices, even really nice ones like the XRGB-Mini Framemeister, sample an entire frame from the RGB source to a buffer, scale that buffer to the output resolution with or without additional effects like dimension adjustment and scanlines, then render that out to the display. In a good one, the vertical sync is locked, so there is never tearing from the two devices (source, and the output device) getting out of sync. However, this will guarantee a certain amount of lag that may approach one or more frames of time. For many this is fine, but considering that the display itself will often do its own display processing and add more lag, it would be nice to not add to the chain.

    The other approach is line doubling. Yes, I keep saying this, but here I'm going to finally explain it. Basically, armed with the knowledge that a VGA line can be exactly double that of the RGB one and fall within the spec, we can use the following technique. Let's use a hypothetical variable for time, [i]t[/y]. At t = 0, the RGB line has just begun. At t = 1, the RGB line is finished. From 0 <= t <= 1, we capture the RGB line into a buffer the size of a single line. Since I am doing this digitally, this means 5 + 5 + 5 + 2 bits per pixel, * 384 (for the whole line, including blanking period). This comes from 5 bits of red, green, and blue, plus the SHAD and DAK bits.



    So, we've captured an entire line into the buffer. We will have two buffers, however, and alternate between them for every other line - one even buffer, and one odd buffer. Let's call them buffers A and B. As the odd buffer is captured, the even buffer is rendered out to the VGA output twice, at double the speed. So, at t = 0.5, the RGB output is halfway through capturing a line into buffer A, but the VGA output has just finished rendering an entire line from buffer B. It will then render buffer B again from the start from t = 0.5 to t = 1.0. Then, A and B will swap roles, and this process repeats forever. That's the basic principle of line doubling.

    The challenge with this design typically comes from getting the timings just right, as off of a JAMMA edge all you have for timing is the Csync information. From that you must determine a input and output pixel clock, and new sync info. Then, you must also do an analogue to digital conversion from the RGB signals present. On the Neo-Geo (and many other arcade boards), this information is available in pure digital format before the JAMMA edge. I mentioned above the 17 bits needed for a single pixel, but timing is the more important thing. The pixel clock is 6MHz - the rate at which an RGB pixel is generated. The CPU clock happens to be 12MHz, which is exactly double the pixel clock (both are divisions of the 24MHz master clock). Since I am trying to double our pixel timings, I will take advantage of this already doubled pixel clock and use it as the clock in my design. During the capture phase, I capture a single pixel every other 12Mhz clock (to match the 6MHz rate coming from the system), while during the display phase I output a new pixel every 12MHz pulse.

    The result is that the captured information is perfect. If displayed properly it is indistinguishable from an emulator. Since I'm using a 12MHz pixel clock, I'm really generating 320x480 video - half the resolution of VGA. That's fine, though - actually perfect - as that is what an exactly line doubled Neo-Geo should be.



    Stuff That's Tricky
    It turns out that while a CRT-based VGA monitor which operates primarily in the analogue domain is pretty allowing in what you give it, a lot of modern displays are particular about what they want from their VGA timings. I learned a lot about VGA output through this project. A few postulates I learned are listed below:

    1. Do not output ANYTHING during the sync pulse of a line.
    During the horizontal syncing period, and maybe some of the back porch, the display sees the voltage level on the RGB lines and clamps to them, meaning it basically treats that value as 0. So, if you are outputting 0.2V on your red line during that time that it should be blank, the red will be darker for that line. So, that needs to be lined up properly! The same seems to go during the vertical sync, though I haven't determined exactly how standard that is.

    2. Continue horizontal sync pulses during Vsync.
    It was hard to figure out whether Hsync should occur during Vsync or not. A few dell LCD monitors, and my big old sony CRT monitor sure didn't care, so I disabled it during Vsync. Then, a few monitors later, my HP 23xi would work, but intermittently drop the image. A few other monitors would show nothing. Turns out you should have it - I put it back, and now the HP monitor is 100% stable.



    3. The Neo-Geo's timings are a little odd, and so are the resulting VGA ones.
    It's hard to get the timings perfect in general, but for the Neo-Geo it's extra odd. Some VGA monitors just aren't okay with it. This is a great reason to go with the full-frame buffer solution that most scalers do, as it lets you deal with this fact. So, this project may just not be compatible with all LCDs. I've had great luck on almost every HDTV with VGA I've tested, but I can't guarantee it works on all.

    4. The Neo-Geo's CPU clock is ugly.
    I scoped out the CPU clock on my MVS systems (MV-1C, MV-1, MV-4) and all of them are very noisy and non-square. It should be a nice square wave pulse, but it is in fact an ugly wave that is almost sinusoidal. Fine for the 68000, I suppose, but it caused some missed / repeated clocks on my FPGA dev boards I tried. A Schmidt trigger (74HC74) solved this issue, but it had be going crazy for a little while trying to determine what the hell was wrong with my design.


    5. DAK and SHAD are poorly documented.
    The Neo-Geo output has a pretty primitive resistor ladder DAC. While I am capturing SHAD and DAK, I'm not 100% sure what to even do with them. Right now I have determind which one is supposed to dim the screen (I test by writing a value to 0x3A0011 and 0x3A0001 and it does work) but within the 8-bit VGA DAC I'm using it won't really look correct. Eventually I plan on just building a duplicate of the original Neo-Geo DAC for output so it will be perfect. A non-issue, but I found it a little odd.

    6. Your Vsync should be exactly two lines of time for 480 lines.
    I had it a little too long, and the display did some weird skewing stuff on my CRT. On a Sony LCD television it was even weirder:

    I made it two lines (768 CPU clock cycles) and it resolved itself.

    Future Work
    So, from here I'm not totally sure where I want to go. Right now the project is fairly stable, and even has a few tiny features like variable-intensity scanlines. However, once every now and then it will power up in a very odd state where the pixels will be captured all dirty, and flicker a bit on changing edges. I'm not sure of the cause. The next thing I will be doing is setting up a proper level converter, as right now I am passing my 5V levels into my 3.3V FPGA system, which is not great and I'm sure could cause issues in the future (though it is supposed to be 5V tolerant to some extent...). Perhaps this will improve things. Right now each line is a huge 384-position 17-bit shift register, which is not a great design, but it is what I am doing because I can not get block memory to be generated properly from ISE's IP core creator. My version of ISE is very old but nothing newer works on here, so it may be an actual bug.



    I think it would be neat to develop a board in the same spirit as the NESRGB board - something for ~$100 that people who are really into their Neo-Geo MVS or AES systems could install in their board with some precise soldering, and enjoy a video output superior to current solutions. There are 22 lines that need to be soldered for it to work. It's not that bad, fortunately everything is pretty clearly laid out on the system. I haven't an AES so I have not tested there, but I do not see why it would not work.


    I don't really know what is needed to go from the FPGA dev board to a proper separate board, though. If anyone is more experienced with this and has some pointers / recommendations, that would be appreciated. It doesn't use a lot of the FPGA's resources, so a smaller and cheaper one could be used. Certainly it will be many times cheaper than an XRGB system if finished. Some will cry out, "the GBS8200 works fine!" but I think if anyone is actually happy with a GBS8200 then they don't care much for video quality in the first place or don't want anything more expensive. I'd like for this to be $100 or lower. I'm using a Virtex-II Pro, which was new in 2003. Surely there are many old-stock or bare ones lying about, so this shouldn't have to be too expensive if a board was really produced.

    Oh, here's a VERY high resolution of Windjammers with the 50% scanlines enabled: http://mikejmoffitt.com/img/neovga/v...p/wjammers.jpg

    Anyway, if you have questions or suggestions I'd like to hear them. I'm not totally sure where to take this project from here, so any expressions of interest would be good motivation / a means to determine the future of it.
    Last edited by mikejmoffitt; 06-15-2014 at 10:38 AM.

  2. #2
    AH
    A
    COLUMBIAN!
    aha2940's Avatar
    Join Date
    Dec 2013
    Location
    Colombia

    Posts
    2,425
    Quote Originally Posted by mikejmoffitt View Post
    It implements a classic line-doubling method, which produces far less than a single millisecond of lag
    This is more than enough lag for me to die in Metal Slug LOL

    Just kidding, it seems a great project

    Regards.

  3. #3
    Mature's Make-Up Artist
    Niko's Avatar
    Join Date
    May 2014
    Location
    Kentucky

    Posts
    1,361
    Very cool. But what ~22 lines does it require from the board? That seems like alot. I would personally prefer an external solution to having to modify my MVS, or especially an AES. Can you not just use the RGB/Sync off the jamma harness?

    Also, I would be very interested in seeing a highres video of the screen in action. I was actually in the pre stages of reverse engineering my GBS8220, I had contacted gonbes to try an optain a data sheet for their GBS800MV but they wouldnt give it to me. My next step was going to be to decap the IC to see what it really was.

  4. #4
    Krauser's Henchman

    Join Date
    Dec 2011
    Location
    my crack den with Dr Shroom

    Posts
    1,089
    Like Niko49 said, I think people would really like a device which simply connected to the JAMMA edge. Then it would be awesome for the arcade scene as a whole. You could passthru everything but the RGBCsync pins and have a single dsub port on the box. Almost like a supergun, but without power supply or player controls of course.

  5. #5
    SouthTown StreetSweeper
    mikejmoffitt's Avatar
    Join Date
    Feb 2014
    Location
    San Jose, CA

    Posts
    569
    That would be nice... but that would defeat the entire purpose, as that's simple analogue data. The point is to bypass the need to decode analogue information and the sync line. Otherwise, what you'e described is an XRGB-3 in B0 mode. The needed lines are:

    5 bits Red
    5 bits Green
    5 bits Blue
    1 bit clock
    1 bit /reset
    1 bit SHAD
    1 bit DAK
    VCC
    Ground

    I suppose that's 21 lines. What could be done is a 3 pin connector with clock, reset, and ground, and the 17 bits of color data could be extracted with a DAC from the JAMMA connector. Still, this will be a less accurate image susceptible to noise. The point is that the image coming from this is *perfect*.

    Soon I will take a good video of it in action.

  6. #6
    Hades Gate Keeper
    Tyranix95's Avatar
    Join Date
    Jun 2010
    Location
    LA, CA

    Posts
    5,416
    He's correct: Analogue signal off the edge, Digital Signal before.

  7. #7

  8. #8
    SouthTown StreetSweeper
    mikejmoffitt's Avatar
    Join Date
    Feb 2014
    Location
    San Jose, CA

    Posts
    569
    Quote Originally Posted by Xian Xi View Post
    Very nice work dude. Where can we get the PCBs? Shoot me a proto if you want.
    I'm still not sure what is all involved in actually making a PCB - I don't know how to set it up to program itself on bootup, as I rely on my dev board's CF card-based solution for that. I do see a lot of very cheap Cyclone II dev boards from China for about $40, including the programming hardware, and they have active serial on-board. In the worst case, I can just get a cheaper $25 dev board with active serial on-board, and just have that plug into the board I design containing the connection pads and the video DAC. Worst case, I think I can definitely have a board available for under $100. Stay tuned - once I get my paycheck I'll order one of the tiny dev boards. They are about 3 x 3" so they should fit inside a CMVS shell at the very least, and definitely under the massive metal shield an MV-2 or MV-4 has.

  9. #9
    Banned
    Join Date
    Dec 2007
    Location
    Pensacola, FL

    Posts
    3,503
    Would love to see one of these boards in my AES at some point.

  10. #10
    Mature's Make-Up Artist
    Niko's Avatar
    Join Date
    May 2014
    Location
    Kentucky

    Posts
    1,361
    Quote Originally Posted by mikejmoffitt View Post
    I'm still not sure what is all involved in actually making a PCB - I don't know how to set it up to program itself on bootup, as I rely on my dev board's CF card-based solution for that. I do see a lot of very cheap Cyclone II dev boards from China for about $40, including the programming hardware, and they have active serial on-board. In the worst case, I can just get a cheaper $25 dev board with active serial on-board, and just have that plug into the board I design containing the connection pads and the video DAC. Worst case, I think I can definitely have a board available for under $100. Stay tuned - once I get my paycheck I'll order one of the tiny dev boards. They are about 3 x 3" so they should fit inside a CMVS shell at the very least, and definitely under the massive metal shield an MV-2 or MV-4 has.
    You've put to much work into this, for the final product to be a consumer grade dev board. Grab yourself a free copy of EAGLE from cad soft. There are tons of manuals online for creating PCBs. Its also fairly cheap if the pcb is smaller than 6x6 and only 2 layers. Look into OSHPark, they are cheap and do quality work for custom PCBs. Then if you have a hot air rework station or a modified toaster oven ( like I do ). You can reflow the FPGA and other SMDs with ease.

    As far as storing the program, Im not very familiar with FPGAs but you should be able to use EEPROM to store the program. There are some opensource FPGA dev kits out there that you could look at to see how they are managing it.

    If you need help just ask. I'm sure there are a ton of members that would be more than willing to lend you a hand, info, maybe even some financial support. Also, please tell me you are going to opensource the core when your done.

    http://papilio.cc/ - Open source FPGA dev board.
    http://www.cadsoftusa.com/eagle-pcb-...w/?language=en - EAGLE PCB Software
    https://learn.sparkfun.com/tutorials...agle-schematic - Tutorial on using EAGLE
    https://oshpark.com/ - PCB manufacturer
    Last edited by Niko; 06-08-2014 at 06:37 PM.

  11. #11
    SouthTown StreetSweeper
    mikejmoffitt's Avatar
    Join Date
    Feb 2014
    Location
    San Jose, CA

    Posts
    569
    Quote Originally Posted by Niko49 View Post
    You've put to much work into this, for the final product to be a consumer grade dev board. Grab yourself a free copy of EAGLE from cad soft. There are tons of manuals online for creating PCBs. Its also fairly cheap if the pcb is smaller than 6x6 and only 2 layers. Look into OSHPark, they are cheap and do quality work for custom PCBs. Then if you have a hot air rework station or a modified toaster oven ( like I do ). You can reflow solder the FPGA and other SMDs with ease.

    As far as storing the program, Im not very familiar with FPGAs but you should be able to use EEPROM to store the program. There are some opensource FPGA dev kits out there that you could look at to see how they are doing.

    If you need help just ask. I'm sure there are a ton of members that would be more than willing to lend you a hand, info, maybe even some financial support. Also, please tell me you are going to opensource the core when your done.

    http://www.cadsoftusa.com/eagle-pcb-...w/?language=en - EAGLE PCB Software
    https://learn.sparkfun.com/tutorials...agle-schematic - Tutorial on using EAGLE
    https://oshpark.com/ - PCB manufacturer
    Sorry, I should have been clear - I'm familiar with routing a board, I meant what support circuitry is needed for the FPGA. If only there could just be a simple application circuit diagram... I'll have to see what it takes to set up the serial EEPROM most boards seemto use.

  12. #12
    Mature's Make-Up Artist
    Niko's Avatar
    Join Date
    May 2014
    Location
    Kentucky

    Posts
    1,361
    Quote Originally Posted by mikejmoffitt View Post
    Sorry, I should have been clear - I'm familiar with routing a board, I meant what support circuitry is needed for the FPGA. If only there could just be a simple application circuit diagram... I'll have to see what it takes to set up the serial EEPROM most boards seemto use.
    I updated my post before I seen this. Check out the papilio, its an open source FPGA dev board. You can always see how they are handling alot of the things your uncertain about.

  13. #13
    Mickey's Coach
    MidnightMonkey's Avatar
    Join Date
    Jun 2014
    Location
    Frederick, MD

    Posts
    725
    It's ingenious stuff like this that makes me want to go back to college and get my engineering degree. I hope to god this comes to fruition before that ever happens. With two hobbies that demand a lot of moolah and a baby on the way, college is on the back burner. Keep up the good work!

  14. #14
    SouthTown StreetSweeper
    mikejmoffitt's Avatar
    Join Date
    Feb 2014
    Location
    San Jose, CA

    Posts
    569
    By the way, that windjammers picture is on a 100% brand new out-of-the-box 1080p LCD display. I don't know about the rest of you but I think the scanlines turned out pretty well there, no?

  15. #15
    Bunker Buster
    goombakid's Avatar
    Join Date
    Oct 2011
    Location
    Orygun

    Posts
    1,459
    Hello! Very nice! I saw your article that was linked at Hack-A-Day. Great work!
    ...console emulation has no soul...

  16. #16
    Vice's Love Slave
    shadowkn55's Avatar
    Join Date
    Dec 2006
    Location
    SoCal

    Posts
    2,171
    Nice work. Your implementation is pretty close to what I have conceptually. The main difference is that I use the 24mhz master clock instead. It's doesn't quite matter in this case because vga is an analog format and everything occurs in the time domain.

    Quote Originally Posted by mikejmoffitt View Post

    1. Do not output ANYTHING during the sync pulse of a line.
    During the horizontal syncing period, and maybe some of the back porch, the display sees the voltage level on the RGB lines and clamps to them, meaning it basically treats that value as 0. So, if you are outputting 0.2V on your red line during that time that it should be blank, the red will be darker for that line. So, that needs to be lined up properly! The same seems to go during the vertical sync, though I haven't determined exactly how standard that is.
    What you have just experienced is how vhs macrovision works. During hsync (and hblank for that matter) is when the video hardware creates reference levels for black. Fluctuations in the voltage during this period will cause the colors to go wonky because it is adjusting for what it thinks is the offset voltage for pure black. Basically, on the RGB lines, the voltage levels must be kept zero at all times except during active video.


    3. The Neo-Geo's timings are a little odd, and so are the resulting VGA ones.
    It's hard to get the timings perfect in general, but for the Neo-Geo it's extra odd. Some VGA monitors just aren't okay with it. This is a great reason to go with the full-frame buffer solution that most scalers do, as it lets you deal with this fact. So, this project may just not be compatible with all LCDs. I've had great luck on almost every HDTV with VGA I've tested, but I can't guarantee it works on all.
    You don't have to double the timing intervals of the neo geo to the letter. As long as the window you choose to sample from the line buffer still has the relevant data, you can rewrite the sync timings to better conform to the vga spec. Since you're running it at a multiple of the neo-geo pixel clock (2x), you may not have to worry about crossing clock domains as much.


    Anyway, if you have questions or suggestions I'd like to hear them. I'm not totally sure where to take this project from here, so any expressions of interest would be good motivation / a means to determine the future of it.
    You're doing great so far. Although VHDL is not my HDL of choice. I do all my programming in Verilog. Way less verbose and it reads a lot like C.

  17. #17
    SouthTown StreetSweeper
    mikejmoffitt's Avatar
    Join Date
    Feb 2014
    Location
    San Jose, CA

    Posts
    569
    Quote Originally Posted by shadowkn55 View Post
    You don't have to double the timing intervals of the neo geo to the letter. As long as the window you choose to sample from the line buffer still has the relevant data, you can rewrite the sync timings to better conform to the vga spec. Since you're running it at a multiple of the neo-geo pixel clock (2x), you may not have to worry about crossing clock domains as much.
    Fortunately I did realize this much early on, and it turns out that nothing would work if I doubled all pulses exactly, especially the vertical sync pulse. That would have meant 16 lines of VGA for a vsync pulse, definitely enough to irritate any display!

    This summer I am doing an internship in Nebraska, and I haven't got my scope, or a logic analyzer, so it's pretty hard for me to compare my VGA pulses to that of a "real" VGA source. Once I'm back home hopefully I can do that to get the VGA as kosher as possible.

  18. #18
    Another Striker
    KalessinDB's Avatar
    Join Date
    Dec 2013
    Location
    United States

    Posts
    319
    I have seen your work elsewhere and it never ceases to amaze me. I wish I had a quarter of your technical wizardry.

    Nice lookin bit of kit there, man!

  19. #19
    Vice's Love Slave
    shadowkn55's Avatar
    Join Date
    Dec 2006
    Location
    SoCal

    Posts
    2,171
    Quote Originally Posted by mikejmoffitt View Post
    Fortunately I did realize this much early on, and it turns out that nothing would work if I doubled all pulses exactly, especially the vertical sync pulse. That would have meant 16 lines of VGA for a vsync pulse, definitely enough to irritate any display!

    This summer I am doing an internship in Nebraska, and I haven't got my scope, or a logic analyzer, so it's pretty hard for me to compare my VGA pulses to that of a "real" VGA source. Once I'm back home hopefully I can do that to get the VGA as kosher as possible.
    The great thing about the vga spec is that it doesn't need to be exact. As long as the various intervals are close enough, you should be fine. Consistency is more important than trying to get the timings down perfectly.

  20. #20
    SouthTown StreetSweeper
    mikejmoffitt's Avatar
    Join Date
    Feb 2014
    Location
    San Jose, CA

    Posts
    569
    I'm happy to report that with a few changes I made last night to the timings, all the monitors it wasn't working on before now work just fine. With the latest build I haven't found any that don't work yet!

  21. #21
    Mature's Make-Up Artist
    Niko's Avatar
    Join Date
    May 2014
    Location
    Kentucky

    Posts
    1,361
    So quick question. Whats the advantage of doing it this way, instead of after the signal is converted into analogue? Just to avoid noise?

  22. #22
    Vice's Love Slave
    shadowkn55's Avatar
    Join Date
    Dec 2006
    Location
    SoCal

    Posts
    2,171
    Quote Originally Posted by Niko49 View Post
    So quick question. Whats the advantage of doing it this way, instead of after the signal is converted into analogue? Just to avoid noise?
    You remove the guess work involved with the interpolation in the a/d conversion. Analog signals are not as noisy as people are led to believe. It gets a bad rep because analog signals are normally associated with composite video or rf which are very noisy.

  23. #23
    Geese's Thug
    purple's Avatar
    Join Date
    Aug 2007
    Location
    KKTC

    Posts
    274
    keep up the work man, very good

  24. #24
    ネオジオ
    massimiliano's Avatar
    Join Date
    Feb 2004
    Location
    On the green!!

    Posts
    2,819
    great project! Keep it coming!
    凄いゲームを連れて。。。売った。

  25. #25
    SouthTown StreetSweeper
    mikejmoffitt's Avatar
    Join Date
    Feb 2014
    Location
    San Jose, CA

    Posts
    569
    So I'm looking into what all is needed to get this onto a board. Fortunately as far as FPGA projects go this one doesn't use a whole lot of the resources available, so even some of the cheapest solutions (Xilinx Spartan or Altera Cyclone series) are viable options. It looks like the best solution for having it program itself on boot-up is to have a small MCU read it off of an EEPROM and do the programming, as that'll facilitate firmware updates in the future. In addition, I wouldn't need to clock the EEPROM off of anything but the clock from the microcontroller.

    Once I get a box with more headers in it I'm going to wire it up to my MV4 board just to see it working on there (and verify that nothing funky happens to timings between a game switch).

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •