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.  

 

Reply via email to