borti4938 wrote:In the menu you'll have the controller reading word on the main page. ATM it's my test output but you can use that to see if the output reading is stable with your Hori pad.
Okay I've had a look at the readings from the Hori pad, it's strange - the N64A doesn't seem to be able to detect anything at all from it.
In the background I am running a controller test ROM that you can see is picking up the inputs from the Hori pad. I had to hotswap the pads as I cannot bring up the menu with the Hori, but if I plug the original pad back in the inputs are once again detected.
Thank you for the feedback!
Unfortunately I do not own such a pad. I have to look on an oscilloscope to see what is exactly going on. I will try to find someone on the German forums to borrow me one.
borti4938 wrote:Thank you for the feedback!
Unfortunately I do not own such a pad. I have to look on an oscilloscope to see what is exactly going on. I will try to find someone on the German forums to borrow me one.
Well I am in the UK rather than Germany but I would be very happy to loan you mine.
Thank you for the offer. I'll come to you back if I cannot find somebody from Germany.
But meanwhile, it could be also something completely simple. I restricted the reaction time to 64us after the N64 command for input reading. Maybe it's too short for the Hori pad. Here is a build where I increased the timeout to 1ms: https://www.dropbox.com/s/ak6zennu4n1wy ... 4.rar?dl=0
maybe it could be also something to do with the very last check bit (actually it's a controllersymbol which is neither a 0 nor a 1 by protocol). But this could we try next...
borti4938 wrote:Thank you for the offer. I'll come to you back if I cannot find somebody from Germany.
But meanwhile, it could be also something completely simple. I restricted the reaction time to 64us after the N64 command for input reading. Maybe it's too short for the Hori pad. Here is a build where I increased the timeout to 1ms: https://www.dropbox.com/s/ak6zennu4n1wy ... 4.rar?dl=0
maybe it could be also something to do with the very last check bit (actually it's a controllersymbol which is neither a 0 nor a 1 by protocol). But this could we try next...
The Hori Pad uses different timings for the protocol... Unfortunately, I cannot find the source.
A strategy that should work with any controller would be to count the time the line is high and low and based on the count you can guess if it was supposed to be a 1 or 0.
In a small research I haven't found any information about that the Hori pad modifies the protocol timings. I also doubt that the PIF-NUS / PIF(P)-NUS allows for a large variance until I see something different.
I also found another reading implementation, where the problem is tackeled in the same way as I do; just with a higher sampling rate but also with a threshold at 2us.
Thanks for looking into it, I tried the test build and unfortunately still no luck. Happy to test out anything else you suggest. There is always a possibility that something is off about my controller, N64 or installation so if anyone else is able to test it that would help rule it out. I believe this controller is pretty popular.
borti4938 wrote:In a small research I haven't found any information about that the Hori pad modifies the protocol timings. I also doubt that the PIF-NUS / PIF(P)-NUS allows for a large variance until I see something different.
I also found another reading implementation, where the problem is tackeled in the same way as I do; just with a higher sampling rate but also with a threshold at 2us.
borti4938 wrote:In a small research I haven't found any information about that the Hori pad modifies the protocol timings. I also doubt that the PIF-NUS / PIF(P)-NUS allows for a large variance until I see something different.
I also found another reading implementation, where the problem is tackeled in the same way as I do; just with a higher sampling rate but also with a threshold at 2us.
borti4938 wrote:In a small research I haven't found any information about that the Hori pad modifies the protocol timings. I also doubt that the PIF-NUS / PIF(P)-NUS allows for a large variance until I see something different.
I also found another reading implementation, where the problem is tackeled in the same way as I do; just with a higher sampling rate but also with a threshold at 2us.
I was wrong - Fantastic! Thank you!
Obviously I throw away the complete read at the very end check symbol. That‘s why you will not have at least anything...
I continuity tested each wire of the 10-pin cable. The cable is ok.
I then connected to a logic analyzer and recorded the signals when attempting to program the board (see pictures below). I'm running out of ideas! It seems like I am missing something very simple. Any more ideas? Thanks again!
Anyone know where I can purchase a Tim Worthington board with the fine pitch adapter?
Displays I currently own:
LG 83C1(OLED),LG 77C2(OLED), LG 42C2(OLED),TCL 75R635(MiniLED),Apple Studio Monitor 21(PCCRT),SONY 34XBR960x2(HDCRT)
SONY 32XBR250,Samsung UBJ590(LED),Panasonic P50VT20(Plasma),JVC NZ8
Bahn Yuki wrote:Anyone know where I can purchase a Tim Worthington board with the fine pitch adapter?
The only web shop I'm aware of is Tim's shop, but unfortunately it seems it's out of stock. You may want to PM either Tim or borti to see if they sell directly.
@mybook4
Do you use a Chinese USB Blaster clone? If yes, I've read somewhere that there are versions out which need a 'special' windows driver. Not sure if you want to try it, but if so, just write me a PM.
Just a follow-up. It turns out Borti was right on the money. I am using a blaster clone and it turned out to be a driver issue. The issue was resolved by uninstalling the v17 programming utility and drivers, installing the FBX-linked v13 Altera utility (with drivers), then installing the v17 utility again. Thanks for the link Syntax!
Afterwards, the jic was able to be successfully flashed to the N64A board. Enjoying the amazing menu!
I am having an issue that I cannot figure out. I modded two systems back and they both have the same issue with the display. Im not sure what exactly the issue is referred to as:
VeeThree wrote:I am having an issue that I cannot figure out. I modded two systems back and they both have the same issue with the display. Im not sure what exactly the issue is referred to as:
VeeThree wrote:I am having an issue that I cannot figure out. I modded two systems back and they both have the same issue with the display. Im not sure what exactly the issue is referred to as:
On my second install of the N64RGBA. I get a black screen with sound on PVM.
I installed it and tried to jtag but kept getting jtag chain error. So just to rule out the port or the clone usb blaster . I took the flash from the working unit and tried. I only get a black screen with sound. Without flash I would get a black screen.
Things to note
Regular composite works.
U6 measured 1.2 and U7 measured 2.5
3.3 and 5v measured fine.
I checked for shorts. This is also the VDC-NUS version, its almost impossible to get shorts on that. I doubled checked anyway.
Pins 3 and 7(luma/Csync) are bridged and I am using a luma sync cable which worked with the other unit
You can check continuity of clock and sync between the FPGA and the ADV7125 (U2). Sync is pin 59 to 12 and VCLK is pin 43 to 24.
You can also check the separated sync output. This is pin 99 of the FPGA to R31 and pin 6 of the 74LVC3G17 (U4).
Dumb question I know, but with like 50+ pages of this thread, having some trouble finding things. Is there a guide somewhere to updating the N64RGB with the de-blur firmware? I still have one of the old models, so I would like to update it and, ideally, set it to always have deblur on. I have a USB Blaster that I previously used to update my NESRGB, just need to know where to get the firmware and what wires to hook up where. Thanks!
thebigcheese wrote:Dumb question I know, but with like 50+ pages of this thread, having some trouble finding things. Is there a guide somewhere to updating the N64RGB with the de-blur firmware? I still have one of the old models, so I would like to update it and, ideally, set it to always have deblur on. I have a USB Blaster that I previously used to update my NESRGB, just need to know where to get the firmware and what wires to hook up where. Thanks!
Assuming that you're using Viletim's N64RGB board, you can use the latest POF file here:
thebigcheese wrote:Dumb question I know, but with like 50+ pages of this thread, having some trouble finding things. Is there a guide somewhere to updating the N64RGB with the de-blur firmware? I still have one of the old models, so I would like to update it and, ideally, set it to always have deblur on. I have a USB Blaster that I previously used to update my NESRGB, just need to know where to get the firmware and what wires to hook up where. Thanks!
Assuming that you're using Viletim's N64RGB board, you can use the latest POF file here:
I am, thank you! However, seeing as I have an older one, I don't have the A and G pads to solder to enable the deblur. What do I need to do to make that happen? I also notice there are two POF files in there, one ending in igr and one ending in sw. What's the difference?
CobraKing wrote:You'd have to ask @borti4938 about the soldering pads.
The IGR suffix is for in-game routine, i.e. you press a specific button combination to enable/disable de-blur. The SW suffix is for a physical switch.
I think the IGR suffix might work in your case, just read up a bit if you can. I don't want you to brick your N64 RGB!
Ah! Nevermind, on further digging I see that the A/M pads are really just extensions of pins on the CPLD. So I would just connect pin 100 to ground to have it on via the heuristic, M to ground to have it force on.
I just started playing around with a console with an N64Advanced board. It's a great device! I'm thinking of leaving the de-blur setting on auto. Does borti or anyone else have a list of games in which it is better to force either on or off? What about a list of 15bit color games?
The line doubling mode is really interesting, and I'm happy that the board supports 480p output through a SCART cable. When combined with the OSSC doubling the 480p output it rivals the look of line3x/5x. I can't decide which one I prefer, but the 480p doubled may actually look a little sharper on my display at least.
fernan1234 wrote:I just started playing around with a console with an N64Advanced board. It's a great device! I'm thinking of leaving the de-blur setting on auto. Does borti or anyone else have a list of games in which it is better to force either on or off? What about a list of 15bit color games?
The line doubling mode is really interesting, and I'm happy that the board supports 480p output through a SCART cable. When combined with the OSSC doubling the 480p output it rivals the look of line3x/5x. I can't decide which one I prefer, but the 480p doubled may actually look a little sharper on my display at least.
Borti talks about the benefit of 15bit color mode here: