Beginner in digital circuitry

ioncannon · Post by **ioncannon** » Sun Feb 20, 2011 8:07 pm

I see. I figured out a DeMux would have been a better choice for address decoding (had a circuit of NORs and NANDs setup lol) so it brings the circuit down to just 1 chip.

Now I just need to grab a demux, and wait for the EPROM burner.

Ah, one more question: the first to pins on the NES 6502 are sound outs as I said before. Looked up on some circuits, and it seems the output in analog, because people have wired RCA jacks to the lines for a fake "stereo" sound. Pin 1 is two triangle channels, and pin 2 is a noise and DMC channel.

Now I have a pc speaker I have sitting here... if I wire it to the pin, will sound get produced, or do those work differently?

GARTHWILSON · Post by **GARTHWILSON** » Mon Feb 21, 2011 1:05 am

Quote:

I see. I figured out a DeMux would have been a better choice for address decoding (had a circuit of NORs and NANDs setup lol) so it brings the circuit down to just 1 chip.

Now I just need to grab a demux,

You can do it all with a single 74xx00 quad NAND and have tons of I/O and 16KB of RAM and 32KB of ROM (or, with a minor change, 32KB RAM and 16KB ROM), and your propagation delays will be a lot shorter than a deMux like the '138. See this diagram. Replace the inverter on the A15 line with one section of the 74xx00. I already had the inverter for something else, so I used it. The other inverter section shown was for something I no longer remember and never used.

BigEd · Post by **BigEd** » Mon Feb 21, 2011 9:06 am

ioncannon wrote:

on the NES 6502 ... Pin 1 is two triangle channels, and pin 2 is a noise and DMC channel.

Now I have a pc speaker I have sitting here... if I wire it to the pin, will sound get produced, or do those work differently?

You might get something. I suspect you'd need more drive, and maybe some filtering. I don't know whether or not you might cause damage. Better would be to drive into the MIC or AUX input of some audio equipment. I think it's normal to have a transistor or two for drive, but this isn't my area of expertise.

Here's what the zx spectrum did: http://www.zxdesign.info/soundbeeper.shtml

ioncannon · Post by **ioncannon** » Thu Mar 10, 2011 4:54 pm

So got my eraser and programmer, and proceded to erase the chips. The data that was left on there dissappeared, and now the reader is reading 0xFE everywhere. Shouldn't it be 0xFF? Also I cannot write anything to the chip except 0xFF. I cooked the chip for 15min.

GARTHWILSON · Post by **GARTHWILSON** » Thu Mar 10, 2011 7:15 pm

Yes, the erased state is $FF not $FE.

ioncannon · Post by **ioncannon** » Thu Mar 10, 2011 9:52 pm

Well, tried cooking again, all the bits are stuck at $FE, any reason why?

BigDumbDinosaur · Post by **BigDumbDinosaur** » Fri Mar 11, 2011 1:04 am

ioncannon wrote:

So got my eraser and programmer, and proceded to erase the chips. The data that was left on there dissappeared, and now the reader is reading 0xFE everywhere. Shouldn't it be 0xFF? Also I cannot write anything to the chip except 0xFF. I cooked the chip for 15min.

15 minutes should be more than adequate. Is it possible that you have a bad ROM?

Dr Jefyll · Post by **Dr Jefyll** » Fri Mar 11, 2011 3:58 am

Have you tried more than one chip? If you have multiple EPROMs that all read 0xFE after being erased, then it's likely there's a problem with the programmer or simply its EPROM socket. I'd suggest you take a close look at the socket pin that corresponds to data bit 0 (the bit with the anomalous results). Bit 0 appears on pin 9 for a 24-pin device such as 2716, for example, or pin 11 on a 28-pin such as 2764. You want to verify that the pin and socket are free of contamination and are firmly in contact.

If you don't find any problem there, then there could be a fault internal to the programmer. As an experiment, you could try programming an EPROM with some test bytes -- bytes (like 0xFE) that already have bit 0 low. For example you could try programming all the bytes to the value 0x44 or even 0x00. But it's not a fix, of course.

If this operation is successful then it merely narrows down the possible explanations of what's going on. Presumably the operation would fail if you tried to program values such as 0x45 or 0x01.

-- Jeff
[edit: reword text, add example values]

ioncannon · Post by **ioncannon** » Sat Mar 12, 2011 11:43 pm

Dr Jefyll wrote:

Have you tried more than one chip? If you have multiple EPROMs that all read 0xFE after being erased, then it's likely there's a problem with the programmer or simply its EPROM socket. I'd suggest you take a close look at the socket pin that corresponds to data bit 0 (the bit with the anomalous results). Bit 0 appears on pin 9 for a 24-pin device such as 2716, for example, or pin 11 on a 28-pin such as 2764. You want to verify that the pin and socket are free of contamination and are firmly in contact.

If you don't find any problem there, then there could be a fault internal to the programmer. As an experiment, you could try programming an EPROM with some test bytes -- bytes (like 0xFE) that already have bit 0 low. For example you could try programming all the bytes to the value 0x44 or even 0x00. But it's not a fix, of course.

If this operation is successful then it merely narrows down the possible explanations of what's going on. Presumably the operation would fail if you tried to program values such as 0x45 or 0x01.

-- Jeff
[edit: reword text, add example values]

Yea, ALL bits are reading FE. I have two EPROMs (same brand/type) and they both act the same. They are NMC27C64 chips. The software seems to detect when pins are disconnected. Maybe the first data pin is being grounded (thus 1111 1110, 0xFE)? Will do what you suggested.

ioncannon · Post by **ioncannon** » Sun Mar 13, 2011 1:09 am

Well it doesn't seem to work. Trying to write any bits other then 0xFF, fails.

Don't know if it helps but the error I get is

Write...Error at:00000:(FF)

It seems it sees FF at programming time, but not at reading. Still, no reason to FAIL if it sees FF.

ioncannon · Post by **ioncannon** » Sun Mar 13, 2011 1:51 am

Think the eprom might be bad, threw it onto my homebrew computer circuit, and stuck a LED onto d0. Blew out three LEDs, and would glow super bright on a green one. Plus it was overheating the 6502. Hopefully I didn't fry anything.

Guess I need a new ROM?

GARTHWILSON · Post by **GARTHWILSON** » Sun Mar 13, 2011 2:00 am

FF is the erased state. So if you try to write FF when you're starting with FE (bit 0 low), you will definitely get an error. As for the LED, you should have a series resistor to limit the current to levels that are safe for both the LED and whatever drives it. 470 ohms would be fine.

ioncannon · Post by **ioncannon** » Sun Mar 13, 2011 2:29 pm

However 0xFF does get written with no problem!

BigEd · Post by **BigEd** » Sun Mar 13, 2011 2:32 pm

Because the erased state is FF, it might be that writing FF doesn't even try to do anything, or the checker doesn't try to check anything. You can only write 0 bits: the 1 bits get put there by erasing.

ioncannon · Post by **ioncannon** » Sun Mar 13, 2011 10:01 pm

Ahh good point. Not sure what to do at this point. Probably will buy another rom and see.

Beginner in digital circuitry

Cook the Books...