PDA

View Full Version : Intersystems Front Panel chokes data on IMS CPU 451 board



RickNel
June 5th, 2010, 11:20 PM
I've been trying to revive my IMS 5000SX machine for some months. Finally a local friend has wire-wrapped a replica Front Panel based on the Intersystems design, and it works perfectly with his IMSAI.

But in my 1980 IMS International, this front panel can not read anything from the data lines of the bus. For example, the initial program loader is in EPROM located on the I\O card. When we use the Front Panel to run or step the system, we can see (by data probing the I\O card) that EPROM is enabling and sending data out through the I\O card's bus driver chips, but the CPU card does not read anything off the bus.

I believe the issue is that my CPU card is hard-wired so that it will only read data when the RUN line (bus pin 71) is under the control of the Z80 CPU. When the RUN signal is coming from the Front Panel, through a header on the CPU card that is in parallel with the Z80, data input is blocked.

I have all the original documentation and schematics, and it seems that the system was supposed to be able to work with a front panel, although not shipping with one. It has a jumper to put mWrite signal on bus pin 68 for Front Panel use - but we can't see how to work a round this issue with the Run signal.

Has anyone seen or sorted this kind of problem before? Any pointers greatly appreciated. I can make any documentation available if that would be of interest, but did not want to clutter the forum with attachments to this exploratory appeal.

Thanks to any or all,
Rick

monahan_z
June 6th, 2010, 10:53 AM
Rick I just finished doing a Front panel like board for the S-100 bus see here:- for details
http://s100computers.com/My%20System%20Pages/S100Bus%20SMB%20Board/S100%20Bus%20SMB.htm

It was never clear to me why the IA board was so complex and convoluted. Its been a while since I was there but I do remember they used a non defined line for the single step function which on older boards was tied to ground. Check each and every line you are using on all your boards (stripping it to a minimal system first), to make sure nothing is pulled low that should no be. Also see my site about about debugging etc.
http://s100computers.com/My%20System%20Pages/Debugging/Debugging%20for%20beginners.htm
Good luck

John

RickNel
June 6th, 2010, 06:40 PM
John, thanks for this.

I'm already on the waiting list for your system bus monitor board as soon as it is in production. I'm also a student of your debugging guide.

There's a feature of your two-part design that you do not mention on your site. You provide 3 optional daughterboard designs for different display options, plus the headers to strap to a permanent front panel.

In addition, the design also seems to me to invite development of a further daughterboard to export the signals and switch states, including the address-setting switches, via USB to a PC environment for display and control in a "virtual" front panel.

If this is doable, it opens the possibility for lots of extra diagnostic tools including realtime display options, logging for later analysis or cumulative graphical display, address setting in hex, octal or decimal, setting of custom run sequences, automated port scans... anything software can do with the available signal states, recognising that the basic design does not include writing data to system memory.

There could also be ergonomic advantages including reduced stress on components from physical switching (especially the little address DIPs) and perhaps being able to leave the board in a bus in a closed cabinet with just the USB port needed for access (save wear on the bus sockets).

Am I right about these possibilities, or are there reasons I should take a cold shower?

all the best,
Rick

NobodyIsHere
June 7th, 2010, 04:32 AM
John, thanks for this.

I'm already on the waiting list for your system bus monitor board as soon as it is in production. I'm also a student of your debugging guide.

There's a feature of your two-part design that you do not mention on your site. You provide 3 optional daughterboard designs for different display options, plus the headers to strap to a permanent front panel.

In addition, the design also seems to me to invite development of a further daughterboard to export the signals and switch states, including the address-setting switches, via USB to a PC environment for display and control in a "virtual" front panel.

If this is doable, it opens the possibility for lots of extra diagnostic tools including realtime display options, logging for later analysis or cumulative graphical display, address setting in hex, octal or decimal, setting of custom run sequences, automated port scans... anything software can do with the available signal states, recognising that the basic design does not include writing data to system memory.

There could also be ergonomic advantages including reduced stress on components from physical switching (especially the little address DIPs) and perhaps being able to leave the board in a bus in a closed cabinet with just the USB port needed for access (save wear on the bus sockets).

Am I right about these possibilities, or are there reasons I should take a cold shower?

all the best,
Rick

Hi! The S-100 SMB design uses a "display mezzanine" because there are many differing technologies that can be used to display state information. I like to think of the SMB as a lot like a Jade Bus Probe rather than a "front panel" device as it primarily displays information.

I believe you are correct that the "display mezzanine" design uses an interface which is intended for four options: HP5082-7340 (high quality & high cost), LED bars (low quality & low cost), TIL311 (mid quality & mid cost), and "builder defined" which could be literally anything. My guess would be builders would be interested in tying the interface to a uC of some sort and then driving 7 segment LEDs via an ICM7218A or some such arrangement. However, the details of the design are left entirely to your imagination and ability to create such a device.

The display mezzanine is not entirely an outgoing interface as the switch inputs do provide some ability to feed information back to the SMB base board. To what extent those can be utilized for other than their stated purposes is TBD.

I would be glad to assist in the creation of more "display mezzanines" of custom varieties based on builder specifications. My only request is that you donate any new designs back into the "pool" from which the S-100 SMB springs. This is an all amateur volunteer non-commercial project for home brew/S-100 enthusiasts so sharing designs with other builders is nice.

Thanks and have a nice day!

Andrew Lynch

PS, John has done an excellent description of the S-100 SMB here:

http://s100computers.com/My%20System%20Pages/S100Bus%20SMB%20Board/S100%20Bus%20SMB.htm

The S-100 SMB is based on John's original design with some modifications. The base board is essentially complete awaiting a PCB manufacturing order. The second round of display mezzanine prototypes (HP5082-7340s, LED bars, & TIL311s) have been ordered and should arrive soon. Assuming good results the manufactured PCBs should be available in the not too distant future but there is no ETA.

Dwight Elvey
June 9th, 2010, 08:13 AM
Hi
The fact that the address lines are changing means that
the CPU is accessing the bus. The header on the CPU card is just
the CPU's data bus. I'm not sure what you are talking about
Run signal there.
Can you point me to a pdf of your board?
Dwight

RickNel
June 9th, 2010, 06:51 PM
Dwight - sorry to be unclear. I was trying to say that something in the interaction of the CPU card with the bus is blocking data when the Front Panel is providing the Run signal.

Schematics for my CPU card, and an incomplete schematic for the Front Panel, are at http:\\thwaites.homemail.com.au\frontpanel.

I suspect that the logic may be choking because of the ways the two cards are using lines 3, 71 and 72. At least, the schematics use slightly different names for the signals on those pins. I don't know whether that is significant, or quite how to trace out the point where the data being sent to the bus from EPROM is not being read on the CPU card.

Any thoughts appreciated.

regards
Rick

Dwight Elvey
June 10th, 2010, 07:49 AM
Hi
Again, a schematic would help.
Dwight

monahan_z
June 10th, 2010, 11:04 AM
Dwight/RickNel The schematic can be seen at the end of this .pdf document
http://s100computers.com/Hardware%20Manuals/Intersystems/Ithaca_Intersystems_Front_Panel.pdf

Dwight Elvey
June 10th, 2010, 01:09 PM
Hi
Sorry, I didn't make my self clear. The schematic for
the processor card ( the location of the suspected problem ).

Ooops can't read myself. I have the CPU schematic now and I'm looking at it.
Dwight

Dwight Elvey
June 10th, 2010, 02:22 PM
Hi
I think I've traced down your problem. The CPU card you have doesn't seem to do anything
with the SS signal ( pin# 21 ).
This signal is used by the front panel to control DBIN.
SS signal is usually OR'd with RUN+ ( 71 ).
It looks like you where close.
I see the schematic for the front panel normally puts the SS
on the header as well but the IMSAI standard is to only have the data
bus on the header and takes the SS from the bus.
There are also a couple of jumpers J5 and J12 that need to be set
correctly to get the direction correct using SSWDSB- ( pin 53 ) instead
of SS ( pin21 ). Check the wiring there.
Dwight

RickNel
June 10th, 2010, 07:38 PM
Thanks Dwight,

I'll check this out but it may take a few days - the Front Panel belongs to a friend and is not with me now.

Rick

Dwight Elvey
June 11th, 2010, 03:58 PM
Hi Rick
I looked at the front panel manual some more. I believe you can
make it work by removing the drive from the front panel on the line RUN
( 71 ) and wire it to the line SS* ( 21 ) from the front panel. This should
work because the SS* signal already has the RUN signal in it.
This can be done on the CPU board or from the front panel board.
If you wanted to experiment without making a permanent change,
put a piece of clear tape ( trimmed to fit ), on pin 71 and jumper
that signal line on the CPU to pin 21 on the CPU board.
Dwight

RickNel
June 11th, 2010, 05:41 PM
Thanks again,
Rick