Extended 80 column card issue
Jeff Shanholtz
memory in my IIe. A gamble that I lost. Ha ha. But it was cheap and
pretty simple as far as the circuitry goes. Anyone know what typically
fails on these cards? I tried booting the Apple IIe diagnostics disk
from asimov (A2eDiagnostics_v2.1.dsk) and it reports "no extended 80
column card" (same as it does if I leave my regular 80 column card
in). That is what leads me to believe the card is not functioning. I
haven't seen any other symptoms caused by this card, although I didn't
leave it in for long either.
I've got an arcade game that uses 4164 ram (I understand 4164 and 4264
are compatible) so I can start swapping ram chips in if the ram itself
is the first place to start, but there's also a pair of logic chips.
So if one of the logic chips typically goes out then I'll start there.
Also there's a jumper on the board that's closed. I'm assuming that
wouldn't cause a problem but throwing it out there just in case.
Linards Ticmanis
> Also there's a jumper on the board that's closed. I'm assuming that
> wouldn't cause a problem but throwing it out there just in case.
The jumper should be open on Rev. A IIe Mainboards, and closed on Rev. B
and later. The revision is typically (always?) written on the board
somewhere.
--
Linards Ticmanis
David Empson
If it is a genuine Apple card, the early models were designed for use
with a rev A or rev B IIe.
I'm hazy on the details, but if memory serves, rev A didn't support
Double Hi-Res graphics, and the jumper needs to be set correctly for the
model you are using, or DHR won't work in a rev B and strange things
will happen in a rev A.
--
David Empson
dem...@actrix.gen.nz
Jeff Shanholtz
> If it is a genuine Apple card, the early models were designed for use
> with a rev A or rev B IIe.
>
> I'm hazy on the details, but if memory serves, rev A didn't support
> Double Hi-Res graphics, and the jumper needs to be set correctly for the
> model you are using, or DHR won't work in a rev B and strange things
> will happen in a rev A.
Tried with the jumper open and got the same results ("no extended 80
column card"). I couldn't find an indication of the revision on the
board so I'm guessing that means it's a rev A board, or maybe I just
missed it somehow.
Linards Ticmanis
> Tried with the jumper open and got the same results ("no extended 80
> column card"). I couldn't find an indication of the revision on the
> board so I'm guessing that means it's a rev A board, or maybe I just
> missed it somehow.
Dumb question maybe, but have you ever tried whether the card fulfills
its primary function, namely giving you an 80-column display? What
happens when you do PR#3 ?
--
Linards Ticmanis
Patrick Schaefer
> (...) Anyone know what typically
> fails on these cards?
There is not really much logic on these boards. Only the RAM chips and
two bus drivers. Years ago I've drawn a schematic,
http://john.ccac.rwth-aachen.de:8000/patrick/data/ext80col.pdf
Try PR#3, then the classic "10PRINT"HALLO";20GOTO10". If the screen
fills with 80column text, the board should be 75% okay. If every second
character looks weird, one of your RAM chips is faulty. In case it hangs
after the PR#3, one of the driver chips (sometimes they use PALs to hide
their function) is broken.
HTH
Patrick
Jeff Shanholtz
> Try PR#3, then the classic "10PRINT"HALLO";20GOTO10". If the screen
> fills with 80column text, the board should be 75% okay. If every second
> character looks weird, one of your RAM chips is faulty. In case it hangs
> after the PR#3, one of the driver chips (sometimes they use PALs to hide
> their function) is broken.
Forgot all about being able to switch it to 80 column mode with pr#3.
Ah, memories! Anyway, that worked fine. However, again, that
diagnostics program reported that there wasn't an extended 80 column
card. Also, when I run adtpro when I either try to receive or format,
the program hangs. Works fine with my standard 80 column card.
On first thought it would seem to me that a ram chip that isn't used
by the 80 column feature is faulty, but on second thought I wouldn't
expect that to cause a hang so it seems more likely one of the logic
chips is bad. Opinions?
And thanks for the input so far guys! I love to learn so I'm soaking
it up. And learning is especially fun on my old, beloved apple iie! :)
Linards Ticmanis
> On first thought it would seem to me that a ram chip that isn't used
> by the 80 column feature is faulty,
No such thing, they're all used (one chip holds bit 0 of every address,
one holds bit 1, etc.). But of course it's possible that inside one of
the chips, one or more bits outside the 1 kilobyte area $400 to $7FF
that's used for the 80-column text screen are bad.
You can try a larger area by booting some game that uses double hi-res.
Pirates!, Prince of Persia, Legend of Blacksilver, Zork Zero come to my
mind, but there are probably lots of others. If that works, you'll know
that (depending on what screen a game uses) $2000-$3fff or $4000-$5fff
are working.
And what about the build-in self test (hold CloseApple during power up),
does that pass?
Then there is that "Call-A.P.P.L.E. test disk" that when booted on a //e
should give you an option to test aux memory. You can try that. The ROM
test on that disk is expected to fail on an enhanced //e by the way,
since the disk came out before the enhanced ROMs and doesn't know about
them. And DON'T use the drive alignment test on that disk to actually
modify drive alignment, it does a lot more harm than good.
> but on second thought I wouldn't
> expect that to cause a hang
It can certainly cause a hang if the computer tries to run code from aux
memory, and some opcode is changed by the bad bit(s) into a jump to
nowhere or something that causes an endless loop, for example, or into a
CPU-crashing code on an unenhanced //e (I don't remember whether you
said you got an enhanced machine or not, the CPU in an enhanced //e
can't be crashed as such).
> so it seems more likely one of the logic
> chips is bad. Opinions?
A bad logic chip would be more likely to cause complete failure of the
card, IMHO. All data bits from and to the card go through these buffers,
one of them for video data (such as characters being displayed on an 80
column screen), the other for CPU data (such as characters being written
to an 80 column screen); so you wouldn't see a working 80 column screen
if one of them had failures.
--
Linards Ticmanis
Linards Ticmanis
Boot ProDOS into BASIC, then store some files to /RAM filling it up as
far as you can (load BASIC programs from disks and save them to /RAM for
example). If you can re-load them without errors, chances are the card
is working as it should.
--
Linards Ticmanis
D Finnigan
(I found this out by examining the ROM listing in the IIe Ref Man)
Michael J. Mahon
> A bad logic chip would be more likely to cause complete failure of the
> card, IMHO. All data bits from and to the card go through these buffers,
> one of them for video data (such as characters being displayed on an 80
> column screen), the other for CPU data (such as characters being written
> to an 80 column screen); so you wouldn't see a working 80 column screen
> if one of them had failures.
But any high address line could be bad and the text and hi-res
screens would never know about it...
and:
Unfortunately, only a real memory test will provide any assurance
that the memory is functional. All "use" tests like those above
are insensitive to a large fraction of problems. (Though Murphy's
law pretty much guarantees that if you're actually trying to run an
important app, a flaky memory chip will stop it in its tracks. ;-)
-michael
NadaNet 3.1 for Apple II parallel computing!
Home page: http://home.comcast.net/~mjmahon/
"The wastebasket is our most important design
tool--and it's seriously underused."
Linards Ticmanis
> But any high address line could be bad and the text and hi-res
> screens would never know about it...
Sure, but a bad buffer chip on the card wouldn't cause such a problem,
right? After all only data is buffered on the card, not addresses, if I
understand the schematic correctly.
Of course there might be a problem with the mainboard as well, but the
OP should be able to rule that out by using a different card in this
board, or this card in a different board.
> Unfortunately, only a real memory test will provide any assurance
> that the memory is functional. All "use" tests like those above
> are insensitive to a large fraction of problems. (Though Murphy's
> law pretty much guarantees that if you're actually trying to run an
> important app, a flaky memory chip will stop it in its tracks. ;-)
That is true if the problem is just one or a few bits, but breakage of
larger memory areas should usually be detectable with "use" tests,
shouldn't it? And if the card isn't even detected as being present by
some software, as reported by the OP... I'd assume that either some key
address (say, 0, $400, $1234, $ffff or one divisible by $1000) happens
to be the one that is bad, or it's a larger area; at least if I were
writing code to merely *detect* the card (rather than to *test* it), I'd
probably test such an address or a few of them, and not $73be or some
other "random" value. Since the chance that some one-bit error happens
to be in such a "nice" location isn't high, I'd assume that it's likely
that a whole block of addresses has failed, which "use" tests SHOULD detect.
Feel free to disagree, though. Maybe my thinking is not correct.
--
Linards Ticmanis
Michael J. Mahon
> On 05/23/2011 10:39 PM, Michael J. Mahon wrote:
>
>
>>But any high address line could be bad and the text and hi-res
>>screens would never know about it...
>
>
> Sure, but a bad buffer chip on the card wouldn't cause such a problem,
> right? After all only data is buffered on the card, not addresses, if I
> understand the schematic correctly.
That may be. I'm a little surprised considering the relatively large
fanout to drive memory chips, but apparently buffering is needed only
for the 1MB boards.
> Of course there might be a problem with the mainboard as well, but the
> OP should be able to rule that out by using a different card in this
> board, or this card in a different board.
>
>
>>Unfortunately, only a real memory test will provide any assurance
>>that the memory is functional. All "use" tests like those above
>>are insensitive to a large fraction of problems. (Though Murphy's
>>law pretty much guarantees that if you're actually trying to run an
>>important app, a flaky memory chip will stop it in its tracks. ;-)
>
>
> That is true if the problem is just one or a few bits, but breakage of
> larger memory areas should usually be detectable with "use" tests,
> shouldn't it? And if the card isn't even detected as being present by
> some software, as reported by the OP... I'd assume that either some key
> address (say, 0, $400, $1234, $ffff or one divisible by $1000) happens
> to be the one that is bad, or it's a larger area; at least if I were
> writing code to merely *detect* the card (rather than to *test* it), I'd
> probably test such an address or a few of them, and not $73be or some
> other "random" value. Since the chance that some one-bit error happens
> to be in such a "nice" location isn't high, I'd assume that it's likely
> that a whole block of addresses has failed, which "use" tests SHOULD detect.
>
> Feel free to disagree, though. Maybe my thinking is not correct.
I don't know how his program detects AUX memory. Most memory detection
schemes are as simple as possible--EORing a pattern with a byte, storing
it, and then reading it back, comparing, and restoring--nothing fancy.
The fact that PR#3 gets him an 80-column display says that the way
the monitor detects is is working fine.
In the case of a RAM disk, the vast majority of the memory is used
to store data, not file system metadata, so unless the contents of
files is compared to their originals, very little memory is actually
tested. Data corruption in a large file can go unnoticed for quite
a while.
If large blocks of addresses are bad, and if the "use" uses those
regions and is sensitive to changes in the data, then use will find
the problem. But there are huge numbers of memory failures that
will not be caught without stringent testing.
Memory tests are not hard to find (though some are much more
thorough than others), so finding one and running it is usually
the best way to verify that the memory is working.
If he has another working machine, I completely agree that swapping
cards to "move the problem" is the most efficient way to test.
Jeff Shanholtz
> And what about the build-in self test (hold CloseApple during power up),
> does that pass?
>
> Then there is that "Call-A.P.P.L.E. test disk" that when booted on a //e
> should give you an option to test aux memory. You can try that. The ROM
> test on that disk is expected to fail on an enhanced //e by the way,
> since the disk came out before the enhanced ROMs and doesn't know about
> them. And DON'T use the drive alignment test on that disk to actually
> modify drive alignment, it does a lot more harm than good.
Now we're talking! I didn't know about the closed apple self test. I
don't even think I knew about that as a kid!
It reports: "*RAM ZP 1 0 0 0 0 0 0 0". Anyone know what specifically
that means or where I can look that up? A google search on "apple ii"
"ram zp" didn't turn up anything.
Also, not sure where to find this Call-A.P.P.L.E. disk. Didn't find it
on asimov other than in the pascal programming directory (non-bootable
disk, so I'm assuming they're source code disks).
Thanks guys! Enjoying the discussion! :)
David Empson
> On May 23, 3:02 am, Linards Ticmanis <ticma...@gmx.de> wrote:
> > And what about the build-in self test (hold CloseApple during power up),
> > does that pass?
> >
> > Then there is that "Call-A.P.P.L.E. test disk" that when booted on a //e
> > should give you an option to test aux memory. You can try that. The ROM
> > test on that disk is expected to fail on an enhanced //e by the way,
> > since the disk came out before the enhanced ROMs and doesn't know about
> > them. And DON'T use the drive alignment test on that disk to actually
> > modify drive alignment, it does a lot more harm than good.
>
> Now we're talking! I didn't know about the closed apple self test. I
> don't even think I knew about that as a kid!
>
> It reports: "*RAM ZP 1 0 0 0 0 0 0 0". Anyone know what specifically
> that means or where I can look that up? A google search on "apple ii"
> "ram zp" didn't turn up anything.
The "*RAM" means it is complaining about auxiliary memory.
ZP means it is testing the zero page area of auxiliary memory (locations
$0000 to $00FF) and found an error. It might actually be using "ZP" as
an abbreviation for "Zero Page and Stack", as they are accessed via the
same soft switch, in which case the error could also be in the $0100 to
$01FF area. (In theory it could also extend to the language card area in
$D000-$FFFF, which is also on the same soft switch, but I'd expect the
self test to display an error differently for that area, especially as
there are multiple banks that would need to be described.)
The 1 in the first position means that bit 7 (I think) of memory in the
zero page area of auxiliary memory. If it is always reporting the same
error, it sounds like you have a single faulty RAM chip.
The 80-column text screen uses $0400-$07FF in auxiliary memory, and as
that seems to be OK, it sounds like you have a RAM fault localised
within a specific range of addresses.
--
David Empson
dem...@actrix.gen.nz
Jeff Shanholtz
> The 1 in the first position means that bit 7 (I think) of memory in the
> zero page area of auxiliary memory. If it is always reporting the same
> error, it sounds like you have a single faulty RAM chip.
Thanks. The 1 refers to chip 8 (the silkscreening on the board uses 1
based numbering - you're probably referring to it with 0 based
numbering).
That chip was bad as was chip 3. Had to borrow a couple of 4164's from
my Defender arcade game so I'll have to get a couple chips ordered!
Now the card passes self test, the diagnostic disk I mentioned runs
all tests with flying colors, and adtpro no longer hangs (now I
realize it hangs because of /ram drive).
Appreciate the help everyone! CSA2 is awesome!