Re: option ROM into a 3032

From: Francesco Messineo <francesco.messineo_at_gmail.com>
Date: Wed, 27 Sep 2017 18:13:07 +0200
Message-ID: <CAESs-_wzWESKT+T-R=+zmtnsjPV_e2202+a5xPXPpGN_R7pzig@mail.gmail.com>
Hi Ethan,

On Wed, Sep 27, 2017 at 4:50 PM, Ethan Dicks <ethan.dicks@gmail.com> wrote:
> On Wed, Sep 27, 2017 at 10:24 AM, Francesco Messineo
> <francesco.messineo@gmail.com> wrote:
>> Hi all,
>> I'm repairing a CBM 3032, I've found all the original ROMs have been
>> replaced with EPROMs (but the character generator one). It's probably
>> an upgrade to BASIC 4, but I'll find it out after I dump all of them
>
> Hi, Francesco,
>
> That seems likely.
>
>> It has a 2532 EPROM on UD5, so this might be a well known option.
>
> UD5 is part of BASIC 4, at $B000.  BASIC 2 starts at $C000 so you have
> 3 sockets for option ROMs.


ok, I've never realized (I should have checked indeed) that BASIC 4
neeed one more ROM.


>    http://www.zimmers.net/anonftp/pub/cbm/firmware/computers/pet/basic-4-b000.901465-23.bin
>
> The notes say it's a patched version of the code there.  I don't know
> off the top of my head what is different with the 901465-19
> "unpatched"/original version.
>

>> By the way, the fault on this PET is a garbage screen with moving
>> patterns, some characters change with cursor blinking and key presses.
>> It doesn't seem to react to basic commands though, but I can't think
>> of an easy way to check if it's executing commands correctly.
>
> If it changes with keypresses, then it's possibly doing something.
> You could plug in a disk drive and try loading a directory.  You could
> also try poking values into the User Port and checking the output pins
> with a volt meter.

well, the changes are really small, actually part of the same
character changes (modifying the
character itself), not the character. So it sounds strange to me, I
didn't study yet the character
generation circuit, but it's really strange as I would expect the
character shape is in the ROM, so
it shouldn't change.

>
>> I think I'll start debugging the video generator circuit (it's
>> obviously the non CRTC dynamic board).
>
> Since you have garbage characters, the video timing chain is good, the
> chargen ROM is good, and in fact, a lot of the video circuitry is good
> or you wouldn't have well-formed characters.  It's not impossible that
> there is a fault there and the 6502 isn't successfully writing to
> video RAM, but I can't think of a mechanism that part of the screen
> RAM works but not all of it.  Dead 2114s are _usually_ just that -
> dead.  100% stuck bits.
>
> Do you see any patterns if you hit CLR-HOME?  Every 8th or 16th char
> is cleared?  What if you type the same char hundreds of times?  Does
> that char appear in regular intervals where it was not before?  Could
> be an address decoder or something where the 6502 can't access all of
> the RAM at $8000-$83FF
>
> In my experience, when you start up to a garbage screen, the reset
> circuit could be affected, or you've got a ROM problem (or a serious
> main RAM problem, like the zero page is not working at all).  Check
> your voltages.  4116 DRAMs need +12V and -5V to operate.

of course my first checks always include the 4116 voltages. They're there.

>
> Oh... if you look up how to ground the diagnostic pin on startup (it's
> on the User Port), and the problem you are having is with a bad BASIC
> ROM and not a bad KERNEL ROM, you will get dumped into TIM.  I used to
> do that when I would be working in Machine Language and I had to reset
> and didn't want BASIC to clear my RAM or I'd lose my work.  If the ROM
> at $E000 or $F000 is bad, then this trick won't work, but it's easy to
> try.

the behaviour is the same even with no other ROMs but the petester.bin
image in UD9, it
just moves parts of some characters but it doesn't of course respond
to keypresses.

I'll do the suggested checks and some other ones and report back later.
Thanks so far.
Frank

       Message was sent through the cbm-hackers mailing list
Received on 2017-09-27 17:00:03

Archive generated by hypermail 2.2.0.