On Tue, 25 Mar 2008 16:58:58 -0700 (PDT), Rich Camarda
wrote:

>Anyone have this board in a working system? I have two of them and
>they both exhibit the same problem in a Compupro 8-16 system. I
>believe there is a timing issue of some kind with the System Support
>or the Disk-3 boards. One of these CPU's actually worked fine at one
>time for a few days. Anyway, they both start the boot sequence fine as
>the Z80 and then when switching processeors to the 286 for CP/M-86
>the system hangs up. I tried the documented jumper settings etc,
>(thanks to the manual from Herb Johnson) but still the same problem.
>If someone has more info, or has had the same probelm, I would
>appreciate hearing from you.
>
>Thanks!

If I were to make a wild guess the, since it worked for a while then
stopped the thought is the one (or more) files required for x86
version of CP/M have become corrupt or gone missing.

The two most likely timing issues for most S100 cards is not enough
wait states for the CPU speed and general conformity to IEE696.
The frist is slow memory (or IO) and fast cpu related. The latter is
usually things like Temp-master/DMA items. I susepct the latter is
lest likely as the system did work for a while and also the DISK3 and
Macrotech are both late enough to conform to IEE696/S100.

FYI: the most common way to kill files in a CPM system is power down
with the floppy is the drive or the hard disk heads not parked (most
MFM drives didn't always autotpark safely).


Allison

On Mar 25, 4:34*pm, no.s...@no.uce.bellatlantic.net wrote:
> On Tue, 25 Mar 2008 16:58:58 -0700 (PDT), Rich Camarda
>
> wrote:
> >Anyone have this board in a working system? I have two of them and
> >they both exhibit the same problem in a Compupro 8-16 system. I
> >believe there is a timing issue of some kind with the System Support
> >or the Disk-3 boards. One of these CPU's actually worked fine at one
> >time for a few days. Anyway, they both start the boot sequence fine as
> >the Z80 *and then when switching processeors to the 286 for CP/M-86
> >the system hangs up. I tried the documented jumper settings etc,
> >(thanks to the manual from Herb Johnson) but still the same problem.
> >If someone has more info, or has had the same probelm, I would
> >appreciate hearing from you.
>
> >Thanks!
>
> If I were to make a wild guess the, since it worked for a while then
> stopped the thought is the one (or more) files required for x86
> version of CP/M have become corrupt or gone missing.
>
> The two most likely timing issues for most S100 cards is not enough
> wait states for the CPU speed and general conformity to IEE696.
> The frist is slow memory (or IO) and fast cpu related. *The latter is
> usually things like Temp-master/DMA *items. *I susepct the *latter is
> lest likely as the system did work for a while and also the DISK3 and
> Macrotech are both late enough to conform to IEE696/S100.
>
> FYI: the most common way to kill files in a CPM system is power down
> with the floppy is the drive or the hard disk heads not parked (most
> MFM drives didn't always autotpark safely).
>
> Allison

Thanks for the reply Allison. Actually the system works fine with just
changing out the CPU with the Compupro 8085/8088 board as well as the
Compupro 80286 board. Also I have floppy based system disks which also
work fine, except with the Macrotech board. The Macrotech board does
work fine as just a Z80 with the 8 bit boot configurations for CPM80.
I tried playing with different wait states etc, and I do know that
there were some inherent issues with timing concerning this board and
the System Support I board. I was just hoping someone had a similar
experience and place to start looking. Looks like if I get the time I
will have to debug the hardware further here.

Take care!

On Tue, 25 Mar 2008 23:05:58 -0700 (PDT), Rich Camarda
wrote:

>On Mar 25, 4:34*pm, no.s...@no.uce.bellatlantic.net wrote:
>> On Tue, 25 Mar 2008 16:58:58 -0700 (PDT), Rich Camarda
>>
>> wrote:
>> >Anyone have this board in a working system? I have two of them and
>> >they both exhibit the same problem in a Compupro 8-16 system. I
>> >believe there is a timing issue of some kind with the System Support
>> >or the Disk-3 boards. One of these CPU's actually worked fine at one
>> >time for a few days. Anyway, they both start the boot sequence fine as
>> >the Z80 *and then when switching processeors to the 286 for CP/M-86
>> >the system hangs up. I tried the documented jumper settings etc,
>> >(thanks to the manual from Herb Johnson) but still the same problem.
>> >If someone has more info, or has had the same probelm, I would
>> >appreciate hearing from you.
>>
>> >Thanks!
>>
>> If I were to make a wild guess the, since it worked for a while then
>> stopped the thought is the one (or more) files required for x86
>> version of CP/M have become corrupt or gone missing.
>>
>> The two most likely timing issues for most S100 cards is not enough
>> wait states for the CPU speed and general conformity to IEE696.
>> The frist is slow memory (or IO) and fast cpu related. *The latter is
>> usually things like Temp-master/DMA *items. *I susepct the *latter is
>> lest likely as the system did work for a while and also the DISK3 and
>> Macrotech are both late enough to conform to IEE696/S100.
>>
>> FYI: the most common way to kill files in a CPM system is power down
>> with the floppy is the drive or the hard disk heads not parked (most
>> MFM drives didn't always autotpark safely).
>>
>> Allison
>
>Thanks for the reply Allison. Actually the system works fine with just
>changing out the CPU with the Compupro 8085/8088 board as well as the
>Compupro 80286 board. Also I have floppy based system disks which also
>work fine, except with the Macrotech board. The Macrotech board does
>work fine as just a Z80 with the 8 bit boot configurations for CPM80.
>I tried playing with different wait states etc, and I do know that
>there were some inherent issues with timing concerning this board and
>the System Support I board. I was just hoping someone had a similar
>experience and place to start looking. Looks like if I get the time I
>will have to debug the hardware further here.
>
>Take care!

Being familiar with the system support board the likely timing issue
is memory and/or IO speed (access times). I'd max out he wait states
as 286 is faster than 8086/8088 and normally wants faster memory and
IO devices. Also you have two places to set waits, CPU and also the
individual boards, max out the cpu board first. There isnt much on
the system support other than the interrupt controller (make sure the
8259 is the faster A part) that should be unduely sensitive to system
bus timing.

Also use a bus terminator... some cards are more sensitive to bus
ringing than others and despite improved backplanes the S100 bus is
never been super clean.

Allison

no.spam@no.uce.bellatlantic.net wrote:
(snip)

> There isnt much on
> the system support other than the interrupt controller (make sure the
> 8259 is the faster A part) that should be unduely sensitive to system
> bus timing.

I always thought that the 8259A was completely different but
backwards compatible. In 8080 mode it outputs the appropriate
8080 instructions, and in 8086 mode the data needed by the 8086
interrupt logic. The 8259 only does 8080 mode. In addition,
the 8259A might need to be faster. That is, unlike just about
every other Intel part where the letter indicates only speed.

> Also use a bus terminator... some cards are more sensitive to bus
> ringing than others and despite improved backplanes the S100 bus is
> never been super clean.

I used to hear stories about DEC specifying a maximum speed for
bus drivers to reduce crosstalk. I never heard that in regard to
S100 systems.

-- glen

On Wed, 26 Mar 2008 11:21:34 -0800, glen herrmannsfeldt
wrote:

>no.spam@no.uce.bellatlantic.net wrote:
>(snip)
>
>> There isnt much on
>> the system support other than the interrupt controller (make sure the
>> 8259 is the faster A part) that should be unduely sensitive to system
>> bus timing.
>
>I always thought that the 8259A was completely different but
>backwards compatible. In 8080 mode it outputs the appropriate
>8080 instructions, and in 8086 mode the data needed by the 8086
>interrupt logic. The 8259 only does 8080 mode. In addition,
>the 8259A might need to be faster. That is, unlike just about
>every other Intel part where the letter indicates only speed.

No, they are functionally identical. the 59A however has a different
timing spec such that it better fits the 8085A and the 8088/6 which
have the multiplexed bus and a different system timing than 8080.

The 59A is generally a faster part. The 59A came around when the 8085
hit 5mhz and there needed to be a part for the (8mhz) 8088/86 as well.

In intel numbering the suffix letter can indicate anything not always
speed or functionality. Usually it indicates some difference from an
earlier part. In the 8200 family of peripherals the "A" parts are
characterized for 8085/8088/8086 use as they have different bus
timings and are generally much faster than the old 8080. I ,ay add
there are 82xxAH (Hmos faster parts) and A-2 parts (usually a screen
or scaling step for faster operation) to match faster CPU speeds
without IOwaits.

>> Also use a bus terminator... some cards are more sensitive to bus
>> ringing than others and despite improved backplanes the S100 bus is
>> never been super clean.
>
>I used to hear stories about DEC specifying a maximum speed for
>bus drivers to reduce crosstalk. I never heard that in regard to
>S100 systems.

S100 is a fairly sloppy bus and it was not designed well. It suffers
from both crosstalk and ringing though many of the later backplanes
were multilayer and that helped. As to spec for speed I think IEE696
covers that well with the timing and overlap requirements.

As to DEC those were terminated busses and the driver tended to be
characterized for the bus speed and faster drivers tended to exhibit
bothersome faster edges and also lower drive impedances which do
not match the characteristic impedance of the bus. That mismatch
tend to give rise to ringing and overshoot (both positive and
negative). There are other reasons as well but it's a bus that falls
outside this group.

Allison

>-- glen