alex_79

I have a similar clone console, altough mine uses a different atari-on-a-chip package that is 40 pins only. My console can only use joysticks which contains mechanical switches; it doesn't have paddle lines nor bidirectional ports and the joysticks and console switches are wired in a 5x3 matrix scheme which reduced the number of pins on the chip. It lacks the b/w switch too. I've found that it has some problems playing cart with bankswitch and added ram, but the behaviour is not consistent with all carts. For example it plays "Crystal Castle" just fine, while it doesn't like "Super Football", and both carts use the same bankswitch method (Atari 16kb with 128bytes of added ram). I only have very basic electronics knowledge, so I don't know if this a bug in the design of the console or if it's due to some component that it's failing.
 P8070020.JPG   178.56K   15 downloads  P8070024.JPG   150.09K   17 downloads
 P8070008.JPG   111.76K   16 downloads  P8070012.JPG   114.09K   12 downloads
 P8070017.JPG   50.49K   12 downloads

Mef, on Fri May 18, 2012 8:47 AM, said:

You can try tracing the board and searching for unused pins on the AOAC near those for the other console switches. Unless it uses some weird connection scheme like my console, the switches just ground the corresponding pin when pressed, so you could easily add a b/w switch once you find the correct pin.

Quote

I think that the best way to know is to test the console with different carts. One source for incompatibility is the fact that those consoles detect the presence of a cart in the slot by checking if a pin is grounded or not. Most carts connect pin 24 to ground internally but there are a few exceptions: some Activision games leave that pin unconneced and the Melody board (used for homebrews and Harmony cart) uses the pin to put the cart in programming mode. When using those carts the console won't deselect the internal games causing a bus contention with the cart rom and the game will crash. A simple workaround for this is to wire a switch to manually ground the pin in the cart port of the console to force the use of the external cart when the autodetection doesn't work.
 vcs_cart_port.png   34.92K   10 downloads

Nope, stella emulation is correct. The program apparently bahaves in the same way with or without the in-line assembly because you tested the bits only with the value "1", which is, incidentally, the same value they assume when configured as inputs. If you set them to "0" in the code the program won't work as expected without the in-line assembly.

Omegamatrix, on Fri May 18, 2012 9:17 AM, said:

Actually you can use the entire SWCHB register to store data and still being able to read all of the switches. You can store a value into the Data Register no matter how the bits are configured in the Data Direction Register (SWBCNT) and the value will be preserved even on subsequent changes to the DDR. You only need to set the bits to output when you need to read back the value you stored, or when using instructions that needs to read/modify/write data.

So you can store a value to SWCHB, set the port to input, read the switches, set the port to output and read back the value you stored before.
Note that this only works on port B, while port A value (SWCHA) may be affected by the controllers connected to the console even when the pins are set to output.

theloon, on Sat May 19, 2012 8:23 AM, said:

I never programmed using BB, but I think I can answer the last question.
The 3 unused bits of the RIOT portB are left unconnected on the 2600 board, and an input pin unconnected will always read as "1". So, If you omit the inline assembly (leaving the 3 portB pins configured as inputs), the 3 playfield pixels will always be on, even if you change the source to write "0" into the swchb bits.

I think you must leave the two pullup resistors (R212 and R208 in the schematic you posted), because TIA has "open collector" outputs. Anyway I'm not an expert as I wrote in the first post and I don't have the modded junior anymore so I can't help you very much to track down the problem.