[N8VEM: 19913] 8088 Breadboard Build

[James Cross]

Hey folks,

I have been trying to get an 8088 working on a breadboard as a means to
learn how it works before attempting to build a Xi 8088. I've been
following along with Grossblatt's *8088 Project Book*. I've attached a
schematic that represents where I am at now. I have a program loaded into
ROM (IC 6) that should blink a single LED in an endless loop. This is the
same as the program in Grossblatt's book and I've verified that the hex
code from my assembler matches what is in the book. Unfortunately, the
behaviour I'm seeing is LEDs light up randomly. The pattern is usually
different each time I turn it on. Sometimes the LEDs are solid and bright,
other times dimmed from subtle flickering.

There are a few differences between the schematic and my build. Mostly it's
substitutions that will let me reuse the parts when I build the Xi 8088.
ICs 3, 4, and 10 have all been replaced with 74ACT573s for simpler wiring
(like the Xi 8088). IC5 is a 74ACT245 rather than an LS part. IC8 is a
74ALS04 rather than a 74LS04. IC9 is a 74ALS00 rather than a 74LS00. I have
also tried taking out the 74ALS00 and using a 74ALS138 with the 74ALS04 to
control all the memory and I/O in a cleaner fashion with no change in
behaviour.

I've checked over my wiring several times. Though that may not mean much in
this rat's nest of wires. I do have a two channel oscilloscope for
debugging and have checked the things that seemed obvious to me but I am
pretty new at this. I did some kit stuff as a kid and have just gotten back
into things by reading Scherz and Monk's *Practical Electronics* and then
starting this project. My only theories left are that maybe my part
substitutions were a bad idea or I'm running into capacitance issues
because this is a breadboard. I think I've bitten off way more than I can
true with this project. Any theories, suggestions, or advice would be
greatly appreciated.

Regards,
James

[James Cross]

Hey folks,

I've been trying to get an 8088 going on a breadboard using Robert
Grossblatt's 8088 Project Book in preparation for building a Xi 8088. The
idea is that if I can work out how an 8088 works on a breadboard, I will
have a much easier time debugging the Xi 8088 if anything goes wrong.

I have gotten as far as trying to blink some LEDs by writing out I/O.
Unfortunately, I'm seeing some pretty random output on the LEDs. Sometimes
they flicker. Sometimes they are solid. Which LEDs are on or off is largely
the random part. The expected behaviour is for a single LED to stay lit.
I've checked and triple checked the wiring (though that's no guarantee
considering the rat's nest this thing is now). I've verified that the hex
code for my ROM program matches that shown in the book. I've even pulled
all the logic chips and tested them using the software that came with my
Minipro programmer.

I've attached the schematic. There are a few differences in my build. I've
used 74ACT573s for IC3, IC4, and IC10 to simplify the wiring. IC6 is
actually an XL28C16A. IC7 is actually a CY7C128A. IC5 is a 74ACT245. IC8 is
a 74ALS04 and IC9 is a 74ALS00. Though at the moment I've tried reducing
the IC8/9 complexity by using a 74ALS138 and the 74ALS04 and no 74ALS00
without any change in behaviour.

Should I not be using ACT and ALS parts for this? Could it be a capacitance
issue with the breadboard? Is there any way to verify that it's a
capacitance issue? I have a two channel oscilloscope that I can check
things with and have already checked what seemed obvious to me but I'm
fairly inexperienced with this stuff, this being my first project that is
even remotely serious. Any theories or troubleshooting recommendations
would be greatly appreciated.

Regards,
James

[James Cross]

Sorry for the double post. On my end, Google Groups seemed to hang after
posting the first one so I tried again.

Post by James Cross
Hey folks,
I have been trying to get an 8088 working on a breadboard as a means to
learn how it works before attempting to build a Xi 8088. I've been
following along with Grossblatt's *8088 Project Book*. I've attached a
schematic that represents where I am at now. I have a program loaded into
ROM (IC 6) that should blink a single LED in an endless loop. This is the
same as the program in Grossblatt's book and I've verified that the hex
code from my assembler matches what is in the book. Unfortunately, the
behaviour I'm seeing is LEDs light up randomly. The pattern is usually
different each time I turn it on. Sometimes the LEDs are solid and bright,
other times dimmed from subtle flickering.
There are a few differences between the schematic and my build. Mostly
it's substitutions that will let me reuse the parts when I build the Xi
8088. ICs 3, 4, and 10 have all been replaced with 74ACT573s for simpler
wiring (like the Xi 8088). IC5 is a 74ACT245 rather than an LS part. IC8 is
a 74ALS04 rather than a 74LS04. IC9 is a 74ALS00 rather than a 74LS00. I
have also tried taking out the 74ALS00 and using a 74ALS138 with the
74ALS04 to control all the memory and I/O in a cleaner fashion with no
change in behaviour.
I've checked over my wiring several times. Though that may not mean much
in this rat's nest of wires. I do have a two channel oscilloscope for
debugging and have checked the things that seemed obvious to me but I am
pretty new at this. I did some kit stuff as a kid and have just gotten back
into things by reading Scherz and Monk's *Practical Electronics* and then
starting this project. My only theories left are that maybe my part
substitutions were a bad idea or I'm running into capacitance issues
because this is a breadboard. I think I've bitten off way more than I can
true with this project. Any theories, suggestions, or advice would be
greatly appreciated.
Regards,
James

[Nikolay Dimitrov]

Hi James,

Post by James Cross
Hey folks,
I have been trying to get an 8088 working on a breadboard as a means to
learn how it works before attempting to build a Xi 8088. I've been
following along with Grossblatt's /8088 Project Book/. I've attached a
schematic that represents where I am at now. I have a program loaded
into ROM (IC 6) that should blink a single LED in an endless loop. This
is the same as the program in Grossblatt's book and I've verified that
the hex code from my assembler matches what is in the book.
Unfortunately, the behaviour I'm seeing is LEDs light up randomly. The
pattern is usually different each time I turn it on. Sometimes the LEDs
are solid and bright, other times dimmed from subtle flickering.
There are a few differences between the schematic and my build. Mostly
it's substitutions that will let me reuse the parts when I build the Xi
8088. ICs 3, 4, and 10 have all been replaced with 74ACT573s for simpler
wiring (like the Xi 8088). IC5 is a 74ACT245 rather than an LS part. IC8
is a 74ALS04 rather than a 74LS04. IC9 is a 74ALS00 rather than a
74LS00. I have also tried taking out the 74ALS00 and using a 74ALS138
with the 74ALS04 to control all the memory and I/O in a cleaner fashion
with no change in behaviour.
I've checked over my wiring several times. Though that may not mean much
in this rat's nest of wires. I do have a two channel oscilloscope for
debugging and have checked the things that seemed obvious to me but I am
pretty new at this. I did some kit stuff as a kid and have just gotten
back into things by reading Scherz and Monk's /Practical Electronics/
and then starting this project. My only theories left are that maybe my
part substitutions were a bad idea or I'm running into capacitance
issues because this is a breadboard. I think I've bitten off way more
than I can true with this project. Any theories, suggestions, or advice
would be greatly appreciated.

Is it possible to reduce the clock to a much lower frequency, like <=
1MHz and check if it affects the stability of your prototype?

Regards,
Nikolay

[James Cross]

That's a great idea. I don't have anything slower on hand to try. But I've
ordered some 2MHz crystals which should knock the circuit down to 666KHz. I
will try one when they arrive.

Post by Nikolay Dimitrov
Hi James,

Post by James Cross
Hey folks,
I have been trying to get an 8088 working on a breadboard as a means to
learn how it works before attempting to build a Xi 8088. I've been
following along with Grossblatt's /8088 Project Book/. I've attached a
schematic that represents where I am at now. I have a program loaded
into ROM (IC 6) that should blink a single LED in an endless loop. This
is the same as the program in Grossblatt's book and I've verified that
the hex code from my assembler matches what is in the book.
Unfortunately, the behaviour I'm seeing is LEDs light up randomly. The
pattern is usually different each time I turn it on. Sometimes the LEDs
are solid and bright, other times dimmed from subtle flickering.
There are a few differences between the schematic and my build. Mostly
it's substitutions that will let me reuse the parts when I build the Xi
8088. ICs 3, 4, and 10 have all been replaced with 74ACT573s for simpler
wiring (like the Xi 8088). IC5 is a 74ACT245 rather than an LS part. IC8
is a 74ALS04 rather than a 74LS04. IC9 is a 74ALS00 rather than a
74LS00. I have also tried taking out the 74ALS00 and using a 74ALS138
with the 74ALS04 to control all the memory and I/O in a cleaner fashion
with no change in behaviour.
I've checked over my wiring several times. Though that may not mean much
in this rat's nest of wires. I do have a two channel oscilloscope for
debugging and have checked the things that seemed obvious to me but I am
pretty new at this. I did some kit stuff as a kid and have just gotten
back into things by reading Scherz and Monk's /Practical Electronics/
and then starting this project. My only theories left are that maybe my
part substitutions were a bad idea or I'm running into capacitance
issues because this is a breadboard. I think I've bitten off way more
than I can true with this project. Any theories, suggestions, or advice
would be greatly appreciated.

Is it possible to reduce the clock to a much lower frequency, like <=
1MHz and check if it affects the stability of your prototype?
Regards,
Nikolay

[Nikolay Dimitrov]

Hi James,

Post by James Cross
That's a great idea. I don't have anything slower on hand to try. But
I've ordered some 2MHz crystals which should knock the circuit down to
666KHz. I will try one when they arrive.

You can implement a very simple RC oscillator with TTL or CMOS logic
elements, which can oscillate from several Hz (nice to watch the
blinkenlights) up to more than several MHz.

Regards,
Nikolay

[James Cross]

You mean something like the attached schematic? I think my spare 74ALS04
could work as those two inverters. I'll give it a try. My spare parts
outside of capacitors and resistors are almost non-existent.

Post by Nikolay Dimitrov
Hi James,

Post by James Cross
That's a great idea. I don't have anything slower on hand to try. But
I've ordered some 2MHz crystals which should knock the circuit down to
666KHz. I will try one when they arrive.

You can implement a very simple RC oscillator with TTL or CMOS logic
elements, which can oscillate from several Hz (nice to watch the
blinkenlights) up to more than several MHz.
Regards,
Nikolay

[Nikolay Dimitrov]

Hi James,

Post by James Cross
You mean something like the attached schematic? I think my spare 74ALS04
could work as those two inverters. I'll give it a try. My spare parts
outside of capacitors and resistors are almost non-existent.

Yep. Also, here are some ideas and explanations about such oscillators,
if you're interested:

http://www.talkingelectronics.com/pay/BEC-2/Page49.html

Regards,
Nikolay

[James Cross]

Trying a 2MHz crystal didn't work as expected. The 8284A's CLK output
seemed to bounce around between 17MHz and 20MHz! That's pretty bizarre
since CLK is supposed to have a frequency 1/3rd that of the input crystal.
I suspect it has a minimum input frequency. I should have an assortment of
crystals showing up on Monday that I will try.

I didn't have much luck getting the 74ALS04 to output a reliable pulse at
high speeds.

Post by Nikolay Dimitrov
Hi James,

Post by James Cross
Hey folks,
I have been trying to get an 8088 working on a breadboard as a means to
learn how it works before attempting to build a Xi 8088. I've been
following along with Grossblatt's /8088 Project Book/. I've attached a
schematic that represents where I am at now. I have a program loaded
into ROM (IC 6) that should blink a single LED in an endless loop. This
is the same as the program in Grossblatt's book and I've verified that
the hex code from my assembler matches what is in the book.
Unfortunately, the behaviour I'm seeing is LEDs light up randomly. The
pattern is usually different each time I turn it on. Sometimes the LEDs
are solid and bright, other times dimmed from subtle flickering.
There are a few differences between the schematic and my build. Mostly
it's substitutions that will let me reuse the parts when I build the Xi
8088. ICs 3, 4, and 10 have all been replaced with 74ACT573s for simpler
wiring (like the Xi 8088). IC5 is a 74ACT245 rather than an LS part. IC8
is a 74ALS04 rather than a 74LS04. IC9 is a 74ALS00 rather than a
74LS00. I have also tried taking out the 74ALS00 and using a 74ALS138
with the 74ALS04 to control all the memory and I/O in a cleaner fashion
with no change in behaviour.
I've checked over my wiring several times. Though that may not mean much
in this rat's nest of wires. I do have a two channel oscilloscope for
debugging and have checked the things that seemed obvious to me but I am
pretty new at this. I did some kit stuff as a kid and have just gotten
back into things by reading Scherz and Monk's /Practical Electronics/
and then starting this project. My only theories left are that maybe my
part substitutions were a bad idea or I'm running into capacitance
issues because this is a breadboard. I think I've bitten off way more
than I can true with this project. Any theories, suggestions, or advice
would be greatly appreciated.

Is it possible to reduce the clock to a much lower frequency, like <=
1MHz and check if it affects the stability of your prototype?
Regards,
Nikolay

[Sergey]

If your oscilloscope can do 5 MHz or so, you can try observing the
following signals:
CLK - make sure you get a clean 4.77MHz (oscillator frequency divide by 3)
ALE - should be pulsing, each time the CPU outputs an address (instruction
fetch, I/O or memory operation).
/RD - should be pulsing
A0/A1 (outputs of IC3) - should be pulsing
/CS on ROM and RAM chips, and LE on IC10 - they also should be pulsing

Several other tips:
- Make sure you have a stable 5V power supply providing enough power (I
guess 500mA would be enough for this circuit)
- Use 0.1uF decoupling capacitors for each IC. Connect them as close as
possible to the VCC and GND pins.
- Use additional 10uF or more capacitor on power.
- NMOS 8088 uses some dynamic logic, and it requires a clock frequency of
at least 2MHz (use CMOS 80C88, or V20 for static design)
- 8088 has two grounds, it is needed to connect both (as far as I
remember)... schematics shows it, but worth checking anyway.
- The resonator based oscillator circuit might be somewhat unstable,
especially if built on a breadboard. You can use an oscillator in a DIP
package instead... Connect it to the EFI input 8284 and connect F/C pin to
VCC. The oscillator frequency must be three times more than desired CPU
frequency.

Thanks,
Sergey

Post by James Cross
Hey folks,
I have been trying to get an 8088 working on a breadboard as a means to
learn how it works before attempting to build a Xi 8088. I've been
following along with Grossblatt's *8088 Project Book*. I've attached a
schematic that represents where I am at now. I have a program loaded into
ROM (IC 6) that should blink a single LED in an endless loop. This is the
same as the program in Grossblatt's book and I've verified that the hex
code from my assembler matches what is in the book. Unfortunately, the
behaviour I'm seeing is LEDs light up randomly. The pattern is usually
different each time I turn it on. Sometimes the LEDs are solid and bright,
other times dimmed from subtle flickering.
There are a few differences between the schematic and my build. Mostly
it's substitutions that will let me reuse the parts when I build the Xi
8088. ICs 3, 4, and 10 have all been replaced with 74ACT573s for simpler
wiring (like the Xi 8088). IC5 is a 74ACT245 rather than an LS part. IC8 is
a 74ALS04 rather than a 74LS04. IC9 is a 74ALS00 rather than a 74LS00. I
have also tried taking out the 74ALS00 and using a 74ALS138 with the
74ALS04 to control all the memory and I/O in a cleaner fashion with no
change in behaviour.
I've checked over my wiring several times. Though that may not mean much
in this rat's nest of wires. I do have a two channel oscilloscope for
debugging and have checked the things that seemed obvious to me but I am
pretty new at this. I did some kit stuff as a kid and have just gotten back
into things by reading Scherz and Monk's *Practical Electronics* and then
starting this project. My only theories left are that maybe my part
substitutions were a bad idea or I'm running into capacitance issues
because this is a breadboard. I think I've bitten off way more than I can
true with this project. Any theories, suggestions, or advice would be
greatly appreciated.
Regards,
James

[James Cross]

Responses are inline. This is a really extensive list. Thanks!

Post by Sergey
If your oscilloscope can do 5 MHz or so, you can try observing the
CLK - make sure you get a clean 4.77MHz (oscillator frequency divide by 3)

This looks okay. There's a bit of a dip in the peak of CLK but it's not
huge. And it's a stable 4.77185MHz, according to the scope.

ALE - should be pulsing, each time the CPU outputs an address (instruction

Post by Sergey
fetch, I/O or memory operation).

This definitely pulses.

/RD - should be pulsing
This definitely pulses.

A0/A1 (outputs of IC3) - should be pulsing
These definitely pulse.

/CS on ROM and RAM chips, and LE on IC10 - they also should be pulsing
For /CS, it looks like I get pulses on RAM and ROM but the voltage on the
ROM line only goes up to 4V. I don't know where that loss is coming from
since the system's voltage is at 5.1V.

Post by Sergey
- Make sure you have a stable 5V power supply providing enough power (I
guess 500mA would be enough for this circuit)

In theory my bench power supply should be good up to 2A. It reads between
200mA and 350mA, largely depending on how the LEDs get stuck on.

- Use 0.1uF decoupling capacitors for each IC. Connect them as close as

Post by Sergey
possible to the VCC and GND pins.

I have my decoupling capacitors one hole away from the VCC pins on each IC.
The other end goes to the common ground bus. Should they be jumping across
to the ground pins on each IC?

- Use additional 10uF or more capacitor on power.
Just between VCC and ground?

- NMOS 8088 uses some dynamic logic, and it requires a clock frequency of

Post by Sergey
at least 2MHz (use CMOS 80C88, or V20 for static design)

I am actually using a NEC V20 since that's what you recommend in the Xi
8088 BOM.

Post by Sergey
- 8088 has two grounds, it is needed to connect both (as far as I
remember)... schematics shows it, but worth checking anyway.

I checked these. They are both connected.

Post by Sergey
- The resonator based oscillator circuit might be somewhat unstable,
especially if built on a breadboard. You can use an oscillator in a DIP
package instead... Connect it to the EFI input 8284 and connect F/C pin to
VCC. The oscillator frequency must be three times more than desired CPU
frequency.

I haven't ever dealt with any other clock generating chips besides the
8284A. Is there any chip or line of chips you'd recommend I look at for
generating something to feed into EFI?

Post by Sergey
Thanks,
Sergey

Post by James Cross
Hey folks,
I have been trying to get an 8088 working on a breadboard as a means to
learn how it works before attempting to build a Xi 8088. I've been
following along with Grossblatt's *8088 Project Book*. I've attached a
schematic that represents where I am at now. I have a program loaded into
ROM (IC 6) that should blink a single LED in an endless loop. This is the
same as the program in Grossblatt's book and I've verified that the hex
code from my assembler matches what is in the book. Unfortunately, the
behaviour I'm seeing is LEDs light up randomly. The pattern is usually
different each time I turn it on. Sometimes the LEDs are solid and bright,
other times dimmed from subtle flickering.
There are a few differences between the schematic and my build. Mostly
it's substitutions that will let me reuse the parts when I build the Xi
8088. ICs 3, 4, and 10 have all been replaced with 74ACT573s for simpler
wiring (like the Xi 8088). IC5 is a 74ACT245 rather than an LS part. IC8 is
a 74ALS04 rather than a 74LS04. IC9 is a 74ALS00 rather than a 74LS00. I
have also tried taking out the 74ALS00 and using a 74ALS138 with the
74ALS04 to control all the memory and I/O in a cleaner fashion with no
change in behaviour.
I've checked over my wiring several times. Though that may not mean much
in this rat's nest of wires. I do have a two channel oscilloscope for
debugging and have checked the things that seemed obvious to me but I am
pretty new at this. I did some kit stuff as a kid and have just gotten back
into things by reading Scherz and Monk's *Practical Electronics* and
then starting this project. My only theories left are that maybe my part
substitutions were a bad idea or I'm running into capacitance issues
because this is a breadboard. I think I've bitten off way more than I can
true with this project. Any theories, suggestions, or advice would be
greatly appreciated.
Regards,
James

[James Cross]

One thing I forgot: LE is NOT pulsing.

Also, I've attached a screenshot of the crystal clock compared to the
8284A's CLK output from my scope. It looks a little noisy but I don't have
anything to really compare it to.

Post by James Cross
Responses are inline. This is a really extensive list. Thanks!

Post by Sergey
If your oscilloscope can do 5 MHz or so, you can try observing the
CLK - make sure you get a clean 4.77MHz (oscillator frequency divide by 3)

This looks okay. There's a bit of a dip in the peak of CLK but it's not
huge. And it's a stable 4.77185MHz, according to the scope.
ALE - should be pulsing, each time the CPU outputs an address (instruction

Post by Sergey
fetch, I/O or memory operation).

This definitely pulses.
/RD - should be pulsing
This definitely pulses.
A0/A1 (outputs of IC3) - should be pulsing
These definitely pulse.
/CS on ROM and RAM chips, and LE on IC10 - they also should be pulsing
For /CS, it looks like I get pulses on RAM and ROM but the voltage on the
ROM line only goes up to 4V. I don't know where that loss is coming from
since the system's voltage is at 5.1V.

Post by Sergey
- Make sure you have a stable 5V power supply providing enough power (I
guess 500mA would be enough for this circuit)

In theory my bench power supply should be good up to 2A. It reads between
200mA and 350mA, largely depending on how the LEDs get stuck on.
- Use 0.1uF decoupling capacitors for each IC. Connect them as close as

Post by Sergey
possible to the VCC and GND pins.

I have my decoupling capacitors one hole away from the VCC pins on each
IC. The other end goes to the common ground bus. Should they be jumping
across to the ground pins on each IC?
- Use additional 10uF or more capacitor on power.
Just between VCC and ground?
- NMOS 8088 uses some dynamic logic, and it requires a clock frequency of

Post by Sergey
at least 2MHz (use CMOS 80C88, or V20 for static design)

I am actually using a NEC V20 since that's what you recommend in the Xi
8088 BOM.

Post by Sergey
- 8088 has two grounds, it is needed to connect both (as far as I
remember)... schematics shows it, but worth checking anyway.

I checked these. They are both connected.

Post by Sergey
- The resonator based oscillator circuit might be somewhat unstable,
especially if built on a breadboard. You can use an oscillator in a DIP
package instead... Connect it to the EFI input 8284 and connect F/C pin to
VCC. The oscillator frequency must be three times more than desired CPU
frequency.

I haven't ever dealt with any other clock generating chips besides the
8284A. Is there any chip or line of chips you'd recommend I look at for
generating something to feed into EFI?

Post by Sergey
Thanks,
Sergey

Post by James Cross
Hey folks,
I have been trying to get an 8088 working on a breadboard as a means to
learn how it works before attempting to build a Xi 8088. I've been
following along with Grossblatt's *8088 Project Book*. I've attached a
schematic that represents where I am at now. I have a program loaded into
ROM (IC 6) that should blink a single LED in an endless loop. This is the
same as the program in Grossblatt's book and I've verified that the hex
code from my assembler matches what is in the book. Unfortunately, the
behaviour I'm seeing is LEDs light up randomly. The pattern is usually
different each time I turn it on. Sometimes the LEDs are solid and bright,
other times dimmed from subtle flickering.
There are a few differences between the schematic and my build. Mostly
it's substitutions that will let me reuse the parts when I build the Xi
8088. ICs 3, 4, and 10 have all been replaced with 74ACT573s for simpler
wiring (like the Xi 8088). IC5 is a 74ACT245 rather than an LS part. IC8 is
a 74ALS04 rather than a 74LS04. IC9 is a 74ALS00 rather than a 74LS00. I
have also tried taking out the 74ALS00 and using a 74ALS138 with the
74ALS04 to control all the memory and I/O in a cleaner fashion with no
change in behaviour.
I've checked over my wiring several times. Though that may not mean much
in this rat's nest of wires. I do have a two channel oscilloscope for
debugging and have checked the things that seemed obvious to me but I am
pretty new at this. I did some kit stuff as a kid and have just gotten back
into things by reading Scherz and Monk's *Practical Electronics* and
then starting this project. My only theories left are that maybe my part
substitutions were a bad idea or I'm running into capacitance issues
because this is a breadboard. I think I've bitten off way more than I can
true with this project. Any theories, suggestions, or advice would be
greatly appreciated.
Regards,
James

[James Cross]

I did some additional poking around today and have discovered some more
mysteries. LE on IC10 does actually pulse sometimes. When it does, it
matches a pulse from IO/M. However, other times I see 4V spikes or so on
the line that don't correspond with anything from IO/M. I assume this noise
is what allows flicker to happen when IO/M isn't doing anything.

The other mystery is that I have reread the contents of my ROM. My program
had been overwritten with 16 bytes of 0xFF. 16 bytes of 0xFF were also
found elsewhere on the ROM, all aligned with addresses ending in 0. After
rewriting the ROM, I've discovered that after a few restarts of my 8088
system I will see the 0xFFs end up on the ROM in different places but
always aligned and always in batches of 16 bytes. This should be impossible
since /WE on the ROM is directly tied high on my board. So I hooked the
oscilloscope up to /WE pin and sure enough I sometimes get sudden huge
ripples between 3V and 7V or so. It seems to happen when the random system
behavior results in all the LEDs going solid. That's straight from the
power bus and I'm guessing every other chip is seeing that too. Am I
correct in assuming that this is a sign that my cheapish Tekpower TP1502D
isn't suitable for this system?

Post by James Cross
One thing I forgot: LE is NOT pulsing.
Also, I've attached a screenshot of the crystal clock compared to the
8284A's CLK output from my scope. It looks a little noisy but I don't have
anything to really compare it to.

Post by James Cross
Responses are inline. This is a really extensive list. Thanks!

Post by Sergey
If your oscilloscope can do 5 MHz or so, you can try observing the
CLK - make sure you get a clean 4.77MHz (oscillator frequency divide by 3)

This looks okay. There's a bit of a dip in the peak of CLK but it's not
huge. And it's a stable 4.77185MHz, according to the scope.
ALE - should be pulsing, each time the CPU outputs an address

Post by Sergey
(instruction fetch, I/O or memory operation).

This definitely pulses.
/RD - should be pulsing
This definitely pulses.
A0/A1 (outputs of IC3) - should be pulsing
These definitely pulse.
/CS on ROM and RAM chips, and LE on IC10 - they also should be pulsing
For /CS, it looks like I get pulses on RAM and ROM but the voltage on the
ROM line only goes up to 4V. I don't know where that loss is coming from
since the system's voltage is at 5.1V.

Post by Sergey
- Make sure you have a stable 5V power supply providing enough power (I
guess 500mA would be enough for this circuit)

In theory my bench power supply should be good up to 2A. It reads between
200mA and 350mA, largely depending on how the LEDs get stuck on.
- Use 0.1uF decoupling capacitors for each IC. Connect them as close as

Post by Sergey
possible to the VCC and GND pins.

I have my decoupling capacitors one hole away from the VCC pins on each
IC. The other end goes to the common ground bus. Should they be jumping
across to the ground pins on each IC?
- Use additional 10uF or more capacitor on power.
Just between VCC and ground?
- NMOS 8088 uses some dynamic logic, and it requires a clock frequency of

Post by Sergey
at least 2MHz (use CMOS 80C88, or V20 for static design)

I am actually using a NEC V20 since that's what you recommend in the Xi
8088 BOM.

Post by Sergey
- 8088 has two grounds, it is needed to connect both (as far as I
remember)... schematics shows it, but worth checking anyway.

I checked these. They are both connected.

Post by Sergey
- The resonator based oscillator circuit might be somewhat unstable,
especially if built on a breadboard. You can use an oscillator in a DIP
package instead... Connect it to the EFI input 8284 and connect F/C pin to
VCC. The oscillator frequency must be three times more than desired CPU
frequency.

I haven't ever dealt with any other clock generating chips besides the
8284A. Is there any chip or line of chips you'd recommend I look at for
generating something to feed into EFI?

Post by Sergey
Thanks,
Sergey

Post by James Cross
Hey folks,
I have been trying to get an 8088 working on a breadboard as a means to
learn how it works before attempting to build a Xi 8088. I've been
following along with Grossblatt's *8088 Project Book*. I've attached a
schematic that represents where I am at now. I have a program loaded into
ROM (IC 6) that should blink a single LED in an endless loop. This is the
same as the program in Grossblatt's book and I've verified that the hex
code from my assembler matches what is in the book. Unfortunately, the
behaviour I'm seeing is LEDs light up randomly. The pattern is usually
different each time I turn it on. Sometimes the LEDs are solid and bright,
other times dimmed from subtle flickering.
There are a few differences between the schematic and my build. Mostly
it's substitutions that will let me reuse the parts when I build the Xi
8088. ICs 3, 4, and 10 have all been replaced with 74ACT573s for simpler
wiring (like the Xi 8088). IC5 is a 74ACT245 rather than an LS part. IC8 is
a 74ALS04 rather than a 74LS04. IC9 is a 74ALS00 rather than a 74LS00. I
have also tried taking out the 74ALS00 and using a 74ALS138 with the
74ALS04 to control all the memory and I/O in a cleaner fashion with no
change in behaviour.
I've checked over my wiring several times. Though that may not mean
much in this rat's nest of wires. I do have a two channel oscilloscope for
debugging and have checked the things that seemed obvious to me but I am
pretty new at this. I did some kit stuff as a kid and have just gotten back
into things by reading Scherz and Monk's *Practical Electronics* and
then starting this project. My only theories left are that maybe my part
substitutions were a bad idea or I'm running into capacitance issues
because this is a breadboard. I think I've bitten off way more than I can
true with this project. Any theories, suggestions, or advice would be
greatly appreciated.
Regards,
James

[Nikolay Dimitrov]

Hi James,

Post by James Cross
That's
straight from the power bus and I'm guessing every other chip is seeing
that too. Am I correct in assuming that this is a sign that my cheapish
Tekpower TP1502D isn't suitable for this system?

That's definitely not cool. Please try with another 5V power supply,
you can even try to get 5V from your PC's USB port (all USB ports
should deliver at least 500mA). Hope this will bring cleaner (aka
non-glitched) power to the ICs.

Regards,
Nikolay

[James Cross]

Okay, I tried it with a good Mastech power supply. That solved the ROM
writing problem. It did not fix the overall problem, however.

I tried moving it to a new breadboard and making wires as short as
possible. Previously I used pre-made jumper wires that left me with a lot
of slack. It still didn't fix the problem but it has made wiring much
easier to inspect and there seems to be less noise now.

I do have a new mystery. I was snooping around the address/data pins. The
pins which are strictly for addresses all seem fine. However, the eight
pins that double as both address and data have some interesting noise on
them in the first few cycles after power on. Some very artificial-looking
oscillations show up. What's strange is that the bursts seem to all occur
at a few pretty stable frequencies. A regular 20MHz or 26.32MHz are the two
most common. That's way too fast for the 8088 itself to be generating it.
Further, running the 8088 at 4.77MHz or 2 MHz does not change the frequency
of this noise. Those eight pins are each hooked up to two 74ACT573s and a
74ACT254. Those chips could certainly do things at higher frequencies than
the 8088. And it looks like this noise is showing up immediately after /DEN
goes low. DT/R is low during this time as well. So the 8088 seems to be
expecting to read something at these times and is getting high frequency
oscillations instead of solid bits. I'll try snooping around on the other
side of the 74ACT254 tomorrow. I'm too tired to keep going. Any theories
here, folks?

At least it has been an educational failure so far.

Post by Nikolay Dimitrov
Hi James,

Post by James Cross
That's
straight from the power bus and I'm guessing every other chip is seeing
that too. Am I correct in assuming that this is a sign that my cheapish
Tekpower TP1502D isn't suitable for this system?

That's definitely not cool. Please try with another 5V power supply,
you can even try to get 5V from your PC's USB port (all USB ports
should deliver at least 500mA). Hope this will bring cleaner (aka
non-glitched) power to the ICs.
Regards,
Nikolay

[Nikolay Dimitrov]

Hi James,

Post by James Cross
Okay, I tried it with a good Mastech power supply. That solved the ROM
writing problem. It did not fix the overall problem, however.
I tried moving it to a new breadboard and making wires as short as
possible. Previously I used pre-made jumper wires that left me with a
lot of slack. It still didn't fix the problem but it has made wiring
much easier to inspect and there seems to be less noise now.
I do have a new mystery. I was snooping around the address/data pins.
The pins which are strictly for addresses all seem fine. However, the
eight pins that double as both address and data have some interesting
noise on them in the first few cycles after power on. Some very
artificial-looking oscillations show up. What's strange is that the
bursts seem to all occur at a few pretty stable frequencies. A regular
20MHz or 26.32MHz are the two most common. That's way too fast for the
8088 itself to be generating it. Further, running the 8088 at 4.77MHz or
2 MHz does not change the frequency of this noise. Those eight pins are
each hooked up to two 74ACT573s and a 74ACT254. Those chips could
certainly do things at higher frequencies than the 8088. And it looks
like this noise is showing up immediately after /DEN goes low. DT/R is
low during this time as well. So the 8088 seems to be expecting to read
something at these times and is getting high frequency oscillations
instead of solid bits. I'll try snooping around on the other side of the
74ACT254 tomorrow. I'm too tired to keep going. Any theories here, folks?
At least it has been an educational failure so far.

What you should be looking instead is not the circuit behavior after
power-on, but after RESET signal is de-asserted. This is where the
defined circuit behavior starts.

Please check your reset circuit. It should deliver a clean reset pulse,
without any oscillations, with fast edges and long enough duration (as
per CPU datasheet).

One more idea - I'm not sure whether this exact CPU has one-phase or
multi-phase clock, but it's worth to check whether the clock duty cycle
is OK, and also multiple clock phases are properly aligned (if
available).

Also, you can replace the ROM with pull-up/pull-down resistors to form
the NOP opcode (0x90). This way the CPU will start incrementing the
address lines, and the frequencies of each 2 consequent address lines
will be 2x different, so you can easily check it.

Regards,
Nikolay

[James Cross]

Sorry, I was a little imprecise. When I said "after power on", I meant
after hitting the reset button.

The reset signal going to the 8088 is an extremely crisp pulse that is
always at least 100ms. The 8088 itself only needs a signal of 50us. So I
think the reset signal is sufficient by a good margin.

The clock signal going to the 8088 is a constant 2MHz (using my 6MHz
crystal) at 34.8% duty cycle. It seems quite stable. Though the duty cycle
should be 33%. I am not sure if that extra 1.8% is just imprecision of the
scope or not.

Trying to fake a ROM full of NOPs will take longer. I'll have to get back
to you on that one. Though I could just fill the ROM with actual NOPs
unless the idea is to try to pinpoint the ROM as the problem.

Post by Nikolay Dimitrov
Hi James,

Post by James Cross
Okay, I tried it with a good Mastech power supply. That solved the ROM
writing problem. It did not fix the overall problem, however.
I tried moving it to a new breadboard and making wires as short as
possible. Previously I used pre-made jumper wires that left me with a
lot of slack. It still didn't fix the problem but it has made wiring
much easier to inspect and there seems to be less noise now.
I do have a new mystery. I was snooping around the address/data pins.
The pins which are strictly for addresses all seem fine. However, the
eight pins that double as both address and data have some interesting
noise on them in the first few cycles after power on. Some very
artificial-looking oscillations show up. What's strange is that the
bursts seem to all occur at a few pretty stable frequencies. A regular
20MHz or 26.32MHz are the two most common. That's way too fast for the
8088 itself to be generating it. Further, running the 8088 at 4.77MHz or
2 MHz does not change the frequency of this noise. Those eight pins are
each hooked up to two 74ACT573s and a 74ACT254. Those chips could
certainly do things at higher frequencies than the 8088. And it looks
like this noise is showing up immediately after /DEN goes low. DT/R is
low during this time as well. So the 8088 seems to be expecting to read
something at these times and is getting high frequency oscillations
instead of solid bits. I'll try snooping around on the other side of the
74ACT254 tomorrow. I'm too tired to keep going. Any theories here,

folks?

Post by James Cross
At least it has been an educational failure so far.

What you should be looking instead is not the circuit behavior after
power-on, but after RESET signal is de-asserted. This is where the
defined circuit behavior starts.
Please check your reset circuit. It should deliver a clean reset pulse,
without any oscillations, with fast edges and long enough duration (as
per CPU datasheet).
One more idea - I'm not sure whether this exact CPU has one-phase or
multi-phase clock, but it's worth to check whether the clock duty cycle
is OK, and also multiple clock phases are properly aligned (if
available).
Also, you can replace the ROM with pull-up/pull-down resistors to form
the NOP opcode (0x90). This way the CPU will start incrementing the
address lines, and the frequencies of each 2 consequent address lines
will be 2x different, so you can easily check it.
Regards,
Nikolay

[James Cross]

For clarification, here's a screenshot of what I'm seeing on AD0 just after
reset goes low. Yellow is the reset and blue is AD0.

Post by Nikolay Dimitrov
Hi James,

Post by James Cross
Okay, I tried it with a good Mastech power supply. That solved the ROM
writing problem. It did not fix the overall problem, however.
I tried moving it to a new breadboard and making wires as short as
possible. Previously I used pre-made jumper wires that left me with a
lot of slack. It still didn't fix the problem but it has made wiring
much easier to inspect and there seems to be less noise now.
I do have a new mystery. I was snooping around the address/data pins.
The pins which are strictly for addresses all seem fine. However, the
eight pins that double as both address and data have some interesting
noise on them in the first few cycles after power on. Some very
artificial-looking oscillations show up. What's strange is that the
bursts seem to all occur at a few pretty stable frequencies. A regular
20MHz or 26.32MHz are the two most common. That's way too fast for the
8088 itself to be generating it. Further, running the 8088 at 4.77MHz or
2 MHz does not change the frequency of this noise. Those eight pins are
each hooked up to two 74ACT573s and a 74ACT254. Those chips could
certainly do things at higher frequencies than the 8088. And it looks
like this noise is showing up immediately after /DEN goes low. DT/R is
low during this time as well. So the 8088 seems to be expecting to read
something at these times and is getting high frequency oscillations
instead of solid bits. I'll try snooping around on the other side of the
74ACT254 tomorrow. I'm too tired to keep going. Any theories here,

folks?

Post by James Cross
At least it has been an educational failure so far.

What you should be looking instead is not the circuit behavior after
power-on, but after RESET signal is de-asserted. This is where the
defined circuit behavior starts.
Please check your reset circuit. It should deliver a clean reset pulse,
without any oscillations, with fast edges and long enough duration (as
per CPU datasheet).
One more idea - I'm not sure whether this exact CPU has one-phase or
multi-phase clock, but it's worth to check whether the clock duty cycle
is OK, and also multiple clock phases are properly aligned (if
available).
Also, you can replace the ROM with pull-up/pull-down resistors to form
the NOP opcode (0x90). This way the CPU will start incrementing the
address lines, and the frequencies of each 2 consequent address lines
will be 2x different, so you can easily check it.
Regards,
Nikolay

[James Cross]

I've narrowed things down a little more. IC4 (a 74ACT573) manages to latch
some sane values by the look things. But everything directly connected on
either side to IC5 (a 74ACT245) is really bad. I have extra 245s but
swapping them out doesn't seem to change anything. My AD0 screenshot from
the last e-mail is the same line that goes to IC5's A0. This one shows
IC5's Q0 which is also the ROM and RAM's I/O 0 and IC10's D0. I'm just not
sure what could be causing this. Is it possible that the '245 can't drive
this many chips and is behaving erratically as a response?

Post by Nikolay Dimitrov
Hi James,

Post by James Cross
Okay, I tried it with a good Mastech power supply. That solved the ROM
writing problem. It did not fix the overall problem, however.
I tried moving it to a new breadboard and making wires as short as
possible. Previously I used pre-made jumper wires that left me with a
lot of slack. It still didn't fix the problem but it has made wiring
much easier to inspect and there seems to be less noise now.
I do have a new mystery. I was snooping around the address/data pins.
The pins which are strictly for addresses all seem fine. However, the
eight pins that double as both address and data have some interesting
noise on them in the first few cycles after power on. Some very
artificial-looking oscillations show up. What's strange is that the
bursts seem to all occur at a few pretty stable frequencies. A regular
20MHz or 26.32MHz are the two most common. That's way too fast for the
8088 itself to be generating it. Further, running the 8088 at 4.77MHz or
2 MHz does not change the frequency of this noise. Those eight pins are
each hooked up to two 74ACT573s and a 74ACT254. Those chips could
certainly do things at higher frequencies than the 8088. And it looks
like this noise is showing up immediately after /DEN goes low. DT/R is
low during this time as well. So the 8088 seems to be expecting to read
something at these times and is getting high frequency oscillations
instead of solid bits. I'll try snooping around on the other side of the
74ACT254 tomorrow. I'm too tired to keep going. Any theories here,

folks?

Post by James Cross
At least it has been an educational failure so far.

What you should be looking instead is not the circuit behavior after
power-on, but after RESET signal is de-asserted. This is where the
defined circuit behavior starts.
Please check your reset circuit. It should deliver a clean reset pulse,
without any oscillations, with fast edges and long enough duration (as
per CPU datasheet).
One more idea - I'm not sure whether this exact CPU has one-phase or
multi-phase clock, but it's worth to check whether the clock duty cycle
is OK, and also multiple clock phases are properly aligned (if
available).
Also, you can replace the ROM with pull-up/pull-down resistors to form
the NOP opcode (0x90). This way the CPU will start incrementing the
address lines, and the frequencies of each 2 consequent address lines
will be 2x different, so you can easily check it.
Regards,
Nikolay

['Bob Grieb' via N8VEM]

If you are using a crystal much lower than expected, you may
have to increase the small caps otherwise you may get an overtone
instead of the fundamental of the crystal.

Another way to do it is to put a resistor in series with the output of the
chip, between it and the cap and the crystal. Start with something small,
like 100 ohms, and go up as needed.

Bob Grieb


--------------------------------------------
On Sat, 8/1/15, James Cross <***@gmail.com> wrote:

Subject: Re: [N8VEM: 19924] 8088 Breadboard Build
To: "N8VEM" <***@googlegroups.com>
Cc: ***@gmail.com
Date: Saturday, August 1, 2015, 5:37 PM

Trying a 2MHz crystal
didn't work as expected. The 8284A's CLK output
seemed to bounce around between 17MHz and 20MHz! That's
pretty bizarre since CLK is supposed to have a frequency
1/3rd that of the input crystal. I suspect it has a minimum
input frequency. I should have an assortment of crystals
showing up on Monday that I will try.

I didn't have much luck getting the 74ALS04 to output a
reliable pulse at high speeds.

On Wednesday, July 29, 2015 at 9:21:18 AM UTC-4, picmaster
wrote:Hi James,

Post by James Cross
Hey folks,
I have been trying to get an 8088 working on a

breadboard as a means to

Post by James Cross
learn how it works before attempting to build a Xi

8088. I've been

Post by James Cross
following along with Grossblatt's /8088 Project

Book/. I've attached a

Post by James Cross
schematic that represents where I am at now. I have a

program loaded

Post by James Cross
into ROM (IC 6) that should blink a single LED in an

endless loop. This

Post by James Cross
is the same as the program in Grossblatt's book and

I've verified that

Post by James Cross
the hex code from my assembler matches what is in the

book.

Post by James Cross
Unfortunately, the behaviour I'm seeing is LEDs

light up randomly. The

Post by James Cross
pattern is usually different each time I turn it on.

Sometimes the LEDs

Post by James Cross
are solid and bright, other times dimmed from subtle

flickering.

Post by James Cross
There are a few differences between the schematic and

my build. Mostly

Post by James Cross
it's substitutions that will let me reuse the parts

when I build the Xi

Post by James Cross
8088. ICs 3, 4, and 10 have all been replaced with

74ACT573s for simpler

Post by James Cross
wiring (like the Xi 8088). IC5 is a 74ACT245 rather

than an LS part. IC8

Post by James Cross
is a 74ALS04 rather than a 74LS04. IC9 is a 74ALS00

rather than a

Post by James Cross
74LS00. I have also tried taking out the 74ALS00 and

using a 74ALS138

Post by James Cross
with the 74ALS04 to control all the memory and I/O in a

cleaner fashion

Post by James Cross
with no change in behaviour.
I've checked over my wiring several times. Though

that may not mean much

Post by James Cross
in this rat's nest of wires. I do have a two

channel oscilloscope for

Post by James Cross
debugging and have checked the things that seemed

obvious to me but I am

Post by James Cross
pretty new at this. I did some kit stuff as a kid and

have just gotten

Post by James Cross
back into things by reading Scherz and Monk's

/Practical Electronics/

Post by James Cross
and then starting this project. My only theories left

are that maybe my

Post by James Cross
part substitutions were a bad idea or I'm running

into capacitance

Post by James Cross
issues because this is a breadboard. I think I've

bitten off way more

Post by James Cross
than I can true with this project. Any theories,

suggestions, or advice

Post by James Cross
would be greatly appreciated.

Is it possible to reduce the clock to a much lower
frequency, like <=

1MHz and check if it affects the stability of your
prototype?



Regards,

Nikolay





--

You received this message because you are subscribed to the
Google Groups "N8VEM" group.

To unsubscribe from this group and stop receiving emails
from it, send an email to n8vem+***@googlegroups.com.

To post to this group, send email to ***@googlegroups.com.

Visit this group at http://groups.google.com/group/n8vem.

For more options, visit https://groups.google.com/d/optout.

[James Cross]

This post might be inappropriate. Click to display it.

[James Cross]

I had some time to look into this a little further tonight. It looks like
the noise only occurs just after the '245's /OE goes low (enabled) while
DIR is low (transferring B to A, which is ROM to CPU). Things are clean in
all other cases. It looks like the output from the ROM to the '245 is
absolutely awful and this is what causes the high-frequency bouncing on the
A side. But my tests last night showed that the ROM's output looks fine
when the '245 is taken out. Pulling IC10 (the I/O '373 or '573) and the RAM
doesn't help either.

Post by James Cross
I've tied the '245's /OE pin high, effectively isolating either side of
the data bus. The noise disappears on the 8088's side and the ROM's side.
The ROM is definitely trying to output data. In fact, triggering on the
falling edge of the ROM's /OE just after reset, I see my code go across the
data pins of the ROM. D0 is 010010. D1 is 001010. D2 is 001001. D3 is
000011. D4 is 100101. D5 is 101011. D6 is 001011. D7 is 101011. If you
interleave those bits, you get B0, 01, E6, 10, EB, and FC. That is
definitely my code. Even translating the opcodes back into assembly I get
MOV AL, 00000001b; OUT 10h, AL; JMP FCh. FCh corresponds to three bytes
backward, or the point where OUT 10h, AL starts. So all the address stuff
and the ROM are good. But everything goes to hell with that '245 in the
mix. Its DIR and /OE pins seem to be getting good input (when I don't have
/OE tied high). But for some reason it really messes up the data lines on
both sides when the 8088 is able to control /OE. That's all the debugging I
can do tonight but I feel like we're getting close.

Post by James Cross
Hey folks,
I have been trying to get an 8088 working on a breadboard as a means to
learn how it works before attempting to build a Xi 8088. I've been
following along with Grossblatt's *8088 Project Book*. I've attached a
schematic that represents where I am at now. I have a program loaded into
ROM (IC 6) that should blink a single LED in an endless loop. This is the
same as the program in Grossblatt's book and I've verified that the hex
code from my assembler matches what is in the book. Unfortunately, the
behaviour I'm seeing is LEDs light up randomly. The pattern is usually
different each time I turn it on. Sometimes the LEDs are solid and bright,
other times dimmed from subtle flickering.
There are a few differences between the schematic and my build. Mostly
it's substitutions that will let me reuse the parts when I build the Xi
8088. ICs 3, 4, and 10 have all been replaced with 74ACT573s for simpler
wiring (like the Xi 8088). IC5 is a 74ACT245 rather than an LS part. IC8 is
a 74ALS04 rather than a 74LS04. IC9 is a 74ALS00 rather than a 74LS00. I
have also tried taking out the 74ALS00 and using a 74ALS138 with the
74ALS04 to control all the memory and I/O in a cleaner fashion with no
change in behaviour.
I've checked over my wiring several times. Though that may not mean much
in this rat's nest of wires. I do have a two channel oscilloscope for
debugging and have checked the things that seemed obvious to me but I am
pretty new at this. I did some kit stuff as a kid and have just gotten back
into things by reading Scherz and Monk's *Practical Electronics* and
then starting this project. My only theories left are that maybe my part
substitutions were a bad idea or I'm running into capacitance issues
because this is a breadboard. I think I've bitten off way more than I can
true with this project. Any theories, suggestions, or advice would be
greatly appreciated.
Regards,
James

[Nikolay Dimitrov]

Hi James,

Post by James Cross
I had some time to look into this a little further tonight. It looks
like the noise only occurs just after the '245's /OE goes low (enabled)
while DIR is low (transferring B to A, which is ROM to CPU). Things are
clean in all other cases. It looks like the output from the ROM to the
'245 is absolutely awful and this is what causes the high-frequency
bouncing on the A side. But my tests last night showed that the ROM's
output looks fine when the '245 is taken out. Pulling IC10 (the I/O '373
or '573) and the RAM doesn't help either.

Can you please check the VCC (+5V) pin on the suspicious IC ('245)? Bad
VCC connection to this pin or a missing bypass capacitor can cause IC
misbehavior (current limitation/voltage sagging will prevent the output
buffers to source current into output signal lines).

Also, you can probably try to replace the IC with another one to rule
out a defective IC.

In addition, you can double-check the IC logic families you're using to
make sure their voltage levels are compatible.

As a last idea, how possible is for the '245's outputs to fight with
other IC outputs, due to timing issues (clock/DIR/OE/RD/WR
propagation)? Driver collisions will cause glitches on the signal lines
and will cause additional noise on the VCC line, probably causing more
issues. If you put 1K resistor in series with a suspicious signal line,
you can watch with the scope for potential difference across the 2
resistor pins (you should be able to differentiate between actual
driver output conflicts and just driving IC's pins parasitic
capacitance).

Regards,
Nikolay

[James Cross]

Responses are in-line.

Post by Nikolay Dimitrov
Hi James,

Post by James Cross
I had some time to look into this a little further tonight. It looks
like the noise only occurs just after the '245's /OE goes low (enabled)
while DIR is low (transferring B to A, which is ROM to CPU). Things are
clean in all other cases. It looks like the output from the ROM to the
'245 is absolutely awful and this is what causes the high-frequency
bouncing on the A side. But my tests last night showed that the ROM's
output looks fine when the '245 is taken out. Pulling IC10 (the I/O '373
or '573) and the RAM doesn't help either.

Can you please check the VCC (+5V) pin on the suspicious IC ('245)? Bad
VCC connection to this pin or a missing bypass capacitor can cause IC
misbehavior (current limitation/voltage sagging will prevent the output
buffers to source current into output signal lines).

VCC is a solid 5V until the noise starts showing up on the '245's data
lines. The 5V line shows the same pattern of noise as the data line but
much less intense. Still, it's a swing between 4V and 6V, which is pretty
bad. In hindsight, this is probably what was causing the bad voltage with
previous power supply. I suspect it would have been fine if the system were
working properly.

Post by Nikolay Dimitrov
Also, you can probably try to replace the IC with another one to rule
out a defective IC.

I previously tried this. I discovered that I have a few more '245s so I
tried a third one just be sure. There is no change.

Post by Nikolay Dimitrov
In addition, you can double-check the IC logic families you're using to
make sure their voltage levels are compatible.

All logic chips in the circuit currently are 74ACT or 74ALS chips. The ALS
chips are normal TTL. The ACT are TTL-compatible CMOS. To the best of my
limited knowledge, they should communicate at the same voltage levels.

Post by Nikolay Dimitrov
As a last idea, how possible is for the '245's outputs to fight with
other IC outputs, due to timing issues (clock/DIR/OE/RD/WR
propagation)? Driver collisions will cause glitches on the signal lines
and will cause additional noise on the VCC line, probably causing more
issues. If you put 1K resistor in series with a suspicious signal line,
you can watch with the scope for potential difference across the 2
resistor pins (you should be able to differentiate between actual
driver output conflicts and just driving IC's pins parasitic
capacitance).

I think this is the issue. It looks like there's a ~72ms or ~150ms
(depending on whether I'm running at 2MHz or 4.77MHz) window where the
8088's AD pins are still in output mode after DIR has changed. I would
expect the 8088 to switch the data lines to input mode simultaneously with
changing DIR.

I tried running the DIR through a series of four inverters to slow it down
but I didn't get the program to actually run that way. I did the same thing
to the /OE line on the ROM though and got some results. I still see bad
noise on the '245. However, most of the time, after a reset, the CPU
manages to actually read and execute the program for a few seconds. IOSEL
pulses and clean bits for the I/O write are being written out by the 8088.
Interestingly, the noise is never at those moments. I tried several
different patterns for the LEDs just to be sure. And I think I established
earlier that the noise only happens during data read (i.e. the '245's /OE
and DIR both low), which corresponds with I/O signals being since my code
only writes to I/O. That would explain why delaying the ROM helped get
things sort of working. Grossblatt's original design may never have had
this issue because his ROM is about 300ns slower than mine.

On a related note, is there a better way to introduce delays other than
do-nothing logic?

I'm fried. More troubleshooting will have to wait for another night. But
tonight's limited success makes me hopeful.

Post by Nikolay Dimitrov
Regards,
Nikolay

[Andrew Bingham]

Is there any chance you're seeing issues with your breadboard?

I have heard of poor breadboards causing problems. It's kind of hard to
see down in the slots to see what is going on.

Post by James Cross
Responses are in-line.

Post by Nikolay Dimitrov
Hi James,

Post by James Cross
I had some time to look into this a little further tonight. It looks
like the noise only occurs just after the '245's /OE goes low (enabled)
while DIR is low (transferring B to A, which is ROM to CPU). Things are
clean in all other cases. It looks like the output from the ROM to the
'245 is absolutely awful and this is what causes the high-frequency
bouncing on the A side. But my tests last night showed that the ROM's
output looks fine when the '245 is taken out. Pulling IC10 (the I/O

'373

Post by James Cross
or '573) and the RAM doesn't help either.

Can you please check the VCC (+5V) pin on the suspicious IC ('245)? Bad
VCC connection to this pin or a missing bypass capacitor can cause IC
misbehavior (current limitation/voltage sagging will prevent the output
buffers to source current into output signal lines).

VCC is a solid 5V until the noise starts showing up on the '245's data
lines. The 5V line shows the same pattern of noise as the data line but
much less intense. Still, it's a swing between 4V and 6V, which is pretty
bad. In hindsight, this is probably what was causing the bad voltage with
previous power supply. I suspect it would have been fine if the system were
working properly.

Post by Nikolay Dimitrov
Also, you can probably try to replace the IC with another one to rule
out a defective IC.

I previously tried this. I discovered that I have a few more '245s so I
tried a third one just be sure. There is no change.

Post by Nikolay Dimitrov
In addition, you can double-check the IC logic families you're using to
make sure their voltage levels are compatible.

All logic chips in the circuit currently are 74ACT or 74ALS chips. The ALS
chips are normal TTL. The ACT are TTL-compatible CMOS. To the best of my
limited knowledge, they should communicate at the same voltage levels.

Post by Nikolay Dimitrov
As a last idea, how possible is for the '245's outputs to fight with
other IC outputs, due to timing issues (clock/DIR/OE/RD/WR
propagation)? Driver collisions will cause glitches on the signal lines
and will cause additional noise on the VCC line, probably causing more
issues. If you put 1K resistor in series with a suspicious signal line,
you can watch with the scope for potential difference across the 2
resistor pins (you should be able to differentiate between actual
driver output conflicts and just driving IC's pins parasitic
capacitance).

I think this is the issue. It looks like there's a ~72ms or ~150ms
(depending on whether I'm running at 2MHz or 4.77MHz) window where the
8088's AD pins are still in output mode after DIR has changed. I would
expect the 8088 to switch the data lines to input mode simultaneously with
changing DIR.
I tried running the DIR through a series of four inverters to slow it down
but I didn't get the program to actually run that way. I did the same thing
to the /OE line on the ROM though and got some results. I still see bad
noise on the '245. However, most of the time, after a reset, the CPU
manages to actually read and execute the program for a few seconds. IOSEL
pulses and clean bits for the I/O write are being written out by the 8088.
Interestingly, the noise is never at those moments. I tried several
different patterns for the LEDs just to be sure. And I think I established
earlier that the noise only happens during data read (i.e. the '245's /OE
and DIR both low), which corresponds with I/O signals being since my code
only writes to I/O. That would explain why delaying the ROM helped get
things sort of working. Grossblatt's original design may never have had
this issue because his ROM is about 300ns slower than mine.
On a related note, is there a better way to introduce delays other than
do-nothing logic?
I'm fried. More troubleshooting will have to wait for another night. But
tonight's limited success makes me hopeful.

Post by Nikolay Dimitrov
Regards,
Nikolay

[James Cross]

I had this suspicion earlier and I wanted to clean up the wiring anyway. So
I moved everything to a new breadboard fresh from Jameco a week ago. The
clock ended up looking better and so did all the known good signals. It was
a noticeable but not drastic change.

Post by Andrew Bingham
Is there any chance you're seeing issues with your breadboard?
I have heard of poor breadboards causing problems. It's kind of hard to
see down in the slots to see what is going on.

Post by James Cross
Responses are in-line.

Post by Nikolay Dimitrov
Hi James,

Post by James Cross
I had some time to look into this a little further tonight. It looks
like the noise only occurs just after the '245's /OE goes low

(enabled)

Post by James Cross
while DIR is low (transferring B to A, which is ROM to CPU). Things

are

Post by James Cross
clean in all other cases. It looks like the output from the ROM to the
'245 is absolutely awful and this is what causes the high-frequency
bouncing on the A side. But my tests last night showed that the ROM's
output looks fine when the '245 is taken out. Pulling IC10 (the I/O

'373

Post by James Cross
or '573) and the RAM doesn't help either.

Can you please check the VCC (+5V) pin on the suspicious IC ('245)? Bad
VCC connection to this pin or a missing bypass capacitor can cause IC
misbehavior (current limitation/voltage sagging will prevent the output
buffers to source current into output signal lines).

VCC is a solid 5V until the noise starts showing up on the '245's data
lines. The 5V line shows the same pattern of noise as the data line but
much less intense. Still, it's a swing between 4V and 6V, which is pretty
bad. In hindsight, this is probably what was causing the bad voltage with
previous power supply. I suspect it would have been fine if the system were
working properly.

Post by Nikolay Dimitrov
Also, you can probably try to replace the IC with another one to rule
out a defective IC.

I previously tried this. I discovered that I have a few more '245s so I
tried a third one just be sure. There is no change.

Post by Nikolay Dimitrov
In addition, you can double-check the IC logic families you're using to
make sure their voltage levels are compatible.

All logic chips in the circuit currently are 74ACT or 74ALS chips. The
ALS chips are normal TTL. The ACT are TTL-compatible CMOS. To the best of
my limited knowledge, they should communicate at the same voltage levels.

Post by Nikolay Dimitrov
As a last idea, how possible is for the '245's outputs to fight with
other IC outputs, due to timing issues (clock/DIR/OE/RD/WR
propagation)? Driver collisions will cause glitches on the signal lines
and will cause additional noise on the VCC line, probably causing more
issues. If you put 1K resistor in series with a suspicious signal line,
you can watch with the scope for potential difference across the 2
resistor pins (you should be able to differentiate between actual
driver output conflicts and just driving IC's pins parasitic
capacitance).

I think this is the issue. It looks like there's a ~72ms or ~150ms
(depending on whether I'm running at 2MHz or 4.77MHz) window where the
8088's AD pins are still in output mode after DIR has changed. I would
expect the 8088 to switch the data lines to input mode simultaneously with
changing DIR.
I tried running the DIR through a series of four inverters to slow it
down but I didn't get the program to actually run that way. I did the same
thing to the /OE line on the ROM though and got some results. I still see
bad noise on the '245. However, most of the time, after a reset, the CPU
manages to actually read and execute the program for a few seconds. IOSEL
pulses and clean bits for the I/O write are being written out by the 8088.
Interestingly, the noise is never at those moments. I tried several
different patterns for the LEDs just to be sure. And I think I established
earlier that the noise only happens during data read (i.e. the '245's /OE
and DIR both low), which corresponds with I/O signals being since my code
only writes to I/O. That would explain why delaying the ROM helped get
things sort of working. Grossblatt's original design may never have had
this issue because his ROM is about 300ns slower than mine.
On a related note, is there a better way to introduce delays other than
do-nothing logic?
I'm fried. More troubleshooting will have to wait for another night. But
tonight's limited success makes me hopeful.

Post by Nikolay Dimitrov
Regards,
Nikolay

[Borut]

Hi,

Could you try replacing HCT245 with LS245? IIRC LS parts have Schmitt trigger inputs and HCT do not.

Best regards,
Bo/

[James Cross]

It's actually an ACT245 but, looking at the data sheet, its buffers does
not use Schmitt triggers. So I tried the swap. And it works 100% of the
time. There is no more high frequency noise and the delay to the ROM seems
to no longer be necessary. The rises from the ROM are slow and only getting
up to 4V or so but it's enough to make the system function reliably. I
guess there is still some fundamental timing issue at play here but the
74LS245 seems to be cleaning things well enough.

I'm going to see about switching out the 74ACT573 lighting the LEDs for a
'574 of some kind. It should ensure that only the I/O bits show up on the
LEDs.

Looking further into Grossblatt's book, it looks like he focuses on a lot
of really primitive and uninteresting I/O devices from here on and requires
a lot of extra logic to keep them all coordinated. How crazy would it be to
just forego all of those devices and go straight for a UART as the system's
one and only type of I/O? I figure I shouldn't go too crazy with this build
since I have a Xi 8088 board here waiting to be soldered.

Post by Borut
Hi,
Could you try replacing HCT245 with LS245? IIRC LS parts have Schmitt
trigger inputs and HCT do not.
Best regards,
Bo/

[Sergey]

74AC/74ACT ICs have really fast switching times, which might result in
noise (e.g. ringing, cross-talk). The problem amplified further by poor
wiring or PCB layout and the lack of signal termination. With that being
said I used 74ACT of bus drivers, transceivers and latches on Xi 8088 board
without any problems. If you like you can use fast TTL series -74F, 74ALS
or in the worst case 74LS gates (later probably will not work very well
with CPU frequencies above 8 MHz, if not less). Check component replacement
notes on the Xi 8088 page.

Connecting a 8250/16550 type UART to 8088 is pretty straight forward
project. You'll need an address decode circuit (for example 74*688 or
74*138/139 based), and an RS-232 driver/receiver like MAX232A. Or you can
connect the UART straight to an FT231/FT232 breakout board or a cable, and
attach it to a USB port on your computer. For the clock frequency source
I'd recommend using a 1.8432 MHz oscillator (for standard PC bit rates)
rather than a crystal resonator...

Thanks,
Sergey

Post by James Cross
It's actually an ACT245 but, looking at the data sheet, its buffers does
not use Schmitt triggers. So I tried the swap. And it works 100% of the
time. There is no more high frequency noise and the delay to the ROM seems
to no longer be necessary. The rises from the ROM are slow and only getting
up to 4V or so but it's enough to make the system function reliably. I
guess there is still some fundamental timing issue at play here but the
74LS245 seems to be cleaning things well enough.
I'm going to see about switching out the 74ACT573 lighting the LEDs for a
'574 of some kind. It should ensure that only the I/O bits show up on the
LEDs.
Looking further into Grossblatt's book, it looks like he focuses on a lot
of really primitive and uninteresting I/O devices from here on and requires
a lot of extra logic to keep them all coordinated. How crazy would it be to
just forego all of those devices and go straight for a UART as the system's
one and only type of I/O? I figure I shouldn't go too crazy with this build
since I have a Xi 8088 board here waiting to be soldered.

Post by Borut
Hi,
Could you try replacing HCT245 with LS245? IIRC LS parts have Schmitt
trigger inputs and HCT do not.
Best regards,
Bo/

[Nikolay Dimitrov]

Hi James,

Post by Nikolay Dimitrov
As a last idea, how possible is for the '245's outputs to fight with
other IC outputs, due to timing issues (clock/DIR/OE/RD/WR
propagation)? Driver collisions will cause glitches on the signal lines
and will cause additional noise on the VCC line, probably causing more
issues. If you put 1K resistor in series with a suspicious signal line,
you can watch with the scope for potential difference across the 2
resistor pins (you should be able to differentiate between actual
driver output conflicts and just driving IC's pins parasitic
capacitance).
I think this is the issue. It looks like there's a ~72ms or ~150ms
(depending on whether I'm running at 2MHz or 4.77MHz) window where the
8088's AD pins are still in output mode after DIR has changed. I would
expect the 8088 to switch the data lines to input mode simultaneously
with changing DIR.

Hmm, are these ms or us (u = micro)?

Post by Nikolay Dimitrov
I tried running the DIR through a series of four inverters to slow it
down but I didn't get the program to actually run that way. I did the
same thing to the /OE line on the ROM though and got some results. I
still see bad noise on the '245. However, most of the time, after a
reset, the CPU manages to actually read and execute the program for a
few seconds. IOSEL pulses and clean bits for the I/O write are being
written out by the 8088. Interestingly, the noise is never at those
moments. I tried several different patterns for the LEDs just to be
sure. And I think I established earlier that the noise only happens
during data read (i.e. the '245's /OE and DIR both low), which
corresponds with I/O signals being since my code only writes to I/O.
That would explain why delaying the ROM helped get things sort of
working. Grossblatt's original design may never have had this issue
because his ROM is about 300ns slower than mine.

Well, I guess that the /OE signal deserves additional attention, as
it's the one that enables the output drivers.

Post by Nikolay Dimitrov
On a related note, is there a better way to introduce delays other than
do-nothing logic?

Yes, but it depends on whether you need asynchronous or synchronous
delay. For the async delay you can use:
- RC delay circuit. 1k + 330pF will delay the TTL signal for 209.5ns
(for 2V voltage level)
- Cheap coaxial cable with low velocity factor (0.66). It takes the
signal 5.054ns to travel 1m in such cable.

For sync delay you need a clock edge and 1 or more D-triggers (if you
need more than 3-4 cycles delay it's probably better to use a
ready-made shift register, like 74HCT164). Usually some CPUs support
wait-states, which is handy and easier than adding D-triggers :).

Post by Nikolay Dimitrov
I'm fried. More troubleshooting will have to wait for another night. But
tonight's limited success makes me hopeful.

Thanks for answering my questions. You've done a great job at analyzing
all these issues so far!

Regards,
Nikolay

[James Cross]

Just a quick follow-up, I meant ~72ns and ~150ns, as in nano seconds.

Post by Nikolay Dimitrov
Hi James,

Post by Nikolay Dimitrov
As a last idea, how possible is for the '245's outputs to fight with
other IC outputs, due to timing issues (clock/DIR/OE/RD/WR
propagation)? Driver collisions will cause glitches on the signal

lines

Post by Nikolay Dimitrov
and will cause additional noise on the VCC line, probably causing

more

Post by Nikolay Dimitrov
issues. If you put 1K resistor in series with a suspicious signal

line,

Post by Nikolay Dimitrov
you can watch with the scope for potential difference across the 2
resistor pins (you should be able to differentiate between actual
driver output conflicts and just driving IC's pins parasitic
capacitance).
I think this is the issue. It looks like there's a ~72ms or ~150ms
(depending on whether I'm running at 2MHz or 4.77MHz) window where the
8088's AD pins are still in output mode after DIR has changed. I would
expect the 8088 to switch the data lines to input mode simultaneously
with changing DIR.

Hmm, are these ms or us (u = micro)?

Post by Nikolay Dimitrov
I tried running the DIR through a series of four inverters to slow it
down but I didn't get the program to actually run that way. I did the
same thing to the /OE line on the ROM though and got some results. I
still see bad noise on the '245. However, most of the time, after a
reset, the CPU manages to actually read and execute the program for a
few seconds. IOSEL pulses and clean bits for the I/O write are being
written out by the 8088. Interestingly, the noise is never at those
moments. I tried several different patterns for the LEDs just to be
sure. And I think I established earlier that the noise only happens
during data read (i.e. the '245's /OE and DIR both low), which
corresponds with I/O signals being since my code only writes to I/O.
That would explain why delaying the ROM helped get things sort of
working. Grossblatt's original design may never have had this issue
because his ROM is about 300ns slower than mine.

Well, I guess that the /OE signal deserves additional attention, as
it's the one that enables the output drivers.

Post by Nikolay Dimitrov
On a related note, is there a better way to introduce delays other than
do-nothing logic?

Yes, but it depends on whether you need asynchronous or synchronous
- RC delay circuit. 1k + 330pF will delay the TTL signal for 209.5ns
(for 2V voltage level)
- Cheap coaxial cable with low velocity factor (0.66). It takes the
signal 5.054ns to travel 1m in such cable.
For sync delay you need a clock edge and 1 or more D-triggers (if you
need more than 3-4 cycles delay it's probably better to use a
ready-made shift register, like 74HCT164). Usually some CPUs support
wait-states, which is handy and easier than adding D-triggers :).

Post by Nikolay Dimitrov
I'm fried. More troubleshooting will have to wait for another night. But
tonight's limited success makes me hopeful.

Thanks for answering my questions. You've done a great job at analyzing
all these issues so far!
Regards,
Nikolay