- It's a Seattle computer 16K static card. Since the little white
blocks jump around randomly, I don't think it's a problem with a bad
chip or socket. I think it's some sort of timing issue. When I get
around to it, I'll solder in a couple more slots and put in a bus
terminator. "Normal" apps work just fine. Except for the 8K BASIC
problem which I'll discuss in another post. But that problem
appeared before I installed the dazzler and additional motherboard
plate and wires, etc.
But you do have an otherwise excellent comment. Everytime I get a
new card, I reseat the chips and sand away any "black plague"
corrosion I see.
I experimented with the new "DeoxIT" chemical. The residue is
appearently a protectant/lubricant and is non-conductive. So I
tried some on an old HP-25C calculator that had light corrosion on
the PC traces. It seemed to work, but after 2 days it started
acting flakey. I flushed and scrubbed the circuit card with alcohol
and all was fine. It's a good chemical cleaner, but I wouldn't
recommend leaving the residue on circuits with contacts. Anyone
familair with the HP woodstock line will recall the many
gold "fingers" connecting the keyboard to the logic board.
Apparently, some of the residue seeped onto those contacts through
time, resulting in erratic behavior.
The best solution to the corrosion problem I've found is to run a
dehumidifier in the room where you store your old goodies. If you
need to work on something, it's best to remove the unit to another
room, as the lowered humidity increases static potential.
--- In firstname.lastname@example.org, "Steve" <alltare@...>
> That sounds like the kind of behavior that one would often see
> dynamic boards having refresh problems.had
> Is it a MITS 16K static board? The memory chips on those boards
> a tendency to lift out of their sockets. LAy the board on a flatfully
> surface and push down on each RAM chip to be sure they're all
> seated. If you've never done this before, you'll be surprised athow
> many are loose.board
> Always put the memory board(s) as close as possible to the CPU
> to avoid buss ringing problems. Dazzler should work OK withoutbuss
> termination as long as all the boards are close together.trouble.
> --- In email@example.com, "john_crane_59"
> <john_crane_59@> wrote:
> > I wondered when something like this would happen...
> > I'm running a Dazzler in a 8800 with a 16K static RAM card.
> > Kalideoscope works fine (apparently), but Life gives me
> > the dozens of times I've tried to run it, it worked properly
> > once. All the other times the lifeforms stop with a mixture ofblack.
> > and white. But the Life colors are red, green, blue, and
> > Not white.area
> > As an experiment, I wrote a Dazzler program to repeatedly copy a
> > block of known stable data (in ROM) down to the Dazzler mapped
> > for display. I saw little white blocks flitting about thecolored
> > quilt pattern like fireflies. I used my monitor to verify thetwo
> > blocks of data, and I found errors: the white blocks were smalltested. I
> > strings of FFh 2-4 bytes in length. Evidently the copy operation
> > fails randomly. But I knew it wasn't the code as I used a copy
> > routine from my assembly library of known good code, well
> > then changed the code to turn off the Dazzler before the memoryall.
> > operation, then after the copy turn it on with a delay for
> > Now the screen flashed off an on very quickly, but I could still
> > the pattern was perfect - no white fireflies, no changes at
> > the memory card was not to blame, and the chips are well under
> > 1ms access time stated in the Dazzler manual. Apparently, theaddition,
> > copy operation is unreliable when the Dazzler is turned on.
> > I have heard of the infamous bus "noise" problemns in the early
> > 8800s. As it happens, I had to install another bus board to fit
> > Dazzler into my system. Yes - with all those tiny wires! Could
> > this be the culprit? When I installed the new bus board
> > did some basic testing of the system - ran several programs (non-
> > Dazzler) and all looked good. But the Dazzler uses a high speed
> > ( 1M bytes per sec.) Could this be asking too much from a
> > (but weak) bus design? Enough to push it over the edge tofailure?
> > If this is the problem, would a bus termintor card help the
> > situation? I also have a one-piece MITS motherboard I could
> > install, but I would rather not do that as it wasn't original
> > for this model. (And I don't want any more nightmares of thinwhite
> > spiders crawling up my soldering iron to bite my fingers!)Cromemco
> > And if this is a common enough problem in Altairs, I'm surprised
> > this sort of thing isn't mentioned in the Dazzler manual.
> > is usually more thorough than that. But then, I could see Edin
> > Roberts going ballistic over someone criticizing "his computer"
> > print. So I guess the silence makes sense in a weird sort ofway.
> > -J
> > "All my Life is Dead!"
- Well, it turns out to be two smaller gremlins and not one big
one... I spent a whole day diagnosing this, so let me summarize:
1) The "white fireflies" only happen when copying data from the
EPROMS. Maybe they're just a bit too slow for the Dazzler. RAM
works just fine with the Dazzler. And the EPROMS work just fine
without the Dazzler. This turns out to be a red herring as I'll
probably never load software from EPROM while my Dazzler is
running. I originally chose the EPROMs as source data for my block
copy test program for the Dazzler simply because I knew I had some
data out there. Sheer chance.
2) Life "hanging". Apparently, Life requires a RESET switch hit to
execute properly. Just copying the data into the right location and
jumping to 0000h won't do it. And doing a DI prior to the JMP
doesn't work either. (That's part of what the RESET switch does). I
just have to run life from my monitor program (this copies the life
program from EPROM to 0000h and executes it). Then I have to hit
STOP RESET RUN, and everything works perfectly.
Anybody care to guess what else the RESET switch does that could
cause this behavior?
Anybody care to guess what else the RESET switch does that could cause this behavior?
One major things that Reset does is clear all cpu registers.
Perhaps the code in Life expects one of the registers to be clear from the start.
You could try to clear certain registers first and then try to run.