NES controller on PC Engine / TurboGrafx 16

My brother needed a second controller for his PCEngine so we could co-op some shmups but original controllers are wildly expensive! And even if you find a cheaper option from another region, you'll need to buy yourself an adapter...ugh. So what I was design a circuit board to implant into an NES controller shell!

Easy as pie. This board supports either the cord for a PCengine or a turbografx and has broken out headers in case you want to install it into a different (larger) controller shell. This version does not support turbo buttons right now though.

Top Side:

Back Side:

Once I print some, I'll update with another post. 

Gameboy Camera Force Trippy H

Here is something I have been working on for a few days now and only got a little bit of progress. But progress is progress and this really helps me understand gameboy debugging.

Analyzed the WRAM addresses for any and all changes that occur when you press buttons, select particular cursor locations and of course: when you enter DJ mode (Trippy H).

After hours and hours, I found that WRAM $D5CE is the game mode byte, or at least that's what I call it. This byte is changed directly before switching between dancing mario, menu, view, shoot and trippy H (as well as the other menus and modes).
1:D5CE 00 w
The first instance was when you press a button while mario dances. I restarted the emu and pressed A. The code broke and stopped at $74AC where there was an "LD A, $00"
Has someone done this before?

Dance = 19, menu = 00, shoot = 01, DJ = 1F, view = 02, play - 07, etc.

After learning this, I set an access break when the byte 00 is written to $D5CE

I replaced this with "LD A, $1F" and restarted again.

This time when you press a button at dancing mario, Trippy H starts!

----------------------------------------------------------------------------------------------------------------

Next update I would like to stop the cart from checking if the camera is present. This will allow the ROM to be put onto a normal flash cart. 

2nd future update would be to remove unnecessary routines like "shoot  " and "view" hopefully the ROM itself can be reduced in size. Potentially an MBC1 + SRAM + BATTERY

3rd future update I would like to break the ROM even more and remove saving altogether so that it can be safely put on a 64M cart along with LSDJ or a dedicated ROM only cart.

ROM, EPROM, EEPROM that I like

Here is a quick-check list of different roms that are easy to get.

All run on single supply voltages of 5v and are accessed via a parallel bus.
Also listed is what to do with those pesky control pins when if you just want these to be read by the controlling system (NES, Genesis, z80, etc)

8-bit UV Eproms:

27c16 - 2,048b x8 = 2 KBytes 

27c32 - 4,096b x8 = 4 KBytes

27c64 - 8,192b x8 = 8 KBytes 

27c128 - 16,384b x8 = 16 KBytes

27c256 - 32,768b x8 = 32 KBytes

27c512 - 65,536b x8 = 64 Kbytes

8-bit EEPROMs:

29f010 - 131,072b x8 = 128 KBytes alt: 29ee010, 49f010

29f020 - 262,144b x8 = 256 KBytes alt: 49f020

29f040 - 524,288b x8 = 512 KBytes alt: 49f040

8- or 16-bit UV EPROMs:

27c400 - 512Kb x8 or 256Kb x16

27c800 - 1Mb x8 or 512Kb x16

27c160 - 2Mb x8 or 1Mb x16

27c322 - 2Mb x16 (no 8-bit mode available)

8- or 16-bit EEPROMs:

29f200  -  256Kb x8 or 128Kb x16 (~1.64usd ea)

29f400 - 512Kb x8 or 256Kb x16 (~2.11usd ea)

29f800 - 1Mb x8 or 512Kb x16 (~3.12usd ea)

29f160 - 2Mb x8 or 1Mb x16 (price unknown)

8-bit EEPROMs I am looking into:

29- or 49-f040  - 512Kb x8
29f080  -  more info once I use them
29f016
29f032

There are of course hundreds of other roms, but I don't use them.

Control Pins:

None of these pins can be left hanging (disconnected) as far as I know. So don't do it.

Note: "!" will be used to distinguish low-enable pins. This means that when this input is pulled low, the function is enabled.

!CE - Chip Enable, AKA !E:
Most likely your system will need this to be connected to the control bus of the system. Sometimes it is connected to GND directly if your system has NO other memory that it must address. Sometimes it is connect to !OE, but only if your system has no other memory to access.

!WE - Write Enable. AKA !WR:
Typically your system will not be able to program the rom, so this should be pulled high by a resistor connected to vcc. Sometimes you can get away with connecting this pin directly to vcc without a resistor. Anywhere between 4k7 to 10k ohms should be good.

!OE - Output Enable. AKA !RD, !G:
Most likely your system will need this to be connected to the control bus of the system. Sometimes it is connected to GND directly if your system has NO other memory that it must address. Sometimes it is connect to !CE, but only if your system has no other memory to access.

!PGM - Program Enable:
This is similar to !WE but is only seen on a select few ROMs that also require a VPP voltage. Connet this pin to vcc inside your system.

VPP - Programming voltage:
This is typically a high voltage of 12v to 21v required to program a UV EPROM. This is not going to be used by your system, so it should always be pulled high/VCC/+5v.

!OEVPP - Output Enable / Programming voltage
When low (0v), this pin acts as the data output enable pin. When high (vcc) this pin shuts off data output. When connected to vpp (typ. 12v - 21v) this pin acts as vpp putting the chip into programming mode. Connect this pin to your control bus as though it were just !OE.

Q15A-1 - This pin is very special! When in 16-bit mode (byte pin high), this pin is used as data pin D15 or Q15.When in 8-bit mode (byte pin low), this pin is Address pin minus 1. And yes, by minus 1, this is less than 0. What that means is, the pin will connect to A0 on your computer's bus, eprom pin A0 will then connect to computer side A1, etc. here is a little diagram:

rom ---- computer
A-1 ---- A0
A0 ----- A1
A1 ----- A2
A2 ----- A3

!BYTEVPP - Byte Mode / Program Supply:
This pin is pulled high if using the rom in 16-bit mode, or ground when in 8-bit mode.
When this pin is connected either to VSS or VCC, then VPP is ignored, The only time the VPP function is used is when the voltage connected is 12v to 21v as instructed by the appropriate datasheet.
Further explanation from a datasheet:

The M27C160 (for example) has two organisations, Word-wide and Byte-wide. The organisation is selected by the signal level on the BYTEVPP pin. When BYTEVPP is at VIH the Word-wide organisation is selected and the Q15A–1 pin is used for Q15 Data Output. When the BYTEVPP pin is at VIL the Byte-wide organisation is selected and the Q15A–1 pin is used for the Address Input A–1. When the memory is logically regarded as 16 bit wide, but read in the Byte-wide organisation, then with A–1 at VIL the lower 8 bits of the 16 bit data are selected and with A–1 at VIH the upper 8 bits of the 16 bit data are selected.

For a much more in-depth explanation of eproms, see:
https://wiki.xtronics.com/index.php/How_EPROMS_Work

Odyssey 2 variety cart

I am also currently working on a flash cart for the Odyssey 2 that supports a wide array of roms, proms, eproms, etc.

27C-, 28F-, 29F-, 29EE-, 49F-, etc.
16, 32, 64, 128, 256, 512, 010, 020, 040, and maybe more.

SwinSID SE - reworked by Me

Been toying with the SwinSID which is a decent DIY version of the SID chip. My version takes up no more space than the original and would be a drop-in-replacement with no extra wiring. Programming the atmega would be a little difficult though since there is no room for an ICSP.

SMS variety Cart

Currently working on a flash cart for the SMS that supports a wide array of roms, proms, eproms, etc.

27C-, 28F-, 29F-, 29EE-, 49F-, etc.
16, 32, 64, 128, 256, 512, 010, 020, 040, and maybe more.

Problem is ... I don't own a Master System to test these out. I will not be printing any until I get one.

Composite Video from the Nintendo Gameboy

My latest project is to get some sort of video output from the nintendo gameboy. The signals are all present, but are not in a form that can be connected to any television or monitor. My first thought is to convert the signals into a single analog signal called composite video.

Composite video is named as such because it contains color data (chroma), brightness (luma) and synchronization on wire.

1. Chroma is not important in this case becuase the gameboy is monochrome. All of the color differences will be made with Luma.

2. Luma: As above, the Luma will be used to create our four different colors. The TV looks for an analog signal here. The gameboy has two data pins which are used for this purpose, so connected through a DAC of some sort, we can create four different levels rather than just 0v and 5v.

3. Sync
 Csync or composite sync is an XOR of horizontal and vertical sync. These two signals tell the television to move down one line or to move back to the top of the screen. I am not quite sure how progressive or interlaced are determined by these just yet.

Next, these have to be connected together over one wire. As mentioned, the luma is an analog value but what I forgot to mention was that it is a positive signal whereas sync is negative. From what I have read, composite must be AC coupled because the TV input is DC coupled. That being said, our sync can actually be positive as well, as long as the luma is offset by DC value. Once the signal goes into the TV, the DC coupling circuit will block the average DC offset which is our black level. Black level will become 0 volts inside the Tv so sync will become 0v to -0.4v and Luma will be between 0v and +0.7v.

I am not at liberty to share my schematic at this point but it doesn't' work that well anyhow. :P
As a first attempt however, the result is quite promising.

You will notice that the image scrolls in several directions and that it is repeated three times over from left to right. I believe this is a problem with synchronization and possibly the LCD itself.

Updates to follow shortly. 

Miracle Piano Final Thougts

I finally had time to probe a few pins inside the Miracle Piano.

AS0012 - Pin 21 (PWM)
It turns out this pin controls the master volume and NOT the envelope as I had originally assumed.
Turning on the keyboard, this pin defaults to about 50%, but as you can see, it is not exactly 50%. How odd.
When the volume is reduced, the pulse width is widened and when the volume is increased, the pulse width is reduced. That is because the integrator, U4A is inverting the output.

Each photo has the scope set to 10 microseconds per division:

Default Volume:



Highest Volume:



Lowest volume:



U4 - Pin 1
This pin goes to the LM13700 to control the master volume, or gain of the sound. It appears as a DC voltage and is remarkably solid. There is no visible ripple as would be expected from an integrator.
No photo is needed of this signal.

J004 - Pins 21-24 (OUT1-OUT4)
The signals from these pins are too small to view on my scope, so I chose the amplified versions from U10. Pins 1, 8, 7 and 14 respectively.

OUT1 is not active for all sound samples, apparently. When Harpsichord and Synthesizer are selected, nothing comes out at all.
When the other four sounds are selected however, the waveform is perfectly clear.

OUT2 is the opposite. Only when Harpsichord and Synth are selected, do we see any activity on this pin.

OUT3 mimics OUT1 exactly, or at least as far as I can tell.

OUT4 on the other hand does not seem to react to any button or key. It simply outputs a DC voltage which measures 5.03v at pin 14 of U10.

I can speculate as to why there are three OUT pins. While probing both Pins 8 and 14 of U4 which has the mixed and filtered outputs split to both left and right output terminals, the waveforms are identical for Harpsichord and Synthesizer but are not identical for the other four sounds. It would seem that Harpsichord and Synthesizer were recorded and digitized in mono while the other four sounds were recorded and digitized in stereo.

I am a little saddened that the envelope is not broken out to any specific pin or sub-circuit.

Some other Notes

J004 - Pin 40 (Bus Strobe)
This pin reacts differently for different sounds, however, when the key is pressed with a sound that has an attack and release; the pin will strobe for the full length of the sound and go to 0 when the note is finished.
For a sound that ends only when the key is released, the pin strobes at key press for a moment, then goes to 0 and strobes once again when the note is released.

I could use this pin for creating a gate and trigger, but it would require that I charge a capacitor then feed it through a comparator and set up some logic to keep the signal high when the key is pressed and low when the key is released. This wouldn't require too much effort, but the function would change from sample to sample since the envelopes are all different. I don't thin the modification is worth it in this case.

"Piano" sample is very hard to photograph since the amplitude changes so rapidly in software. It looks very similar to "Organ, but is more rounded whereas the Organ is more triangular.


"Organ:"



This photo shows a sample that is identical on both sound channels. Trust me, they are identical but the channels are not being displayed the same way.


These two photos show sounds that are not identical from OUT1 and OUT2.



PS: Yes, the reflection in my oscope is naked. Deal with it.

min64 - The bare minimum rom cart for commodore 64 - part 2

The boards arrived but I have yet to test them out.

min64 - The bare minimum rom cart for commodore 64

The idea was to design a cart that would fit entirely in the commodore without sticking out. Surprisingly, it could even be made small enough to fit a shell, if I make one in the future.

The board has has one ROM and thats it.








The board is a meer 1.05 inches deep and has notches for easy removal or mounting (granted a shell is designed). Measuring my own commodore, a board of 1.1875 inches would be flush with the chassis. Also has optional reset switch as suggested by catskull.

My main concern was supporting as many proms, eproms and eeproms as I could since too many are no longer made, but easy to find.

Those supported include:

28F010, 28F020, 28F040,
29F010, 29F020, 29F040,
49F010, 49F020, 49F040
2764, 27128, 27256, 27512
27c64, 27c128, 27c256, 27c512

As well as SF's, GL's, EE's, etc.

Also working on support for 2704, 2708, 2716, and 2732. These will fit, but would require a few rerouted pins.

In any case, I can't wait for these to arrive from OSHpark.

Arduino - Cast Int to Byte - What happens?

For a project I need to spread a 16-bit unsigned integer across one byte variable and two 1-bit variables, all of which will be written to pins. The reason is not important, but I needed to know what happens to the byte value when I cast it to the byte variable. I understand that it will be truncated, but what will? The higher 8-bits or the lower 8-bits?

To find out, I wrote a quick program with a lot of clear text output.

// cast test by Jordan
// Test truncation of variables from one type to another
// most importatntly: int to byte

unsigned int intVar = 0x4080; // will it truncate to 01000000 or 10000000?
byte byteVar = 0x33;
void setup(){
  Serial.begin(9600);
  Serial.print("hello world.");
  Serial.println();
  Serial.println();

}

void loop(){
  Serial.println("integer variable equals: ");
  Serial.println(intVar, BIN); // print variable in binary
  Serial.println();
  Serial.println("byte variable equals: ");
  Serial.println(byteVar, BIN);
  Serial.println(".");
  Serial.println("..");
  Serial.println("...");
  byteVar = (byte)intVar;
  Serial.println("byte variable now equals: ");
  Serial.println(byteVar, BIN);
  while(1){} // loop forever
}

Then I uploaded it to my Arduino Nano and opened the serial monitor. I then uploaded it to my Teensy 2.0 to double check the code across platforms. Teensy is a little different in some aspects, so I had to make sure. They both output exactly the same thing:

Serial monitor output:

"hello world.
integer variable equals:
100000010000000
byte variable equals:
110011
.
..
...
byte variable now equals:
10000000"

These are the exact results that I wanted to see. I may continue on with more programming now...

EDIT: Further testing proves that the same theory does NOT hold true with booleans. (get it? "true") I had hoped that the boolean could be used to store a 1-bit number, but it turns out they are actually some sort of integer in disguise! I will have to figure out some fast way to manipulate individual bits...

Adding Analog Pins to Arduino pt.2

Don't forget part 1: http://jazz-disassemblies.blogspot.com/2014/01/adding-analog-pins-to-arduino-pt1.html

The first step in part 2 of adding analog pins to an arduino is by getting rid of the MCP3008! Yes, I am sorry but that particular IC is overly complicated and too expensive for what it offers.

Since I wrote that first part, I began looking for alternatives because of the price of the MCP3008. Even in quantities of 10 or more, the IC was still more expensive than a bare Atmel microcontroller! At first I thought that I could buy another microcontroller for less than the MCP3008 at a fraction of the cost and even be able to simplify the methods of communication to my own liking.

After looking for the cheapest, yet adequately powerful uC, I came across the ATtiny48 which has several Analog inputs and even more digital IO's. The Analog inputs would in theory, be read, stored in variables and then transferred to the master microcontroller across an 8-bit wide data bus. The particular analog value that would be transferred would be selected by the master uC via three other pins; select bits. The pins were going to offer a binary value which would select the current pot to be transferred.

This method would allow for me to read many many more pots than the master microcontroller was equipped with, but at a large cost; the cost of many digital IO pins. One way to get those digital IOs back would be to use analogWrite on one of the PWM outputs and connect that pin to an analog input on the master uC. Considering that, I could sacrifice one analog input for 8 more. HOWEVER, the AT48 has no PWM outsputs. :(

After mulling over it for a long time, I realized what I had actually designed. The program I had spent an hour writing... The program that utilized the exact methods of communication to suite my exact needs...was, you guessed it: An analog multiplexer which decodes 3-to-8 inputs. They have an app...I mean IC for that. The 74HC4052 accepts two sets of 4 analog inputs and connects them to one of two outputs respectively. Two select bits, choose the analog input to transfer to the output.

The 4052 is a mere 50 cents, requires no external programming, runs on a large voltage range and comes in a variety of packages!

I will simply import photos and descriptions of my project, so that I can describe how to use the 4052.
Analog pins A0-A3 are used for higher priority data, so that leaves A4-A7 open. Again, we will also need two digital IO to use as select bits on the 4052.

// ***************************************************************
// define pin connections
// ***************************************************************

int pSelect0 = 3;
int pSelect1 = 4;

// ***************************************************************
// define variables
// ***************************************************************

// locate the delay between the select bits and the updated output
// of your 4052 IC and update this value:
int latency = 100; 

byte aVal00 = 0; // analog Value, 4052 # 0, input 0
byte aVal01 = 0; // analog Value, 4052 # 0, input 1
byte aVal10 = 0; // analog Value, 4052 # 1, input 0
byte aVal11 = 0; // analog Value, 4052 # 1, input 1

byte aVal02 = 0; // analog Value, 4052 # 0, input 2
byte aVal03 = 0; // analog Value, 4052 # 0, input 3
byte aVal12 = 0; // analog Value, 4052 # 1, input 2
byte aVal13 = 0; // analog Value, 4052 # 1, input 3

byte aVal04 = 0; // analog Value, 4052 # 0, input 4
byte aVal05 = 0; // analog Value, 4052 # 0, input 5
byte aVal14 = 0; // analog Value, 4052 # 1, input 4
byte aVal15 = 0; // analog Value, 4052 # 1, input 5

byte aVal06 = 0; // analog Value, 4052 # 0, input 6
byte aVal07 = 0; // analog Value, 4052 # 0, input 7
byte aVal16 = 0; // analog Value, 4052 # 1, input 6
byte aVal17 = 0; // analog Value, 4052 # 1, input 7

// ***************************************************************

// Setup

// ***************************************************************

void setup()

{

Serial.begin(9600);

// define pin modes   

pinMode(pSelect0, OUTPUT);

pinMode(pSelect1, OUTPUT);

}  

// ***************************************************************

// Main Loop

// ***************************************************************

void loop()

{

getAnalog();

processAnalog();

}

// ***************************************************************

// Get Analog Values

// ***************************************************************

void getAnalog()

{

  // read the first set of four

  // part 1 of 4

  digitalWrite(pSelect0, LOW), digitalWrite(pSelect1, LOW); // 00

    delayMicroseconds(latency);

  

aVal00 = map(analogRead(A4), 0, 1023, 0, 255),

aVal01 = map(analogRead(A5), 0, 1023, 0, 255),

aVal10 = map(analogRead(A6), 0, 1023, 0, 255),

aVal11 = map(analogRead(A7), 0, 1023, 0, 255);

  

  // read the second set of four

  // part 2 of 4

  digitalWrite(pSelect0, LOW), digitalWrite(pSelect1, HIGH); // 01

    delayMicroseconds(latency);

  

aVal02 = map(analogRead(A4), 0, 1023, 0, 255),

aVal03 = map(analogRead(A5), 0, 1023, 0, 255),

aVal12 = map(analogRead(A6), 0, 1023, 0, 255),

aVal13 = map(analogRead(A7), 0, 1023, 0, 255);

  

  // read the third set of four

  // part 3 of 4

  digitalWrite(pSelect0, HIGH), digitalWrite(pSelect1, LOW); // 10

    delayMicroseconds(latency);

  

aVal04 = map(analogRead(A4), 0, 1023, 0, 255),

aVal05 = map(analogRead(A5), 0, 1023, 0, 255),

aVal14 = map(analogRead(A6), 0, 1023, 0, 255),

aVal15 = map(analogRead(A7), 0, 1023, 0, 255);

  

  // read the last set of four

  // part 4 of 4

  digitalWrite(pSelect0, HIGH), digitalWrite(pSelect1, HIGH); // 11

    delayMicroseconds(latency);

  

aVal06 = map(analogRead(A4), 0, 1023, 0, 255),

aVal07 = map(analogRead(A5), 0, 1023, 0, 255),

aVal16 = map(analogRead(A6), 0, 1023, 0, 255),

aVal17 = map(analogRead(A7), 0, 1023, 0, 255);  

  

  

  return; // return to main loop    

return;

}

// ***************************************************************

// Process the values

// ***************************************************************

void processAnalog()

{

// Do whatever you would like to do with the values here

return;

}

// ***************************************************************

That is all. I realize that the getAnalog function could be simplified using an array, but I did it quickly. If anyone wants to make that change, please share it! Also, I used the map function to change the analog value that was read from 10-bits to 8-bits. I have my reasons, but anyone may remove that if they want a higher resolution. 

There you have it. 16 independent analog values on top of the 4 I needed for something else. With all of the analog pins at our disposal, you could have 32 analog values! I am using this for 16 pots and the other 4 for external control voltages. Just imagine, 32 analog values with a simple Atmega168. 

Keep up with future posts to see when I actually breadboard this out. 

NES TSOP ROM Adapter Development Board

The title is quite a mouth full, but I have been working on an adapter board for use in the NES. While EPROMs are still available for burning ROMs, (for development purposes of course) they are running out.

27C, 29F, 49F series chips, etc. They are no longer produced and as stocks dwindle, prices increase. Some companies do still make ROM chips though! The newly produced chip are rarely made in a DIL package though, so an adapter is needed, else the user very carefully hand solders each pin. Even with each pin hand soldered, how are you supposed to program the ROM to it? With an adapter, thats how.

So say you have an adapter for one such new ROM chip. Is the final pinout the same as a CHR mask ROM, PRG mask ROM or the old 27Cxxx/29Fxxx/49Fxxx pinout? How about all three? The thing that my adapter board has, which others may not, is solder-pad jumpers to change the pinout of the two rows of pins. Each pad is named so the user can see which pads to use when they want the pinout of a CHR ROM, PRG ROM or normal flash ROM.

The only draw back is that the Chip that I used, the GLS29EE010, is only a 1 MegaBit EEPROM. That is only 128 KiloBytes. Many NES ROMs are small enough to use these, but many complex RPG's are much larger. Now for a beginner NES programmer, 128KB is plenty of room.

Anyhow, the biggest reason that I wanted to make this adapter is so I can configure the board to be a 29F010, program it with my Willem Programmer and then reconfigure the pads for either a CHR ROM or a PRG ROM. This makes it so I do not have to modify the traces on an NES cart or connect wires all over the board.

In the pictures, you can see how far I have come. I still need to place the solder pads in convenient locations and the last thing I will do is make the board smaller. As you can see, the board protrudes past the through-hole pins. This small amount of extra board may not cause any problems, but it is best to be safe.

TOP:



BOTTOM:



SCHEMATIC:


UPDATE:





The above pictures are of my finished board. The top side contains the filter capacitor, a pull up resistor for the Write enable pin and the 128 KByte ROM itself.

The bottom side has all of the jumpers which are labelled accordingly. If you want the pinout of a CHR ROM, solder the jumpers which are labelled CHR, but if you want to program the chip with your EPROM burner with factory settings, the solder the 010 jumpers and set your programmer in software as a 29F010. Its as easy as that!

I have also reduced the size to 41.91mm x 19.05mm. The filter capacitor is optional since the standard cart will have one immediately next to the power pin of the original mask ROM. The pull up resistor is required unfortunately. Many IC's now-a-days have internal pull-up or down resistors so that pins can be left open or hanging, but the datasheet does not say anything about pull up resistors and this is not a pin we can leave to self-oscillate!

The Nintedno Gameboy Pocket's CPU pinout

I finally got around to probing the pins on the gameboy pocket's CPU and made a diagram. The CPU is not the same as the CPU inside of the original gameboy or the super gameboy SNES cartridge. When I get the chance, I will draw a schematic of the entire gameboy pocket.

Pinout photo direct link (huge): http://imageshack.com/a/img835/3936/nyix.png

1.  A0
2.  A1
3.  A2
4.  A3
5.  A4
6.  A5
7.  A6
8.  A7
9.  A8
10.  A9
11.  A10
12.  A11
13.  A12
14.  A13
15.  A14
16.  A15
17.  D0
18.  D1
19.  D2
20.  D3
21.  D4
22.  D5
23.  D6
24.  D7
25.  /RES
26.  VIN
27.  SO1
28.  SO2
29.  MD7
30.  MD6
31.  MD5
32.  GND
33.  MD4
34.  MD3
35.  MD2
36.  MD1
37.  MD0
38.  SOUT
39.  SCK
40.  SIN
41.  CPG
42.  CPL
43.  ST
44.  LD0
45.  LD1
46.  CP
47.  FR
48.  S
49.  MA0
50.  MA1
51.  MA2
52.  MA3
53.  VCC
54.  MA4
55.  MA5
56.  MA6
57.  MA7
58.  MA12
59.  /MCS
60.  MA10
61.  /MRD
62.  MA11
63.  MA9
64.  MA8
65.  /MWR
66.  CK2
67.  CK1
68.  P15
69.  P14
70.  P13
71.  P12
72.  GND
73.  P11
74.  P10
75.  GND
76.  GND
77.  CLOCK-OUT
78.   /WR
79.   /RD
80.   /CS

Some notes:

• The naming convention that I followed is directly from the silkscreen on the gameboy pocket itself. 
• It would seem that the gameboy pocket's CPU has the video RAM built-in as opposed to being on the PCB since the vram buses are all hanging open. Because of this, rewiring a DMG-01's CPU or a Super Gameboy CPU to the gameboy pocket is not immediately possible. 
•  The DMG and SGB CPU's have two pins named T1 and T2 which are tied to ground. I believe that pins 75 and 76 of the MGBCPU  are T1 and T2 respectively, but only because of their placement near the clock output. 
• The "/" means low-enable
• For more information what some of the pins do, see the photo near the top. Or comment below.

Jazz Disassemblies Ep4: N64 Gameboy Adapter Teardown

Some time ago, I needed the shell and cartridge connector of the gameboy adapter for the Nintendo 64, but I never throw things away. In light of this, I decided to de solder all of the components and write up a pinout diagram of the internal CPU itself.

This CPU is an 80-pin SMT IC just like the Original Gameboy, gameboy pocket and super gameboy however I am sure that it is more similar to the gamboy Color's CPU because of the abilities.

During my time desoldering everything, I forgot to record what components were so I no longer have that information. I would not have known some of the tiny transistor-like components anyhow because they had no markings.

In any case, I just want to share some photos with close ups of the traces and also the pin diagram.
Check it out:









I feel like I cheated on this dissassembly, because I have so little information. Sorry about that, I will just have to make the next one twice as in depth.

Jazz-Assembly #2 - Yup, Another ArduinoBoy

Everyone and their mother has made one, so what took me so long? I have built them before, but this time I designed a PCB. What differs between mine and anyone else's is that I used economical parts rather than a pre built Arduino or an Atmega pulled form one with a bootloader.




The entire board is a tiny 5cm x 5cm, MIDI connectors and LEDs included. I also plan on designing an acrylic shell to sell along side them, though anyone may choose to house it in their own enclosure.

Anyhow, this was the first time I had used SMT components besides an IC. Passive components including the resistors and caps were a new item for me to tackle. They did not challenge me as I had hoped. At one point, I blew one away from the pads, but it was all too easy to fix.







Below is a shot for size comparison. You may have noticed in one of the photos that there is a notch on one side with a hole about 2 millimeters from it. This will be used for a zip tie so that I can ensure the cable does not break free. I will upload another picture once I complete that portion.



Below is the wiring that I used to program both the flash and fuse bits. It is the same Bit Bang connection as we used on my version of the Gameboy Programmer board in a previous post. I found that the fuse bits were the most difficult to figure out in the whole project. in the end, I decided just to copy the fuse bits from a Pro Mini 5v/16MHz because that is what configuration I went with here.



Thanks for reading. All credits for the ArduinoBoy go to Trash80 (Timothy Lamb) as can be found here:
https://code.google.com/p/arduinoboy/

Jazz Disassemblies Ep3: Sega Genesis Saving Teardown

I love the Sega Genesis, but rarely do anything with it. I have made a handful of reproduction carts in the past because there is nothing better than playing games on real hardware but I always have a regret after destroying a donor cartridge, whether it is sports or not. One of the goals I always set myself up with during a creating is to use 100% renewable components. By renewable, I mean of course modern and commercially produced components; nothing salvaged and nothing obsolete. Having nothing obsolete is very difficult in my circle of interests, but salvaging components is my greatest downfall.

During my journeys into the technologies that Sega and other companies used within the cartridges for the Sega Genesis/MegaDrive, I have found three official forms of saving data. Two forms use serial EEPROMs and the third uses the tried-and-true parallel SRAM with battery backup. My goal is to recreate these cartridges using new components and my stretch goal is to expand the addressable memory or just to improve them in some way while making the carts themselves renewable.

We already know that the plastic shells can be remade by the everyday hobbyist and their 3D printers and circuit boards can be fabricated by Chinese companies for pennies on the dollar. All that leave now is the components which are definitely on their way out of style. The components that we are looking for are 8- and 16-bit, parallel ROMs and RAMs. Referring to a statement above: by renewable I meant purchasable from Mouser or Digikey, etc in large quantities which will later be restored. Glancing at Mouser (My supplier of choice) I have already been able to locate a handful of ROMs and RAMs that come in both selectable 8- and 16-bit configurations!

The next goal I will have is to recreate the higher density logic with PLDs, but that is best left for another time.

1. KM62256 Parallel SRAM

These boards found in most of the miserable football and soccer games. Until I find another varient, I will cover one such board revision: "171-6279A"

The board seems to be made by Sega though I have long lost the ROM which was originally soldered in. It contains:

1x (CE) 47uF electrolytic capacitor
5x (C1-C5) .1uF ceramic capacitors
1x (BAT) CR2032 coin-cell battery
1x (IC1) 42-pin Mask ROM (27c160 equivalent) - 16Mbit
1x (IC2) KM62256BPL-7L, 32Kx8 bit (32Kbyte) Low Power CMOS Static RAM
1x (IC3) BA6162, Reset IC with battery backup function by Rohm
2x (IC4, IC5) 74HC00AP, Quad two-input NAND gate

I have already recreated everything on the board in Eagle PCB libraries including the board dimensions and general component layout. Tracing all of the connections is slower work and I will get to that eventually. In the meantime, my goal is to layout a functionally-identical board with 3v3 ROM/RAM, SMT caps and level shifters for proper data flow. THen we will have ourselves a flash cartridge!









Above you have seen the board itself with and without components. Ignore the text on the Mask ROM though since I just stuck a random IC in there to show it with one.

Looks pretty good if I do say so myself, though the traces are not as authentic as the layout. Sega never seemed to use top-side pads. They have vias which allow for double sided boards, but I have only seen EA cartridges that use top-side pads. These pads of course make for miserable desoldering since I need much more heat... and patience.

Some fun facts about this board is that the ROM is 16-bits but the SRAM is only 8-bit. Although I do not have the full details on how the software accesses these, the Gen/MD has two pins which are called !LDSW and !UDSW (Upper Data Set Write and Lower Data Set Write). When reading from RAM, the processor ignores the upper byte of data since there should be nothing there. While writing though, the !LDSW pin goes low which enables the !WE pin on our RAM. These two pins are for transferring 8-bits (one byte) at a time rather than 16 (two bytes).Not knowing how to activate either of these pins, it would seem that someone may add a second SRAM and use the currently unused !UDSW pin as the enable.




The above picture is how I found the glue logic for addressing our memories. Only 6 out of 8 gates are used which is a waste of space and battery power since the unused pins are connected to the Vout pin on our reset IC. If you think about it, the three NAND gates that have both inputs connected act as NOT gates which is something we would take into consideration if we were to redesign this with single-gate SMT ICs or on a PLD.

one problem I have with this board is that A21 and A22 are simply left hanging. Just a guess, but using A20 as a ROm address and A21 in the logic would expand the addressable memory, but Sega chose not to for some reason.

2. Acclaim Serial 24LC02B RAM

The next board I will cover is the P/N 670120 REV 2 by Acclaim. The contents of our board are as follow:

1x (C1) 47uF electrolytic capacitor
4x (C2-C5) 0.1uF ceramic capacitors
2x (R1, R2) 4.7K Ohm resistors
1x (U1) Mask ROM (capacity not yet known)
1x (U2) 74ALS138N, 1-of-8 decoder/demultiplexer
1x (U3) 74ALS74AN, Dual D-type flip-flop with set and reset
1x (U4) 74ALS125AN, Quad TRI-STATE Buffer
1x (U5) 24LC02B, I2C™ Serial EEPROM (2K capacity)

As you can see, the naming routines is different than that of Sega and yet again, we could reduce the chip count to much less with a PLD. U2-U4 could easily be designed in a PLD to reduce space and cost. For the time being, I assume the resistors are pull-ups or pull-downs.








3. Acclaim Serial 24LC04B RAM w/ LZ95A53

You're probably thinking that I recycled this board from a previous post and yes, yes I have. It does pertain to the topic though and I can probably shed a little more light on the special IC now that I know more about !LDSW and serial eeproms.

Anyhow, this board contains:

1x (C1) 47uF electrolytic capacitor
4x (C2-C5) 0.1uF ceramic capacitors
1x (R1) 10K Ohm resistor
2x (U1, U2) Mask ROMs (27c160 equivalents)
1x (U3) Acclaim LZ95A53 (memory mapper, glue logic, serial data interpreter, etc)
1x (U4) 24LC04B, I2C™ Serial EEPROM (4K capacity)

Above is the board that I created by probing all of the traces. Looks nice, but my next goal would be to reverse engineer the Acclaim's LZ95A53. Unfortunately, I have no scope to do so...



The above picture is my schematic which shows the connections on the LZ95A53. I had to make an addition to my cartridge connector since it uses several different pins that very few others use. I believe that the Acclaim's LZ95A53 IC contains the same logic as the board which used the 24lc02 serial RAM. Again, I cannot test this theory.




In hindsight, all of these boards used 27c160 equivalent Mask ROMs. The 27c160 can store a 2MB ROM which means the board with 2 Mask ROMs had a 4MB game. A piece of information for those making reproduction carts with the 27c400, 800, 160 and 322's, the first three mentioned all have a !BYTE pin. This pin allows for the EPROM to function as either an 8-bit or 16-bit ROM which means you may use it in many different systems.

Besides a little bit of work on the silkscreens, these boards are all ready to send to any fab house, granted they make 1.6mm thick boards. I will also be adding some more pictures of the other two boards shortly. Thanks for reading.

Gameboy MBC - Which to choose?

Just a quick overview for unfamiliar readers before we get into the thick of it.

The Nintendo Gameboy uses a Memory Bank Controller inside of official cartridges for switching between banks of memory and ultimately expanding the addressable memory. The MBC will switch between banks of both ROM and RAM so that the programmer may code larger games and backup more data in save files.

There are four main MBC's numbered 1 through 5 and excluding 4. The reason I am writing this is because each following revision did not simply add more addressable memory. Each one has unique capabilities built in as well as expanding the addressable memory. in general the MBC's function by waiting for specific data bits to be written to yet more specific memory locations. Once the data in question is written to the specific memory location, the MBC switches the active bank of ROM and RAM to accommodate more code.
I will summarize each MBC as well as quote some information from datasheets.

MBC1


Is the first in the series of controllers which did only expand the addressable memory. Since the gameboy has 16 address pins and 8 data pins running through to the cartridge, the gameboy may without an MBC address only read from and write to a maximum of 256Kbits or 32Kbytes which is incredibly small considering Mario Land has 12 massive levels with multiple means of gameplay including the platformer and shooter, in both an airplane and submarine. Some of these levels even have secondary underworlds where Mario drops to an extra map off screen to collect secret coins or other items.

In any case, the MBC1 has two different modes to choose from. There is the 16Mbit ROM/8KByte RAM and 4Mbit ROM/32KByte RAM. 

Note: RAM is an external IC which needs to be connected to a battery while disconnected from gameboy power to retain data.

MBC2

Similarly to the MBC1, the MBC2 maps extra banks of memory with specific memory writes; however, it may only map up to 2Mbits or 256Kbytes of ROM. Why a decrease? Well the magical thing about the MBC2 is that it contains 512 x 4 bits of SRAM built into the IC itself. This saves a lot of room on your cartridge board granted you are designing one.

The MBC2 can save money on RAM and space on your board if you are programming a small game that requires little ROM and RAM. Referring to the MBC1 above, if you wanted to offer a saving feature, you would need to source a RAM IC as well and route all of the Address, data and control pins to another location on the board.

MBC3

The MBC3 may again address up to 16Mbits of memory, but has a major feature built like the MBC2 has RAM. The MBC3 has an RTC or Real Time Clock built in. The RTC while still needing battery power when disconnected, offers a real-time count so that games such as pokemon may tell whether it is night or day, or when an hour in real life has passed for example.

Some games use the MBC3 without utilizing the RTC, but games that do include Pokemon of Generation 2 and Harvest Moon.

MBC5

Lastly, the MBC5 is the final Memory Bank Controller from Nintendo. This particular MBC does not come with internal RAM or an RTC. It simply maps huge amounts of memory. It may map up to 64Mbits of ROM and up to 1Mbit of RAM but not both. There are different configurations to choose from; these are just the maximums.

This MBC which I find in nearly every Gameboy Color cartridge regardless of ROM size is guaranteed to work with the GBC's double speed mode. The others seem to work just fine too though, considering any GB game will run on your GBC.

For more information on how to use the MBC's with software, please refer to "Cartridge Types" in this document:
http://www.devrs.com/gb/files/gbspec.txt

MBC CPLD Clones & Reproductions

Aside from the Official Nintendo MBC's, people have had major success in recreating them using CPLD's. Both Homebrew developers and Chinese pirating companies that is.

Since the MBC2 and MBC3 contain separate ICs, recreating them is much too difficult for a single person. MBC1 and MBC5 on the other hand can and have been redesigned by using CPLD's. They way they work as mentioned above is that they look for specific data bytes to be written to specific address locations. This Logic can be entirely drawn out using logic gates, which in turn can be programmed onto the CPLD.

MBC1 - CPLD

The MBC1 being the most simple, can be drawn using as little as 11 gates! (granted you do not need RAM)

MBC5 - CPLD

The MBC5 is much more complex of course, but it has also been cloned successfully by at least two separate people using two different CPLD's. One person used the XC9536 and the other person used the XC9572.

XC9536
http://chipmusic.org/forums/topic/2988/mbc5-clone-in-cpld/
and XC9572
http://home1.stofanet.dk/hvaba/gameboy/mbc5cpld/cpldcart.html

Depending on the number of inputs and outputs, more complex logic ought to be designed using PLD's or CPLD's. Not only can you save money on IC's, but space on your circuit boards. More often than not, a logic IC will take up space on your board and have a handful of unused pins and gates which is wasteful and lazy.

As always, thanks for reading! I hope I opened someone's eyes to new and old hardware.
Cheers

Populating the GB-Programmer (Jazz-Assembly #1)

The board has been designed to accommodate different methods of programming the Atmega8515 (hereby simply called 8515). Once programmed, you may never choose to reprogram it again because there may never be updates to the firmware anytime in the future.

Step 0.
Admire your beautiful new toy. 

It shall prove to be very useful regardless of your individual purposes. Also, at no time should you power your board until I say so.

Step 1.
Soldering both SMT ICs

The picture below is of two board prior to me cutting them apart. To reduce cost, I panelized my design.




You may choose to solder one IC at a time or both at once depending on your skill and resources. It would be highly suggested to use either a hot air gun or some type of oven and solder paste. Soldering by iron is perfectly possible, but creates more chance for failure. If you are a frequent reader, you should know that I now own an awesome hot air station, so I also bought a tube of solder paste.

Simply apply a very small amount of solder paste to the bare pads and carefully place your IC over top of them. Make sure that it is aligned as closely as possible, not forgetting to orient pin 1 in the right direction. Pin 1 is designated by the white circle on the board.





Once you finish both ICs, make sure that there are no shorts in places that they may not be. If you find one, attempt to draw the solder off of the pins with your iron or solder wick. Check it again and once satisfied, move on.

Step 2.
Through-hole components.

As much as I had hoped not to use any through-hole components, my audience insisted. The through-hole components required include:

2x 0.1uF ceramic capacitors (may be labelled 104)
1x 4.7uF electrolytic capacitor
1x 10K ohm resistor
1x 1K ohm resistor
2x 220 ohm resistors
2x LEDs (two colors)
1x female USB type B connector
1x gameboy cartridge connector

For the time being, do not populate C4, R6 and R7. These are not relevant at this time. You may choose to use a 6MHz ceramic oscillator, but I suggest saving the money and moving on. If you do though, cut the trace leading from it to the FDTI chip.

Start by placing the leads into the holes and bending them away from center so that they stay in place. Sodler each component on the underside and clip the legs at the board. Some people would suggest to clip them before soldering though.

Also make sure that the electrolytic capacitor (C3) faces negative lead down as shown below. Each components has the appropriate value marked on the board, so you cannot go wrong. Seating the gameboy cartridge connector may be the most difficult through-hole component. It has the most pins and each of these pins could be slightly bent from originally removing it. Take your time and do not stress.



The LEDs can be any color you like, but know that the one farthest from the resistor is power and the other one is activity. I prefer my toys to have a green power LEd. ;)




Step 3. 
PC Connection

Check your SMT soldering ONE MORE TIME. If and only if there are no shorts between pins, connect the board to your PC and cross your fingers... IF all is well, the LED should light up and a driver should automatically install for your device. It will also be given a COM port number.




Step 4.
Programming the FT232RL and 8515

Thats right, you're going to program both ICs. There is only one modification that needs to be made to the FT232RL (hereby simply called 232) which is to make it output a 6 MHz clock rate. This is for the 8515 to run on.

First, the 232's internal eeprom must be modified. To do this, we will use FT_Prog found on the FTDI website here:
http://www.ftdichip.com/Support/Utilities.htm#FT_Prog

Only one modification must be made and that is to change the CBUS0 pin to act as a 6 MHz clock. We will not worry about the other pins because they are all unconnected. CBUS0 is one of five programmable I/O pins and there are many options to choose from, but I am not going to cover these here.

Install FT_Prog and run it. You'll be greeted by a well designed GUI ... just don't touch anything. plug in your device and it should install a driver if it has not already. Once "Your device is ready to use" go ahead and click "Scan and Parse" which looks like a magnifying glass. Your device should pop up in the dialog box under device tree like this:



You can see that your device is already programmed, but we must now change one function. Expand the device tree as such:
FT EEPROM -> Device Specific -> IO Controls -> C0
Use the drop-down to select CLK6 in the C0 bus only. The other pins are all useless as they are not connected to anything. Ignore them.



Click on the lightning bolt which is the program button, make sure your device is selected and press "program" if and only if you are positive you did not change any other settings.
The bottom of the window will say finished and then ready. Close the window and close FT_Prog, then disconnect your programmer.



Reconnect your device once more and it should install the drivers again and give it a new COM port. You can now move on, but if you were to open your device in FT_Prog again, you would notice that C0 is still set to CLK6. Good job!

Just a note, but the reason you should not touch any other options in the eeprom settings is because there are too many settings that can be set incorrectly. For example, if you were to program your device to use an external oscillator, it would be rendered useless and you spent a lot of time and energy soldering that chip perfectly! So be careful!

Step 5.
Programming the 8515.

The easiest way to program the 8515 is via FTDI BitBang. It is a totally new concept to me, but incredibly useful considering how much people want to charge for ordinary ICSP programming kits. It may be a tad bit slower at programming, but since you will only program the 8515 once, it does not matter.

I put together a file-pack to get you started. This pack  includes AVR_DUDE, my custom config file special for this programmer and the hex file which needs programmed to your 8515. I am writing the guide on the GUI version of AVR-DUDE. Everything is easier with a GUI, though you have to show a little love for the tried and true command prompt. ;)

Download it here:
http://www.noisechannel.org/wp-content/uploads/2013/09/GB-Progger-kit.zip

Lets get started.

Go ahead and hook up your programmer if it is not already. Open avrdude-GUI.exe.
1. Direct the first box to your avrdude.exe
In our case, we will be using the avrdude-serjtag that you downloaded.
2. Pull down the "Programmer" Box and select the "FT232R Synchronous BitBang for Jazz (GBProgger)."
3. Leave the port drop box blank.
4. Locate "ATmega8515 (m8515)" under the "Device" drop-down.
5. Type "-P ft0 -B 4800" in the "Command line Option" box. It should look just like this below:




6. Click the "Read" button under Fuse. This will show you the fuse bits on your 8515 which must be changed. It does not matter what they are now.




7. Change the fuse bits to C910 as pictured and hit write. It will be very fast and just ask you if it went well.




8. Now erase "-B 4800" from the "Command line Option" and browse for the hex file under Flash then hit write. It is also fast, too fast for me to get a screenshot even.




9. Exit and done. Disconnect your device and reconnect it. If all went as planned, you now own a GB Programmer and Dumper for whatever needs you may have.

Lets test it out, shall we? That is another blog post, for another time. See you then! :D

 Cheers,
Jazz