ICE-86 theory of operation?

[Steven Hirsch]

My ICE-86 subsystem is failing tests for MAP, ICE and SCRATCH RAM.  There are static RAM chips on all (3) boards, but I'm only able to identify BREAKPOINT RAM (which is passing) as IC A41-42, 62-63, 61-81 and 82-83 on the 'trace' board.  I have the schematic set, but it doesn't call out the functions for any of the RAM chips (the only way I was able to identify the breakpoint chips was because they were called out by id in the tests).  Has anyone encountered a service manual or theory of operation for the ICE-86 or 86A board set?  In the interim I'll try the "usual" and reseat, inspect for corroded leads, etc.

[Jon Hales]

Hi Stephen

So, your adventure continues ... Excellent.

Are you aware of Intel publication 162554-001?  The title is "162554-001 ICE-86A Microsystem In-Circuit Emulator Operating Instructions for ISIS-II Users May81". It's to be found on Bitsavers.org and Archive.org.

Apparently, it includes schematic drawings. I'm attaching a screenshot of the preface to the manual. Hopefully, some of the information will be of use to you.

Best regards

Jon

On Sat, 23 Sept 2023 at 17:53, Steven Hirsch <snhi...@gmail.com> wrote:

My ICE-86 subsystem is failing tests for MAP, ICE and SCRATCH RAM.  There are static RAM chips on all (3) boards, but I'm only able to identify BREAKPOINT RAM (which is passing) as IC A41-42, 62-63, 61-81 and 82-83 on the 'trace' board.  I have the schematic set, but it doesn't call out the functions for any of the RAM chips (the only way I was able to identify the breakpoint chips was because they were called out by id in the tests).  Has anyone encountered a service manual or theory of operation for the ICE-86 or 86A board set?  In the interim I'll try the "usual" and reseat, inspect for corroded leads, etc.

--
You received this message because you are subscribed to the Google Groups "intel-devsys" group.
To unsubscribe from this group and stop receiving emails from it, send an email to intel-devsys...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/intel-devsys/f61ba8cc-079a-4c18-8093-cac14388c936n%40googlegroups.com.

[Steven Hirsch]

Hi, Jon.  I do indeed have that manual.  It's helpful, but unless I managed to skip the pertinent bits it does not help in identifying which bank of SRAM is responsible for the functionality in question.  I will comb through it again!  Thanks for your response.

[Herbert Johnson]

If you can't find documentation, consider cruder methods. Don't get mad
when I've already said these are "crude".

You can likely identify RAM chips on the board, get specifications for
those chips. Then selectively disable a RAM chip and observe diagnostic
results. It's less important which chip of a set and bank you select, it
will disable that bank - you are identifying function, also confirming
the diagnostic you have.

The crudest means of disabling would be to find a chip-select pin and
snip the IC pin at the PC end; then solder-bridge the gap. You have
other choices, don't choose grounds or DC power.

With care you can desolder the pin to the point where the IC pin is in
place but makes no contact with the PC board. That's tough in practice
to do, unless you also pull the IC pin out of the PC board - the obvious
risk is breaking off the pin. Don't break the pin. Solder wick can be
effective in removing solder, but you can also cook the board doing so.
Now you see why snipping the pin above the solder connection is
least-risky. Use a real small-jaw snipping tool, not some crude
wire-cutter-snipper.

Once you have determined 1) diagnostics have said "this functional set
of RAM is failing and 2) which physical chips those are, then you can
proceed to 1) create your own diagnostics to access that RAM and 2)
reverse engineer the chips connected to that RAM to find faults.

absent driving software, check with your signal equipment. oscilloscope
may show a faulty signal on a RAM pin - logic levels are screwy. Then
you look for the driving IC and the other ICs which are driven. A logic
analyzer may be informative, I don't have that level of practice myself.

To determine new diagnostic software, may involve reverse engineering
the current diagnostic software, to see how its accessing that RAM. That
may be some work.

Now, I may be an idiot on this product. Say it runs its own processor
on-board and your X86 software is just talking the local processor's
software. That's OK, you relocate your interests to the local
processor's ROM to decode the software secrets there.

The point of all this, is not to provide a road map, but to suggest how
you draw your OWN map. Everyone wants factory documentation. This is how
it's done when you don't have that. Take it as encouraging advice.

regards Herb

On 9/23/2023 1:57 PM, Steven Hirsch wrote:
> Hi, Jon.  I do indeed have that manual.  It's helpful, but unless I
> managed to skip the pertinent bits it does not help in identifying which
> bank of SRAM is responsible for the functionality in question.  I will
> comb through it again!  Thanks for your response.
>
> On Saturday, September 23, 2023 at 1:08:35 PM UTC-4 Jon Hales wrote:
>
> Are you aware of Intel publication 162554-001?  The title is
> "162554-001 ICE-86A Microsystem In-Circuit Emulator Operating
> Instructions for ISIS-II Users May81". It's to be found on
> Bitsavers.org and Archive.org.
>

> On Sat, 23 Sept 2023 at 17:53, Steven Hirsch <snhi...@gmail.com> wrote:
>
> My ICE-86 subsystem is failing tests for MAP, ICE and SCRATCH
> RAM.  There are static RAM chips on all (3) boards, but I'm only
> able to identify BREAKPOINT RAM (which is passing) as IC A41-42,
> 62-63, 61-81 and 82-83 on the 'trace' board.  I have the
> schematic set, but it doesn't call out the functions for any of
> the RAM chips (the only way I was able to identify the
> breakpoint chips was because they were called out by id in the
> tests).  Has anyone encountered a service manual or theory of
> operation for the ICE-86 or 86A board set?  In the interim I'll
> try the "usual" and reseat, inspect for corroded leads, etc.
>


--

Herb Johnson, New Jersey USA
http://www.retrotechnology.com or .net
preserve and restore 1970's personal computing
email: hjohnson @ retrotechnology dot com
or try later at herbjohnson @ comcast dot net

[Steven Hirsch]

Thanks, Herb!  I would have gotten to all of that at some point, but it helps greatly to have the steps pulled together as you have. 

Found a block diagram in the user manual that goes a bit further towards explaining the different bits of SRAM. 

[Steven Hirsch]

And - fixed. Pulled the SRAM chips from the 'FM Controller' board, cleaned pins, added de-Oxit and reinserted.  Everything passes now.  An error on the 'scratchpad RAM' was likely causing the downstream symptoms.

[Herbert Johnson]

Wow - you desoldered *all the pins*? ;) Sockets makes my diagnostic
easier. But sockets caused the problem in the first place, long term.

I've used DeOxit on DRAM cards with mixed success. Got a 64K card of 16K
Drams working, but only for an hour at a time. Then heat "caused" bit
failures, "cured" by cooling. Did not have opportunity to resolve where
the heat-sensitive delay caused the problem. Selective cooling didn't
resolve it at the time. Massive replacement now with faster DRAM might,
or replacement with 265K chips (one row maybe) might.

Regards Herb

On 9/23/2023 6:00 PM, Steven Hirsch wrote:
> And - fixed. Pulled the SRAM chips from the 'FM Controller' board,
> cleaned pins, added de-Oxit and reinserted.  Everything passes now.  An
> error on the 'scratchpad RAM' was likely causing the downstream symptoms.
>
>
> On Saturday, September 23, 2023 at 3:06:46 PM UTC-4 Steven Hirsch wrote:
>
> Thanks, Herb!  I would have gotten to all of that at some point, but
> it helps greatly to have the steps pulled together as you have.
>
> Found a block diagram in the user manual that goes a bit further
> towards explaining the different bits of SRAM.
>
> On Saturday, September 23, 2023 at 2:52:23 PM UTC-4 Herbert Johnson
> wrote:
>

> The crudest means of disabling would be to find a chip-select
> pin and
> snip the IC pin at the PC end; then solder-bridge the gap. You have
> other choices, don't choose grounds or DC power.
>
>

[Steven Hirsch]

All the SRAM chips on the FM Controller were socketed.  The sockets do not inspire much confidence either, but it's working now.