IPB failure

[Steven Hirsch]

While in the midst of probing the power supply voltages and ripple the IPB board suddenly developed a fault.  I'm about 99.9% positive I didn't short anything or cause this myself, but who knows.  The initial symptom was a hang when I attempted to boot ISIS.  After disconnecting the drive, I could get it to drop into the monitor prompt. When I invoke the self-test with 'Z$' it passes the IOC and checksum, but runs into odd problems with the memory check.  Symptoms:  When the test starts, the run LED is fully illuminated, but after a few seconds it dims significantly.  Eventually, it returns to full brightness (with no test results displayed) and reboots to the monitor prompt.  Rinse, repeat. 

Pulling the 32k expansion board did not correct the issue, so I ran the 4116 chips on the IPB through a chip tester.  Lo and behold, one was completely dead.  With high hopes I replaced it only to find that it made no difference in the (mis)behavior.  I'm highly suspicious of the old-school IC sockets, but I'd appreciate some input from others before doing any shotgun replacement.

To fill in some blanks:  All voltages are spot on and none of the rails have ripple exceeding ~ 50mv P-P.  I have applied De-Oxit to all connectors and worked them in and out vigorously. 

[Vale, Martyn]

Not that this really helps however it is normal for the Run LED to dim during the RAM Test although not normal for no results to be displayed.

 

Have a look at the Ready Pin on the 8080 and see if it seems clean and stable. As mentioned before I’ve had issues with the wire-ORed Acknowledge Circuit that feeds it. In my case it was 9602PC that had failed.

 

Martyn.

 

From: intel-...@googlegroups.com <intel-...@googlegroups.com> On Behalf Of Steven Hirsch
Sent: 10 May 2023 14:09
To: intel-devsys <intel-...@googlegroups.com>
Subject: intel-devsys IPB failure

 

⚠ Caution: External sender

 

While in the midst of probing the power supply voltages and ripple the IPB board suddenly developed a fault.  I'm about 99.9% positive I didn't short anything or cause this myself, but who knows.  The initial symptom was a hang when I attempted to boot ISIS.  After disconnecting the drive, I could get it to drop into the monitor prompt. When I invoke the self-test with 'Z$' it passes the IOC and checksum, but runs into odd problems with the memory check.  Symptoms:  When the test starts, the run LED is fully illuminated, but after a few seconds it dims significantly.  Eventually, it returns to full brightness (with no test results displayed) and reboots to the monitor prompt.  Rinse, repeat. 

 

Pulling the 32k expansion board did not correct the issue, so I ran the 4116 chips on the IPB through a chip tester.  Lo and behold, one was completely dead.  With high hopes I replaced it only to find that it made no difference in the (mis)behavior.  I'm highly suspicious of the old-school IC sockets, but I'd appreciate some input from others before doing any shotgun replacement.

 

To fill in some blanks:  All voltages are spot on and none of the rails have ripple exceeding ~ 50mv P-P.  I have applied De-Oxit to all connectors and worked them in and out vigorously. 

--
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/b3ed6f8b-a904-462b-bdc7-bbec91fdf3dbn%40googlegroups.com.

[Herb Johnson]

I thought about general suggestions to Steven, but I decided that was a
lecture. Steven: consider reseating all the chips, inspect for blackened
chip leads, inspect for other chip ills - use good lighting, take your
time.

One suggestion is a busy one but may be useful. Your failure report is
"program fails to complete". To monitor program execution without a
logic analyzer, build the simplest means. A string of LED's on the upper
address lines, enabled by appropriate bus signals, will display the
general location of program execution. Using your visual memory of
patterns, you'll develop a memory of what's going on per program. That
may provide a clue as to where your failure is. Follow along with the
monitor/test code source accordingly.

Hope this is helpful. No lectures.

regards Herb

> --
--
Herbert R. Johnson, New Jersey in the USA
http://www.retrotechnology.com OR .net
preserve, recover, restore 1970's computing
email: hjohnson AT retrotechnology DOT com
or try later herbjohnson AT comcast DOT net

[Steven Hirsch]

On Wed, 10 May 2023, Herb Johnson wrote:

> I thought about general suggestions to Steven, but I decided that was a
> lecture. Steven: consider reseating all the chips, inspect for blackened chip
> leads, inspect for other chip ills - use good lighting, take your time.
>
> One suggestion is a busy one but may be useful. Your failure report is
> "program fails to complete". To monitor program execution without a logic
> analyzer, build the simplest means. A string of LED's on the upper address
> lines, enabled by appropriate bus signals, will display the general location
> of program execution. Using your visual memory of patterns, you'll develop a
> memory of what's going on per program. That may provide a clue as to where
> your failure is. Follow along with the monitor/test code source accordingly.
>
> Hope this is helpful. No lectures.

All input is helpful, Herb.

There are precious few socketed chips in the unit and I've carefully
inspected all of them, removed, fiberglass pen to the leads, De-Oxit,
reseat.

The only chips showing oxidized pins are soldered. I've looked at them
through a magnifier and none appear to be mechanically broken - just
surface blackening.

I do not think this is a bad-contact issue. This AM, after being
off all night, it booted immediately to ISIS and worked for a half-minute
or so before locking up. But, after it fails it's very consistant at
acting dead after reset. That's a good thing since a trace will be of
reasonable length (I have a 32-ch LA connected to the bus - no need for
LEDs).

I have to leave the bench for a bit, but I'll plan on watching Martyn's
youtube series later today.

[Herb Johnson]

"acting dead after reset" does not match your prior description. You
said it ran some diagnostics but apparently restarted the monitor code
during memory tests. That is not "dead". Precision is your friend,
Steven, when diagnosing problems.

"fails when on for some time" suggests heat-related issues. Heat can
slightly change timing constants on R/C (resistor-capacitor) circuits.
Also one-shots (monostables) seem to shift their timing.

Plan A: R/C problems

Look for one-shots in the schematic. Look for a resistor/capacitor
combination that turns a logic level-shift into a pulse.

Then, measure the resistance and capacitance. surprisingly, resistors
and caps can change value in 40 years. Measure the actual timing of
these circuits, see if that matches the specified timing or the
calculated timing.

Plan B: isolate

to confirm heat is the issue, *freeze* the IPB board (or some other
board). See if that prolongs the "good while cold" time. Then heat it (I
use a kitchen over BRIEFLY turned on to get above room temp) and see if
that shortens the good-run time. Then use freeze spray to isolate the
faulty area: selectively chill a space, test for good/bad result, divide
the space and repeat.

Yes, these are brutal methods. But they require few or no assumptions,
few tools beyond your noggin. When problems have no obvious origin, use
the problem as a diagnostic and control the variables that evoke the
problem.

regards herb

On 5/10/2023 12:41 PM, Steven Hirsch wrote:
>
> I do not think this is a bad-contact issue.  This AM, after being off
> all night, it booted immediately to ISIS and worked for a half-minute or
> so before locking up.  But, after it fails it's very consistant at
> acting dead after reset.  That's a good thing since a trace will be of
> reasonable length (I have a 32-ch LA connected to the bus - no need for
> LEDs).
>
> I have to leave the bench for a bit, but I'll plan on watching Martyn's
> youtube series later today.

[Steven Hirsch]

On Wed, 10 May 2023, Herb Johnson wrote:

> "acting dead after reset" does not match your prior description. You
> said it ran some diagnostics but apparently restarted the monitor code
> during memory tests. That is not "dead". Precision is your friend,
> Steven, when diagnosing problems.

Absolutely, Herb. But since the problems and symptoms are shifting around
it's tough to have a description hold over time. The "dead after reset"
only appeared this AM. It's no longer behaving as it did when I posted
that initial report.

> "fails when on for some time" suggests heat-related issues. Heat can slightly
> change timing constants on R/C (resistor-capacitor) circuits.
> Also one-shots (monostables) seem to shift their timing.
>
> Plan A: R/C problems
>
> Look for one-shots in the schematic. Look for a resistor/capacitor
> combination that turns a logic level-shift into a pulse.
>
> Then, measure the resistance and capacitance. surprisingly, resistors and
> caps can change value in 40 years. Measure the actual timing of these
> circuits, see if that matches the specified timing or the calculated timing.
>

> Plan B: isolate
>
> to confirm heat is the issue, *freeze* the IPB board (or some other board).
> See if that prolongs the "good while cold" time. Then heat it (I use a
> kitchen over BRIEFLY turned on to get above room temp) and see if that
> shortens the good-run time. Then use freeze spray to isolate the faulty area:
> selectively chill a space, test for good/bad result, divide the space and
> repeat.

I'm currently doing exactly that. So far, nothing is showing sensitivity
to freeze spray and/or a hair dryer. Yet, the only thing that results in
a proper startup seems to be letting the unit sit with power off. This
does tend to suggest heating as an issue - I simply haven't found any
way to trigger it deliberately. Yet.

> Yes, these are brutal methods. But they require few or no assumptions, few
> tools beyond your noggin. When problems have no obvious origin, use the
> problem as a diagnostic and control the variables that evoke the problem.
>
> regards herb
>
> On 5/10/2023 12:41 PM, Steven Hirsch wrote:
>>
>> I do not think this is a bad-contact issue.  This AM, after being off all
>> night, it booted immediately to ISIS and worked for a half-minute or so
>> before locking up.  But, after it fails it's very consistant at acting dead
>> after reset.  That's a good thing since a trace will be of reasonable
>> length (I have a 32-ch LA connected to the bus - no need for LEDs).
>>
>> I have to leave the bench for a bit, but I'll plan on watching Martyn's
>> youtube series later today.
> --
> Herbert R. Johnson, New Jersey in the USA
> http://www.retrotechnology.com OR .net
> preserve, recover, restore 1970's computing
> email: hjohnson AT retrotechnology DOT com
> or try later herbjohnson AT comcast DOT net
>

> --
> You received this message because you are subscribed to a topic in the Google
> Groups "intel-devsys" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/intel-devsys/9fngKpeILnM/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to

> intel-devsys...@googlegroups.com.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/intel-devsys/73645fcd-21f8-ee61-8298-ed5c49689937%40retrotechnology.com.
>

[Herb Johnson]

> letting the unit sit with power off

What else is in your system, that's not a Multibus card? It's hard to
believe the power supplies are a cause, more likely they are a symptom.

Try discharging the large caps on the power supply (with power off!).
That will really bring residual DC voltages to zero. Also discharge the
DC at the bus - caps on the boards may hold some charge. Some dynamic
RAM (like those 16K DRAMS) may hold values when DC power drops to a few
volts. The RAMs won't draw power, but microamps will sustain that charge.

Check the DRAM voltage sources. Is there a local regulator to provide
say -5V to those 16K DRAMS? What if that's faulty? Check how refresh is
accomplished, see if that hardware is operating.

Are the DRAMs necessary memory in your system? Can you disable them and
add a RAM card to substitute? If that scheme doesn't work, could be the
scheme.

Just flailing around here, of course.

regards Herb

On 5/10/2023 2:35 PM, Steven Hirsch wrote:
> On Wed, 10 May 2023, Herb Johnson wrote:
>
>   So far, nothing is showing
> sensitivity to freeze spray and/or a hair dryer.  Yet, the only thing
> that results in a proper startup seems to be letting the unit sit with
> power off.  This does tend to suggest heating as an issue - I simply
> haven't found any way to trigger it deliberately. Yet.

[craig andrews]

Steven,

I may have missed the beginning of the IPB diagnostics. Fortunately, the IPB is a single board computer and can be tested running your own code and starting with the basics. Are INT, READY, HOLD, & RESET appropriate levels? SYNC look good? When it locks up, does it have its clock inputs? I have come across some cranky 8224 clock generators that couldn’t reliably keep a crystal oscillating. When it locks, is it still fetching instructions? I always prefer to diagnose using software. Have you tried writing/running any diagnostic code? First I would try some RAM-less test routines like just toggling the INTE, then establish communication with a terminal, then test RAM for reliability, and then expand the tests using RAM. Also remember if something is wrong with memory (or the memory map control port) when it does an opcode fetch and it gets 0xFF, that is a RST 7 so the PC takes up from 0x0038. (Actually 0xE838, I think, since until boot is complete the base ROM is overlaid at 0xE800 as I recall).

Best of luck
Craig



> On May 10, 2023, at 11:35 AM, Steven Hirsch <snhi...@gmail.com> wrote:

> 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/c7d98093-cfc5-e78-2df-5e3c6a93d35%40fast.net.

[Steven Hirsch]

I have spent some time probing signals on the IPB and found a smoking gun.  If watch the CAS* signal at the output of A2 (74S00 NAND), it shows brief activity after reset before settling in a quiescent high state.  But, both inputs (pins 12 and 13) show constant activity that is not affected by reset.  Unless I'm misreading something, the output should be low when both 12 and 13 are high, correct?  If so, there are long periods of time where this is the case - so, bad gate? Before replacing it I'd like to know what the brief activity is all about.  It doesn't seem logical that reset has no effect on the inputs to the NAND, yet causes a change in the output.  Comments?

[Vale, Martyn]

 

Is the output just floating high or is it really being driven high ? If it’s just floating high you could try the piggy back trick by pressing a good gate over the top of the possibly duff one. Obviously do this at your own risk !

 

Bye

Martyn.

To view this discussion on the web visit https://groups.google.com/d/msgid/intel-devsys/6b9d8788-1023-4065-8f8d-c11c511a1df4n%40googlegroups.com.

[Steven Hirsch]

Based on the schematic it's not being driven by anything else and I don't see a pullup anywhere.  Before I break out the desoldering gear, it's probably worth asking if there are alternate revisions of the board that have multiple drivers for CAS* ?  My IPB has the legend 'PWA 1002321-03J' screened on the board and '4001246 04 REVE' printed on the top of the front panel assembly above the interrupt and reset buttons.

[Vale, Martyn]

Unfortunately there are multiple revisions and a raft of engineering change orders (ECO’s) for the IPB for which there are no updated schematics…………………..

 

The best advice really is unless you are really in love with the IPB then get an IPC it’s much better developed.

 

Bye

Martyn.

 

From: intel-...@googlegroups.com <intel-...@googlegroups.com> On Behalf Of Steven Hirsch
Sent: 11 May 2023 17:17
To: intel-devsys <intel-...@googlegroups.com>
Subject: Re: intel-devsys IPB failure

 

⚠ Caution: External sender

 

To view this discussion on the web visit https://groups.google.com/d/msgid/intel-devsys/4cbd0856-112a-4bd5-ac8e-72995e68e8f2n%40googlegroups.com.

[Jon Hales]

Steven

I'm attaching the Intel Engineering Change Orders document dated March 1980.

This shows that your 4-layer IPB is of a relatively late specification (revision -03K being the current version in 1980). 

I'm not sure there's any directly useful information for you in this document, except that it makes Martyn's point about the multiple changes that were (apparently) not systematically reflected in reissued schematic drawings.

You haven't mentioned whether you received schematic drawings with the MDS - my understanding is that Intel normally issued schematics for each of the main components in the system sold to a client. It's possible that you may have schematics that were up to date for your IPB.

Regards

Jon

To view this discussion on the web visit https://groups.google.com/d/msgid/intel-devsys/4cbd0856-112a-4bd5-ac8e-72995e68e8f2n%40googlegroups.com.

[Herb Johnson]

A 7400 NAND is a totem-pole output, not an open collector output. So it
should not "float".

But a reset condition, affects many circuits on a board; that suggests a
power surge, that may find its way to the Vcc of that gate. I'd monitor
pin 14 (Vcc) simultaneously with the output to look for voltage spikes
on power. Also put your scope ground at pin 7 (gnd) so you aren't seeing
power surges on your ground path to the gate.

If the designers used a 74S00 instead of a 7400, they wanted a FAST
response. RAS and CAS are among the fastest timing on any 8/16 bit
computer. All good reasons to watch your grounds when reading signals.

Martin's idea of a piggy-back on the gate, isn't awful. Don't attach the
outputs! only the inputs. You might add a modest load to the test
output - say a 5K pullup, maybe 1K? It's just a sanity test but it may
be informative.

HP produced an IC tester, which clamped onto an IC with a matching IC.
Inputs were paralleled, outputs went to comparators that latched on a
difference, which was displayed on LEDs per pin. Thus any error per pin
was displayed. Enough said.

This symptom goes to my hypothesis that DRAM is the culprit. But this
may be a case of "I'm looking where the light is strongest, not where I
lost my keys". I believe I suggested, disabling DRAM and substituting
some Multibus RAM board on the bus - if that is possible, if the DRAM is
not internal to the board.

The clue "... at reset" suggests looking carefully at the reset signal
around the board. Many resets depend on RC circuits - check those as i
described previously.

Of course this is all, "chasing clues". Keep notes, Steven, and share
them. In the course of writing readable notes, your brain may extract
more clues. Good luck and be patient.

regards Herb

On 5/11/2023 11:30 AM, Vale, Martyn wrote:
> Is the output just floating high or is it really being driven high ? If
> it’s just floating high you could try the piggy back trick by pressing a
> good gate over the top of the possibly duff one. Obviously do this at

> your own risk ! - Martyn.
>
> *From: Steven Hirsch

>
> I have spent some time probing signals on the IPB and found a smoking
> gun.  If watch the CAS* signal at the output of A2 (74S00 NAND), it
> shows brief activity after reset before settling in a quiescent high
> state.  But, both inputs (pins 12 and 13) show constant activity that is
> not affected by reset.  Unless I'm misreading something, the output
> should be low when both 12 and 13 are high, correct?  If so, there are
> long periods of time where this is the case - so, bad gate? Before
> replacing it I'd like to know what the brief activity is all about.  It
> doesn't seem logical that reset has no effect on the inputs to the NAND,
> yet causes a change in the output.  Comments?

[Vale, Martyn]

Jerry Walker has reproduced his own enhanced version of the HP Logic Comparator Herb mentions below:

http://jmprecision.co.uk/shopping/start.php?browse=1&cat=28&=SID

Works quite well, takes some time to build up though.

Martyn.

-----Original Message-----
From: intel-...@googlegroups.com <intel-...@googlegroups.com> On Behalf Of Herb Johnson
Sent: 11 May 2023 18:09
To: intel-...@googlegroups.com
Subject: Re: intel-devsys IPB failure

⚠ Caution: External sender

http://www.retrotechnology.com/ OR .net preserve, recover, restore 1970's computing

email: hjohnson AT retrotechnology DOT com or try later herbjohnson AT comcast DOT net

--
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/340a3d3f-559d-9ae6-9b90-418a153f8b7b%40retrotechnology.com.

[Herb Johnson]

Thanks for the link. Seems a bit pricey. Also I now worry about tariffs
from the UK - anyone had to pay them lately for this class of product?
The original HP products sell on eBay for not much more. But this UK
version is a packaged solution and the boards look of quality. - regards
Herb

On 5/11/2023 1:14 PM, Vale, Martyn wrote:
>
> Jerry Walker has reproduced his own enhanced version of the HP Logic
Comparator Herb mentions below:
>
> http://jmprecision.co.uk/shopping/start.php?browse=1&cat=28&=SID
>
> Works quite well, takes some time to build up though.
>
> Martyn.
>
> -----Original Message-----
> From: intel-...@googlegroups.com <intel-...@googlegroups.com>
On Behalf Of Herb Johnson
> Sent: 11 May 2023 18:09
> To: intel-...@googlegroups.com
> Subject: Re: intel-devsys IPB failure
>

> HP produced an IC tester, which clamped onto an IC with a matching IC.
> Inputs were paralleled, outputs went to comparators that latched on a
difference, which was displayed on LEDs per pin. Thus any error per pin
was displayed. Enough said.

--
Herbert R. Johnson, New Jersey in the USA

http://www.retrotechnology.com OR .net

preserve, recover, restore 1970's computing
email: hjohnson AT retrotechnology DOT com
or try later herbjohnson AT comcast DOT net

--
Herbert R. Johnson, New Jersey in the USA

http://www.retrotechnology.com OR .net

[Vale, Martyn]

I noticed on the IPB I repaired recently that only one of the RAS / CAS lines run all the time, can’t remember which off hand but both lines only run together when the RAM is accessed unlike the expansion boards on which they both run continuously.
I’m on the train so can’t look anything up !

On 11 May 2023, at 16:25, Steven Hirsch <snhi...@gmail.com> wrote:



⚠ Caution: External sender

To view this discussion on the web visit https://groups.google.com/d/msgid/intel-devsys/6b9d8788-1023-4065-8f8d-c11c511a1df4n%40googlegroups.com.

[Steven Hirsch]

After poking at the system for the past month or so, I'm really not getting anywhere at all.  All data and address lines seem to be wiggling in reasonable manner (but see below), reset signal is proper, voltages are spot-on.  It does seem as if the 8218 bus controller and 8228 'system controller' chips are running very hot, but since this is older technology that may well be normal. 

Current operational status with no floppy connected, but 8271 FDC chip installed:

• Blank screen with a flashing underline cursor at initial power on. 
• After a few minutes and multiple pushes of the reset button, the '.' monitor prompt appears and responds to input.
• The Z$ test passes the first three checks, then hangs at testing memory with no output or progress.  After a minute or so it resets back to the sign-on and monitor prompt.
• The IOC self-test passes (disk obviously not checked).
• If the FDC controller sees a valid RDY* signal the system will never display a prompt regardless of how long it sits or how many resets are done.
• There is constant rolling 'snow' in the background of the video display. 
  

Some questions for folks who have spent time poking around in the guts of these systems:

• Should I see activity on the 8218 (A66 on IPB) when sitting idle at the monitor '.' prompt?  All signals are quiescent.
• Re: the above, what is the proper part number for that bus controller chip?  The documentation calls it out as an 8218, but the chip in my unit is marked '52-217  S2990' with an Intel logo present.  I cannot find any reference to those identifiers.  More confusingly, an '8218' chip from my parts bin turns out to be a 24-pin device (A66 is a 28-pin package)!
  

[roger arrick]

Hi Steven,

If it's any help, I have systems similar in my queue that I've just never been able to fix.  Sometimes I set them aside and do other projects then return with a fresh (ie: Forgot the stuff I tried) and often that works.

I'd probably suggest at this point that you revisit the cause of 90% of old electronic malfunctions -- connections.  Every chip in a socket needs to be pulled and plugged many times.  Study each connector.  EVERY connection point needs to be worked.  This usually doesn't require any kind of cleaner.

The 2^nd biggest problem is capacitors.  I wish they'd just blow so I can replace them, but some hang around, looking all functional, but inside they are worse than open, sometimes shorty.

I'd also revisit PROMs.  Dump yours, collect others, compare.

Divide and conquer - See if you can get access to another set of hardware and start removing unknowns.  You can check socketed chips too.  If you were closer I'd bring over a system and we could do this.  Buy more hardware if you have to.

Replace RAM.

I've been fixing complex electronics for 45 years and I've NEVER needed or used a digital logic analyzer or an emulator.  I use a scope and verify power, clocks, chip selects, stuff like that.

BTW, on your serial port, make sure to jumper 4 and 5 (RTS/CTS) which is hardware handshake, otherwise the UART will never be ready.

Those are my thoughts, let me know how I can help.

--

Roger Arrick

Tyler, Texas, USA

Ro...@Arrick.com

---

From: intel-...@googlegroups.com <intel-...@googlegroups.com> on behalf of Steven Hirsch <snhi...@gmail.com>
Sent: Monday, June 26, 2023 9:02 AM
To: intel-devsys <intel-...@googlegroups.com>

Subject: Re: intel-devsys IPB failure

To view this discussion on the web visit https://groups.google.com/d/msgid/intel-devsys/d5b3ec71-8a7c-483d-ac47-7e03f872cf25n%40googlegroups.com.

[Steven Hirsch]

After replacing the IPB and expansion memory with an IPC from eBay the system is alive again.  Then I got lucky and found a shorted tantalum cap on the double-density interface board.  It's able to boot and read diskettes on the external drives now, but writes are a no-go.  Format operation just sits for a bit and complains about an Error 20 on track 0 sector 1.  Already tried different media and a single-drive IDISK format.  Same issue.  Something tells me this will be a bit more work to track down, but progress is progress.

[intel-devsys]

Got it!  Problem was between the stool and the keyboard.  I got turned around on the meaning of an exposed protect notch on 8" media. Error 20 denotes an attempt to write a protected diskette.  After covering the notch with a stick-on everything is working. 

[Herbert Johnson]

We oldies sometimes call that "a short between the ears". and the
polarity of the write-protect notch is easily confused. Glad to hear
your progress on your System. Also glad to hear you got past your stool
problem. ;) - regards herb

On 9/18/2023 7:14 PM, intel-devsys wrote:> Got it! Problem was between

the stool and the keyboard. I got turned
> around on the meaning of an exposed protect notch on 8" media. Error 20
> denotes an attempt to write a protected diskette. After covering the
> notch with a stick-on everything is working.
>
>
> On Monday, September 18, 2023 at 5:01:13 PM UTC-4 Steven Hirsch wrote:
>
> After replacing the IPB and expansion memory with an IPC from eBay
> the system is alive again. Then I got lucky and found a shorted
> tantalum cap on the double-density interface board. It's able to
> boot and read diskettes on the external drives now, but writes are a
> no-go. Format operation just sits for a bit and complains about an
> Error 20 on track 0 sector 1. Already tried different media and a
> single-drive IDISK format. Same issue. Something tells me this
> will be a bit more work to track down, but progress is progress.

--
--
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

[intel-devsys]

Next question:  Can a system with drives attached to both the IOC board and double-density controller be started from the IOC (SSSD) disk?  I was hoping there'd be a monitor command to choose the startup drive but I'm not able to find any mention of it. 

[Vale, Martyn]

No it can’t unfortunately.

 

I do have an untested theory though I was going to put a switch across one of the IO Address Switches on the Channel Board so the system can’t find it which will cause it to boot from the internal drive. Just need to find an address which doesn’t conflict with anything.

 

As far as my testing has gone using a Zendex Controller it’s also not possible to boot single density and have a double density set in the system as well as ISIS won’t allow it.

 

Thanks

Martyn.

 

From: intel-...@googlegroups.com <intel-...@googlegroups.com> On Behalf Of intel-devsys
Sent: 19 September 2023 01:28
To: intel-devsys <intel-...@googlegroups.com>
Subject: Re: intel-devsys IPB failure

 

⚠ Caution: External sender

 

--

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/8d8b52a1-bde8-49ac-aa13-6b5cbb0aa046n%40googlegroups.com.

[Sid Jones]

A quick shout out to see if anybody has a source of 8087 co-processors in 40-pin DIL form. Preferably in the UK - to save on carrier pigeons.

 

I’ve got an add-on board for my Series-III, but I’d like to source a real live 8087 for some testing with an early laptop PC.

 

Regards

 

Sid

 

 

[Sid Jones]

Whoops – my bad.

 

Got the etiquette wrong and posted to this thread...

 

I’ll try again!

 

Regards

 

Sid