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

CCAM - Crystal Clear Audio Mod for Sega Genesis/MegaDrive by Tiido

I took an afternoon to look at Tiido's circuit to clean up and amplify certain channels on the poorer created versions of the Sega Genesis and megadrive. This circuit separates all of the audio channels, amplifies them individually, mixes, amplifies again, offsets the DC output and applies a low pass filter. This is based on the sound filter inside of the original "HD Graphics" models of the sega genesis which arguably has the best sounding output.

I have taken the liberty of redesigning the circuit with all higher quality 1% tolerant, through-hole components, a low power op amp and easy to solder tie points for installation.

Fun with the Sega Genesis - Ultimate Portable Game player

Found a crazy deal on fleabay for one of these and had to have it. I had heard stories of how badly they are made, and how miserable the audio is.
All very true, but I think it can be improved a little.

The video is great, the size a too small, the sound from the speaker is crap but the sound from the headphone could be worse.
I immediately took it apart after opening the box. I was THRILLED to see only one epoxy-chip and several SOP's! :D

I want to believe that the audio issue is because of the amp/filter they have used. Through headphones, it sounds ok, but also a little clipped and shallow. This could also be because of the power supply, which is very weak. The battery is 3.7v and droops when the PSG is loud.




Its like a portable MP3 player considering all the titles that have sound tests. :p
You know, except horrible sounding.

Intec PS2 LCD screen Mod

I found a controller at a junk shop for $5, and figured I would mod it onto a console. For the longest time I couldn't figure out how to add it to a console because I didn't know which cable was which. Now I figured it out: Orange: +12v (connects to a 7808 regulator so the voltage range should be greater and lesser than 12.) Black: Ground Brown: Ground Red: Right Audio input White: Left Audio input yellow: Composite video input Now I can finally build it into something. Maybe my new Sega Genesis 3, since it will fit right on the face of it and hopefully can share the same +10v power supply!

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...

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.