Announcement

Collapse

Forum Rules and Etiquette

Our mission ...

This forum is part of our mission to promote the preservation of vintage computers through education and outreach. (In real life we also run events and have a museum.) We encourage you to join us, participate, share your knowledge, and enjoy.

This forum has been around in this format for over 15 years. These rules and guidelines help us maintain a healthy and active community, and we moderate the forum to keep things on track. Please familiarize yourself with these rules and guidelines.


Rule 1: Remain civil and respectful

There are several hundred people who actively participate here. People come from all different backgrounds and will have different ways of seeing things. You will not agree with everything you read here. Back-and-forth discussions are fine but do not cross the line into rude or disrespectful behavior.

Conduct yourself as you would at any other place where people come together in person to discuss their hobby. If you wouldn't say something to somebody in person, then you probably should not be writing it here.

This should be obvious but, just in case: profanity, threats, slurs against any group (sexual, racial, gender, etc.) will not be tolerated.


Rule 2: Stay close to the original topic being discussed
  • If you are starting a new thread choose a reasonable sub-forum to start your thread. (If you choose incorrectly don't worry, we can fix that.)
  • If you are responding to a thread, stay on topic - the original poster was trying to achieve something. You can always start a new thread instead of potentially "hijacking" an existing thread.



Rule 3: Contribute something meaningful

To put things in engineering terms, we value a high signal to noise ratio. Coming here should not be a waste of time.
  • This is not a chat room. If you are taking less than 30 seconds to make a post then you are probably doing something wrong. A post should be on topic, clear, and contribute something meaningful to the discussion. If people read your posts and feel that their time as been wasted, they will stop reading your posts. Worse yet, they will stop visiting and we'll lose their experience and contributions.
  • Do not bump threads.
  • Do not "necro-post" unless you are following up to a specific person on a specific thread. And even then, that person may have moved on. Just start a new thread for your related topic.
  • Use the Private Message system for posts that are targeted at a specific person.


Rule 4: "PM Sent!" messages (or, how to use the Private Message system)

This forum has a private message feature that we want people to use for messages that are not of general interest to other members.

In short, if you are going to reply to a thread and that reply is targeted to a specific individual and not of interest to anybody else (either now or in the future) then send a private message instead.

Here are some obvious examples of when you should not reply to a thread and use the PM system instead:
  • "PM Sent!": Do not tell the rest of us that you sent a PM ... the forum software will tell the other person that they have a PM waiting.
  • "How much is shipping to ....": This is a very specific and directed question that is not of interest to anybody else.


Why do we have this policy? Sending a "PM Sent!" type message basically wastes everybody else's time by making them having to scroll past a post in a thread that looks to be updated, when the update is not meaningful. And the person you are sending the PM to will be notified by the forum software that they have a message waiting for them. Look up at the top near the right edge where it says 'Notifications' ... if you have a PM waiting, it will tell you there.

Rule 5: Copyright and other legal issues

We are here to discuss vintage computing, so discussing software, books, and other intellectual property that is on-topic is fine. We don't want people using these forums to discuss or enable copyright violations or other things that are against the law; whether you agree with the law or not is irrelevant. Do not use our resources for something that is legally or morally questionable.

Our discussions here generally fall under "fair use." Telling people how to pirate a software title is an example of something that is not allowable here.


Reporting problematic posts

If you see spam, a wildly off-topic post, or something abusive or illegal please report the thread by clicking on the "Report Post" icon. (It looks like an exclamation point in a triangle and it is available under every post.) This send a notification to all of the moderators, so somebody will see it and deal with it.

If you are unsure you may consider sending a private message to a moderator instead.


New user moderation

New users are directly moderated so that we can weed spammers out early. This means that for your first 10 posts you will have some delay before they are seen. We understand this can be disruptive to the flow of conversation and we try to keep up with our new user moderation duties to avoid undue inconvenience. Please do not make duplicate posts, extra posts to bump your post count, or ask the moderators to expedite this process; 10 moderated posts will go by quickly.

New users also have a smaller personal message inbox limit and are rate limited when sending PMs to other users.


Other suggestions
  • Use Google, books, or other definitive sources. There is a lot of information out there.
  • Don't make people guess at what you are trying to say; we are not mind readers. Be clear and concise.
  • Spelling and grammar are not rated, but they do make a post easier to read.
See more
See less

Intersystems Front Panel chokes data on IMS CPU 451 board

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    Intersystems Front Panel chokes data on IMS CPU 451 board

    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

    #2
    Rick I just finished doing a Front panel like board for the S-100 bus see here:- for details
    http://s100computers.com/My%20System...0Bus%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...0beginners.htm
    Good luck

    John

    Comment


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

      Comment


        #4
        Originally posted by RickNel View Post
        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...0Bus%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.
        Last edited by NobodyIsHere; June 7, 2010, 03:46 AM.

        Comment


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

          Comment


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

            Comment


              #7
              Hi
              Again, a schematic would help.
              Dwight

              Comment


                #8
                Dwight/RickNel The schematic can be seen at the end of this .pdf document
                http://s100computers.com/Hardware%20...ront_Panel.pdf

                Comment


                  #9
                  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
                  Last edited by Dwight Elvey; June 10, 2010, 12:18 PM.

                  Comment


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

                    Comment


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

                      Comment


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

                        Comment


                          #13
                          Thanks again,
                          Rick

                          Comment

                          Working...
                          X