In the T102 and M100 there are SRAM modules that are plugged into sockets, I am not familiar with the M10, but these modules are easy to remove from the socket and do not need to be desoldered. Sorry about confusion. If I am working on a motherboard I would remove these modules by simply unplugging from their sockets. A very easy operation without any need for desoldering tools :)
The WR signal is staying high because I suspect the ROM is not being read correctly or it is not reaching the part of the code that requires any SRAM operations. There appears to be some IO access part way through the cycling. So it could be trying to do something with an IO device like the clock chip, keyboard or even the screen. Can you aggregate the AD0-AD7 signals to look at the data as HEX values on those lines? Perhaps look at the signals directly on the ROM and SRAM chips see if they arrive from the CPU correctly? From: M100 <[email protected]<mailto:[email protected]>> on behalf of Mauro Pintus <[email protected]<mailto:[email protected]>> Reply-To: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Date: Friday, December 29, 2017 at 5:20 PM To: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: Re: [M100] diagnose 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<https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fphotos.app.goo.gl%2Fn39TcOt24QtVrfJo1&data=02%7C01%7C%7C846c409b7cf84a761a0f08d54f12b548%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636501864121577510&sdata=62tqU4WLKSdKcffemO04oBu82hQ4Q6XimG1wNrJp9IA%3D&reserved=0> 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]<mailto:[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]<mailto:[email protected]>> on behalf of Mauro Pintus <[email protected]<mailto:[email protected]>> Reply-To: <[email protected]<mailto:[email protected]>> Date: Thursday, December 28, 2017 at 11:43 AM To: <[email protected]<mailto:[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]<mailto:[email protected]>> ha scritto: Here you go. This is a good working M100, running properly during test. https://photos.app.goo.gl/pgBErSewdSk6lQ2F3<https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fphotos.app.goo.gl%2FpgBErSewdSk6lQ2F3&data=02%7C01%7C%7Cbc6d68febb1e4ab2969d08d54e2b59cd%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636500870445863159&sdata=VHB5%2FABXiGztc%2B8uPgIH4xeoCmipJdNtNC%2BQPW3bqaw%3D&reserved=0> 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]<mailto:[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<https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fphotos.app.goo.gl%2Fn39TcOt24QtVrfJo1&data=02%7C01%7C%7Cbc6d68febb1e4ab2969d08d54e2b59cd%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636500870445863159&sdata=Y9U1SCSPIMENILcnncBV3H5Y%2FiXJrTwQf5vTRohI3Eg%3D&reserved=0> 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]<mailto:[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]<mailto:[email protected]>> on behalf of Brian White <[email protected]<mailto:[email protected]>> Reply-To: <[email protected]<mailto:[email protected]>> Date: Monday, December 18, 2017 at 5:18 AM To: <[email protected]<mailto:[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<https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fphotos.app.goo.gl%2FvcTg4yUhvjXKBxeh1&data=02%7C01%7C%7Cb95f328a00c443cac69c08d54619c7f7%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636491998893045761&sdata=qHGx%2FKPE7hDkQojuMyGp6OFiuUvW89G5pRICZlOrfdE%3D&reserved=0> 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]<mailto:[email protected]>> wrote: I have a really basic one like this, based on the Cypress CY7C68013A https://sigrok.org/wiki/Lcsoft_Mini_Board<https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsigrok.org%2Fwiki%2FLcsoft_Mini_Board&data=02%7C01%7C%7Cb95f328a00c443cac69c08d54619c7f7%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636491998893045761&sdata=pKKoy6jhKELmp2gu%2FA46lG45dgQ0OEfiZz4kKEBS5dY%3D&reserved=0> 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]<mailto:[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<https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Ftisca.li%2FOPEN7GBFirma&data=02%7C01%7C%7Cb95f328a00c443cac69c08d54619c7f7%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636491998893045761&sdata=pKP2eU7zzR1lsWJGBn7kyII9mInd%2FrunF9Q%2FIrzWO1A%3D&reserved=0>
