Nintendo 64 RGB Blur fixing

[zakruowrath]

I received a lot of emails about the N64RGB recently! It will be back in the shop in a few days, with the anti-blur feature added (switchable). All versions of N64RGB hardware have the same programming header as the NESRGB so the anti-blur feature can be added with a software update if you have the Byte Blaster programmer.

This should have been ready a couple of weeks ago, but I got a bit distracted by another project. At a my previous job I used to mostly write software with the occasional bit of hardware design. Now I mostly work on hardware and when I do write software, it's usually some fairly simple program on a microcontroller. Recently I started to do some work on the (open source) software tools that I use to design PCBs. I didn't realise how much I missed working on a large software project. Two weeks and a new release of software went by before I could put it away. (it live at http://www.pcbelegance.org/ in case anybody is interested)

Anyway, I have the new version of N64RGB hardware ready. It's basically the same as the old one with some extra solder pads. Inspired by the flex-cable from the Ultra-HDMI, I thought I'd have a go at making a flex adapter board to mate with the fine pitch DAC chip.



It turned out very well indeed. There's some double sided tape on the back. Just stick it down, solder to the DAC pins, then solder a standard 1.27mm ribbon cable to it. It's ten times easier than the previous method.

That is simply a beautiful piece of simple yet effective engineering, I'm thinking now this will make it easier and possible to have both RGB and UltraHDMI installed in the same N64

[borti4938]

I've installed both - the RGB mod as well as the UltraHDMI in the same console. However, I observed several discoloring effects, spontaneous sync losses and so on... It termed out that the RCP-NUS wasn't able to drive three devices: the MAV-NUS, the MAX II and the UltraHDMI (including the cables). As I was to lazy to install additional buffers, I decided to install the UltraHDMI into another N64.
This doesn't mean that all RCP-NUS has to have a problem with driving three ICs including the wire to those devices.

[zakruowrath]

I've installed both - the RGB mod as well as the UltraHDMI in the same console. However, I observed several discoloring effects, spontaneous sync losses and so on... It termed out that the RCP-NUS wasn't able to drive three devices: the MAV-NUS, the MAX II and the UltraHDMI (including the cables). As I was to lazy to install additional buffers, I decided to install the UltraHDMI into another N64.
This doesn't mean that all RCP-NUS has to have a problem with driving three ICs including the wire to those devices.

What kind of data buffers would you put in and where would they be in the circuit? Also would data buffers introduce any kind of lag to the picture?

I'd really love to have both boards but if there's too many issues then the Ultra HDMI would do just fine

[CobraKing]

^^^^
N64 consoles are relatively inexpensive - why not get a second one instead?

[borti4938]

What kind of data buffers would you put in and where would they be in the circuit? Also would data buffers introduce any kind of lag to the picture?

I'd really love to have both boards but if there's too many issues then the Ultra HDMI would do just fine

You just have to search for line drivers or non-inverting buffers. You would have to connect them directly to the RCP-NUS (or DENC-NUS, MAV-NUS, what ever) and connect the cables to the RGB Mod and the UltraHDMI to the output of the buffer. Lag would be in the nano-second domain.
But - too much effort to be honest Just give it a try whether it works or not. For me it hasn't work.
(If I had a N64 with a DENC-NUS, I would have removed the DENC-NUS for another try. But I have a MAV-NUS who also does audio processing.)

[bobrocks95]

Hey Tim, if you see this, were there manufacturing problems with the flex PCB or anything else gone awry? It's been quite a while since you said the new board revision would be on the store in a couple days, curious if you hit a snag or if other things just got in the way.

[Ikaruga11]

Any news on an RGB version of the Ultra HDMI?

[Guspaz]

Wouldn't that be the N64RGB?

[viletim]

Hey Tim, if you see this, were there manufacturing problems with the flex PCB or anything else gone awry? It's been quite a while since you said the new board revision would be on the store in a couple days, curious if you hit a snag or if other things just got in the way.

There's nothing wrong, I'm just a bit busy. I've updated the installation docs and also put the circuit diagram + software. It will available in the shop tomorrow.

I spent some time playing with borti4938's new software the other day and the result was no good. It didn't improve the video, it made it more blurry, not less. I was using the static 'you forgot to plug in your controller' screen from Mario Tennis as a test. I would like to investigate this further, but it will have to wait for another day.

All boards will be programmed with the usual (version 1.0) software that I've always used. For those that want to experiment, I've uploaded the software and programming information.

[andykara2003]

Thanks for the update Tim, much appreciated. Just to clarify, can the de-blur feature be toggled on and off with an external switch?

[bobrocks95]

Thanks for the update Tim. Do you think it's worth waiting for further testing on the de-blur to avoid buying a USB Blaster in the future for it? Could it be possible the wrong columns were being deleted as an explanation for why it's blurrier?

Thanks for the update Tim, much appreciated. Just to clarify, can the de-blur feature be toggled on and off with an external switch?

Sounds like it doesn't have the de-blur feature at all, unless I misread.

[andykara2003]

Ahh OK I'm a bit confused here - I was thinking that Tim was developing his own deblur software for us to update his new board. If that's not his intention, I'm not sure exactly what the situation is - I guess we would use Borti's software on the new board & that there would be no option to toggle the effect on or off. Am I off base here?

Do you think it's worth waiting for further testing on the de-blur to avoid buying a USB Blaster in the future for it? Could it be possible the wrong columns were being deleted as an explanation for why it's blurrier?

I'm wondering about this as well...

[borti4938]

I spent some time playing with borti4938's new software the other day and the result was no good. It didn't improve the video, it made it more blurry, not less. I was using the static 'you forgot to plug in your controller' screen from Mario Tennis as a test. I would like to investigate this further, but it will have to wait for another day.

Strange... For me it works fine. I also got another positive feedback as well as another negative feedback yet.

There might be two reasons for that:
1. The code is not stable enough...
2. PAL consoles and NTSC consoles might need inverted reset logic of the blanking...

I cannot test it - either the first nor the secon guess However, I send out a slightly modified version to viletim

[Blaasvis]

Well if you don't have a n64 ntsc version i could ship you one. I have to test them quickly. But i recon they are fine anyway.
I live in the netherlands so the shipping shouldn't be to expensive.

[bobrocks95]

Ahh OK I'm a bit confused here - I was thinking that Tim was developing his own deblur software for us to update his new board. If that's not his intention, I'm not sure exactly what the situation is - I guess we would use Borti's software on the new board & that there would be no option to toggle the effect on or off. Am I off base here?

Tim has the regular 1.0 software up on his site including the source code, and I would assume Borti could provide his code if you asked.

What I don't know is if there's a spare solder pad to add a switch on the new board or if you'd have to solder directly to the CPLD. Either way those without one already would have to buy a USB Blaster as well to flash the board.

Hopefully there was just a minor glitch and Tim can find the time soon to test it further. USB Blaster clones are cheaper than I thought they were, but it might honestly be faster to wait for Tim to test more than the month+ it would take to get one shipped from China.

[andykara2003]

Nice one :) I think I'll wait & see how the testing goes then.

Still unsure about the possibility of a switch to toggle the effect though. This would be ideal for me, but don't know if it'll be implemented in the software - time will tell...

[mvsfan]

The installation instructions dont mention it but on the first page for the n64rgb on Tims shop, i can see in the picture that there are 3 new pads towards the bottom of the board labeled M, A, G.

[bobrocks95]

The installation instructions dont mention it but on the first page for the n64rgb on Tims shop, i can see in the picture that there are 3 new pads towards the bottom of the board labeled M, A, G.

So G is ground and that would make for a 2-pole switch that shorted one or the other to ground? Do I have that right?

[andykara2003]

I send out a slightly modified version to viletim

Borti, it just occurred to me to ask - is it actually even possible that software running on Tim's board could provide an option to toggle the deblur effect on or off with a switch?

[RGB32E]

The installation instructions dont mention it but on the first page for the n64rgb on Tims shop, i can see in the picture that there are 3 new pads towards the bottom of the board labeled M, A, G.

So G is ground and that would make for a 2-pole switch that shorted one or the other to ground? Do I have that right?

http://etim.net.au/n64rgb/tech/n64rgb12.pdf

Tim posted a Circuit Diagram of hardware version 1.2 (PDF) under his Software and technical info page.

The M/A/G corresponds to Manual, Automatic, Ground per the v1.2 circuit diagram:


I surmise the two connections work like this:
Manual -> Ground == Force de-blur (240p only)
Automatic -> Ground == Automatically apply de-blur (320x240p only)

Just as a reminder, not all N64 "240p" games have a 320px width back buffer. It will be interesting to see if/how well Automatic detects non-square (>320px) 240p games.

[andykara2003]

Thanks for that :)

[Ikaruga11]

I've heard that the newer Funtastic model Nintendo 64s have better picture quality than the original charcoal grey N64. is this true? Do they have better RGB, or just composite and S-Video?

[Guspaz]

There's a difference, but it's not obvious if it's actually better rather than just different. MLiG covered it here: https://www.youtube.com/watch?v=qpy1M6v ... u.be&t=449

[borti4938]

I send out a slightly modified version to viletim

Borti, it just occurred to me to ask - is it actually even possible that software running on Tim's board could provide an option to toggle the deblur effect on or off with a switch?

It's already implemented. However, I wanted to make an update quite soon - just have to test it this evening before testing.
At the moment I'm curious about what does 'Manual' and 'Auto' exactly mean!?

[andykara2003]

Do they have better RGB, or just composite and S-Video?

The RGB output is the same.

It's already implemented.

Great, thanks!

[borti4938]

I spent some time playing with borti4938's new software the other day and the result was no good. It didn't improve the video, it made it more blurry, not less. I was using the static 'you forgot to plug in your controller' screen from Mario Tennis as a test. I would like to investigate this further, but it will have to wait for another day.

OK, after some testing I might have a clue why Mario Tennis looks blurry with the feature enabled: It seems like to me that Mario Tennis uses the full horizontal resolution while being in progressive mode.
The question is how to detect/estimate such a game!?!?

[atheistgod1999]

There's a difference, but it's not obvious if it's actually better rather than just different. MLiG covered it here: https://www.youtube.com/watch?v=qpy1M6v ... u.be&t=449

It's probably more noticeable on a CRT, though. Looking at that as well as other videos, it looks like the Framemeister somehow detects pixel width and averages out the video information received over a given amount of time to map to a virtual pixel on the screen, if anyone can follow me.

[bobrocks95]

I spent some time playing with borti4938's new software the other day and the result was no good. It didn't improve the video, it made it more blurry, not less. I was using the static 'you forgot to plug in your controller' screen from Mario Tennis as a test. I would like to investigate this further, but it will have to wait for another day.

OK, after some testing I might have a clue why Mario Tennis looks blurry with the feature enabled: It seems like to me that Mario Tennis uses the full horizontal resolution while being in progressive mode.
The question is how to detect/estimate such a game!?!?

So Mario Tennis is a weird exception and that happens to be the game Tim tested with? That's a big letdown...

[Guspaz]

That raises two questions:

1) How does UltraHDMI detect that scenario?
2) Does it actually need to be detected, as in, could a physical on/off switch be sufficient?

[viletim]

OK, after some testing I might have a clue why Mario Tennis looks blurry with the feature enabled: It seems like to me that Mario Tennis uses the full horizontal resolution while being in progressive mode.
The question is how to detect/estimate such a game!?!?

I recently ordered a logic analyser which I can use to look at the digital video data. Once it arrives (I suppose late next week) I'll be able to see the full story....

I send out a slightly modified version to viletim

Borti, it just occurred to me to ask - is it actually even possible that software running on Tim's board could provide an option to toggle the deblur effect on or off with a switch?

It's already implemented. However, I wanted to make an update quite soon - just have to test it this evening before testing.
At the moment I'm curious about what does 'Manual' and 'Auto' exactly mean!?

Auto asserted = Automatically de-blur at the appropriate time
Manual asserted = Always de-blur, regardless.
neither asserted = no de-blur, behave like original software

At least that's what I was thinking a few months ago when I revised the hardware. In practice, it's just a couple of extra input pads labelled A and M that a do whatever the software decides.