Forums

Hello everybody,

As part of a larger project, I'm trying to get my Game Gear to run code off of an SST39SF040 parallel flash chip. I created a PCB that goes in the cartridge slot, and it has wires that go to a small protoboard holding the chip in a socket (see the picture). The chip is fully erased, except for 32K of code at address 0 (I'm using this for now, as a test: https://www.smspower.org/Homebrew/GamegearButtonTest-GG). The chip was erased, programmed, and verified in my friend's TL866 programmer.

In the system, A0-A15 and D0-D7 are connected between the GG and the flash, as well as /Wr, /Rd, and /CE. The chip is powered by the GG's 5V line, and all the higher flash address lines are held low. /TV is high and /GG is low.

The problem is that I cannot get the system to run. On the oscilloscope, I can see that the Z80 is trying to run code (cyclic address lines and strobing /Rd and /CE), and the output signals from the GG look nice and sharp. However, the flash's output on the data lines looks...weird (see the attachment). I don't think those ~2.5V parts are crosstalk, but I have no idea why they're there, and I suspect they may be the issue.

Does anybody have experience with flash chips like this? Is the flash just not capable of driving pins in a precarious system like this?

For the record, I have gotten this to work exactly twice. Both times, the system was connected with female headers on the PCB connected to wires that ran to a breadboard with the flash chip in the socket. I have no idea why it worked those times.

image.png (50.55 KB)

Data line D0 on the scope

pcb_setup.jpg (381.56 KB)

My PCB setup

Use /M0-7, not /CE.

Despite the pin name, /CE does not mean "exclusively ready for hardware on the cartridge"

lidnariq wrote

Use /M0-7, not /CE.

Despite the pin name, /CE does not mean "exclusively ready for hardware on the cartridge"

Yes, that is very likely the problem here. To give a little more explanation @liamur, ~CE on the cart connector will be active even when the system is attempting to access onboard RAM, so in that situation you may be getting bus contention on read operations, as both the RAM and your ROM chip attempt to respond to the read request. That may be why you're seeing those little half height blips on your scope (also see below about bypass cap), although the resolution looks very low on that trace so I wouldn't necessarily take it to heart.

lidnariq's suggestion should ensure that you don't get the contention since ~M0-7 will not be active when RAM is being accessed, but you may want to build some more sophisticated address decoding if you intend to use more than 32KB of ROM address space.

You might not have seen a bus contention issue if you'd created a much simpler test program that didn't use RAM at all. I usually start with something that just sets a backdrop color (for some reason I usually pick cyan), turns the display *off* and then halts. With ~GG mode active I think the following machine code should do it for you, if you can get it into your ROM somehow:

f3 3e 20 d3 bf 3e c0 d3 bf 3e f0 d3 be 3e 0f d3
be 3e a0 d3 bf 3e 81 d3 bf 76 18 fd 00 00 00 00

I would also highly advise, if you haven't already done it, chucking at least a 100nF bypass capacitor across the power supply near to your ROM if you want to do experiments, especially with those long wires and daughter board. I can't count the times I've decided to lazily skip bypass caps only to have the system do weird things without them.

Thank you both! That did it! Unfortunately, it means the memory system is more complicated than I thought.

Yes, I do have a small filter cap on the board that holds the flash chip.

Is this /CE behavior specific to the Game Gear? My favorite pinout document, https://www.smspower.org/maxim/Documents/Pinouts, describes /CE as being enabled whenever the cartridge slot is in use, and implies that cartridge /CE is only for the cartridge slot. Is that document inaccurate? It's the only one I can find that really explains what each pin does.

liamur wrote

Thank you both! That did it! Unfortunately, it means the memory system is more complicated than I thought.

Yes, I do have a small filter cap on the board that holds the flash chip.

Is this /CE behavior specific to the Game Gear? My favorite pinout document, https://www.smspower.org/maxim/Documents/Pinouts, describes /CE as being enabled whenever the cartridge slot is in use, and implies that cartridge /CE is only for the cartridge slot. Is that document inaccurate? It's the only one I can find that really explains what each pin does.

No, the SMS has the same behaviour.

In a nutshell, the ~CE line (or the various ~CE lines in the SMS) is simply an on / off switch which selects whether or not the cartridge (or the respective device on the SMS, e.g. BIOS, expansion port, Sega Card) should be present on the address bus or not. In the SMS, port $3e directly controls the state of the various ~CE lines, so the BIOS, or indeed any program, can turn any combination of the various ~CE lines on or off.

This is how the SMS is able to run a BIOS (including built in games) and also detect and run a cartridge if one is inserted. The BIOS ~CE line (~CE0 iirc) starts enabled which allows the onboard ROM to present itself, and during the boot routine the cartridge ~CE line (~CE3) becomes active while the BIOS ~CE becomes inactive to allow the onboard ROM to turn off and the cart ROM to turn on. Either way some additional address decoding logic is present to handle the RAM space vs. either ROM space. I'm not sure exactly how it works on the GG as I know some models don't have a BIOS so I suppose it might always be active, but I'm sure others can confirm under what circumstances ~CE becomes active.

Depends on your exact needs, but you should be able implement a functional address decoder with pretty minimal discrete logic, either a small number of logic gates or very likely a single 74x138 decoder.

Author	Message
liamur Joined: 03 Jan 2022 Posts: 9 Location: Albuquerque, NM, USA	Running a Game Gear off of an SST39SF040 Posted: Sun Dec 04, 2022 12:50 am
	Hello everybody, As part of a larger project, I'm trying to get my Game Gear to run code off of an SST39SF040 parallel flash chip. I created a PCB that goes in the cartridge slot, and it has wires that go to a small protoboard holding the chip in a socket (see the picture). The chip is fully erased, except for 32K of code at address 0 (I'm using this for now, as a test: https://www.smspower.org/Homebrew/GamegearButtonTest-GG). The chip was erased, programmed, and verified in my friend's TL866 programmer. In the system, A0-A15 and D0-D7 are connected between the GG and the flash, as well as /Wr, /Rd, and /CE. The chip is powered by the GG's 5V line, and all the higher flash address lines are held low. /TV is high and /GG is low. The problem is that I cannot get the system to run. On the oscilloscope, I can see that the Z80 is trying to run code (cyclic address lines and strobing /Rd and /CE), and the output signals from the GG look nice and sharp. However, the flash's output on the data lines looks...weird (see the attachment). I don't think those ~2.5V parts are crosstalk, but I have no idea why they're there, and I suspect they may be the issue. Does anybody have experience with flash chips like this? Is the flash just not capable of driving pins in a precarious system like this? For the record, I have gotten this to work exactly twice. Both times, the system was connected with female headers on the PCB connected to wires that ran to a breadboard with the flash chip in the socket. I have no idea why it worked those times. image.png (50.55 KB) Data line D0 on the scope pcb_setup.jpg (381.56 KB) My PCB setup

lidnariq Joined: 24 Mar 2021 Posts: 120	Posted: Sun Dec 04, 2022 1:00 am
lidnariq Joined: 24 Mar 2021 Posts: 120	Use /M0-7, not /CE. Despite the pin name, /CE does not mean "exclusively ready for hardware on the cartridge"

willbritton Joined: 06 Mar 2022 Posts: 670 Location: London, UK	Posted: Sun Dec 04, 2022 9:39 am
	lidnariq wrote Use /M0-7, not /CE. Despite the pin name, /CE does not mean "exclusively ready for hardware on the cartridge" Yes, that is very likely the problem here. To give a little more explanation @liamur, ~CE on the cart connector will be active even when the system is attempting to access onboard RAM, so in that situation you may be getting bus contention on read operations, as both the RAM and your ROM chip attempt to respond to the read request. That may be why you're seeing those little half height blips on your scope (also see below about bypass cap), although the resolution looks very low on that trace so I wouldn't necessarily take it to heart. lidnariq's suggestion should ensure that you don't get the contention since ~M0-7 will not be active when RAM is being accessed, but you may want to build some more sophisticated address decoding if you intend to use more than 32KB of ROM address space. You might not have seen a bus contention issue if you'd created a much simpler test program that didn't use RAM at all. I usually start with something that just sets a backdrop color (for some reason I usually pick cyan), turns the display off and then halts. With ~GG mode active I think the following machine code should do it for you, if you can get it into your ROM somehow: f3 3e 20 d3 bf 3e c0 d3 bf 3e f0 d3 be 3e 0f d3 be 3e a0 d3 bf 3e 81 d3 bf 76 18 fd 00 00 00 00 I would also highly advise, if you haven't already done it, chucking at least a 100nF bypass capacitor across the power supply near to your ROM if you want to do experiments, especially with those long wires and daughter board. I can't count the times I've decided to lazily skip bypass caps only to have the system do weird things without them.

liamur Joined: 03 Jan 2022 Posts: 9 Location: Albuquerque, NM, USA	Posted: Sun Dec 04, 2022 5:17 pm
	Thank you both! That did it! Unfortunately, it means the memory system is more complicated than I thought. Yes, I do have a small filter cap on the board that holds the flash chip. Is this /CE behavior specific to the Game Gear? My favorite pinout document, https://www.smspower.org/maxim/Documents/Pinouts, describes /CE as being enabled whenever the cartridge slot is in use, and implies that cartridge /CE is only for the cartridge slot. Is that document inaccurate? It's the only one I can find that really explains what each pin does.

willbritton Joined: 06 Mar 2022 Posts: 670 Location: London, UK	Posted: Sun Dec 04, 2022 6:20 pm
	liamur wrote Thank you both! That did it! Unfortunately, it means the memory system is more complicated than I thought. Yes, I do have a small filter cap on the board that holds the flash chip. Is this /CE behavior specific to the Game Gear? My favorite pinout document, https://www.smspower.org/maxim/Documents/Pinouts, describes /CE as being enabled whenever the cartridge slot is in use, and implies that cartridge /CE is only for the cartridge slot. Is that document inaccurate? It's the only one I can find that really explains what each pin does. No, the SMS has the same behaviour. In a nutshell, the ~CE line (or the various ~CE lines in the SMS) is simply an on / off switch which selects whether or not the cartridge (or the respective device on the SMS, e.g. BIOS, expansion port, Sega Card) should be present on the address bus or not. In the SMS, port $3e directly controls the state of the various ~CE lines, so the BIOS, or indeed any program, can turn any combination of the various ~CE lines on or off. This is how the SMS is able to run a BIOS (including built in games) and also detect and run a cartridge if one is inserted. The BIOS ~CE line (~CE0 iirc) starts enabled which allows the onboard ROM to present itself, and during the boot routine the cartridge ~CE line (~CE3) becomes active while the BIOS ~CE becomes inactive to allow the onboard ROM to turn off and the cart ROM to turn on. Either way some additional address decoding logic is present to handle the RAM space vs. either ROM space. I'm not sure exactly how it works on the GG as I know some models don't have a BIOS so I suppose it might always be active, but I'm sure others can confirm under what circumstances ~CE becomes active. Depends on your exact needs, but you should be able implement a functional address decoder with pretty minimal discrete logic, either a small number of logic gates or very likely a single 74x138 decoder.

Forums

View topic - Running a Game Gear off of an SST39SF040