[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [N8VEM-S100:1471] New/Old Project (Altair restoration)



Hi Eric,

That does sound like good news.  Those 8T97's on the 2nd CPU board might be the issue there.

Sockets on all the chips shouldn't make a big difference, just as long as they are decent sockets.
The only very sensitive chip that you might not want to socket is the Crystal Oscillator chip, 7404.

How's your soldering? did you give a good visual for solder shorts?  I like to hold the board up with a bright light behind so the board glows, you can see solder shorts and/or micro shorts. 

That's wonderful that you have a 2nd board.   Now you can compare signal pulses between them.  Go pin by pin on the CPU board, make your notes or take pictures.

Yes, it does eat lots of time.  I have the same frustration with time.  Every project turns into hours, but I love doing it so those hours pass by so fast!  But rest assured, you will find the problem(s) and fix if you keep studying the schematic, datasheets, etc The victory in the end is worth it! :)

Cheers,
Josh






From: er...@osmancrew.com
To: n8vem...@googlegroups.com
Subject: RE: [N8VEM-S100:1471] New/Old Project (Altair restoration)
Date: Mon, 25 Feb 2013 11:59:49 -0800

Hi Josh -
 
Thanks for all the pointers and ideas.
 
Voltage levels to CPU chip OK.
 
I wired up a proto board to pull the DI lines low for the NOP test as you suggested.  Going through a 100 ohm resistor didn't seem to successfully pull the lines low, so I tied directly to ground.
 
I still observe very flaky behavior with that CPU board that I can't begin to characterize.  You've got me wondering if those sockets I put on that board were a good idea.
 
I have another used Altair CPU board I bought a few years ago in anticipation of this project.  When I tried it the address bus does "count" as you suggest, but that board has its own problems.  I can stop the processor and reset.  Examine next seems to work, if I look real close at the lights.  This got me to checking the voltage levels on the address bus (with the processor stopped).  "High" is in the range of 1V.  "Low" is in the range of 0.1V.  This varies a bit from one address line to the next.  For some lines "high" is in the range of 1.5V which is enough to actually light the LED on the front panel.  Recall that with the first CPU card (the one I rebuilt) I was seeing more like 3.4V.  I verified that the addresses output to the 8T97 from the CPU chip are in the +5V range.  I notice the 8T97 seems to be getting fairly warm so it must be dissipating all that voltage internally for some reason.
 
My current plan is to pull one of the 8T97s from this CPU and put a socket in there to see if a new 8T97 works better.  If I can get a known working CPU I feel like I can begin to debug any problems I may have on the front panel.
 
Fun stuff.  Eating lots of time.
 
Thanks again.  I really appreciate your help.
 
- Eric
 
-----Original Message-----
From: n8vem...@googlegroups.com [mailto:n8vem...@googlegroups.com]On Behalf Of Crusty OMO
Sent: Sunday, February 24, 2013 9:44 PM
To: n8vem...@googlegroups.com
Subject: RE: [N8VEM-S100:1468] New/Old Project (Altair restoration)

Hi Eric,

Yes, you must have the front panel in place.  It is required to put the CPU in a "RUN" mode.  The front panel controls or generates the CPU mode (RUN, WAIT or RESET).  The 2 lines of interest are the pRESET (pin 75 on the S-100) and XRDY (pin 3).
Other S-100 lines of interest are pRDY (pin 72), and pHOLD (pin 74).

When running the NOP test, you want to scope every pin on the CPU to understand what it's doing.
Look at the timing diagrams of the 8080A data sheet.
1st check the voltage pins (good idea to check ground pin 2 with ohm meter prior to powering system).
2nd check the CPU clocks, Pin 22 & 15 should have non-overlapping positive pulses to 12V.  These are not TTL inputs.
3rd check the CPU mode, Reset* pin 12 must be high, Ready pin 23 must be high, Hold pin 13 must be low, INT pin 14 should be low.
The mode inputs should be steady, no pulses.
4th check the CPU timing output pulses.  WR* pin 18 should be high (we're executing NOP's, there should be no memory writes), DBIN should be pulsing high to fetch/read the NOP instructions, Sync pin 19 should be pulsing high during M1 of every cycle as per the data sheet.
5th Scope your data lines, these should be LOW (as tied low for the NOP) during the DBIN pulses, some pins should pulse high during the PSYNC to indicate M1 and sMEMR cycles (read the data sheet).
6th Scope your address lines, these should be counting up, you should see them all toggling high/low.  Follow this signal onto the S-100 bus.

The advantage of running NOP's, is that the CPU wave forms are repetitive and easy to follow on the scope.
Also, it eliminates all other memory and I/O boards, breaks your system down to the basics.

See CPU run.
Run CPU run.

Once you can get this far, it's likely that your system will operate if the other boards are good.
But getting here isn't always so easy.

I did a similar test to fix my OHIO Superboard.  It was working intermittently with the NOP test.  The problem was bad sockets, to make things a challenge, when I would scope a pin, the pressure put on that pin would make it temporarily connect.  I think the Altair used good quality sockets, but best to keep your wits about you!

Please keep in mind that I'm running an IMSAI 8080, but I think it's almost an identical copy of the Altair.

Cheers,
Josh









From: er...@osmancrew.com
To: n8vem...@googlegroups.com
Subject: RE: [N8VEM-S100:1452] New/Old Project (Altair restoration)
Date: Sat, 23 Feb 2013 21:54:57 -0800

Hi Josh -
 
I assume I can leave the front panel hooked up for the NOP test?  I dread the thought of removing and replacing all those wires again.
 
I actually have three different 8080 chips and the computer doesn't work with any of them, although the symptoms change slightly.  In any case I have a new one on order "just in case".  It is true that none of the three are "known good", so I like the idea of this test, I just hope I can do it with the front panel in place.
 
- Eric
-----Original Message-----
From: n8vem...@googlegroups.com [mailto:n8vem...@googlegroups.com]On Behalf Of Crusty OMO
Sent: Saturday, February 23, 2013 9:29 PM
To: n8vem...@googlegroups.com
Subject: RE: [N8VEM-S100:1449] New/Old Project (Altair restoration)

Hi Eric,

Very cool!

I have an IMSAI 8080.  I checked the address lines and I also get 3.43V.  Using 8T97 chips.

You are right about the LS chips not being an exact replacement for the standard chips.
They will work well enough as drop in replacements for digital circuits, but a crystal oscillator is an analog circuit.
I have seen such oscillators fail with same part numbers by different manufacturers.
That same oscillator circuit even failed by simply installing a socket.  Trust me, I didn't believe it at first but after installing and removing it a few times, I recognize that crystal oscillators using TTL are very sensitive.
Lee Hart has taught me that CMOS chips make much better choices for crystal oscillators.

Back to your Altair.  The 3.4V should work fine, it does on my system.
The ring looks big, but I don't believe it's beyond a reasonable amount for a functioning system.
You can probably reduce the ring by terminating that line, but it's quite likely you don't need to.

May I recommend a "NOP" test?  Remove all boards except the CPU.  Pull the DI0-7 lines low.  Ground them or use 100 ohm.  There shouldn't be anything driving those DI lines, so be suspicious if you read voltage on those lines.
This is the NOP command, let the CPU run, now scope all the lines.  Look for pSync, o1, o2, clock, MEMR, DBIN.  The address lines should be counting.  Check your CPU for correct voltage, check the WAIT, HOLD and RESET signals.  Your CPU must be running, if not, then you have a bad CPU chip.  If anything isn't right, trace the signals back to the front panel switches.  Check that DI0-7 is reaching the CPU through the buffer chip.

I hope that idea helps. good luck.

Josh






> From: er...@osmancrew.com
> To: n8vem...@googlegroups.com
> Subject: RE: [N8VEM-S100:1447] New/Old Project (Altair restoration)
> Date: Sat, 23 Feb 2013 20:07:43 -0800
>
>
> With advice from Tom Lafleur and others I've been making some progress on my
> Altair restoration. This machine was killed by a lightning induced power
> surge many years ago. I've installed new, modern power supplies, and I've
> removed all the chips from the front panel and the CPU. These were replaced
> with sockets. I learned that apparently, you can't always replace 74xx with
> 74LSxx. I learned this when the system clock would not run when I tried two
> different 74LS04 chips in the clock circuit but works fine with a 7404.
>
> Anyway, after repopulating the chip sockets with mostly LS parts, the Altair
> exhibits very strange and unstable behavior. I almost don't know where to
> begin to describe it. Let's just say that the results of a reset are fairly
> random.
>
> I thought I'd ask a few specific questions:
> If I "stop" the Altair and check the voltage of an address line on the bus
> that is high, I get about 3.4 volts. The only boards in the system are the
> front panel and the CPU. In this configuration, all that's going on is the
> 8080 address lines are buffered through 74LS367’s onto the bus. The front
> panel is involved only insofar as the address lines each go through an LED
> and a 220 ohm resistor to ground to display the address line's state. Hard
> to imagine a simpler situation. The output from the 8080 is a healthy 4.9V
> where it goes into the 74LS367, but on the output side it is only 3.4V.
> This low voltage value for a high logic state seems like a potential problem
> to me. Am I right?
>
> Lest you think it might be a bad 74LS367, be aware that I previously had the
> functionally equivalent 8T97 chips in there and had essentially the same
> result.
>
> Also, the CPU and front panel regulators were replaced and I get a healthy
> 4.96V on the +5 side of the regulators.
>
> So the immediate questions are:
> 1. Am I right in saying that the 3.4V level is an issue?
> 2. If so, any ideas what could be causing this?
> 3. I'm attaching the oscilloscope trace of the system clock as seen on bus
> line 49. Does that look OK, or is there too much ringing?
>
> CPU Schematic here:
> http://www.s100computers.com/Hardware%20Manuals/MITS/8080%20CPU%20Board%20Sc
> hematic.pdf
>
> Thanks for your ideas.
>
> - Eric Osman
>
> -----Original Message-----
> From: n8vem...@googlegroups.com [mailto:n8vem...@googlegroups.com]On
> Behalf Of Eric Osman
> Sent: Saturday, February 02, 2013 12:48 PM
> To: n8vem...@googlegroups.com
> Subject: RE: [N8VEM-S100:1357] New/Old Project
>
>
> Douglas -
>
> Thanks for the introduction and summary. I'm on Andrew's list for an
> extender, and I'll probably be looking to obtain a prototyping card as well.
> These are driven by my initial goal, which is just to get my Altair working
> again. Longer term I'll be looking to enhance it a bit.
>
> I was intrigued enough by the Raspberry Pi to get one, but of course, that
> is not the focus of this board.
>
> I'll be looking over the Wiki's and mail group archives that you mentioned.
>
> Thanks again.
>
> - Eric
>
> -----Original Message-----
> From: n8vem...@googlegroups.com [mailto:n8vem...@googlegroups.com]On
> Behalf Of Douglas Goodall
> Sent: Saturday, February 02, 2013 10:52 AM
> To: n8vem...@googlegroups.com
> Subject: Re: [N8VEM-S100:1355] New/Old Project
>
>
> Eric,
>
> Our group consists of lots of old-timers and youth as well.
>
> Apparently all of us like to fiddle with hardware, and there is quite a lot
> of fun going on.
>
> The major interests within the group are focused on a range of hardware, as
> simple as a single
> board computer (See the Zeta), and more sophisticated buss oriented systems,
> both S-100 and ECB.
>
> Andrew supplies bare circuit boards for us, mini boards, SBC's, and a highly
> integrated machine we
> started calling the N8 (originally named "Home Computer").
>
> John sells S-100 bare boards, CPU cards, memory boards, ...
>
> There are two main Google mail groups, one for Andrew's focus
> (n8...@googlegroups.com) and one
> for John's (n8vem...@googlegroups.com). There is another one recently
> formed for the scsi to ide
> project, aka S2I.
>
> Information about the boards, schematics, board layouts, etc are found on
> the wiki (n8vem-sbc.pbworks.com).
>
> Building these boards is a learning experience, and we gain knowledge about
> sourcing parts, building up
> boards and then debug them. The community members are very happy to help
> each other get things working
> the google groups are a constant stream of questions and answers about
> aspects of the hardware and
> software.
>
> There are a number of different BIOSs written by community members, some of
> which are more specific and
> some of which are more productized and full featured. If you want to find
> out more about the boards, look
> under board information on the wiki. There is a software information section
> as well.
>
> Welcome to our community, and don't be shy to communicate with us via the
> lists or privately.
>
> Regards,
>
> Douglas Goodall
>
> On Feb 2, 2013, at 1:23 AM, Eric O <ewo...@gmail.com> wrote:
>
> > Andrew Lynch suggested I join this group and seek assistance with my
> "project".
> >
> > Background:
> > Back in 1975 I was a 20 year-old electrical engineering college student
> and electronics hobbyist and saw the famous Popular Electronics article on
> the Altair 8800 computer. I ordered it, assembled it and it worked great as
> soon as I powered it on for the first time. Over the next year or three I
> enhanced it with some additional memory, a homebrew parallel and serial
> interface and the Processor Technology video card. I wrote hand-assembled
> machine code to "boot load" my own little monitor via a modem to the
> mainframe computer on campus. This involved an automated log-in to my
> account, starting the listing of a hex file and then capturing and loading
> that hex file into the Altair RAM. Of course I had to switch a couple
> hundred bytes of machine code into the Altair whenever I needed to "reboot".
> I also wrote a terminal emulation program so I could then use it as a
> terminal to that same mainframe. Great fun and done on a shoe string
> because I was a very poor college student.
> >
> > Disaster literally struck out of the sky one day around 1979 when a very
> powerful thunderstorm hit and a lightning bolt literally blew the top off
> the power pole that fed the off-campus house I shared with three other
> students. I should have unplugged the Altair when the thunderstorm arrived,
> but I didn't want to have to take 15 minutes to reboot it. Stupid! Anyway
> the power surge killed the machine. It would still light up but it wouldn't
> do anything approaching normal operation. I did replace a number of the
> chips in the weeks that followed, but I couldn't afford to do a proper job
> of it.
> >
> > Well, graduation came, then a job, then an IBM 5150, and then other
> computers over the decades and now the Altair has been stored in a box for
> almost 35 years. I always meant to fix it someday but never got around to
> it. But now that I'm semi-retired from a career in computers I'm finally
> getting around to it. So a couple months ago I finally got it out of that
> box and started doing a bit of research and I'm so happy to see all the love
> that people have for these old machines.
> >
> > One of the first things I learned was not to trust the original power
> supply. So I went out and got a couple switching power supplies from
> MeanWell, mounted them up in the chassis, and leaving the old supply
> physically in place, removed it electrically and replaced it with the new
> supply.
> >
> > I popped out all the boards, and turned it on. I'm getting all the proper
> voltages in all the proper places, including regulated +5.13 on the display
> board. With the CPU in I get the proper regulated voltages on the CPU card:
> (-5.25 on Pin 11, +11.69 on pin 28, +5.00 out of the regulator).
> >
> > I've started working on the front panel and I've already identified two
> inverters with the same logic state on each side of the gate, on two
> different chips. So I know I need to replace those.
> >
> > Any and all suggestions welcome.
> >
> > (I've seen the very good article at
> http://s100computers.com/My%20System%20Pages/Debugging/Debugging%20for%20beg
> inners.htm)
> >
> > Eric O
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> "N8VEM-S100" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> email to n8vem-s100+...@googlegroups.com.
> > For more options, visit https://groups.google.com/groups/opt_out.
> >
> >
>
> ---
> Douglas Goodall, http://goodall.com
>
> Note: I don't use messenger, or skype, or facebook, chat programs in
> general. Having always-on open communication links through massive public
> servers I don't have control over seems like too much of an invitation to be
> infected by a virus or bot. It is bad enough that my Mac wants to stay in
> periodic contact with Apple's cloud. Skype was tempting before Microsoft
> bought them. There have been too many examples of remote session links being
> abused by vendor employees. Even "back to my mac" makes me nervous. There
> was a recent episode where Apple cooperated with a social engineer and
> compromised someone's entire electronic persona. If you want to speak with
> me, calling me on the phone works well, and you don't have to wonder if the
> electronic mail got through or not. When I say "Hello, this is Doug", you
> know who you are talking to. Just in case you were curious.
>
> --
> You received this message because you are subscribed to the Google Groups
> "N8VEM-S100" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to n8vem-s100+...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "N8VEM-S100" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to n8vem-s100+...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
> --
> You received this message because you are subscribed to the Google Groups "N8VEM-S100" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to n8vem-s100+...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

--
You received this message because you are subscribed to the Google Groups "N8VEM-S100" group.
To unsubscribe from this group and stop receiving emails from it, send an email to n8vem-s100+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
You received this message because you are subscribed to the Google Groups "N8VEM-S100" group.
To unsubscribe from this group and stop receiving emails from it, send an email to n8vem-s100+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
You received this message because you are subscribed to the Google Groups "N8VEM-S100" group.
To unsubscribe from this group and stop receiving emails from it, send an email to n8vem-s100+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
You received this message because you are subscribed to the Google Groups "N8VEM-S100" group.
To unsubscribe from this group and stop receiving emails from it, send an email to n8vem-s100+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.