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

mikejmoffitt

Mickey's Coach
Joined
Feb 6, 2014
Posts
578
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:
lcd_full.JPG


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.

mai_close2.JPG


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:
Disp.png


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, 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.

rgb_pins.JPG


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.

kasumi1.JPG


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.

23xi.JPG


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.
12mhz_clk.JPG


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:
sync_skewing.JPG

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.

ribbon.JPG


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/v2psetup/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:

aha2940

AH, A, COLUMBIAN!,
Joined
Dec 15, 2013
Posts
2,528
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.
 

Niko

Whip's Subordinate
Joined
May 15, 2014
Posts
1,773
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.
 

Jassin000

Frenzy Football Player
Joined
Dec 9, 2011
Posts
985
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.
 

mikejmoffitt

Mickey's Coach
Joined
Feb 6, 2014
Posts
578
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.
 

Tyranix95

Chang's Grocer
Joined
Jun 30, 2010
Posts
4,593
He's correct: Analogue signal off the edge, Digital Signal before.
 

Xian Xi

JammaNationX,
15 Year Member
Joined
Dec 1, 2005
Posts
27,748
Very nice work dude. Where can we get the PCBs? Shoot me a proto if you want.
 

mikejmoffitt

Mickey's Coach
Joined
Feb 6, 2014
Posts
578
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.
 

Pope Sazae

Known Scammer, DO NOT DEAL WITH!, The Management.,
Joined
Dec 9, 2007
Posts
3,480
Would love to see one of these boards in my AES at some point.
 

Niko

Whip's Subordinate
Joined
May 15, 2014
Posts
1,773
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-design-software/product-overview/?language=en - EAGLE PCB Software
https://learn.sparkfun.com/tutorials/using-eagle-schematic - Tutorial on using EAGLE
https://oshpark.com/ - PCB manufacturer
 
Last edited:

mikejmoffitt

Mickey's Coach
Joined
Feb 6, 2014
Posts
578
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-design-software/product-overview/?language=en - EAGLE PCB Software
https://learn.sparkfun.com/tutorials/using-eagle-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.
 

Niko

Whip's Subordinate
Joined
May 15, 2014
Posts
1,773
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.
 

MidnightMonkey

Loyal Neo-Disciple
Joined
Jun 1, 2014
Posts
825
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!
 

mikejmoffitt

Mickey's Coach
Joined
Feb 6, 2014
Posts
578
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?
wjammers.jpg
 

goombakid

Fu'un-Ken Master
10 Year Member
Joined
Oct 11, 2011
Posts
1,537
Hello! Very nice! I saw your article that was linked at Hack-A-Day. Great work!
 

shadowkn55

Genbu's Turtle Keeper
15 Year Member
Joined
Dec 9, 2006
Posts
2,386
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.

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.
 

mikejmoffitt

Mickey's Coach
Joined
Feb 6, 2014
Posts
578
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.
 

KalessinDB

Mr. Big's Thug
Joined
Dec 17, 2013
Posts
202
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!
 

shadowkn55

Genbu's Turtle Keeper
15 Year Member
Joined
Dec 9, 2006
Posts
2,386
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.
 

mikejmoffitt

Mickey's Coach
Joined
Feb 6, 2014
Posts
578
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!
 

Niko

Whip's Subordinate
Joined
May 15, 2014
Posts
1,773
So quick question. Whats the advantage of doing it this way, instead of after the signal is converted into analogue? Just to avoid noise?
 

shadowkn55

Genbu's Turtle Keeper
15 Year Member
Joined
Dec 9, 2006
Posts
2,386
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.
 

mikejmoffitt

Mickey's Coach
Joined
Feb 6, 2014
Posts
578
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).
 
Top