7 Jan
2003
7 Jan
'03
7:22 a.m.
Hello Peoples,
I am reading the the mail starting fairly recently. I have a Commodore Pet vintage 1975,
serial # in the 13,000
range, received on Guam while in the U.S. Navy, currently not running has a screen full of
random characters, seems to me I
remember this as indicative of a 6550 MOSTEK ram failure. An Ohio Scientific Superboard,
used as a development tool
by a firm just starting in computer control of the real world. A DEC something that
hasn't been run since it was shut down.
The DEC had the BIG 10m removable drive packs, drives and packs since departed this earth
in one lost shipment or other.
I don't always get to the mail in a timely manner, but it certainly is interesting
reading. I am encouraged that
there are other enthusiasts out there who appreciate the electronics for what it is not
necessarily what it will do at 4.8Ghz.
Faster and bigger is not always better. It seems to me the days when programs had to be
chained, led to better and less
buggy programming.
Kev
kandres(a)epssecurity.com
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.435 / Virus Database: 244 - Release Date: 12/30/2002
7 Jan
7 Jan
10:53 a.m.
--- Kevin Andres <kandres(a)epssecurity.com> wrote:
Hello Peoples,
I am reading the the mail starting fairly recently. I have a
Commodore Pet vintage 1975... currently not running has
a screen full of random characters, seems to me I
remember this as indicative of a 6550 MOSTEK ram failure.
That's one possibility, but typically only if it's in the zero
page area. One way to test that is to swap out the zero page
RAM with a higher page and see if the problem persists. If
the machine comes up with less RAM for BASIC, that's probably
what the problem is. OTOH, those sockets are really crappy.
It's possible that removing and reinserting the RAM will make
a difference. Just pressing down on the socketed parts to reseat
them can revive a "dead" PET.
On a couple of later units, I've had to resort to removing sockets
and replacing them with machined-pin ones. No chips were faulty,
but there was intermittent contact causing all sorts of flaky
behavior.
Using a test instrument (pulse stretcher/logic probe, oscilloscope,
etc.) to monitor the reset line is another thing to check. IIRC,
they use a 555 timer to generate the reset pulse (common in the
mid-70s) and I've seen those circuits fail for a variety of reasons.
You can also build a NOP generator (use a second CPU chip) by bending
the appropriate data bus leads up and hardwiring the databus to the
NOP instruction (0xEA?) - You can then use a logic analyzer to monitor
the address bus for stuck bits and the select lines on the MSI chips
to see that they respond at the appropriate times.
An Ohio Scientific Superboard, used as a development
tool
by a firm just starting in computer control of the real world.
A buddy of mine had one of those when we were kids. He built his
into a robot chassis (his second - the first was run by a Quest
Elf with 256 bytes of RAM). Fun little guys, as I recall.
A DEC something that hasn't been run since it was
shut down.
The DEC had the BIG 10m removable drive packs, drives and packs since
departed this earth in one lost shipment or other.
RL02s. Not rare, but that means that you have the drive controller,
either an RL11 or RLV11, probably (unless it's a PDP-8/a, in which case
it's an RL8A controller, but that's less likely).
There are plenty of people who could help you with that one if you
provide a description of what you have.
Welcome and good luck,
-ethan
__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
11:18 a.m.
Using a test instrument (pulse stretcher/logic probe,
oscilloscope,
etc.) to monitor the reset line is another thing to check. IIRC,
they use a 555 timer to generate the reset pulse (common in the
mid-70s) and I've seen those circuits fail for a variety of reasons.
You can also build a NOP generator (use a second CPU chip) by bending
the appropriate data bus leads up and hardwiring the databus to the
NOP instruction (0xEA?) - You can then use a logic analyzer to monitor
the address bus for stuck bits and the select lines on the MSI chips
to see that they respond at the appropriate times.
Hey, that's pretty slick! Yes, $ea is NOP on the 6502.
--
----------------------------- personal page: http://www.armory.com/~spectre/ --
Cameron Kaiser, Point Loma Nazarene University * ckaiser(a)stockholm.ptloma.edu
-- 10% of computer users [use] Mac ... the top 10 percent. -- Douglas Adams ---
2:19 p.m.
New subject: 6502 NOP tester (was Re: New and reading the mail)
--- Cameron Kaiser <spectre(a)stockholm.ptloma.edu> wrote:
I wrote:
Thanks. I wasn't home and that was from memory.
I have one or two of these in a parts drawer that I bought from
the local C= dealer when they went out of business. *rummage*
*rummage* Here they are!
Pins 29, 31 and 33 are bent up and connected to pin 21, and pins
26, 27, 28 30 and 32 are bent up and connected to pin 8.
I recommend mounting the results in a machined-pin socket. One of
the two I have here has pin 1 broken off, no doubt from too many
rough deployments.
I also recommend not using one in an Apple II or any design where
*reading* memory locations can cause interesting side effects.
In Commodore hardware, you have to *write* to I/O registers to
make stuff happen; not so with the Apple.
-ethan
__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
You can also
build a NOP generator (use a second CPU chip) by bending
the appropriate data bus leads up and hardwiring the databus to the
NOP instruction (0xEA?) - You can then use a logic analyzer to monitor
the address bus for stuck bits and the select lines on the MSI chips
to see that they respond at the appropriate times.
Hey, that's pretty slick! Yes, $ea is NOP on the 6502.
8085
days inactive
8085
days old
3 comments
3 participants
participants (3)
-
erd_6502＠yahoo.com -
kandres＠epssecurity.com -
spectre＠stockholm.ptloma.edu