Good point Fugu!!! I didn't removed the SRAMs since without a proper desoldering gun will be tedious and I was hoping to spot a wrong signal that will give me a reason to do it or not...
I connected the LA to the 40 pin system bus connector (plus ROM CS) and added couple of screenshots in the shared album: https://photos.app.goo.gl/n39TcOt24QtVrfJo1 As you can see in the first picture, IO/M is moving in sync with ROM CS, but after the first pulse of IO/M, the ROM CS from a repetitive signal with a short pulse every ~15us become a more complicated one. In the second picture you can see that everithing is cycling every ~300ms. Is it normal that WR* it never moves? This can be caused by an issue on the SRAMs? I know I'm really slow in this troubleshoot but I'm enjoying the learning process of this amazing little PC. Thank you for the support!! Mauro Inviato da iPhone > Il giorno Dec 29, 2017, alle ore 01:52, Fugu ME100 <[email protected]> ha > scritto: > > You may of already done this but have you removed all the SRAM modules from > the M10? Or at least the ones that can be removed. This will a) eliminate > them as a possible problem and b) prevent them being damaged should something > happen while probing around the motherboard :) > > Are the IO/M pulses in sync with the ROM CS? I could not tell from the > screen captures. > > As you say it seems to read the ROM and then heads off into IO space - if > the line is high all the time after that. Five pulses would be 5 reads to a > ROM, it should be the first two are the reset vector. Three more reads might > be a jump type of operand at the address pointed to by the reset vector. > When it takes that jump it ends up nowhere in this case. I would expect at > least the ROM portion to keep going for a little longer until it has to do > some RAM operations. > > > From: M100 <[email protected]> on behalf of Mauro Pintus > <[email protected]> > Reply-To: <[email protected]> > Date: Thursday, December 28, 2017 at 11:43 AM > To: <[email protected]> > Subject: Re: [M100] diagnose > > Thank you so much Brian!!! > You got it right also for the reset, yes it is M20 pin3 also on the M10, the > schematic is almost identical to the M100 one. > > Apparently my M10 is doing the same of your working M100 on the ROM CS and on > the AD0, reading the content of the ROM. > > The big difference I can see is with IO/M. On your unit it moves a lot ~40ms > after reset. > On my M10 it moves only for 5 pulses every 300ms. > > Someone have any Idea on the possible cause? > > I'll continue the investigation and let you know. Hope to get out the LA > tomorrow. > > Mauro > > Ps: on the shared Google album I've added few pictures of the measuring > setup. > > Inviato da iPhone > > Il giorno Dec 28, 2017, alle ore 11:06, Brian White <[email protected]> ha > scritto: > >> Here you go. This is a good working M100, running properly during test. >> >> https://photos.app.goo.gl/pgBErSewdSk6lQ2F3 >> >> Click the info button on each pic if the description text doesn't show. >> That's where I described the actual pins I used and a few other details. >> >> Main thing is I interpret "reset out after the buffer" to mean M20 pin 3, in >> case that's not what you wanted. >> >> -- >> bkw >> >>> On Tue, Dec 26, 2017 at 7:06 PM, Mauro Pintus <[email protected]> wrote: >>> Hi, I tried to replicate the measures of Brian end at the following link >>> you can find my oscilloscope screenshot: >>> >>> https://photos.app.goo.gl/n39TcOt24QtVrfJo1 >>> >>> The first 16 images are the AD0-AD7 and A8-A15 >>> As you can see I don't have any stuck condition at the outputs of the 8085, >>> now i'll verify the buffers and demultiplexers. >>> Image 17 CLK pin 37 of the 8085 and Image 18 Pin 7 of the 8085 >>> >>> The last 6 images are the most interesting. >>> Here I'm acquiring: >>> >>> CH1) ROM CS >>> CH2) 8085 AD0 >>> CH3) 8085 IO/M >>> CH4) 8085 Reset Out (actually after the buffer) >>> >>> As you can see as soon as I release the reset button, ROM CS and 8085 AD0 >>> start moving but IO/M stay low for ~300ms >>> At this point the ROM CS change completely and from a stady clock, become >>> like a data line. >>> AD0 keep changing and IO/M toggle only 5 times. >>> On the last 3 pictures you can see that this sequence continue exactly the >>> same over and over every ~300ms >>> >>> Brian: Can you please measure this 4 signals in the working unit? >>> I'm doing a single capture, triggering on the falling edge of the reset >>> (CH4). >>> >>> I hope to be closer to find the culprit :) >>> >>> Mauro >>> >>> >>>> On Dec 18, 2017, at 6:57 PM, Brian White wrote: >>>> >>>> Ah yeah I forgot to relabel a17. I just went one pin too far and >>>> mis-labeled it. I'm not looking at the pdf now, but the a17 pic will be >>>> for pin 28 whatever that is. >>>> >>>> Thank you I'll look at m21. >>>> -- >>>> bkw >>>> >>>> >>>> On Dec 18, 2017 11:54 AM, "Fugu ME100" <[email protected]> wrote: >>>> Are BAD M100 A16 & BAD M100 A17 correctly titled on the screenshots? >>>> >>>> The sawtooth will be caused by the multiplex nature of the bus from >>>> AD0-AD7. >>>> >>>> The stuck condition of the lines could just be that the CPU never gets out >>>> of a certain address range so the lines appear never to move. Or it could >>>> be the 80C85 (M19) is indeed bad or the H244 (M21) is possibly bad causing >>>> the inputs to be stuck high. The bad Address lines go straight into M21 >>>> based on the schematic. >>>> >>>> On the bad M100 the pattern repeats ~53ms so that is about 10,000 >>>> instructions (if my math is right) so I would expect all the Address/Data >>>> lines to at least toggle. It looks like M19 is bad. Any other lines >>>> appear to be stuck? >>>> >>>> From: M100 <[email protected]> on behalf of Brian White >>>> <[email protected]> >>>> Reply-To: <[email protected]> >>>> Date: Monday, December 18, 2017 at 5:18 AM >>>> To: <[email protected]> >>>> Subject: Re: [M100] diagnose >>>> >>>> Last night I did a little more poking. >>>> >>>> First, I looked at all the data lines at the cpu on a good M100, and >>>> verified that on a good M100, all of those pins show continuous streams of >>>> data while the machine is on. >>>> >>>> Then on the bad M100 I saw 2 differences from the good M100. >>>> >>>> 1) I can't get a stable trigger lock on any of the A* & AD* pins on the >>>> good M100. >>>> IE, On the good machine the data doesn't repeat exactly around 53ms like >>>> it does on most pins on the bad M100. >>>> >>>> 2) 4 pins are stuck high: A10, A12, A13, A14 >>>> >>>> Screenshots of pins AD0-AD7 & A8-A16 >>>> https://photos.app.goo.gl/vcTg4yUhvjXKBxeh1 >>>> >>>> I thought those ramps and 2-volt sawtooths on the AD0-AD7 lines looked >>>> bad, but the good machine has the same thing. >>>> >>>> -- >>>> bkw >>>> >>>>> On Fri, Dec 15, 2017 at 7:52 AM, <[email protected]> wrote: >>>>> I have a really basic one like this, based on the Cypress CY7C68013A >>>>> https://sigrok.org/wiki/Lcsoft_Mini_Board >>>>> >>>>> I like to use it with the saleae software, but to have 16ch instead of 8 >>>>> I use Sigrok. >>>>> >>>>> Mauro >>>>> >>>>> >>>>> >>>>> Il 15.12.2017 12:56 Brian White ha scritto: >>>>> >>>>>> On Dec 15, 2017 6:16 AM, <[email protected]> wrote: >>>>>>> >>>>>>> BTW: Brian do you have a LA so we can compare the same signals on the >>>>>>> ROM and RAM addressing/enabling on the working and not working >>>>>> >>>>>> Sorry I am looking at them but hadn't picked one yet. >>>>>> -- >>>>>> bkw >>>>> >>>>> >>>>> >>>>> Con Mobile Open 7 GB a 9 euro/4 sett navighi veloce con 7 GB di Internet >>>>> e hai 200 minuti ed SMS a 12 cent. Passa a Tiscali Mobile! >>>>> http://tisca.li/OPEN7GBFirma
