Image Map Image Map
Page 2 of 9 FirstFirst 123456 ... LastLast
Results 11 to 20 of 89

Thread: Faulty 8032-SK with no V-Sync - Gary

  1. #11

    Default

    Yet another thing broken on 'Gary' (and, mostly, another attempt to get to that magical approval-free 10 posts )

    This 8032-SK lived in an outdoor shed for many years on the coast. Many of the pins of socketed IC have literally rusted off, especially on the 6502 and the Character ROM. The CPU I'll replace but thought to try and save the ROM, if possible, by Dremeling the pin open and soldering a new leg on.

    Broken pins - 1.jpg

    Broken pins - 2.jpg

  2. #12
    Join Date
    Feb 2009
    Location
    Southern California, USA
    Posts
    3,049

    Default

    The trick is to use two sockets so that the NOP instruction pattern (1110 1010) is connected to the CPU chip only on the top socket, and the data lines (D7 thru D0) pins 26 thru 33 are open to the board circuitry on the bottom socket. In that way the CPU will happily execute NOPs all day while incrementing the address lines from $0000 to $FFFF. The CPU will then roll over to zero and start again. With a scope you can follow the square waves on the address lines. A0 will have the highest frequency of about 250 KHZ, A1 half of that, and A2 half of A1. If you spot something not in that pattern, you have found the problem. Note however that the RAM address inputs are multiplexed with the dynamic RAM refresh logic so it gets a little messy there. Hopefully with this method you will spot a bad buffer or whatever.


    Also I would look at the eight data lines on the board (not at CPU) for shorted or open signals.

    Here is a schematic from MikeS that shows all the pins straight thru from the top socket to the bottom socket except for the data lines that form the NOP code $EA (1110 1010).

    6502_NOPpcb-ad5f77f0e6c0439f8e08cece619c407e.png
    Last edited by dave_m; September 26th, 2020 at 12:45 PM. Reason: added NOP schematic

  3. #13

    Default

    Quote Originally Posted by dave_m View Post
    The trick is to use two sockets so that the NOP instruction pattern (1110 1010) is connected to the CPU chip only on the top socket, and the data lines (D7 thru D0) pins 26 thru 33 are open to the board circuitry on the bottom socket. In that way the CPU will happily execute NOPs all day while incrementing the address lines from $0000 to $FFFF. The CPU will then roll over to zero and start again. With a scope you can follow the square waves on the address lines. A0 will have the highest frequency of about 250 KHZ, A1 half of that, and A2 half of A1. If you spot something not in that pattern, you have found the problem. Note however that the RAM address inputs are multiplexed with the dynamic RAM refresh logic so it gets a little messy there. Hopefully with this method you will spot a bad buffer or whatever.


    Also I would look at the eight data lines on the board (not at CPU) for shorted or open signals.
    Thanks Dave, will definitely try that.

    I plugged a logic analyser onto the inputs and outputs of the 74154 to try and see if the chip decodes the binary input correctly. This is while the Tynemouth Diagnostic board is doing the ROM CRCs. It selects the ROM one by one and does 16 reads to calculate the CRC of each. Because each ROM is tested 16 times, it's slightly more difficult (a lot actually ) to check if the logic is working, due to the 16 individual selects (see below), but it does seem so. There are 16 inverted CS pulses in the previous-selected ROM but I suspect it might be how the diagnostics board works as it's seen with all the chip-select lines. But it could also be wrong......See screenshot below.

    It'll definitely be easier with clean signals with each address being read only once so I'm going to try the NOP method for sure. Love getting an excuse to build a new piece of test kit.

    74154-3.jpg

  4. #14

    Default

    Quote Originally Posted by Jannie View Post
    A bit of a side-story with more errors on this board

    In addition to the inconsistent CRCs, I noticed the Tynemouth board also reported Reset stuck high and IRQ stuck low. It's also reporting RAM issues with the VRAM (and one can occasionally see random characters on the screen) but I'll fix that a bit later. Probably one of the 2114 chips.

    The stuck Reset line, I traced to a faulty 555, and is now working properly. Quite cool that the PET diag board measures the reset timing.

    The stuck IRQ is probably a bigger issue. From reading the circuit it seems the IRQ is driven by the VIA and two PIAs. So one of these chips is probably pulling this line low. Will go and sniff around them to see if I can see something but suspect I might have to socket them.

    1. The IEEE PIA (UB16) is already on a socket and makes no difference if I pull it. IRO stays stuck low.
    2. Getting the startup chirp so at least some of the VIA (UB15) must be working.
    3. The Keyboard PIA (UB12) is the last one driving IRQ. Is there a way one can short a key and see if it generates an Interrupt?

    Reset stuck high and IRQ stuck low.
    Attachment 63677

    Reset fixed, now to look at that IRQ.
    Attachment 63678
    Looking at these screenshots, I just noticed now that D7 on the Data Bus did not pull high like it previously did. So, yet another problem to chase.

  5. #15

    Default

    Quote Originally Posted by dave_m View Post
    The trick is to use two sockets so that the NOP instruction pattern (1110 1010) is connected to the CPU chip only on the top socket, and the data lines (D7 thru D0) pins 26 thru 33 are open to the board circuitry on the bottom socket. In that way the CPU will happily execute NOPs all day while incrementing the address lines from $0000 to $FFFF. The CPU will then roll over to zero and start again. With a scope you can follow the square waves on the address lines. A0 will have the highest frequency of about 250 KHZ, A1 half of that, and A2 half of A1. If you spot something not in that pattern, you have found the problem. Note however that the RAM address inputs are multiplexed with the dynamic RAM refresh logic so it gets a little messy there. Hopefully with this method you will spot a bad buffer or whatever.


    Also I would look at the eight data lines on the board (not at CPU) for shorted or open signals.

    Here is a schematic from MikeS that shows all the pins straight thru from the top socket to the bottom socket except for the data lines that form the NOP code $EA (1110 1010).

    6502_NOPpcb-ad5f77f0e6c0439f8e08cece619c407e.png
    I see this board straps the 6502 data bus directly to VCC and VSS while you indicated to use a 100ohm resistor per data line.

    Would it be OK to strap the data bus directly to the supply lines?
    Last edited by Jannie; September 28th, 2020 at 02:29 AM.

  6. #16

    Default

    My own 6502's NOP generator is also connecting the databus directly to VCC/VSS, so far I had no issues with it. However, in case some memory is permanently selected, it would kill it. I think the safe resistor value begins at 220 ohms however, and you need one resistor on each databus line to be safe.
    I always check for RAM/ROM/IO chips clashing the databus before resorting to the NOP generator however (it's a kind of last chance on stubborn cases).

    Frank IZ8DWF

  7. #17

    Default

    Quote Originally Posted by iz8dwf View Post
    My own 6502's NOP generator is also connecting the databus directly to VCC/VSS, so far I had no issues with it. However, in case some memory is permanently selected, it would kill it. I think the safe resistor value begins at 220 ohms however, and you need one resistor on each databus line to be safe.
    Thanks Frank,

    So, if the 6502 stays on 1 address and the data lines are strapped hard to supply, it can damage the CPU?
    Quote Originally Posted by iz8dwf View Post
    I always check for RAM/ROM/IO chips clashing the databus before resorting to the NOP generator however (it's a kind of last chance on stubborn cases).
    Frank IZ8DWF
    In this case, with the NOP generator, the CPU is disconnected from the data bus, it only exercises the address bus. If I read you correctly, you're saying that, by selecting chips on the data bus (via the stepping address bus), that could create problem. Can see that, yes.

    How do you check for these clashed on the data bus? Just shorts to high and/or low?

  8. #18
    Join Date
    Jun 2012
    Location
    UK - Worcester
    Posts
    4,104

    Default

    The NOP generator disconnects the 6502 CPU data bus from the PET data bus and 'jams' a NOP instruction directly on the pins of the CPU.

    No damage can, therefore, occur as a result of a data bus clash with the CPU.

    In theory, no damage should occur to the CPU - as it should always be reading instructions from the data bus (with these being NOP instructions) with no data writes occurring.

    It is just the 'engineer' in me that is abhorrent to tying things like this directly to VCC or 0V...

    But, if push comes to shove, tying the data bus pins directly to VCC and 0V saves a few components, a bit of money and construction hassle - so why not. It is only a temporary measure for testing anyhow.

    I once constructed an ETHERNET network from a bit of 2-core flex and a few 100 Ohm resistors for the terminators - bodge job or what (but I had no thicknet ethernet cable or terminators to use)!

    If there are data bus clashes (e.g. one device trying to pull the data bus to +5V and another trying to pull the data bus to 0V) - then your oscilloscope should show you absolutely horrid waveforms that are neither at a logic '0' or a logic '1' level - but (possibly) somewhere in between. The story of the three bears - but in this case neither '1' or '0' is bad...

    Dave

  9. #19

    Default

    Quote Originally Posted by daver2 View Post
    I once constructed an ETHERNET network from a bit of 2-core flex and a few 100 Ohm resistors for the terminators - bodge job or what (but I had no thicknet ethernet cable or terminators to use)!
    Dave
    With Z0 set correctly (like you did), the medium would not be an issue over short distances, so a perfectly acceptable hack.

  10. #20

    Default

    Weekend, so time to work on this again.

    Built a 6502 NOP Generator and it's a pretty cool tool!

    All address signals directly on the CPU and after the first set of buffers (UD13, UD14) looks very clean. Will now start measuring deeper into the circuit. Any hints on where to sniff?

    Then had a look at how UE12 is decoding the ROM select lines (see screenshot below) and the 154 seems to be working as expected. Need to look further for the inconsistent CRC report on all the ROMS.

    I used two back to back tulip sockets and strapped the 6502 data lines directly to VSS and VCC
    Attachment 63854
    Attachment 63855

    Measuring the input (A,B,C,D - the 4 bottom traces in the screenshot) and the ROM select lines (9 to F - top 7 signals) on the 74154.
    Attachment 63856
    Last edited by Jannie; October 3rd, 2020 at 02:42 AM.

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •