...the memory battery only protects the RAM when changing the AA’s... That's why I recommend using Eneloops along with a supercap. The
very low self-discharge of the Eneloops could conceivably keep RAM alive <and> the supercap charged for years. ... On 5/6/18, Jeffrey Birt <[email protected]> wrote: > I just peeked at the CE signals (on M4) for the RAM (only std RAM module is > installed). All /CE signals toggle but it is not consistent from reset to > reset. I guess I should have checked they were getting to the RAM as well. > I > looked and at the input signal sot M4 and they all toggle happily after > reset as well. > > > > One thing that has been bothering me is the /RD* timing when reading from > the ROM. Take a look at the screen capture from my LA here: > > > > https://1drv.ms/u/s!AtH4vpaZnzX7j8BykM3nU_zsOHq5iA > > > > Channel 7 here is the /RD* signal and is being used as a clock for the > simple parallel decoder. Notice that as /RD* goes low the data line state > is > just changing. I would expect the data to already be valid here.well. > Thinking again that would not make sense. The 80C85 would set /RD and would > have to give the ROM a chance to preset the data to the data bus and then > read it on the falling edge of the next clock. So, the issue I have here is > that the simple parallel decoder is not looking at the falling edge of the > next clock but rather the falling edge of the /RD*. > > > > O, back to the RAM. I do see all the /CE signals but as I said what I see > is > not consistent with each reset. Sometimes the M100 seems to keep running > for > just over a second before stopping and while it does this I see quite a lot > of activity on the RAM /CE lines (some more than others). > > > > One other ting I did today was to lift the anode of D11 (diode which > prevents the memory battery from back feeding the whole machine) and > soldered in a 3.6V lithium primary cell. This did no good of course, but it > will keep what ever content of RAM consistent at least. Once I get the M100 > running I'll take some current measurements so see what is drawn from the > memory battery when the AA's are not present. The way it looks the memory > battery only protects the RAM when changing the AA's. By knowing what is > drawn from the battery I hope to size a suitable super cap replacement. > > > > I guess for further work I can check that the signals from M4 are getting > to > the RAM module and check that it seems to output data. After that I am > stuck > again. If I can resolve the issue with the LA software so it will decode > the > collected parallel data correctly I might have a better chance of knowing > how far it gets in the boot process. I'm wondering if it gets to a point > where it tried to talk to some I/O device which causes a problem. > > > > Thanks again for your help! > > > > Jeff > > > > From: M100 <[email protected]> On Behalf Of Fugu ME100 > Sent: Sunday, May 6, 2018 2:11 AM > To: [email protected] > Subject: Re: [M100] SPAM-LOW: Re: New member - question on 'half' alive > Model 100 > > > > I would say your CPU looks good :) The ROM seems to be working as are all > the buffers and ROM decoding, the code is executing correctly to the point > of failure. The IO is still a possible source of error but as there are > multiple accesses it looks like it performs the operations correctly. > > > > Did you check the CE- on the RAM module? Just after that IN op RAM > accesses > start to happen. Without the NiCd the RAM might always start up with > garbage which could cause some oddness. > > > > Interrupts are disabled so that should not cause problems. > > > > Looks like the RAM is the next target to investigate. > > > >
