Direct HDMI output for N64 (and other consoles)...

Discussion in 'Nintendo Game Development' started by OzOnE, Nov 13, 2012.

  1. Calpis

    Calpis Champion of the Forum

    Joined:
    Mar 13, 2004
    Messages:
    5,906
    Likes Received:
    21
    Frames overlap?

    If your raster lines converge then with interlaced video which has twice the lines per unit area, each line would seep into the previous field's lines above and below it. I'm not sure how that would look, but I presume not great.

    Every CRT I can remember has had visible scanlines, you just have to get up close to see. On my current CRT they are ~1/10 the line width. I don't see how you could not have scanlines unless the dot pitch is approaching the line height.

    Traditionally it's not necessary to keep track of the field or do anything, the 0.5-line-early deflection is what offsets the beam 0.5 lines above the topmost even line.

    Most likely the monitors you speak of are aren't analog/they're performing some sort of sync processing (useful for multi-sync and cleaning up the malformed sync signals from arcade games).
     
    Last edited: Nov 29, 2012
  2. OzOnE

    OzOnE Site Supporter 2013

    Joined:
    Nov 10, 2011
    Messages:
    538
    Likes Received:
    173
    Hi, all,

    Just an update on the HDMI thingy...

    I've added an output flag to the code which detects whether the N64 is outputting an interlaced signal or not (480i / 576i)...

    With the interlaced modes, on the first line (after the rising edge of vsync), the hsync pulse happens half-way through a line on alternate fields (as @calpis poiinted out),
    but with progressive modes (240p / 288p), the rising edge of hsync happens at the same time as the rising edge of the vsync pulse...

    So, to detect between interlaced and progressive, I just check the state of the hsync signal directly after vsync goes high.
    If hsync toggles on alternate frames, the output is interlaced, if hsync is always high, it's progressive.

    EDIT: Forgot image. Here is a SignalTap capture of the sync pulses (240p, Hsync always coincides with first Vsync)...

    [​IMG]

    Oh, damn it!! Only just noticed...
    Does that mean that the sync pulses are active-HIGH after all!! That explains a lot. :redface-new:
    Might also explain why my line counting was a bit dodgy. lol

    EDIT2: Ok, it seems that the "blue" coloured signals are post-fitting, so the software has inverted them after compilation.
    It's nice to have another thing to worry about. lol So, The signals are active-LOW as originally thought. phew...

    [​IMG]

    It seems Hsync actually stays LOW on the rising edge of Vsync for progressive signals. Fixed.

    The PAL detection is also working (just checks if the total lines == 625).

    I've assigned these signals to two LEDs on the FPGA board and it's interesting to see how often certain "hi-res" games switch modes...

    With Vigilante 8: 2nd Offence, the title screen is hi-res and looks very nice, but as soon as the animation starts where the logo (tumbles) into the distance, it switches to low-res mode.
    The attract demo is also low res, so it's only hi-res on the title screen, or in the game itself if you select hi-res.

    (It looks like 480i modes are displaying fine because the two fields both belong to the same framebuffer frame.)

    With PAL games, it's displaying OK but missing a small part of the image to the right and lower part of the screen.
    This is just because I'm still using 480p output timings instead of 576p, but I'll fix this soon.

    Also, I've managed to do a nice overclock on the RCP (and hence the CPU)...

    Originally I tried generating the clock signal from the FPGA itself to run the RCP, but it was too unstable (wiring too long, impedance not matched etc)...
    So I just changed crystal X1 to a 20MHz one. The result is that the RCP is now theoretically running at 85MHz instead of 60.852265MHz!

    On a stock NTSC N64, X1 is normally 14.31818MHz (four times the NTSC carrier freq of 3.579545MHz). This gets internally multiplied by PLL chip U7, then divided by 5 to generate "VCLK"...

    14.31818MHz * 17 / 5 = 48.681812MHz

    This master "VCLK" clock supplies the video output timing + video DAC, possibly the audio master clock too?

    The RCP then multiplies VCLK internally by 1.25 to generate the main graphics clock...

    48.681812MHz * 1.25 = 60.852265MHz

    AFAIK, this is what the RCP itself actually runs at.

    The graphics clock is then supplied unchanged to the MIPS CPU's Masterclock input.

    The CPU then multiplies this again by 1.5 to generate the CPU clock (assuming stock pin settings)...

    60.852265MHz * 1.5 = 91.2783975MHz.

    This is a bit lower than I expected, unless I'm missing something obvious (quite likely).

    It looks like the CPU on a PAL console runs at 93.10599375MHz.
    In this case, crystal X1 is 17.734475MHz (four times the PAL carrier freq of 4.43361875MHz), but the PLL chip only multiplies by 14 instead of 17.

    OK, so to cut a long story short, my N64 is running fine with this...

    XTAL = 20MHz
    VCLK = 68MHz
    RCP = 85MHz
    CPU = 127.5MHz


    The reason it doesn't screw up the video signal is because the FPGA can happily accept these different frequencies then outputs it as 480p.
    All I need to do when I change the crystal is adjust the PLL in the FPGA slightly to keep the 480p / HDMI output timings happy.

    The obvious problem with this "overclock" is that it speeds up the audio as well as the animation timing.

    I haven't changed the RDRAM clock at all, so if it's causing any bottlenecks, it might actually be worse due to the CPU / RCP trying to cram more data through it per second.

    The result is quite amusing though. The voices all sound like chipmunks and the music is faster too.
    Everything apart from the RDRAM is overclocked to around 140%, so even the timing of MIDI sequences is faster.

    I'll have to make a vid of it soon, it's quite amusing. :witless:

    Although the effective frame rate is faster, it still looks like it's lagging at the same points (relative to the faster overall speed).
    So, it's probably the RDRAM latency which causes the problem (eg. on things like Goldeneye multiplayer when lots of explosions are happening).

    This is what many others had pointed out in the past - RDRAM was supposed to be revolutionary back in the day, but it was expensive and didn't survive very long in the PC market.
    It might have fast peak throughput of data, but apparently had relatively poor latency performance?

    I might try overclocking the RDRAM by a small amount as well.

    UPDATE: I tried overclocking the RDRAM with a 16MHz crystal instead of the usual 14.7MHz to give 272MHz, but it froze quite often (as others have found).
    The 14.7MHz crystal was obviously chosen so the RDRAM master clock was around 250MHz (X2 gets multiplied by 17).
    So not much point trying to overclock the RDRAM, it's running at it's max speed already.

    The real aim of all this is to patch the ROM images so the video framerate / animation and audio is back to normal speed, but the RCP keeps the better fill rate performance.

    We might then have a bit more power for hi-res games. With Castlevania: Legacy of Darkness, the frame rate seems to keep up fine with the overclock.
    This tells us that the RCP / RDP draw rate is often the limiting factor with hi-res frame rates.

    OK, so that was fun to mess around with, but basically the HDMI output is looking very nice.

    There are still some issues though - there's a roughly 1-in-4 chance that you'll get four thin vertical lines down the screen at switch on, I'll have to figure that out.
    (if you keep switching off then on, you eventually get the lines to disappear).

    It's also still not outputting each 240p / 288p "frame" on separate 480p frames (no line doubling), as it will be quite tricky to figure out with this setup.
    Luckily, it looks fine on my TV. I do notice the odd mouse-teeth on very fast moving objects, but it's not bad.

    OzOnE.
     
    Last edited: Dec 2, 2012
  3. Chilly Willy

    Chilly Willy Robust Member

    Joined:
    Mar 15, 2011
    Messages:
    242
    Likes Received:
    0
    Overclocking is one of those things that tends to vary from one system to the next. While your N64 runs with a 20MHz xtal, maybe someone else's will only work at 18MHz, and perhaps someone else's would work at 22MHz. There's also the matter of long-term viability - some systems will run at a higher speed for a short time... and then burn out completely. I'm not sure I'm ready to do a durability test on my N64 for overclocking. :D

    Yes, RAMBUS RAM has a very high latency. It's something N64 homebrewers need to keep in mind when working on the N64. While most PC makers went with wide and slower ram interfaces (like two 64-bit SIMM/DIMM modules accessed in parallel), RAMBUS tried narrow and super-fast ones. The ram bus on the N64 is only 18-bits wide! That's 16 data bits with 2 parity bits... which the RDP can use for extra alpha bits in 16-bit color mode.

    Anywho, sounds like the HDMI interface is coming along nicely. This would be a real boon for use with HDTVs.
     
  4. APE

    APE Site Supporter 2015

    Joined:
    Dec 5, 2005
    Messages:
    6,416
    Likes Received:
    138
    Out of all of the N64s I've tried to overclock, a late model (an 08 IIRC) failed to do anything and another (05 IIRC) would overclock for a while and then freeze.

    All of the 03 and 04s (easily RGB modded models) have overclocked with only 1 problematic unit which I'm guessing may have something to do with being shipped to France. Once it got there it would quickly freeze which could have been damage from transit or maybe something to do with a voltage step down device being poor at what it does. My default is to run the multiplier to 2x from 1.5x. Never bothered to try 3x.
     
  5. OzOnE

    OzOnE Site Supporter 2013

    Joined:
    Nov 10, 2011
    Messages:
    538
    Likes Received:
    173
    Yeah, I wouldn't want to push the overclock much faster than it is tbh. The RCP on this console seems to be perfectly happy running at 85MHz though.

    Many N64's seem to run with a 2x CPU multiplier (~121MHz), so it's similar to what this is running at.

    The HDMI is looking nice. The only issue is the vertical lines down the screen on most boots?
    It must be an async problem where the Read / Write signals to SDRAM are clashing or something?
    I can't see on SignalTap what could be causing the issue?

    I've now combined the flags for "interlaced" + "pal" to give the following modes...
    n64_mode, 0 == 240p, 1 == 480i, 2 = 288p, 3 == 576i.

    It's funny seeing which games switch between 240p and 480i.
    I always wondered why the title screen on KI: Gold looked so nice. Now we know. :encouragement:
    The whole title screen + character stats screens are in 480i, but it switches back to 240p for the actual gameplay (just like on Vigilate 8: 2nd Offence).

    I'm not sure how to implement the HDMI adapter as an "upgrade" kit?
    I was thinking about how it could be soldered to the vid DAC easier using a short ribbon cable?

    It would also be nice to encode the I2S audio from the N64 into S/PDIF (optical output), then eventually send the audio via HDMI (will be a pain to code).

    There are still a few things to be done...

    Fix the "vertical lines" issue at power-up.
    Find the best H/V positioning for the image vs TV for different games.
    Implement line doubling for 240p / 288p.
    Maybe output NTSC at 640x480p so the aspect is slightly better matched?
    Get the proper 576p output mode working.
    Clock the data into SDRAM twice as fast to allow full 21-bit colour.
    Possibly implement multiplayer privacy / zoom modes and add extra HDMI outputs.
    Test the HDMI signal levels to ensure correct voltage swing / current ('cos it's using LVDS drivers, not TMDS).
    Find the best priced FPGA for the job which will work reliably at HDMI speeds.
    Do the PCB layout and get boards made.

    So, not much to do then. lol

    I really don't want to let this project die, but I'll certainly be using it on my N64 from now on (no more crappy video issues, yay!).
    I might even mod this console to remove the AV Multiout socket completely and just stick the HDMI socket there. :witless:

    I've tested a fair few games now (NTSC + PAL), and all work fine.
    (The top quarter of the DRAM in my V64 is faulty though, so I can't try 256Mbit ROMs atm.)

    I don't think it's feasible to use the SDRAM on the FPGA board to do cart emulation + HDMI output simultaneously,
    but maybe a chunk of SRAM might work better for the HDMI framebuffer?

    In theory, the HDMI / CEA standard has equivalent timings for 240p / 480i / 288p / 576p, so it should be possible to completely do away with the SDRAM framebuffer?
    It will just take a long time (for me) to figure out the proper timings etc.

    It's not just a case of passing the sync / data straight through because a lot of these lower-res modes need the pixels to be double-clocked when going via HDMI.
    There's also the problem that the HDMI / CEA spec appears to need the pixel repetition value sent via the "data island" periods. That won't be easy either.

    Oh well, it's almost working as is, and SDRAM is quite cheap these days.
    When a ready-made FPGA board with SDRAM is only $41 from china, it suppose it's not worth worrying about. hehe

    OzOnE.
     
  6. Calpis

    Calpis Champion of the Forum

    Joined:
    Mar 13, 2004
    Messages:
    5,906
    Likes Received:
    21
    No doubt it's incorrect. LVDS is a very different technology than CML/TMDS drivers. I'm surprised it even works for you. Depending on how the LVDS driver is constructed you could potentially be pulling down a 50 ohm load which would be a disastrous 66 mA, so your LVDS driver must be sink-current limited to 3.5 mA. So the "only" problem is that the signal swings 175 mV instead of TMDS' 500 mV.
     
  7. OzOnE

    OzOnE Site Supporter 2013

    Joined:
    Nov 10, 2011
    Messages:
    538
    Likes Received:
    173
    Yep, I'm a tad worried about that.
    I was thinking of using a level converter IC (commonly found in laptops these days), but it would be nice to find a solution which doesn't use a separate chip.

    Although, I guess an HDMI transmitter IC with bt.656 input wouldn't take up many more pins, since it's already using 8 pins as it is.
    This will require a custom board though of course, and finishing a PCB layout has always been a problem for me. :moody:

    I've only been using Eagle (for 6 or so years though), and it's autorouter isn't great.
    (I know many people manually route their boards, but it's not my idea of fun.)

    I've played around with Altium Designer, but it looks like will take a long time to learn.

    The direct HDMI output seems perfectly stable at these frequencies though (27MHz pix clock * 5 == 135MHz clock to DDIO, which doubles the data rate to 270MHz).

    Do you think the current could be limited using resistors, or some simple output drivers made?

    OzOnE.
     
  8. Calpis

    Calpis Champion of the Forum

    Joined:
    Mar 13, 2004
    Messages:
    5,906
    Likes Received:
    21
    Nobody level shifts for HDMI unless they absolutely HAVE to due to the bandwidth, so parts out there are just obscure and overpriced. Don't bother, any recent FPGA has TMDS drivers.

    When dealing with high speed signals like this you kinda have to route your own boards in order to keep a precise 50 ohm characteristic impedance. Obviously horrific signal integrity doesn't necessarily mean something won't still work lol

    Since CML and LVDS are current driven, there's no way to protect the driver without screwing up the output impedance. No matter what your LVDS outputs will source/sink 3.5 mA since that's the most common spec. Building your own true CML driver would be very difficult if not impossible with discrete parts at such high speeds. I developed a really hackish voltage-mode HDMI driver using only 3.3V CMOS outputs and resistors, but I doubt it will perform well enough to be used in any video application. Basically it's a 1-bit DAC with controlled output impedance so that the voltage divider between the DAC and receiver termination resistor yields a few hundred mV. If you don't mind pushing the output drivers to 20 mA then it's possible to get the full 500 mV swing.
     
    Last edited: Dec 3, 2012
  9. reprep

    reprep Gutsy Member

    Joined:
    Jun 8, 2012
    Messages:
    475
    Likes Received:
    1
    congratulations,

    i think you have accomplished most of what you want.

    just wondering, did you get the chance to try 480i and 240p modes via hdmi with external timing. you said it is tricky but as you will try to use PAL timing for PAL games (720x576p), i thought maybe you might give these other modes a try too.

    also for me it would be perfect when 21 bits output and 240p line doubling is done.
     
  10. Unknown-Organization

    Unknown-Organization <B>Site Supporter 2014</B>

    Joined:
    Sep 28, 2011
    Messages:
    782
    Likes Received:
    6
    Can anyone tell me why HD TV looks awful on Retro gaming console. HDTV is been out six years now and none of them have solve that issue yet. Surprisingly watching DVD on PS3 with upscale setting and looks so good on HDTV, why cannot be done on games platform ?
     
  11. smf

    smf mamedev

    Joined:
    Apr 14, 2005
    Messages:
    1,255
    Likes Received:
    88
    They are analogue, bog standard 15khz rgb monitors with composite sync (like scart). They just don't treat odd and even fields any differently.

    Scan lines and dot mask are quite different. If you connect something like a C64 to a monitor with visible scan lines then you get a line of pixels followed by the same width of black. None of my TV's have had anything like that visible, but monitors do. The dot mask is way way thinner than a scanline.
     
  12. Calpis

    Calpis Champion of the Forum

    Joined:
    Mar 13, 2004
    Messages:
    5,906
    Likes Received:
    21
    What I'm trying to explain is that as an analog monitor, presumably with a functioning sync separation circuit, they have no choice in the matter whether the odd field is offset. The only ways it can be screwed up that I can think of would be to purposefully latch Vsync using Hsync for consistency, or maybe to have a very strong PLL loop filter that rejects the early Vsync. Either way it makes no sense because interlacing is a "free" feature. Perhaps on such monitors interlaced video IS being offset, but since they are calibrated for 240p, interlaced rasters overlap and only APPEAR to be in the same vertical position.

    My comment was that when the dot pitch approaches the width of a line (very small screen), only then is it possible for 240p scanlines to not exist (on a television, which is calibrated for interlaced video). With a sufficient dot pitch, correct vertical size etc, CRT TV must have them. I never said they will be as pronounced as monitors with the "same width of black", which have a higher dot pitch and a raster that can't be defocused/scattered/wide enough for such a low resolution (if they could, there would be significantly less black too).
     
    Last edited: Dec 4, 2012
  13. dacide

    dacide Newly Registered

    Joined:
    Nov 21, 2011
    Messages:
    3
    Likes Received:
    0
    Hi OzonE!
    Any progress?
     
  14. RetroSwim

    RetroSwim <B>Site Supporter 2013</B><BR><B>Site Supporter 20

    Joined:
    Dec 10, 2012
    Messages:
    605
    Likes Received:
    26
    The upscaling systems built in to HD displays are designed to make filmed "real life" scenes look good. They are geared towards soft edges, natural colours, human movement, etc.

    They aren't designed for sharp edges, flickering graphics, bright contrasty colours, etc that are found in classic games.

    The upscaler in the PS3 is probably better than the one in your TV, plus it can be updated if Sony chooses.
     
  15. bagheera

    bagheera Rising Member

    Joined:
    Aug 1, 2014
    Messages:
    65
    Likes Received:
    3
    I am working on a similar project. I want to read out the digital video signals from the RCP and generate a VGA signal from this (after this I will try to upgrade this to HDMI, but I don't have the equipment for that atm). I have been working on an SDRAM controller that should have enough bandwith to write the N64 image and also read it out for the VGA signal. I am facing one challenge. I don't know a lot about video signals. I am not completely sure what I can do best with the signal to convert it to VGA.

    At the moment I have my FPGA hooked up to the N64 video bus. I am using an Everdrive to play NTSC games. I have been observing the video signals. It seems a line only has 626 pixels of image data. I suppose the most logical resolution for my VGA output would be 640x480. This would mean however that I would have 16 visible black pixels on a monitor (I guess they don't have overscan). I haven't looked at how many lines have image data, but I guess this is also probably less than 480. So basically the image is too small for 640x480 VGA.

    Of course I also need to take interlaced signals into account. At the moment I think I will just line double every field. I suppose every even and odd field can also be combined harmlessly, since I doubt there are any games that run at 480i with true 60fps, so there shouldn't be any "combing".

    So my question is, what is an easy way to convert the N64 image to a suitable VGA image. My guess would be to just keep the original size of the N64 image and have black borders around the VGA picture. :( Does anyone know how other people (Ozone, MarshallH) do it?
     
sonicdude10
Draft saved Draft deleted
Insert every image as a...
  1.  0%

Share This Page