Reseat all IC's in their sockets, unplug all connections, dioxit them and refit. Those push-in wire connectors are dodgy too, I have had plenty of problems with those, pull each wire out and re-insert them on a fresh bit of wire, you can still buy those kinds of connectors too if you need to replace any. Also don't assume that the ribbon flex connections are good, check end to end to each wire connections. Check all tantalums for shorts.
I would go back to the clock circuit and look at that, inject your own clock signal and see if that changes anything, bad jitter on the clock could cause lockups in the processor due to timing changes. It could also be another IC on the bus that is shorting out and loading down the processor/bus, I noticed that the same "packet" pattern appeared in various places in your tests, so I think that pattern is the clue as to why it is not working.
Replacing the EPROM is a good idea, since it's socketed, and they do lose their data sometimes. Also, just try reading it with your programmer. Read, then verify. If you read the same data 5 times in a row, then the data is probably still OK (the chip could still have a problem, of course). This CPU puts 8 addresses onto the data bus, then latches them into an external chip, usually a 373 type. The rest of the address lines come directly from the CPU. Look at all address lines on the EPROM to see if one is stuck high or low. Also check all data bus lines on the CPU to see if one is shorted by some chip on the bus. That repeating pattern of bus activity, then nothing looks pretty odd. It's unusual to have such a long period where the code EPROM is not being accessed. If there were a watchdog timer driving the reset line, I would say it's causing that cycling, but there doesn't appear to be one. You should check reset for sure. The 6 MHz clock must start up while reset to the CPU is low, then a short time later, reset should go high and stay high. You have a nice 4-channel scope, so trigger on the rising edge of the 5V supply. Watch the 6 MHz clock, and reset, and also the chip select to the EPROM. Anything above about 2-2.5V is a valid TTL high, so if high signals aren't sitting at 5 volts, don't let that worry you. That CPU clock signal doesn't look that great, but it's probably OK. The CPU probably has a Schmitt trigger inside to clean it up. Good luck.
Tony, When I trouble shoot electronic systems with that requires a microprocessor start up, I simply use and AM radio, tuned to an open frequency to hear the microprocessor start up and set various components. If you can not hear the running of the CPU, then I know that there is either a program boot problem or lack of power provided to the processor. For your audience, turn on an AM radio to show your fans what the system sounds like when you first turn it on.
The 80C39 should be a CMOS variant of a (NMOS) 8039, part of the Intel MCS-48 family. More info on these MCUs (it has internal RAM so not just a simple CPU) can be found in the Intel MCS-48 Family User's Manual. PDFs are floating around the internet. I believe this was Intel's first true MCU (Microcontroller) and is a different architecture from the older 8085 (MCS-85) but you can put 8085 peripherals on this 8039 MCU as the MCU uses the multiplexed AD (address/data) bus system, same as the 8085. The 60 Hz clock to the interrupt line is just a way for the MCU to have a periodic interrupt, typically for measuring time intervals, or a regular task that is has to do, eg. scan the keyboard. Interrupt clock is a good description for it. Anyhoo, I would say do the standard checks: DC voltages on the MCU are all good, clock is good (you checked), Reset is good (important to check this!) make sure Reset clears after powerup. If the MCU has a HALT mode, make sure it is not halted. Beyond that, there are a few AC checks to try, make sure the Address lines are going from VCC to ground and not floating. Complication here is that the lower 8 address lines are also the data lines.. the external ROM/PROM may be 8085 compatible and not need a address/data demultiplexer either. Address lines that do not go rail to rail can show an external device "dragging" a line up or down or point to a bad MCU. Another trick is to build a "NOP" ROM. "No operation" opcode is 0x00 (all low) on the data lines so a PROM that is programmed to all zeros (or a debug board with the address/data lines "gently" pulled down) will cause the MCU to constantly increment through the memory range and then loop back to zero. After reset the MCU will first try to read address 0 for the first instruction. If you see the address lines counting up in binary then the CPU is reading data from external RAM correctly. You could also try to reach out and do a TH-cam collab? Someone mentioned Ian, but he is in Ireland. Adrian (up in Oregan) of Adrian's Digital Basement is pretty heavy into 8-bit computer repairs. and in the South, there is Bert (Hey Birt! channel). I think you can probably get this though. On another subject, RIP to the original Sencore tech, it's sad to hear when we lose another tech or engineer with legacy knowledge. A bit of the past dies with them.
I had interminent data from ic socets with rectangle shaped pin holes, went to sockets with round holes with spring or wire wound pin contack...for prosesors and Eproms
I work w/ microprocessor based systems every day. Some suggestions. The microprocessor signals look to me like your oscilloscope probe doesn't have a clean ground w/r/t the ground pin of the microprocessor. Also, those periodic "burst" signals may be at a much higher frequency that your scope is set to. Set a trigger and a higher scope frequency to see the high speed stuff. Also, are any of those lines maybe rs232, or some other non micro bus or control line? Also, I would ring out all address, data and control lines between the eprom and micro w/ a dmm. Definately pull the eprom and see if the programmer can read the entire chip. If it can, you could dump out the eprom content, and program a new eprom w/ the current program/code. Remove one variable. Check that the micro's power is clean. Verify its clock is also clean. Is there perhaps a diagnostic firmware you could burn on a new eprom? Are there any bus driver chips (ls244, ls245)? Finally, is the eprom being selected? There maybe one or more enable pins that must be correct to read the eprom and if you see those pins strobing (typically low is active) then the micro is doing something right. Wish I could help 😐
The pin @ 33:49 is floating. It has a RMS of 3.06V and that is a no no. My best guess is a defective multiplexer on that bus. Keep up with the good work.
You are correct! I'm really glad you commented on this. In the inductance test section of the board, there are two mux chips, IC16 and IC17 (CD4051's) that select the different test sources when in the inductance test mode. Pin 3 (com in/out) of the two chips is coupled by what appears to be a TL081 configured as a voltage follower with +/-5 volts, but the schematic is drawn incorrectly. I will show this on the next video. Anyway, I am seeing +18volts at pin 3 of IC17. The only power supplies on the chip are +12 at pin 16 (Vdd) and -5 at pin 7 (Vee). It also seems as if multiple channels are being selected at the same time and I don't think that is correct. Octal flip-flop IC12 provides the drive data for these chips and it gets really warm. I think the problem is somewhere in that area. Thanks again!
@@xraytonyb I'm happy to have the honour to help the guru. The TL081 must be dead, who else can provide 18v. You can safely use sockets; but spend 2 cents more and buy those who has metal on both sides of the pin. Another gotcha are the different 74xxx families have different logic levels, you can not always replace a 74lsXX with the 74hctXX you have in your drawer. Spent many hours learning that. Sencore are using all families. Looking forward to see your Sencore in action. 73 de OZ1GNN Chris
This has to be one of the top five videos. Really interesting, can’t wait for the next chapter. I bet the print that was included is a clue. I know you will figure it out.
Hey Tony - some Ideas from me after repairing a lot of retro computer. Sockets could be tarnished - so give the EPROM Socket and its pins a good deoxi clean. Have you checked the RESET Circuit - should be PIN 4 of the MCU . Sometimes the reset circuit is looping because some sort of monitoring triggers it. The LCD Display may be connected by zebrastrips (some kind of conductive foam) and could also be cleaned or need some more compression between pcb and glass. This could fix the confused display.
I have a Sencore LC75 that I restored a while back and still use , it's one of the ones between the LC53 and the LC101. I love these devices, very useful.
I have one of this brand new. It has failed. I am going to follow your eloquent steps to check and get it up and running. Hope you can help where I might need with the manual and eeprom. Thank you.
Replace every electrolytic capacitor inside that thing! Some are for timing and others are for noise filtering. I try to swap out the smaller caps with tantalum type for better reliability.
Tony, look with the scope at all the pins on the cpu, they must have a clear 5V or 0v level, at 31:33 there is a hardware conflict, put the cpu on a socket, and when you see a conflict, bend the pin outside the socket and look again at the pin, still a conflict, its inside the cpu, no conflict then look at the logic connected to that pin, that's a good point to start with...,you do not solve this with an software update.
Yes, also noticed that. Pin 10 is WR (output, write strobe to access memory) and looks to be going from 5V to 3V (and not 0.45V minimum, ideally 0V) indicating some form of contention. Would be worth scoping the other micro pins to see if anything similar.
@@jbboating3268 I don't believe so, but then I am only going by the schematic. WR (and RD) go to multiple IC's and any one of those could be causing contention (as could the select lines to them or the micro itself). As a minimum I would check the ALE, PSEN and RD signals. Best to start with the micro in socket idea (or unsolder individual pins) as at least then you could isolate signals.
Nice unit and it must be fixed ! I would read and verify the eprom as its relatively easy and can be put out of mind for a while, I'm wondering if removing the LEDs is worth doing to take it closer to factory ? thou haff checked voltages that seems ok so there's a lot better comments than mine below !....cheers.
Great video Tony, very interesting. Wish I knew anything about this and could help. Just listening to you, since the prom has a more likelihood of having an issue in your experience, and is already on a socket and you can burn a new one, would that be a sensible first item to substitute rather than the CPU? As far as the noise goes, is it possible to trace it with the scope to a component? Perhaps a bypass cap etc somewhere? Looking forward to this series, thanks.
I don't have much experience w/ those older style EPROMS, but I have had some weird faults end up being caused by a corrupt BIOS while troubleshooting motherboards. My little fleet of re programmers have kept quite a few Laptops out of the landfill. I'm curious to see if burning a new PROM is the fix.....
Would like to have one. But they are very expensive to get. Couldn't find one for less than a thousand if i remember correctly. Maybe America is different in that front. You seem to keep so much old junk around prices stay low.
There is an old rechargeable NiMH BY234 ( 12 Volt at 2 A/Hr ) battery pack on the back of this unit. Pretty sure it should be replaced before going any further Tony. Just my 2 cents.
I have not worked on these specifically but I have seen a lot of videos of how they fixed old CPU boards. 1) I would check the RAM chips to make sure they are not bad. RAM chips do go bad sometimes. 2) I would also look with a logic probe to see if there I/O lines that are not pulsing. This can be a clue to which chips are bad. 3) Another thing I would check is to make sure there are no dead batteries on any of the boards, sometimes a dead memory backup or timekeeper RAM battery can cause a CPU to not boot or do strange things. These batteries being dead can also brick some devices too because if the battery holds a decryption key or some kind of anti-tamper device. Sometimes these are batteries in epoxy blocks in some chips too. I know dead batteries causing non-booting was common on some old PCs, arcade games, and oscilloscopes. I am not sure if this device has batteries on the boards, but I know this is a common problem for some older devices. 4) Another thing to check is that your display board. First make sure your display driver chip is getting power and there is power getting to the display itself. If there is no power here, the display will not light. If a display driver chip went bad, this can also cause the display not to light. If the display is LCD and it is dark, check for a bad backlight or inverter. If it is Vacuum Flourescent, check to see how the 30-40V supply for it created (sometimes this is in the driver chip and other times there is a separate inverter) and if there is problem there. It is also possible for the VFD tube itself to fail. A burned out backlight can also cause a display to appear dark too. If LED, check the segments and driver chips. 5) Check for any missing voltages from the internal power supplies to the low voltage digital board. Make sure the CPU, RAM, ROM, and Bus chips are getting power. Especially common CPU-related voltages such as +3.3V, +5V, -5V, +12V, -12V, and similar (some older devices just used 5V and 12V, and 3.3V came a bit later in CPU history). Some computer devices did use a negative voltage. Regulators can go bad here. 6) Check for any bad I/O or bus chips. These can also cause non-booting. 7) Check the EEPROM and compare its checksum to the checksums of known versions of the software. See if it matches any of them. If not, you could have a bad EEPROM. 8) Make sure the clock is putting out the correct frequency for the CPU and bus. 9) Check the CPU reset circuit if the CPU uses a reset circuit.
I have a similar problem with my Lc-102 Tried the edebris link below for the Eprom BIN file but found it to be corrupt Has anyone a different copy of the Bin file ?? Thanks
Strange ... I downloaded it and viewed wit an HEX editor and it seemed to be OK. Maybe loading it in an EEPROM programmer software gives you this problem. Sorry ...
@@Area51Corsair Hi Corsair My original firmware is version 12 whilst this Bin is version 17 Perhaps there was a hardware change because this BIN gives me garbage on the LCD display (Burnt 2 eproms to check) I wonder what version xraytonyb has ?? Thanks for the reply
!["สนธิ" ห่วงมีขบวนการปกป้อง "ทนายตั้ม" : [THE MESSAGE]](http://i.ytimg.com/vi/2GQNp3EoMc0/mqdefault.jpg)
Reseat all IC's in their sockets, unplug all connections, dioxit them and refit. Those push-in wire connectors are dodgy too, I have had plenty of problems with those, pull each wire out and re-insert them on a fresh bit of wire, you can still buy those kinds of connectors too if you need to replace any. Also don't assume that the ribbon flex connections are good, check end to end to each wire connections. Check all tantalums for shorts.
I would go back to the clock circuit and look at that, inject your own clock signal and see if that changes anything, bad jitter on the clock could cause lockups in the processor due to timing changes. It could also be another IC on the bus that is shorting out and loading down the processor/bus, I noticed that the same "packet" pattern appeared in various places in your tests, so I think that pattern is the clue as to why it is not working.
Replacing the EPROM is a good idea, since it's socketed, and they do lose their data sometimes. Also, just try reading it with your programmer. Read, then verify. If you read the same data 5 times in a row, then the data is probably still OK (the chip could still have a problem, of course). This CPU puts 8 addresses onto the data bus, then latches them into an external chip, usually a 373 type. The rest of the address lines come directly from the CPU. Look at all address lines on the EPROM to see if one is stuck high or low. Also check all data bus lines on the CPU to see if one is shorted by some chip on the bus. That repeating pattern of bus activity, then nothing looks pretty odd. It's unusual to have such a long period where the code EPROM is not being accessed. If there were a watchdog timer driving the reset line, I would say it's causing that cycling, but there doesn't appear to be one. You should check reset for sure. The 6 MHz clock must start up while reset to the CPU is low, then a short time later, reset should go high and stay high. You have a nice 4-channel scope, so trigger on the rising edge of the 5V supply. Watch the 6 MHz clock, and reset, and also the chip select to the EPROM. Anything above about 2-2.5V is a valid TTL high, so if high signals aren't sitting at 5 volts, don't let that worry you. That CPU clock signal doesn't look that great, but it's probably OK. The CPU probably has a Schmitt trigger inside to clean it up. Good luck.
Tony, When I trouble shoot electronic systems with that requires a microprocessor start up, I simply use and AM radio, tuned to an open frequency to hear the microprocessor start up and set various components. If you can not hear the running of the CPU, then I know that there is either a program boot problem or lack of power provided to the processor. For your audience, turn on an AM radio to show your fans what the system sounds like when you first turn it on.
That is a great suggestion!
The 80C39 should be a CMOS variant of a (NMOS) 8039, part of the Intel MCS-48 family. More info on these MCUs (it has internal RAM so not just a simple CPU) can be found in the Intel MCS-48 Family User's Manual. PDFs are floating around the internet. I believe this was Intel's first true MCU (Microcontroller) and is a different architecture from the older 8085 (MCS-85) but you can put 8085 peripherals on this 8039 MCU as the MCU uses the multiplexed AD (address/data) bus system, same as the 8085.
The 60 Hz clock to the interrupt line is just a way for the MCU to have a periodic interrupt, typically for measuring time intervals, or a regular task that is has to do, eg. scan the keyboard. Interrupt clock is a good description for it.
Anyhoo, I would say do the standard checks: DC voltages on the MCU are all good, clock is good (you checked), Reset is good (important to check this!) make sure Reset clears after powerup. If the MCU has a HALT mode, make sure it is not halted.
Beyond that, there are a few AC checks to try, make sure the Address lines are going from VCC to ground and not floating. Complication here is that the lower 8 address lines are also the data lines.. the external ROM/PROM may be 8085 compatible and not need a address/data demultiplexer either. Address lines that do not go rail to rail can show an external device "dragging" a line up or down or point to a bad MCU.
Another trick is to build a "NOP" ROM. "No operation" opcode is 0x00 (all low) on the data lines so a PROM that is programmed to all zeros (or a debug board with the address/data lines "gently" pulled down) will cause the MCU to constantly increment through the memory range and then loop back to zero. After reset the MCU will first try to read address 0 for the first instruction. If you see the address lines counting up in binary then the CPU is reading data from external RAM correctly.
You could also try to reach out and do a TH-cam collab? Someone mentioned Ian, but he is in Ireland. Adrian (up in Oregan) of Adrian's Digital Basement is pretty heavy into 8-bit computer repairs. and in the South, there is Bert (Hey Birt! channel).
I think you can probably get this though.
On another subject, RIP to the original Sencore tech, it's sad to hear when we lose another tech or engineer with legacy knowledge. A bit of the past dies with them.
I had interminent data from ic socets with rectangle shaped pin holes, went to sockets with round holes with spring or wire wound pin contack...for prosesors and Eproms
Ian Johnson would be the guy to talk to he does tons of test equipment and is a digital expert
I work w/ microprocessor based systems every day. Some suggestions. The microprocessor signals look to me like your oscilloscope probe doesn't have a clean ground w/r/t the ground pin of the microprocessor. Also, those periodic "burst" signals may be at a much higher frequency that your scope is set to. Set a trigger and a higher scope frequency to see the high speed stuff. Also, are any of those lines maybe rs232, or some other non micro bus or control line? Also, I would ring out all address, data and control lines between the eprom and micro w/ a dmm. Definately pull the eprom and see if the programmer can read the entire chip. If it can, you could dump out the eprom content, and program a new eprom w/ the current program/code. Remove one variable. Check that the micro's power is clean. Verify its clock is also clean. Is there perhaps a diagnostic firmware you could burn on a new eprom? Are there any bus driver chips (ls244, ls245)? Finally, is the eprom being selected? There maybe one or more enable pins that must be correct to read the eprom and if you see those pins strobing (typically low is active) then the micro is doing something right.
Wish I could help 😐
The pin @ 33:49 is floating. It has a RMS of 3.06V and that is a no no. My best guess is a defective multiplexer on that bus. Keep up with the good work.
You are correct! I'm really glad you commented on this. In the inductance test section of the board, there are two mux chips, IC16 and IC17 (CD4051's) that select the different test sources when in the inductance test mode. Pin 3 (com in/out) of the two chips is coupled by what appears to be a TL081 configured as a voltage follower with +/-5 volts, but the schematic is drawn incorrectly. I will show this on the next video. Anyway, I am seeing +18volts at pin 3 of IC17. The only power supplies on the chip are +12 at pin 16 (Vdd) and -5 at pin 7 (Vee). It also seems as if multiple channels are being selected at the same time and I don't think that is correct. Octal flip-flop IC12 provides the drive data for these chips and it gets really warm. I think the problem is somewhere in that area. Thanks again!
@@xraytonyb I'm happy to have the honour to help the guru. The TL081 must be dead, who else can provide 18v. You can safely use sockets; but spend 2 cents more and buy those who has metal on both sides of the pin. Another gotcha are the different 74xxx families have different logic levels, you can not always replace a 74lsXX with the 74hctXX you have in your drawer. Spent many hours learning that. Sencore are using all families. Looking forward to see your Sencore in action. 73 de OZ1GNN Chris
Awesome video, Tony! Now dying to see part 2!
Thank you.
Cheers,
Mark
This has to be one of the top five videos. Really interesting, can’t wait for the next chapter. I bet the print that was included is a clue. I know you will figure it out.
Hey Tony - some Ideas from me after repairing a lot of retro computer. Sockets could be tarnished - so give the EPROM Socket and its pins a good deoxi clean. Have you checked the RESET Circuit - should be PIN 4 of the MCU . Sometimes the reset circuit is looping because some sort of monitoring triggers it. The LCD Display may be connected by zebrastrips (some kind of conductive foam) and could also be cleaned or need some more compression between pcb and glass. This could fix the confused display.
I have a Sencore LC75 that I restored a while back and still use , it's one of the ones between the LC53 and the LC101. I love these devices, very useful.
I have fond memories of the days when electronics could actually be fixed. I think that ended in the 1990’s
Certainly check that the reset pin on the microcontroller isn’t being pulsed by something misbehaving.
I have one of this brand new. It has failed. I am going to follow your eloquent steps to check and get it up and running. Hope you can help where I might need with the manual and eeprom. Thank you.
Replace every electrolytic capacitor inside that thing! Some are for timing and others are for noise filtering. I try to swap out the smaller caps with tantalum type for better reliability.
Tony, look with the scope at all the pins on the cpu, they must have a clear 5V or 0v level, at 31:33 there is a hardware conflict, put the cpu on a socket, and when you see a conflict, bend the pin outside the socket and look again at the pin, still a conflict, its inside the cpu, no conflict then look at the logic connected to that pin, that's a good point to start with...,you do not solve this with an software update.
Still learning, how do you know there is a conflict? Because, the signal never has a clear “0” ??
Yes, also noticed that. Pin 10 is WR (output, write strobe to access memory) and looks to be going from 5V to 3V (and not 0.45V minimum, ideally 0V) indicating some form of contention. Would be worth scoping the other micro pins to see if anything similar.
@@ralphj4012 It would be nice if there was such a thing as a break out socket. Is there?
@@jbboating3268 I don't believe so, but then I am only going by the schematic. WR (and RD) go to multiple IC's and any one of those could be causing contention (as could the select lines to them or the micro itself). As a minimum I would check the ALE, PSEN and RD signals. Best to start with the micro in socket idea (or unsolder individual pins) as at least then you could isolate signals.
Nice unit and it must be fixed ! I would read and verify the eprom as its relatively easy and can be put out of mind for a while, I'm wondering if removing the LEDs is worth doing to take it closer to factory ? thou haff checked voltages that seems ok so there's a lot better comments than mine below !....cheers.
Great video Tony, very interesting. Wish I knew anything about this and could help. Just listening to you, since the prom has a more likelihood of having an issue in your experience, and is already on a socket and you can burn a new one, would that be a sensible first item to substitute rather than the CPU? As far as the noise goes, is it possible to trace it with the scope to a component? Perhaps a bypass cap etc somewhere? Looking forward to this series, thanks.
Wow now this is interesting, I have one of those and it works great.
I don't have much experience w/ those older style EPROMS, but I have had some weird faults end up being caused by a corrupt BIOS while troubleshooting motherboards. My little fleet of re programmers have kept quite a few Laptops out of the landfill. I'm curious to see if burning a new PROM is the fix.....
I have been long time owner of Sencore equipment !
Test any glue logic and memory components if you have the test equipment for that?
Would like to have one. But they are very expensive to get. Couldn't find one for less than a thousand if i remember correctly. Maybe America is different in that front. You seem to keep so much old junk around prices stay low.
Some of the noisy logic signals look like they might be caused by bad bypass caps so check the VCC pins on the chips for excessive noise.
There is hi low and tristate, where it’s kind of floating as it multiplexes between address and data
A nice challenge to have.
I remember those 8048 family parts had reset problems
There is an old rechargeable NiMH BY234 ( 12 Volt at 2 A/Hr ) battery pack on the back of this unit. Pretty sure it should
be replaced before going any further Tony. Just my 2 cents.
This one didn't have the battery in it.
The rechargeable battery does not effect the operation on AC. I have one that has never had a battery pack and it works just great. Fine unit.
Missing those vintage amp refurbishment vids man?
I too have two LC53 and wanted a LC-102 !
We use one of these at work.
I have not worked on these specifically but I have seen a lot of videos of how they fixed old CPU boards.
1) I would check the RAM chips to make sure they are not bad. RAM chips do go bad sometimes.
2) I would also look with a logic probe to see if there I/O lines that are not pulsing. This can be a clue to which chips are bad.
3) Another thing I would check is to make sure there are no dead batteries on any of the boards, sometimes a dead memory backup or timekeeper RAM battery can cause a CPU to not boot or do strange things. These batteries being dead can also brick some devices too because if the battery holds a decryption key or some kind of anti-tamper device. Sometimes these are batteries in epoxy blocks in some chips too. I know dead batteries causing non-booting was common on some old PCs, arcade games, and oscilloscopes. I am not sure if this device has batteries on the boards, but I know this is a common problem for some older devices.
4) Another thing to check is that your display board. First make sure your display driver chip is getting power and there is power getting to the display itself. If there is no power here, the display will not light. If a display driver chip went bad, this can also cause the display not to light. If the display is LCD and it is dark, check for a bad backlight or inverter. If it is Vacuum Flourescent, check to see how the 30-40V supply for it created (sometimes this is in the driver chip and other times there is a separate inverter) and if there is problem there. It is also possible for the VFD tube itself to fail. A burned out backlight can also cause a display to appear dark too. If LED, check the segments and driver chips.
5) Check for any missing voltages from the internal power supplies to the low voltage digital board. Make sure the CPU, RAM, ROM, and Bus chips are getting power. Especially common CPU-related voltages such as +3.3V, +5V, -5V, +12V, -12V, and similar (some older devices just used 5V and 12V, and 3.3V came a bit later in CPU history). Some computer devices did use a negative voltage. Regulators can go bad here.
6) Check for any bad I/O or bus chips. These can also cause non-booting.
7) Check the EEPROM and compare its checksum to the checksums of known versions of the software. See if it matches any of them. If not, you could have a bad EEPROM.
8) Make sure the clock is putting out the correct frequency for the CPU and bus.
9) Check the CPU reset circuit if the CPU uses a reset circuit.
Thumbs up for #3 suggestion, good starting place for older equip. In my experiences.
You would like to me to take some close-up photos of my LC102 circuitry of the power supply and signal board and email them to you?
There must be a CMOS or similar to store calibration data. Try to reset it.
Could be that address data latch 74ls373 or 4
I have a similar problem with my Lc-102
Tried the edebris link below for the Eprom BIN file but found it to be corrupt
Has anyone a different copy of the Bin file ??
Thanks
Strange ... I downloaded it and viewed wit an HEX editor and it seemed to be OK. Maybe loading it in an EEPROM programmer software gives you this problem. Sorry ...
@@Area51Corsair
Hi Corsair
My original firmware is version 12 whilst this Bin is version 17
Perhaps there was a hardware change because this BIN gives me garbage on the LCD display (Burnt 2 eproms to check)
I wonder what version xraytonyb has ??
Thanks for the reply
@@georgelivanes2832 Thanks, let's wait for Tony's next episode
I would say eprom, looks like classical GiGo garbage in garbage out.
Good head scratcher ! Thanks for the look.
Thats cool. I have an lc75 or two. If you wanna sell it when its fixed...