[N8VEM: 17189] Input Desired - Extended Bus Monitor or Bus Monitor V2

[Andrew Bingham]

All,

I'm starting my ECB bus build in a Siemens/TI 505-6508 chassis; I'll be
using one of the 12-slot backplanes that John C. has designed specifically
for that chassis.

As part of that build, I've realized there are a few drawbacks to the
existing Bus Monitor board:
1. The existing card only supports 16-bit addresses and 8-bit data. The
mini-68k CPU board drives up to 22-bit address, and 24-bit is a clear
possibility. 16-bit data is a future possibility as well. (The available
CPU and memory cards have, happily, outgrown the original Bus Monitor.)
2. If displays/DIP switches are installed in the current card and it is
installed inside a chassis with other cards near it, the displays/DIP
switches are not easily visible/accessible - the card is really best suited
for use in a benchtop open air chassis. (With surplus prices of the
505-6805 dropping, we now have an excellent off-the-shelf chassis available
with a backplane to match)
3. Connecting external LEDs requires hard-to-locate or custom cables ending
in DIP20 package-like connections. (this makes it difficult to resolve #2
above)

I'm starting work on an update to the Bus Monitor card that will address
some of these issues. I'd like to get input from the group as to any
features that would be desirable in such an update. Right now I have the
following *minimum set* of changes identified. I would consider this the
"Extended Bus Monitor" - it is a minimum set of changes that extend the
existing design and fix drawback #1 above, but #2 & #3 remain.
1. Expand address lines to 24-bit and data lines to 16-bit. Add /DS0 and
/DS1 (high and low byte transfer signals) to monitored signals. Update
layout to try and fit these new items (1 DIP8, 2 10-segment bar graphs)
onto the PCB. The current board is pretty full so it's not clear
everything will fit.

A more extensive set of changes would product what I would call the "Bus
Monitor V2":
1. Expand address lines to 24-bit and data lines to 16-bit. Add /DS0 and
/DS1 (high and low byte transfer signals) to monitored signals.
2. Move the LED displays and DIP switches onto a Front Panel/daughterboard
connected with standard headers. This would free up additional space on
the Bus Monitor PCB itself, as well as allowing for multiple display/front
panel configurations similar to the S-100 Bus Monitor/Front Panel
combination which has 3 options for the front panel part.

So, questions for the group:
-Which approach above makes the most sense? Extended or V2?
-Is there interest from the ~5 people who are building systems in the
505-6508 chassis in having a new Bus Monitor to use with their builds? From
others?
*-Are there any other new signals, for instance used by the SBC-188, SBC
Mark IV, mini-68k, etc that would be useful to include in a revision of the
Bus Monitor?*

I've already taken an initial stab at a schematic for the Extended version
but haven't made it to trying to route the PCB yet.

(In my head I have an image of a sweet "modernized" front panel with a
Propeller or another microcontroller driving an LCD or VFD multiline
character display and 4 buttons with a menu to setup which addresses to
latch the display on, etc....but that's a whole separate project on its own
that doing the V2 option would enable if all the LED and switches were on a
separate card.)

Thanks,

Andrew

[J. Alexander Jacocks]

I'm quite interested in a full-bus-width bus monitor board, so I suppose my
limited experience would point towards a v2 board.

[Vince Mulhollon]

as well as allowing for multiple display/front panel configurations
similar to the S-100 Bus Monitor/Front Panel combination which has 3
options for the front panel part.

I "need" a S100 front panel also.. Might be interesting to respin both S100
and ECB cards, such that both would somehow use the same daughter-displays.

I'd buy two "super ECB" bus monitors and two S100 bus monitors, and I guess
4 daughter display cards.

Even if the S100 isn't re-run at this time, it would be nice if the new ECB
were more or less theoretically compatible with a future S100.

The "modernized front panel" sounds highly appealing. I would go big for
my display. I'm mulling over something physically large for my next
chassis project.

[Andrew Bingham]

As far as the "modern" display, I was thinking a microcontroller, 16x2 (or
larger) character display (OLED maybe...sexy), and 4 buttons. The
LED_LATCH signal would be used to trigger a read-in of the monitored
signals (using the outputs that used to drive the LEDs) and update of the
character display. A menu system and a set of shift register outputs could
be used in place of the items that were DIP switches, allowing for
menu-driven selection of the configuration of the address to halt on and
the generation of the IN_ signal. I've been trying to think of how I could
make all that fit into the pin count, say, a DIP Atmel chip or a Propeller.
(Personally I have more experience using Arduino libraries to program the
Atmel chips, but the N8VEM project already uses the Propeller in
PropIO/ParPortProp and I think consistency in what "modern"
microcontrollers are used as part of supporting hardware is a good thing.)

I don't know if I'd embark on such an in-dept project without someone to
partner with on it, but I'd certainly want a Bus Monitor V2 that I design
myself to have the 'hooks' in the design to support it in the future.

Andrew

Post by Vince Mulhollon

as well as allowing for multiple display/front panel configurations
similar to the S-100 Bus Monitor/Front Panel combination which has 3
options for the front panel part.

I "need" a S100 front panel also.. Might be interesting to respin both
S100 and ECB cards, such that both would somehow use the same
daughter-displays.
I'd buy two "super ECB" bus monitors and two S100 bus monitors, and I
guess 4 daughter display cards.
Even if the S100 isn't re-run at this time, it would be nice if the new
ECB were more or less theoretically compatible with a future S100.
The "modernized front panel" sounds highly appealing. I would go big for
my display. I'm mulling over something physically large for my next
chassis project.

[Vince Mulhollon]

As far as the "modern" display, ... make all that fit into ... a
Propeller.

Ah OK. I figured propeller meant the display would be a VGA out of a
prop. Then I'd find a relatively small VGA monitor and made it the entire
end of the chassis, or under glass surface of a desk or something like
that. That would certainly be an interesting looking bus monitor. The
hardware would be simpler although I imagine the temptation to make the
software very elaborate would be pretty high.

[Andrew Bingham]

VGA would be overkill for a bus monitor, in my opinion (although I wouldn't
rule it out). But someone willing to spend a few $$ could still have a
really nice looking screen, for instance:
http://www.adafruit.com/products/1596 combined
with http://www.adafruit.com/products/1590 would give nice crisp text and
plenty of rows/columns to show the current address and data, the trap
address, and the status of the control lines, while acting effectively as a
SPI interface character display as far as the microcontroller goes.

I agree there is a temptation to start making the software very complex for
something like this.

Andrew

Post by Vince Mulhollon

As far as the "modern" display, ... make all that fit into ... a
Propeller.

Ah OK. I figured propeller meant the display would be a VGA out of a
prop. Then I'd find a relatively small VGA monitor and made it the entire
end of the chassis, or under glass surface of a desk or something like
that. That would certainly be an interesting looking bus monitor. The
hardware would be simpler although I imagine the temptation to make the
software very elaborate would be pretty high.

[John Coffman]

[Andrew Bingham]

John - you had sent me the image file in an email earlier, but thanks for
the additional information.

My read of the schematic of the current Bus Monitor board is that it works
essentially as follows:
-An address is selected using DIP switches
-An "input signal" IN_ is selected from among

When that address is reached & the input signal IN_1 is "true", the LEDs
latch and the board generates a WAIT that continues until the physical
switch is switched to resume operation (the operation of the switch part of
things is a little unclear to my new person brain to be honest). There are
also several control signals that are buffered, but not latched.

So other than expanding the address and data lines, the only thing I can
think of that would be useful would be to add additional signals (such as
INTA) that could be selected as the IN_ signal.

Andrew

Andrew,
I hope you have found the attached file on the Wiki.
Rows A & C have the original Z80 signals used by Kontron; only /IQ0, /IQ1,
& /IQ2 are not used by any existing board. The row B expansion began with
the SBC-188. DT/R is the most important signal (data transmit/receive).
The Mini-M68K does not use the /IQx signals, but rather, vectors
interrupts from the NS32202 on the MF/PIC board. As far as I know, no one
has seriously used the vectored interrupts on the Z80; however, they work
in IM0 and IM2.
The extended addressing goes, as you have said, in leaps of 4: 16, 20, 24
bits. I can envision a leap to 28 bits on a 68010 with MMU. 32-bits is
out of the question on 3U (100mm X 160mm) boards. Also, more than 16 data
bits is also out of the question. In other words, either board you are
envisioning would be useful for quite some time.
I lean toward the V2 -- a two board solution. Coming up with a board that
would be adaptable to many different mounting situations would be a
formidable challenge.
BTW: I experimented with an LCD display, 4 x 20 chars, driven from the
82C55 on the SBC v1. This is several years ago, but I dropped development
for lack of a card housing and ability to mount the display. It looked
like a rather useful beast.
One thing bugs me: the LED displays come with 10 bar LEDs in a 20 pin DIP
package. I sure wish they came in 4's or 8's or 12's.
=============================================================
Power (rust brown): +5 and GND only. N8VEM does not use/support any
other voltages, except VBAT (optional).
Data 0-7, Address 0-15: all boards
Control Signals: all boards (with certain signal exceptions)
/RFSH -- driven on SBC v1/v2, not driven on other CPU boards
/BUSRQ, /BUSAK -- for DMA by external boards
/RESET, /RESOUT -- N8VEM and Kontron usage differs; newer boards allow
jumpers for one standard or the other
N8VEM -- /RESET is a CPU board output; /RESOUT not driven
on old boards
Kontron -- /RESET is a CPU board input; /RESOUT is the
correct peripheral Reset signal.
Daisy Chain signals: not supported by any board but Zilog peripherals;
probably incompatible;
Address Expansion A16-23: SBC-188 drives A16-19; Mini-M68K drives A16-A23
Intel Specific: first used on the SBC-188
DT/R used by a couple of peripheral boards in place of /RD
INTA used optionally in place of /IORQ & /M1
/DREQ and /TEND connected, but not currently used anywhere
Prioritized Interrupts: Used by MF/PIC and Mini-M68K combo
/IQ0, IQ1, IQ2 unused; reserved for 68000 without MF/PIC
Data Bus Extension: D8-15 reserved for 68000
includes 4 control signals: /DS0, /DS1, /SXTRQ, /SXTAK (last 2,
like the S-100 usage)
The SBC-188 BIOS uses interrupts and uses DMA for floppy disk transfers.
The Mini-M68K BIOS uses interrupts.
All CPU boards are designed for DMA transfers initiated by external
boards; but no such boards exist. SBC v1 DMA does not work.
--John
All,
I'm starting my ECB bus build in a Siemens/TI 505-6508 chassis; I'll be
using one of the 12-slot backplanes that John C. has designed specifically
for that chassis.
As part of that build, I've realized there are a few drawbacks to the
1. The existing card only supports 16-bit addresses and 8-bit data. The
mini-68k CPU board drives up to 22-bit address, and 24-bit is a clear
possibility. 16-bit data is a future possibility as well. (The available
CPU and memory cards have, happily, outgrown the original Bus Monitor.)
2. If displays/DIP switches are installed in the current card and it is
installed inside a chassis with other cards near it, the displays/DIP
switches are not easily visible/accessible - the card is really best suited
for use in a benchtop open air chassis. (With surplus prices of the
505-6805 dropping, we now have an excellent off-the-shelf chassis available
with a backplane to match)
3. Connecting external LEDs requires hard-to-locate or custom cables
ending in DIP20 package-like connections. (this makes it difficult to
resolve #2 above)
I'm starting work on an update to the Bus Monitor card that will address
some of these issues. I'd like to get input from the group as to any
features that would be desirable in such an update. Right now I have the
following *minimum set* of changes identified. I would consider this the
"Extended Bus Monitor" - it is a minimum set of changes that extend the
existing design and fix drawback #1 above, but #2 & #3 remain.
1. Expand address lines to 24-bit and data lines to 16-bit. Add /DS0 and
/DS1 (high and low byte transfer signals) to monitored signals. Update
layout to try and fit these new items (1 DIP8, 2 10-segment bar graphs)
onto the PCB. The current board is pretty full so it's not clear
everything will fit.
A more extensive set of changes would product what I would call the "Bus
1. Expand address lines to 24-bit and data lines to 16-bit. Add /DS0 and
/DS1 (high and low byte transfer signals) to monitored signals.
2. Move the LED displays and DIP switches onto a Front
Panel/daughterboard connected with standard headers. This would free up
additional space on the Bus Monitor PCB itself, as well as allowing for
multiple display/front panel configurations similar to the S-100 Bus
Monitor/Front Panel combination which has 3 options for the front panel
part.
-Which approach above makes the most sense? Extended or V2?
-Is there interest from the ~5 people who are building systems in the
505-6508 chassis in having a new Bus Monitor to use with their builds? From
others?
*-Are there any other new signals, for instance used by the SBC-188, SBC
Mark IV, mini-68k, etc that would be useful to include in a revision of the
Bus Monitor?*
I've already taken an initial stab at a schematic for the Extended
version but haven't made it to trying to route the PCB yet.
(In my head I have an image of a sweet "modernized" front panel with a
Propeller or another microcontroller driving an LCD or VFD multiline
character display and 4 buttons with a menu to setup which addresses to
latch the display on, etc....but that's a whole separate project on its own
that doing the V2 option would enable if all the LED and switches were on a
separate card.)
Thanks,
Andrew
--
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
Visit this group at http://groups.google.com/group/n8vem.
For more options, visit https://groups.google.com/groups/opt_out.

[Michael Haardt]

Post by Andrew Bingham
-Which approach above makes the most sense? Extended or V2?

The V2 approach sounds best to me. Such boards are usually constructed
with a flat ribbon cable from the regular board to an assistent board
which is made to fit behind a front plate mounted in a subrack range
not occupied by backplane slots.

See the hex keyboard on the bottom of this page as example:

http://www.hd64180-cpm.de/html/computer.html

Michael

[yoda]

I have been thinking about this for a while and will throw out some
questions. What is the ultimate goal of the monitor? Is it to have
blinky leds or to debug hardware / software. I have been thinking the
latter in my ideas. There are some relatively nice and not too expensive
FPGA modules that are through hole friendly. I must admit I am just
exploring FPGAs and verilog now so I am still a novice in this area but
they intrigue me because with just "HDL" they can easily be reconfigured.
There is a design for a 128 bit wide by 4K design on opencores.org (over
kill for most) that collects data once triggered and dumps it to a pc.
The data then can be viewed by a simple program. It would be easy then to
build a program to display the data. The beauty of this is you could write
a personality module to interpret the address and data into the specific
processor machine language. In HP's term I think they call it a state
machine on their old logic analyzers. I actually used an old one to debug
a problem on my S100-68K board so kind of like that approach. This would
allow you to trace backwards to what led you to get to where you triggered.
This would effectively be a bus analyzer for ECB or S100 depending on what
board was made as you could capture all bus signals. I guess it could also
drive the blinky leds as well, though I think the state analysis would be
more useful

-Dave

Post by Andrew Bingham
All,
I'm starting my ECB bus build in a Siemens/TI 505-6508 chassis; I'll be
using one of the 12-slot backplanes that John C. has designed specifically
for that chassis.
As part of that build, I've realized there are a few drawbacks to the
1. The existing card only supports 16-bit addresses and 8-bit data. The
mini-68k CPU board drives up to 22-bit address, and 24-bit is a clear
possibility. 16-bit data is a future possibility as well. (The available
CPU and memory cards have, happily, outgrown the original Bus Monitor.)
2. If displays/DIP switches are installed in the current card and it is
installed inside a chassis with other cards near it, the displays/DIP
switches are not easily visible/accessible - the card is really best suited
for use in a benchtop open air chassis. (With surplus prices of the
505-6805 dropping, we now have an excellent off-the-shelf chassis available
with a backplane to match)
3. Connecting external LEDs requires hard-to-locate or custom cables
ending in DIP20 package-like connections. (this makes it difficult to
resolve #2 above)
I'm starting work on an update to the Bus Monitor card that will address
some of these issues. I'd like to get input from the group as to any
features that would be desirable in such an update. Right now I have the
following *minimum set* of changes identified. I would consider this the
"Extended Bus Monitor" - it is a minimum set of changes that extend the
existing design and fix drawback #1 above, but #2 & #3 remain.
1. Expand address lines to 24-bit and data lines to 16-bit. Add /DS0 and
/DS1 (high and low byte transfer signals) to monitored signals. Update
layout to try and fit these new items (1 DIP8, 2 10-segment bar graphs)
onto the PCB. The current board is pretty full so it's not clear
everything will fit.
A more extensive set of changes would product what I would call the "Bus
1. Expand address lines to 24-bit and data lines to 16-bit. Add /DS0 and
/DS1 (high and low byte transfer signals) to monitored signals.
2. Move the LED displays and DIP switches onto a Front
Panel/daughterboard connected with standard headers. This would free up
additional space on the Bus Monitor PCB itself, as well as allowing for
multiple display/front panel configurations similar to the S-100 Bus
Monitor/Front Panel combination which has 3 options for the front panel
part.
-Which approach above makes the most sense? Extended or V2?
-Is there interest from the ~5 people who are building systems in the
505-6508 chassis in having a new Bus Monitor to use with their builds? From
others?
*-Are there any other new signals, for instance used by the SBC-188, SBC
Mark IV, mini-68k, etc that would be useful to include in a revision of the
Bus Monitor?*
I've already taken an initial stab at a schematic for the Extended version
but haven't made it to trying to route the PCB yet.
(In my head I have an image of a sweet "modernized" front panel with a
Propeller or another microcontroller driving an LCD or VFD multiline
character display and 4 buttons with a menu to setup which addresses to
latch the display on, etc....but that's a whole separate project on its own
that doing the V2 option would enable if all the LED and switches were on a
separate card.)
Thanks,
Andrew

[Andrew Bingham]

Interesting. I understand what you're describing in a general sense, but I
think it's beyond current expertise to create it.

My ultimate goal was to update the existing Bus Monitor for larger
address/data lines, make the front panel/DIP switches separate modular
board(s) that could be remote mounted in a chassis, and provide additional
display options beyond just simple LEDs (or expensive hex displays) to make
the design more useful going into the future.

The current bus monitor allows the user to set an address with DIP switches
and it will WAIT the CPU and latch the LEDs when that address is reached.
So it's a bit beyond the simple blinking LEDs of say an Altair and into
being a debugging tool as far as being able to stop and see what data is on
the bus when a certain address is reached. (I think the physical switch
circuits that I don't quite understand might allow single-stepping after
the WAIT but I'm not sure to be honest, that part still confuses me)

The idea of the character LCD display was that for the price of the 10
characters worth of TIL311 or similar hex display you might want to show
the address and data line data in a useful form beyond just LEDs, 20x4
character displays are readily available - and will continue to be
available well into the future, while the hex displays are getting harder
and harder to source. So by moving to a microcontroller + character
display type of display, it would ensure that builders can source and build
the hardware easily in the future, with updates to the microcontroller code
to support new display types, etc. The extension to a menu system to set
the address to latch on, etc. was just my thought of how to have both
functions of the monitor - the input and the output - in one place.

The bus analyzer/state monitor you describe is one step beyond that in
terms of collecting a bunch of data and outputting it to a PC for a more
in-depth analysis. With the speed of many FPGAs, I don't know if any WAIT
states would even be needed. I think it would be a useful tool, but I
don't know if it's something I could design on the first try. I can see a
logical progression from the existing Bus Monitor schematic to what I'm
thinking of doing for V2; I think the state monitor would be a full new
design.

Andrew

Post by yoda
I have been thinking about this for a while and will throw out some
questions. What is the ultimate goal of the monitor? Is it to have
blinky leds or to debug hardware / software. I have been thinking the
latter in my ideas. There are some relatively nice and not too expensive
FPGA modules that are through hole friendly. I must admit I am just
exploring FPGAs and verilog now so I am still a novice in this area but
they intrigue me because with just "HDL" they can easily be reconfigured.
There is a design for a 128 bit wide by 4K design on opencores.org (over
kill for most) that collects data once triggered and dumps it to a pc.
The data then can be viewed by a simple program. It would be easy then to
build a program to display the data. The beauty of this is you could write
a personality module to interpret the address and data into the specific
processor machine language. In HP's term I think they call it a state
machine on their old logic analyzers. I actually used an old one to debug
a problem on my S100-68K board so kind of like that approach. This would
allow you to trace backwards to what led you to get to where you triggered.
This would effectively be a bus analyzer for ECB or S100 depending on what
board was made as you could capture all bus signals. I guess it could also
drive the blinky leds as well, though I think the state analysis would be
more useful
-Dave

Post by Andrew Bingham
All,
I'm starting my ECB bus build in a Siemens/TI 505-6508 chassis; I'll be
using one of the 12-slot backplanes that John C. has designed specifically
for that chassis.
As part of that build, I've realized there are a few drawbacks to the
1. The existing card only supports 16-bit addresses and 8-bit data. The
mini-68k CPU board drives up to 22-bit address, and 24-bit is a clear
possibility. 16-bit data is a future possibility as well. (The available
CPU and memory cards have, happily, outgrown the original Bus Monitor.)
2. If displays/DIP switches are installed in the current card and it is
installed inside a chassis with other cards near it, the displays/DIP
switches are not easily visible/accessible - the card is really best suited
for use in a benchtop open air chassis. (With surplus prices of the
505-6805 dropping, we now have an excellent off-the-shelf chassis available
with a backplane to match)
3. Connecting external LEDs requires hard-to-locate or custom cables
ending in DIP20 package-like connections. (this makes it difficult to
resolve #2 above)
I'm starting work on an update to the Bus Monitor card that will address
some of these issues. I'd like to get input from the group as to any
features that would be desirable in such an update. Right now I have the
following *minimum set* of changes identified. I would consider this the
"Extended Bus Monitor" - it is a minimum set of changes that extend the
existing design and fix drawback #1 above, but #2 & #3 remain.
1. Expand address lines to 24-bit and data lines to 16-bit. Add /DS0
and /DS1 (high and low byte transfer signals) to monitored signals. Update
layout to try and fit these new items (1 DIP8, 2 10-segment bar graphs)
onto the PCB. The current board is pretty full so it's not clear
everything will fit.
A more extensive set of changes would product what I would call the "Bus
1. Expand address lines to 24-bit and data lines to 16-bit. Add /DS0
and /DS1 (high and low byte transfer signals) to monitored signals.
2. Move the LED displays and DIP switches onto a Front
Panel/daughterboard connected with standard headers. This would free up
additional space on the Bus Monitor PCB itself, as well as allowing for
multiple display/front panel configurations similar to the S-100 Bus
Monitor/Front Panel combination which has 3 options for the front panel
part.
-Which approach above makes the most sense? Extended or V2?
-Is there interest from the ~5 people who are building systems in the
505-6508 chassis in having a new Bus Monitor to use with their builds? From
others?
*-Are there any other new signals, for instance used by the SBC-188, SBC
Mark IV, mini-68k, etc that would be useful to include in a revision of the
Bus Monitor?*
I've already taken an initial stab at a schematic for the Extended
version but haven't made it to trying to route the PCB yet.
(In my head I have an image of a sweet "modernized" front panel with a
Propeller or another microcontroller driving an LCD or VFD multiline
character display and 4 buttons with a menu to setup which addresses to
latch the display on, etc....but that's a whole separate project on its own
that doing the V2 option would enable if all the LED and switches were on a
separate card.)
Thanks,
Andrew

[yoda]

I understand - it is something I am considering doing and I wanted to throw
it out and see which way you were thinking. It would be pretty easy to add
switches to set the compare value for the FPGA. Some are enamored by
lights - I see that you want to do more than that which is good. I will
probably do what I laid out - just don't the time frame. It should be
fairly straight forward as all that would be needed initially would be
level translators like 74lvc244's to buffer the 3.3V only inputs of the
FPGAs from the bus signals.

Post by Andrew Bingham
Interesting. I understand what you're describing in a general sense, but
I think it's beyond current expertise to create it.
My ultimate goal was to update the existing Bus Monitor for larger
address/data lines, make the front panel/DIP switches separate modular
board(s) that could be remote mounted in a chassis, and provide additional
display options beyond just simple LEDs (or expensive hex displays) to make
the design more useful going into the future.
The current bus monitor allows the user to set an address with DIP
switches and it will WAIT the CPU and latch the LEDs when that address is
reached. So it's a bit beyond the simple blinking LEDs of say an Altair
and into being a debugging tool as far as being able to stop and see what
data is on the bus when a certain address is reached. (I think the
physical switch circuits that I don't quite understand might allow
single-stepping after the WAIT but I'm not sure to be honest, that part
still confuses me)
The idea of the character LCD display was that for the price of the 10
characters worth of TIL311 or similar hex display you might want to show
the address and data line data in a useful form beyond just LEDs, 20x4
character displays are readily available - and will continue to be
available well into the future, while the hex displays are getting harder
and harder to source. So by moving to a microcontroller + character
display type of display, it would ensure that builders can source and build
the hardware easily in the future, with updates to the microcontroller code
to support new display types, etc. The extension to a menu system to set
the address to latch on, etc. was just my thought of how to have both
functions of the monitor - the input and the output - in one place.
The bus analyzer/state monitor you describe is one step beyond that in
terms of collecting a bunch of data and outputting it to a PC for a more
in-depth analysis. With the speed of many FPGAs, I don't know if any WAIT
states would even be needed. I think it would be a useful tool, but I
don't know if it's something I could design on the first try. I can see a
logical progression from the existing Bus Monitor schematic to what I'm
thinking of doing for V2; I think the state monitor would be a full new
design.
Andrew

Post by yoda
I have been thinking about this for a while and will throw out some
questions. What is the ultimate goal of the monitor? Is it to have
blinky leds or to debug hardware / software. I have been thinking the
latter in my ideas. There are some relatively nice and not too expensive
FPGA modules that are through hole friendly. I must admit I am just
exploring FPGAs and verilog now so I am still a novice in this area but
they intrigue me because with just "HDL" they can easily be reconfigured.
There is a design for a 128 bit wide by 4K design on opencores.org (over
kill for most) that collects data once triggered and dumps it to a pc.
The data then can be viewed by a simple program. It would be easy then to
build a program to display the data. The beauty of this is you could write
a personality module to interpret the address and data into the specific
processor machine language. In HP's term I think they call it a state
machine on their old logic analyzers. I actually used an old one to debug
a problem on my S100-68K board so kind of like that approach. This would
allow you to trace backwards to what led you to get to where you triggered.
This would effectively be a bus analyzer for ECB or S100 depending on what
board was made as you could capture all bus signals. I guess it could also
drive the blinky leds as well, though I think the state analysis would be
more useful
-Dave

Post by Andrew Bingham
All,
I'm starting my ECB bus build in a Siemens/TI 505-6508 chassis; I'll be
using one of the 12-slot backplanes that John C. has designed specifically
for that chassis.
As part of that build, I've realized there are a few drawbacks to the
1. The existing card only supports 16-bit addresses and 8-bit data. The
mini-68k CPU board drives up to 22-bit address, and 24-bit is a clear
possibility. 16-bit data is a future possibility as well. (The available
CPU and memory cards have, happily, outgrown the original Bus Monitor.)
2. If displays/DIP switches are installed in the current card and it is
installed inside a chassis with other cards near it, the displays/DIP
switches are not easily visible/accessible - the card is really best suited
for use in a benchtop open air chassis. (With surplus prices of the
505-6805 dropping, we now have an excellent off-the-shelf chassis available
with a backplane to match)
3. Connecting external LEDs requires hard-to-locate or custom cables
ending in DIP20 package-like connections. (this makes it difficult to
resolve #2 above)
I'm starting work on an update to the Bus Monitor card that will address
some of these issues. I'd like to get input from the group as to any
features that would be desirable in such an update. Right now I have the
following *minimum set* of changes identified. I would consider this the
"Extended Bus Monitor" - it is a minimum set of changes that extend the
existing design and fix drawback #1 above, but #2 & #3 remain.
1. Expand address lines to 24-bit and data lines to 16-bit. Add /DS0
and /DS1 (high and low byte transfer signals) to monitored signals. Update
layout to try and fit these new items (1 DIP8, 2 10-segment bar graphs)
onto the PCB. The current board is pretty full so it's not clear
everything will fit.
A more extensive set of changes would product what I would call the "Bus
1. Expand address lines to 24-bit and data lines to 16-bit. Add /DS0
and /DS1 (high and low byte transfer signals) to monitored signals.
2. Move the LED displays and DIP switches onto a Front
Panel/daughterboard connected with standard headers. This would free up
additional space on the Bus Monitor PCB itself, as well as allowing for
multiple display/front panel configurations similar to the S-100 Bus
Monitor/Front Panel combination which has 3 options for the front panel
part.
-Which approach above makes the most sense? Extended or V2?
-Is there interest from the ~5 people who are building systems in the
505-6508 chassis in having a new Bus Monitor to use with their builds? From
others?
*-Are there any other new signals, for instance used by the SBC-188, SBC
Mark IV, mini-68k, etc that would be useful to include in a revision of the
Bus Monitor?*
I've already taken an initial stab at a schematic for the Extended
version but haven't made it to trying to route the PCB yet.
(In my head I have an image of a sweet "modernized" front panel with a
Propeller or another microcontroller driving an LCD or VFD multiline
character display and 4 buttons with a menu to setup which addresses to
latch the display on, etc....but that's a whole separate project on its own
that doing the V2 option would enable if all the LED and switches were on a
separate card.)
Thanks,
Andrew