InGameRoutines for NESRGB

Anyway you could also release the schematic file?

 

If you are talking about the NES-IO project, he is. A placeholder has been created at https://github.com/borti4938/NESRGB-IGR/tree/master/NES-IO

 

Does the PIC microcontroller saves the palette selection when the console is turned off or does the user needs to cycle through the palette choices every time the system is turn on?

 

Of course, it does save the selection. This small feature is at least needed if you turn on and off RGB because you can not switch on/off RGB in runtime without causing issues.

However, I uploaded the NES-I/O on GitHub but still need to create a part list (or a shopping cart on digikey) and an installation manual in English.

 

I finally assembled my board for my American NES toploader with Tim Worthington's NESRGB. It works great! Many thanks to borti4938 for the great work!

Here are the components I ordered from Mouser:
1x Thick Film Resistors - SMD1/8watts 10Kohms 1%
2x Thick Film Resistors - SMD1/8watts 220ohms 1%
2x Multilayer Ceramic Capacitors MLCC - SMD/SMT50volts 0.1uF X7R 10%
1x Buffers & Line Drivers2-3.6V Quad Bus 3-State
1x 8-bit Microcontrollers - MCU3.5KB 128 RAM 12 I/O

 

Thanks for the feedback

 

I just installed this into my NES Top Loader and love it. I did notice a small issue, and was wondering if anyone has a solution. On the NES Front Loader (I guess what Borti developed on), the /RST lines of the CPU (pin 3) and PPU (pin 22) are tied together. But on the top loader, pin 22 is tied to Vcc! So when someone resets the console, there's screen corruption (CPU cycles) and then the reset occurs. This does not happen with stock unmodified systems - reset is correct. Any idea what can be done to correct this? I know it's a tiny details .. but prefer to get it right.

 

I don't have a NES Top Loader. But if pin 22 of the PPU is staticly connected with Vcc, I would try to disconnect pin 22 (lift) and connect it to CPU pin 3. This could help.

 

I noticed that the /RST pin is fed all the way to the NESRGB. I wonder if the NESRGB does anything with it. Here's some schematics for you as proof:

CPU Famicom AV/Top loader schematics: http://atariusa.com/Famicom_Schematics/FC CPU Schematic.png
PPU Schematics: http://atariusa.com/Famicom_Schematics/FC PPU Schematic.png

Notice how pin 22 and pin 40 on PPU are tied together and into Vcc.

 

The schematic says that pin 22 (/rst) of the PPU is statically connected to Vcc. So the PPU does not reset. Again: I would disconnect Vcc there (connection between NESRGB and mainboard) and solder a wire between pin 3 of the CPU and PPU pin 22.

 

Hi. Spoke to Tim, he said that the NESRGB does use the /RST pin. He suggested breaking the connection between the socket and Vcc and not socket and NESRGB. You have to be careful, the wire to Vcc is very thick, and has 2 very thin traces on either side. Very easy to get one of them cut. Then, I ran a wire from CPU /RST to PPU /RST. Now the system resets correctly!!! No more frozen corrupt video on the screen!

I think you might want to document this somewhere for NES toploader / AV Famicom users.

 

Does any of this put more or less strain on the PPU or NESRGB? If so, I want to look into it. If not, I don't think it's worth the time...simply because I don't care if the console is essentially crashing on reset...it still resets.

 

TriState: I think it's worst than that. Without the fix, the system takes about 3 seconds to reset. With the fix, the reset is less than 1s.

According to http://wiki.nesdev.com/w/index.php/PPU_pin_out_and_signal_description :

"/RST resets certain parts of the chip to their initial power-on state: the clock divider, video phase generator, scanline/pixel counters, and the even/odd frame toggle. It also keeps several registers zeroed out for a full frame .. and the VRAM read buffer. It is used in the NES to clear the screen when the console is reset either by the button or the CIC"

So resetting the CPU, but not resetting the PPU does not return the system to the same state as initial startup!

The NES Front Loader has /RST of PPU and CPU tied together. This "mod" corrects it for the top loader / Famicom AV. Not doing it seems silly for me, when the fix is so simple.

 

I've just installed the IGR in my AV Famicom and it seems to work great. One thing I'm not sure about is the RGB blanking - I've only been using component with Viletim's add-on board so far and the picture seems fine, but should I be tying the RGB point to a high signal or is it only relevant for SCART leads to differentiate between composite and RGB?

Also, I was considering using the Start button on the controller for a different purpose (latching power button for a wireless controller) and was wondering what code would need altering in the Github .asm file in order to compile it so that only Select needed to be used in combination with other buttons? Is it a case of deleting any instances of "Button_St"?

 

No - it has nothing to do with the Button_St
You only have to touch the few lines after checkkeys

Here you have three lines begin with "M_belf". This command has three arguments: a 8bit number, a register and a branch. If you want to change the button combination for accessing a certain feature, you have to change the number!

The NES reads the controller in the order: A, B, Sl, St, Up, Dw, Le, Ri
Each bit in the byte represents a button in the same order from MSB to LSB. A '1' is button not pressed, a '0' is button pressed.
This means as an example: if you want to do a reset with A+B+Sl the byte is 0001 1111 or in hex 0x1f. Line 422 hence has to be "M_belf 0x1f, reg_ctrl_data, ctrl_reset"

I hope the explanation is good enough to do your changes

Best

 

Code:

checkkeys
    clrf    INTCON
    M_belf  0x1f, reg_ctrl_data, ctrl_reset  
    btfsc   reg_ctrl_reset, bit_ctrl_reset_flag
    goto    doreset                       
    M_belf  0xdd, reg_ctrl_data, domode_prev
    M_belf  0xde, reg_ctrl_data, domode_next
    goto    idle_prepare

Thanks for the instructions - I'm guessing the code above would work fine then. I'll try and compile it and give it a go this weekend.

Another thing (which I've also been wondering about with SNES IGR for a while now) - is there a way of setting it up for both controllers? I'm guessing palette and reset would just go to the same points and Data, Latch and Clock would be soldered to the P2 connections. How about the LED?

 

If you wanted to use both controllers at once, you will need to use some diodes.

 

Diodes on just P2 lines merged into the board input or is there a reason for diodes on everything?

 

Because controller 2 will end up controlling player one as well as player 2 and vice versa.

 

Obviously diodes on just P2 would mean that there would be nothing stopping an input from P2 interfering with P1.

I'm just going to throw six 1N4148 diodes on the input lines for both pads and see if it works.