Well... in the future I am planning to redesign the N64 on a smaller PCB, much like Kibble attempted on Ben Heck. the idea of it is to have EVERYTHING on one board. While I'm not ready for that stage yet, I already rigged a prototype of how the video will work and thought others might be interested in hearing. I used the screen LQ035NC111.
I know what you are thinking: "You cant use that screen, it doesn't have " a driver. Well, that is the point of this exercise, making one.
The board itself uses a cpld and takes the digital data from the RCP-NUS, ignoring the MAV-NUS (in this case) or the DENC-NUS. I found the following link immensely helpful when trying to understand the N64 video protocol. It also has an integrated dc converter to generate the ~20v required for the back light. The rest of the screen runs on 3.3V, which is one of the reasons I am trying to accomplish this: eliminating the 5v supply and the 12v supply, being able to power the whole thing from a single cell (voltage wise).
If you look closely, you'll see that the colors are off and look bad. In part, the camera angle in that picture is partly responsible, see the next picture.
However, most of the color discrepancy is caused by rather simple issue: I'm throwing half the picture away because my test probes can't be on adjacent pins and I also had a limited number of test probes. I'm not even trowing the least significant bits only, but every other bit since, well, the probes only let me reach every other pin and the vsync/hsync are present on the least significant bits. Which means, I'm throwing most of the picture quality away.
Of course, if I manage to make the N64 into a board, I would use all pins instead of throwing half the image away. If I have time, I will be posting the schematic and CPLD code (well, schematic since I used the schematic-like programming provided by Altera) tomorrow for educational purposes. The schematic has a mistake, as evidenced by the wire on the PCB and the CPLD code....well, lets just say there where parts were I proceeded by trial and error, thus, the solution is not exactly the most elegant one
.
Michael Chen
I know what you are thinking: "You cant use that screen, it doesn't have " a driver. Well, that is the point of this exercise, making one.
The board itself uses a cpld and takes the digital data from the RCP-NUS, ignoring the MAV-NUS (in this case) or the DENC-NUS. I found the following link immensely helpful when trying to understand the N64 video protocol. It also has an integrated dc converter to generate the ~20v required for the back light. The rest of the screen runs on 3.3V, which is one of the reasons I am trying to accomplish this: eliminating the 5v supply and the 12v supply, being able to power the whole thing from a single cell (voltage wise).
If you look closely, you'll see that the colors are off and look bad. In part, the camera angle in that picture is partly responsible, see the next picture.
However, most of the color discrepancy is caused by rather simple issue: I'm throwing half the picture away because my test probes can't be on adjacent pins and I also had a limited number of test probes. I'm not even trowing the least significant bits only, but every other bit since, well, the probes only let me reach every other pin and the vsync/hsync are present on the least significant bits. Which means, I'm throwing most of the picture quality away.
Of course, if I manage to make the N64 into a board, I would use all pins instead of throwing half the image away. If I have time, I will be posting the schematic and CPLD code (well, schematic since I used the schematic-like programming provided by Altera) tomorrow for educational purposes. The schematic has a mistake, as evidenced by the wire on the PCB and the CPLD code....well, lets just say there where parts were I proceeded by trial and error, thus, the solution is not exactly the most elegant one
.Michael Chen
That is so amazing ! Keep up the good work 
