Forums

After the idea was brought up in another thread about using an SMSReader to try and diagnose a non-working mapper circuit, I built an SMSReader.

Typical then of course that it doesn't work right either!

I tried dumping a retail copy of Hang On which autodetected as 64k and failed to read properly. I manually selected 32k but also had issues - basically the cartridge would not read properly and would create a different checksum each time.

I swapped the ROM out for a burnt EPROM (NMC27C256) copy of another game (Transbot) and it read just fine, verified correctly etc, which I tested 3 times in a row and got the same result.

I started out with the 'troubleshooting' resistors and capacitors installed as standard (which seems to be suggested to do) and I also have the 47k pulldown resistors on the parallel port\data lines so I really don't know what else to try.

The fact that it can at least dump something at all seems to suggest it's not software or parallel port settings etc, so why it doesn't like the other ROM IC I don't know.

I will try to borrow some more retail games from a friend and do more tests but I don't see why my copy of Hang On doesn't work - It has no problems loading in the real SMS console.

Well, I borrowed some games from my friend (Michael Jackson's Moonwalker, Alien Storm and Sonic 2) and they read just fine.

I read each one 10 times and I made sure to swap them around between reads to try and cause problems but I had no errors.

Even stranger then that Hang On will consistently read incorrectly (and with different results each time).

Today I tried Hang On again, after replacing both capacitors on the cartridge in the event they might have been faulty.

Then, I noticed a very odd thing: while (trying to) read the cartridge with the SMSReader, there was static\noise on my PC speakers.

I don't believe this happened last time, and I have not noticed it with the other 3 games at all (re-tested to be sure)

I thought perhaps the new capacitors might be dodgy so I put the old ones back but the noise was still present. Thinking perhaps the IC had died, I put in my NMC27C256 with Transbot which read fine and made no noise.

I then removed the IC socket I had installed in the cartridge, and soldered the original ROM IC back in, in the event it was a bad connection, but this didn't make any difference.

I tried it back on the SMS where it worked just fine.

It then came to my mind that I had moved the parallel cable last time, so perhaps the noise had always been present but the cable was now closer to the speaker leads and was causing the problem.

I moved it away but the noise remained. I then found out the noise could be stopped by unplugging the speakers from the sound card!

Whatever is causing the noise, it seems it is ending up on the audio output of the soundcard somehow.

Will borrow more games later and see if I can get any of them to fail, but for now I am now going on the theory that the SMSReader might be just fine, but there is something funny going on with the Hang On cartridge itself. Perhaps the SMSReader isn't as tolerant to this noise from Hang On but the SMS is?

Well this is disappointing.

My friend brought over some more games, including another copy of Hang On.

His copy of Sonic 1 read just fine on the SMSReader but copies of Wonderboy, Black Belt and his copy of Hang On did not work properly - all doing the same thing as my copy of Hang On, that is: An unrecognised dump that has a different checksum every time.

So it does seems like there is something of an issue with the SMSReader itself.

I've just re-read the troubleshooting section of the SMSReader page and noticed it says to try removing the pull-down resistors for the parallel port - something which I overlooked - so I guess I'll try removing them and seeing if that makes any difference (logic levels being pulled too low and interpreted wrong?)

Aside from this I don't know what else I can try, really

Does anyone else have any ideas if removing the pull-down resistors doesn't work?

By any odd chance is your sound card IRQ on the same IRQ as your parallel port? There's a small possibility your case could not be grounded properly.

I would try in this order: checking IRQ of sound card and parallel port, moving cable away from speakers/anything with a magnet (i.e. crt monitor), replacing the parallel cable, testing on a completely different PC.

After that, I'm stumped.

Thanks for the suggestions, I will try to try them out later today.

EDIT: Parallel port uses IRQ7 and the sound card IRQ11 so I guess that isn't a problem.

Looked for another cable, couldn't find one. Got a box of ones with Centronics plugs for printers, and the only one that had the right plug was wired differently.

Tried on an old P3 Laptop - same problem.

However in the mean time I have another update - I did try removing the pull-down resistors this morning but it doesn't seem to have made any difference, at least not to my copy of Hang On.

I had the clever idea to actually save some of the bad dumps of Hang On and then compare them in a hex editor - the result is they are not totally corrupt or random data at all! (but I don't know why the checksum keeps changing)

For the most part, all the dumps are all the same, except large chunks of the data is actually missing, replaced with just blocks of FFFF

Unfortunately my friend took his games back so I can't test the others that didn't work and see if they have the same problem right now.

I have uploaded 5 bad dumps of Hang On which show this problem, for anyone who wants to have a look.

Hang On (Corrupt Dumps).zip (16.76 KB)

I had the noise-in-PC-speakers problem with some of my SMS Reader and cartridge combination and it never led to good dump. I don't know what caused it but then I'm totally ignorant in electronics and there's probably variety of reasons anyway. Maybe Charles MacDonald would have an idea?

Bock wrote

I had the noise-in-PC-speakers problem with some of my SMS Reader and cartridge combination and it never led to good dump. I don't know what caused it but then I'm totally ignorant in electronics and there's probably variety of reasons anyway. Maybe Charles MacDonald would have an idea?

That's quite interesting you had the same problem. I wonder what causes it...

Strange though that some of my friend's cartridges also consistently resulted in a bad dump, but did not cause the noise in the speakers. (Or perhaps the noise just wasn't at a frequency to cause the probelem!)

I guess this is where a good DSO and Logic Analyser would come in handy - except that I don't have either one :(

Is the FFFF in about the same areas every time? Maybe one of the address lines on the reader itself aren't wired up properly or one of the wire wrap wires are loose?

Also, have you tried another power supply? Maybe the one you have is a cheap shitty one and it can't handle the SMSReader.

Maraakate wrote

Is the FFFF in about the same areas every time? Maybe one of the address lines on the reader itself aren't wired up properly or one of the wire wrap wires are loose?

It is for Hang On - if you take a look at the dumps I posted you'll see what's going on.

But I doubt it could be a wiring issue as some cartridges do work - if there was a wiring error I would expect none of them to work.

I was starting to think that myself though - perhaps it's a problem on the address lines rather than the data lines, but then why would it only happen on some cartridges? Perhaps some cartridges don't like the output voltages from the 4040 ICs for some reason (noise etc) or those ICs themselves have issues with some cartridges somehow and are getting confused.

Again, I can't analyse anything like that though as I don't have the right equipment.

Everything is soldered - no wire wrapping here.

Maraakate wrote

Also, have you tried another power supply? Maybe the one you have is a cheap shitty one and it can't handle the SMSReader.

No I haven't tried a different power supply but it seems unlikely to be an issue either. I'll try another but I doubt it will make a difference. The one I'm using is 9v at 1 Amp which is actually more current than the SMS own power supply gives, so it should be better, but in any case the current drawn for 3 CMOS ICs and one game cartridge should be minimal.

I would think any ripple and noise etc would get filtered out by the SMSReader's own 5v regulator circuit etc anyway.

Sorry, when I say wire wrap I meant those jumper wires and stuff all over the board.

Quote

Read operation verifies correctly, but still results in a bad dump (on some cartridges)

Reason: 4040 chip(s) are being affected by noise on the parallel port lines.
Solution: See solution to problem 1 above.

Reason: Read line is not connected/does not function correctly.
Solution: Check continuity of connections to and from the 74HC00 chip.

Reason: Pull-down resistors are causing problems with your parallel port.
Solution: Try desoldering the SIL resistor and see if it makes a difference.

I'm guessing you tried all of this. Maybe it's quite possible that the 74HC00 IC is bad? Or even the 4040s?

I've never built this before. I've always procrastinated doing it. But, I do know those types of sockets can be easy to bend the pins if you insert it wrong. So check for stupid things like that.

Agent24,

First, connect all the ground pins of the 25 pin Sub-D connector together.
http://www.hardwarebook.info/Parallel_(PC)

Second, add 4k7 pull up resistors to the three parallel port outputs. This will help if there is a mismatch between TTL (parallel port) and CMOS (4040, etc) levels.

viletim wrote

Agent24,

First, connect all the ground pins of the 25 pin Sub-D connector together.
http://www.hardwarebook.info/Parallel_(PC)

Already had it like that ;)

viletim wrote

Second, add 4k7 pull up resistors to the three parallel port outputs. This will help if there is a mismatch between TTL (parallel port) and CMOS (4040, etc) levels.

The troubleshooting notes show to use 2.2k resistors on the RESET and CLK lines, in fact it is advised to do this anyway (which I did)

So for the third one, that is /SEL line? Do you think it should have a 4.7nF decoupling capacitor on it the same as the other two?

Agent24 wrote

viletim wrote

Second, add 4k7 pull up resistors to the three parallel port outputs. This will help if there is a mismatch between TTL (parallel port) and CMOS (4040, etc) levels.

The troubleshooting notes show to use 2.2k resistors on the RESET and CLK lines, in fact it is advised to do this anyway (which I did)

So for the third one, that is /SEL line? Do you think it should have a 4.7nF decoupling capacitor on it the same as the other two?

I didn't read the troubleshooting section... Yes, put a pull up resistor on the /SEL line as well. It connects to a CMOS input just like the other two.

Are those 4.7nF caps between the parallel port output and ground (I don't follow this circuit by coordinates scheme)? I can't see that there's anything to be gained by that - try removing them.

viletim wrote

Are those 4.7nF caps between the parallel port output and ground (I don't follow this circuit by coordinates scheme)? I can't see that there's anything to be gained by that - try removing them.

Yes, they go between those lines and ground.

The instructions say:

Quote

Two more ceramic capacitors, 4.7nF ones, are used for filtering purposes on the Reset and Clock lines - see the Troubleshooting section and read the solution to problem 1. The idea is to improve reliability by filtering out transient pulses which might trigger a spurious clock or reset. This is particularly important if you use 74HC4040s rather than regular 4040s; the 74HC chips have something of a "hair trigger" and the slightest spike can affect them.

Well I tried first removing the 4.7nF capacitors and that only made the situation worse - when reading Hang On I got almost all the data as FFFF and what was not such was in fact corrupt.

So I think whatever those capacitors are there for, there is a good reason. But perhaps the values aren't right.

Does anyone know why the value of 4.7nF was chosen? I am thinking perhaps they should be some other value.

I didn't yet try a pullup resistor on the /SEL line as it was already at 3.36v and didn't change during the read operation.

I actually think it may only be used when writing to a RAM cartridge...?

Agent24 wrote

Well I tried first removing the 4.7nF capacitors and that only made the situation worse - when reading Hang On I got almost all the data as FFFF and what was not such was in fact corrupt.

So I think whatever those capacitors are there for, there is a good reason. But perhaps the values aren't right.

Does anyone know why the value of 4.7nF was chosen? I am thinking perhaps they should be some other value.

The capacitor is part of an RC filter. It's the C, the R is the output resistance of your parallel port - not something which is well documented or even predictable. I suspect the value was chosen empirically.

Quote

I didn't yet try a pullup resistor on the /SEL line as it was already at 3.36v and didn't change during the read operation.

That's not good news. The minimum to reliably turn on the input of a generic CMOS 4040 is 3.5V. I don't think the solution lies in placing capacitors or pull up resistors on the parallel port lines. What you need is a 4040 counter which is designed for TTL level input, not CMOS level. The 74HCT4040 would be ideal.

EDIT: And a 74HCT00 to replace the 74HC00.

viletim wrote

Agent24 wrote

I didn't yet try a pullup resistor on the /SEL line as it was already at 3.36v and didn't change during the read operation.

That's not good news. The minimum to reliably turn on the input of a generic CMOS 4040 is 3.5V. I don't think the solution lies in placing capacitors or pull up resistors on the parallel port lines. What you need is a 4040 counter which is designed for TTL level input, not CMOS level. The 74HCT4040 would be ideal.

EDIT: And a 74HCT00 to replace the 74HC00.

I tried swapping with HCT parts and I still have the same problems: blocks of FFFF in the same places as before, where there should be real data.

Got the thing working, finally. Turned out I had never connected the /M0-7 line to the cartridge, so the ROM chips always had their Output Enable pins floating!

Surprising that any cartridges worked at all.

Author	Message
Agent24 Joined: 28 Mar 2011 Posts: 88	SMSReader not working properly Posted: Fri Dec 09, 2011 2:36 am
Agent24 Joined: 28 Mar 2011 Posts: 88	After the idea was brought up in another thread about using an SMSReader to try and diagnose a non-working mapper circuit, I built an SMSReader. Typical then of course that it doesn't work right either! I tried dumping a retail copy of Hang On which autodetected as 64k and failed to read properly. I manually selected 32k but also had issues - basically the cartridge would not read properly and would create a different checksum each time. I swapped the ROM out for a burnt EPROM (NMC27C256) copy of another game (Transbot) and it read just fine, verified correctly etc, which I tested 3 times in a row and got the same result. I started out with the 'troubleshooting' resistors and capacitors installed as standard (which seems to be suggested to do) and I also have the 47k pulldown resistors on the parallel port\data lines so I really don't know what else to try. The fact that it can at least dump something at all seems to suggest it's not software or parallel port settings etc, so why it doesn't like the other ROM IC I don't know. I will try to borrow some more retail games from a friend and do more tests but I don't see why my copy of Hang On doesn't work - It has no problems loading in the real SMS console.

Agent24 Joined: 28 Mar 2011 Posts: 88	Posted: Sat Dec 10, 2011 3:34 am
Agent24 Joined: 28 Mar 2011 Posts: 88	Well, I borrowed some games from my friend (Michael Jackson's Moonwalker, Alien Storm and Sonic 2) and they read just fine. I read each one 10 times and I made sure to swap them around between reads to try and cause problems but I had no errors. Even stranger then that Hang On will consistently read incorrectly (and with different results each time).

Agent24 Joined: 28 Mar 2011 Posts: 88	Posted: Sun Dec 11, 2011 12:06 am
Agent24 Joined: 28 Mar 2011 Posts: 88	Today I tried Hang On again, after replacing both capacitors on the cartridge in the event they might have been faulty. Then, I noticed a very odd thing: while (trying to) read the cartridge with the SMSReader, there was static\noise on my PC speakers. I don't believe this happened last time, and I have not noticed it with the other 3 games at all (re-tested to be sure) I thought perhaps the new capacitors might be dodgy so I put the old ones back but the noise was still present. Thinking perhaps the IC had died, I put in my NMC27C256 with Transbot which read fine and made no noise. I then removed the IC socket I had installed in the cartridge, and soldered the original ROM IC back in, in the event it was a bad connection, but this didn't make any difference. I tried it back on the SMS where it worked just fine. It then came to my mind that I had moved the parallel cable last time, so perhaps the noise had always been present but the cable was now closer to the speaker leads and was causing the problem. I moved it away but the noise remained. I then found out the noise could be stopped by unplugging the speakers from the sound card! Whatever is causing the noise, it seems it is ending up on the audio output of the soundcard somehow. Will borrow more games later and see if I can get any of them to fail, but for now I am now going on the theory that the SMSReader might be just fine, but there is something funny going on with the Hang On cartridge itself. Perhaps the SMSReader isn't as tolerant to this noise from Hang On but the SMS is?

Agent24 Joined: 28 Mar 2011 Posts: 88	Posted: Wed Dec 14, 2011 5:16 am
Agent24 Joined: 28 Mar 2011 Posts: 88	Well this is disappointing. My friend brought over some more games, including another copy of Hang On. His copy of Sonic 1 read just fine on the SMSReader but copies of Wonderboy, Black Belt and his copy of Hang On did not work properly - all doing the same thing as my copy of Hang On, that is: An unrecognised dump that has a different checksum every time. So it does seems like there is something of an issue with the SMSReader itself. I've just re-read the troubleshooting section of the SMSReader page and noticed it says to try removing the pull-down resistors for the parallel port - something which I overlooked - so I guess I'll try removing them and seeing if that makes any difference (logic levels being pulled too low and interpreted wrong?) Aside from this I don't know what else I can try, really Does anyone else have any ideas if removing the pull-down resistors doesn't work?

Maraakate Joined: 05 Jun 2010 Posts: 757 Location: Pennsylvania, USA	Posted: Thu Dec 15, 2011 6:10 am
	By any odd chance is your sound card IRQ on the same IRQ as your parallel port? There's a small possibility your case could not be grounded properly. I would try in this order: checking IRQ of sound card and parallel port, moving cable away from speakers/anything with a magnet (i.e. crt monitor), replacing the parallel cable, testing on a completely different PC. After that, I'm stumped.

Agent24 Joined: 28 Mar 2011 Posts: 88	Posted: Thu Dec 15, 2011 10:49 pm
Agent24 Joined: 28 Mar 2011 Posts: 88	Thanks for the suggestions, I will try to try them out later today. EDIT: Parallel port uses IRQ7 and the sound card IRQ11 so I guess that isn't a problem. Looked for another cable, couldn't find one. Got a box of ones with Centronics plugs for printers, and the only one that had the right plug was wired differently. Tried on an old P3 Laptop - same problem. However in the mean time I have another update - I did try removing the pull-down resistors this morning but it doesn't seem to have made any difference, at least not to my copy of Hang On. I had the clever idea to actually save some of the bad dumps of Hang On and then compare them in a hex editor - the result is they are not totally corrupt or random data at all! (but I don't know why the checksum keeps changing) For the most part, all the dumps are all the same, except large chunks of the data is actually missing, replaced with just blocks of FFFF Unfortunately my friend took his games back so I can't test the others that didn't work and see if they have the same problem right now. I have uploaded 5 bad dumps of Hang On which show this problem, for anyone who wants to have a look. Hang On (Corrupt Dumps).zip (16.76 KB)

Bock Site Admin Joined: 08 Jul 2001 Posts: 8653 Location: Paris, France	Posted: Fri Dec 16, 2011 12:56 am
	I had the noise-in-PC-speakers problem with some of my SMS Reader and cartridge combination and it never led to good dump. I don't know what caused it but then I'm totally ignorant in electronics and there's probably variety of reasons anyway. Maybe Charles MacDonald would have an idea?

Agent24 Joined: 28 Mar 2011 Posts: 88	Posted: Fri Dec 16, 2011 2:49 am
Agent24 Joined: 28 Mar 2011 Posts: 88	Bock wrote I had the noise-in-PC-speakers problem with some of my SMS Reader and cartridge combination and it never led to good dump. I don't know what caused it but then I'm totally ignorant in electronics and there's probably variety of reasons anyway. Maybe Charles MacDonald would have an idea? That's quite interesting you had the same problem. I wonder what causes it... Strange though that some of my friend's cartridges also consistently resulted in a bad dump, but did not cause the noise in the speakers. (Or perhaps the noise just wasn't at a frequency to cause the probelem!) I guess this is where a good DSO and Logic Analyser would come in handy - except that I don't have either one :(

Maraakate Joined: 05 Jun 2010 Posts: 757 Location: Pennsylvania, USA	Posted: Fri Dec 16, 2011 7:20 am
	Is the FFFF in about the same areas every time? Maybe one of the address lines on the reader itself aren't wired up properly or one of the wire wrap wires are loose?

Maraakate Joined: 05 Jun 2010 Posts: 757 Location: Pennsylvania, USA	Posted: Fri Dec 16, 2011 7:22 am
	Also, have you tried another power supply? Maybe the one you have is a cheap shitty one and it can't handle the SMSReader.

Agent24 Joined: 28 Mar 2011 Posts: 88	Posted: Fri Dec 16, 2011 8:30 am
Agent24 Joined: 28 Mar 2011 Posts: 88	Maraakate wrote Is the FFFF in about the same areas every time? Maybe one of the address lines on the reader itself aren't wired up properly or one of the wire wrap wires are loose? It is for Hang On - if you take a look at the dumps I posted you'll see what's going on. But I doubt it could be a wiring issue as some cartridges do work - if there was a wiring error I would expect none of them to work. I was starting to think that myself though - perhaps it's a problem on the address lines rather than the data lines, but then why would it only happen on some cartridges? Perhaps some cartridges don't like the output voltages from the 4040 ICs for some reason (noise etc) or those ICs themselves have issues with some cartridges somehow and are getting confused. Again, I can't analyse anything like that though as I don't have the right equipment. Everything is soldered - no wire wrapping here. Maraakate wrote Also, have you tried another power supply? Maybe the one you have is a cheap shitty one and it can't handle the SMSReader. No I haven't tried a different power supply but it seems unlikely to be an issue either. I'll try another but I doubt it will make a difference. The one I'm using is 9v at 1 Amp which is actually more current than the SMS own power supply gives, so it should be better, but in any case the current drawn for 3 CMOS ICs and one game cartridge should be minimal. I would think any ripple and noise etc would get filtered out by the SMSReader's own 5v regulator circuit etc anyway.

Maraakate Joined: 05 Jun 2010 Posts: 757 Location: Pennsylvania, USA	Posted: Fri Dec 16, 2011 7:01 pm
	Sorry, when I say wire wrap I meant those jumper wires and stuff all over the board.

Maraakate Joined: 05 Jun 2010 Posts: 757 Location: Pennsylvania, USA	Posted: Fri Dec 16, 2011 7:09 pm
	Quote Read operation verifies correctly, but still results in a bad dump (on some cartridges) Reason: 4040 chip(s) are being affected by noise on the parallel port lines. Solution: See solution to problem 1 above. Reason: Read line is not connected/does not function correctly. Solution: Check continuity of connections to and from the 74HC00 chip. Reason: Pull-down resistors are causing problems with your parallel port. Solution: Try desoldering the SIL resistor and see if it makes a difference. I'm guessing you tried all of this. Maybe it's quite possible that the 74HC00 IC is bad? Or even the 4040s? I've never built this before. I've always procrastinated doing it. But, I do know those types of sockets can be easy to bend the pins if you insert it wrong. So check for stupid things like that.

viletim Joined: 24 Sep 2006 Posts: 191 Location: Sydney, Australia	Posted: Sat Dec 17, 2011 4:10 am
	Agent24, First, connect all the ground pins of the 25 pin Sub-D connector together. http://www.hardwarebook.info/Parallel_(PC) Second, add 4k7 pull up resistors to the three parallel port outputs. This will help if there is a mismatch between TTL (parallel port) and CMOS (4040, etc) levels.

Agent24 Joined: 28 Mar 2011 Posts: 88	Posted: Sat Dec 17, 2011 4:39 am
Agent24 Joined: 28 Mar 2011 Posts: 88	viletim wrote Agent24, First, connect all the ground pins of the 25 pin Sub-D connector together. http://www.hardwarebook.info/Parallel_(PC) Already had it like that ;) viletim wrote Second, add 4k7 pull up resistors to the three parallel port outputs. This will help if there is a mismatch between TTL (parallel port) and CMOS (4040, etc) levels. The troubleshooting notes show to use 2.2k resistors on the RESET and CLK lines, in fact it is advised to do this anyway (which I did) So for the third one, that is /SEL line? Do you think it should have a 4.7nF decoupling capacitor on it the same as the other two?

viletim Joined: 24 Sep 2006 Posts: 191 Location: Sydney, Australia	Posted: Sat Dec 17, 2011 11:48 am
	Agent24 wrote viletim wrote Second, add 4k7 pull up resistors to the three parallel port outputs. This will help if there is a mismatch between TTL (parallel port) and CMOS (4040, etc) levels. The troubleshooting notes show to use 2.2k resistors on the RESET and CLK lines, in fact it is advised to do this anyway (which I did) So for the third one, that is /SEL line? Do you think it should have a 4.7nF decoupling capacitor on it the same as the other two? I didn't read the troubleshooting section... Yes, put a pull up resistor on the /SEL line as well. It connects to a CMOS input just like the other two. Are those 4.7nF caps between the parallel port output and ground (I don't follow this circuit by coordinates scheme)? I can't see that there's anything to be gained by that - try removing them.

Agent24 Joined: 28 Mar 2011 Posts: 88	Posted: Sat Dec 17, 2011 8:25 pm
Agent24 Joined: 28 Mar 2011 Posts: 88	viletim wrote Are those 4.7nF caps between the parallel port output and ground (I don't follow this circuit by coordinates scheme)? I can't see that there's anything to be gained by that - try removing them. Yes, they go between those lines and ground. The instructions say: Quote Two more ceramic capacitors, 4.7nF ones, are used for filtering purposes on the Reset and Clock lines - see the Troubleshooting section and read the solution to problem 1. The idea is to improve reliability by filtering out transient pulses which might trigger a spurious clock or reset. This is particularly important if you use 74HC4040s rather than regular 4040s; the 74HC chips have something of a "hair trigger" and the slightest spike can affect them.

Agent24 Joined: 28 Mar 2011 Posts: 88	Posted: Thu Dec 22, 2011 2:06 am
Agent24 Joined: 28 Mar 2011 Posts: 88	Well I tried first removing the 4.7nF capacitors and that only made the situation worse - when reading Hang On I got almost all the data as FFFF and what was not such was in fact corrupt. So I think whatever those capacitors are there for, there is a good reason. But perhaps the values aren't right. Does anyone know why the value of 4.7nF was chosen? I am thinking perhaps they should be some other value. I didn't yet try a pullup resistor on the /SEL line as it was already at 3.36v and didn't change during the read operation. I actually think it may only be used when writing to a RAM cartridge...?

viletim Joined: 24 Sep 2006 Posts: 191 Location: Sydney, Australia	Posted: Thu Dec 22, 2011 9:17 am
	Agent24 wrote Well I tried first removing the 4.7nF capacitors and that only made the situation worse - when reading Hang On I got almost all the data as FFFF and what was not such was in fact corrupt. So I think whatever those capacitors are there for, there is a good reason. But perhaps the values aren't right. Does anyone know why the value of 4.7nF was chosen? I am thinking perhaps they should be some other value. The capacitor is part of an RC filter. It's the C, the R is the output resistance of your parallel port - not something which is well documented or even predictable. I suspect the value was chosen empirically. Quote I didn't yet try a pullup resistor on the /SEL line as it was already at 3.36v and didn't change during the read operation. That's not good news. The minimum to reliably turn on the input of a generic CMOS 4040 is 3.5V. I don't think the solution lies in placing capacitors or pull up resistors on the parallel port lines. What you need is a 4040 counter which is designed for TTL level input, not CMOS level. The 74HCT4040 would be ideal. EDIT: And a 74HCT00 to replace the 74HC00.

Agent24 Joined: 28 Mar 2011 Posts: 88	Posted: Wed Jun 20, 2012 8:01 am
Agent24 Joined: 28 Mar 2011 Posts: 88	viletim wrote Agent24 wrote I didn't yet try a pullup resistor on the /SEL line as it was already at 3.36v and didn't change during the read operation. That's not good news. The minimum to reliably turn on the input of a generic CMOS 4040 is 3.5V. I don't think the solution lies in placing capacitors or pull up resistors on the parallel port lines. What you need is a 4040 counter which is designed for TTL level input, not CMOS level. The 74HCT4040 would be ideal. EDIT: And a 74HCT00 to replace the 74HC00. I tried swapping with HCT parts and I still have the same problems: blocks of FFFF in the same places as before, where there should be real data.

Agent24 Joined: 28 Mar 2011 Posts: 88	Posted: Sat Jul 05, 2014 3:35 am
Agent24 Joined: 28 Mar 2011 Posts: 88	Got the thing working, finally. Turned out I had never connected the /M0-7 line to the cartridge, so the ROM chips always had their Output Enable pins floating! Surprising that any cartridges worked at all.

Forums

View topic - SMSReader not working properly