Image Map Image Map
Page 9 of 17 FirstFirst ... 5678910111213 ... LastLast
Results 81 to 90 of 161

Thread: PETunia's Repair Log

  1. #81

    Default

    Many thanks for the help. I need to pause this until the weekend at which point I will build a NOPer.

    re:Video I was thinking about the BLANK_TV signal from the PIA at G8 pin 39 CA2 which then combines in the quad NAND at E9 to gate the video.

    [BLANK_TV is marked at the bottom of sheet 1 of 3 as /EOI; /EndofInterupt?]

    I presume the tester doesn't rely on the Interrupts... one thing I possibly should have reported was there is a degree of snow on the screen I assumed this was a feature due to the lack of sync between the testers (vossi and PETTESTER) and the blanking period.

    Anyway.. better do some work to fund my hobbies! Back soon!

  2. #82

    Default

    Quote Originally Posted by Dwight Elvey View Post
    I thought I'd also mention that the video RAM is scanned as a continuous memory. There is some empty addresses at the end since the screen does not use a full power of 2 size of display. The scan circuit resets the counter at the end of the screen and generates the vertical retrace. One can use that empty space for extra RAM at the cost of flicker when accessed.
    That's interesting. I had never considered that.

  3. #83
    Join Date
    Jun 2012
    Location
    UK - Worcester
    Posts
    3,967

    Default

    And to fill in a bit of firmware details for you:

    The reset vector is in the very top memory locations of the kernal ($Fxxx) ROM. This vectors to the start-up code (that is also located within the kernal ROM).

    This start-up code is only a few instructions long, and ends up calling the hardware initialisation entry point within the EDIT ROM.

    This EDIT ROM routine initialises the hardware devices and clears the screen.

    So, if the PET does actually clear the screen, we know the reset code within the kernal is working and the CPU is correctly getting into the EDIT ROM.

    We also know that works, because my PETTESTER is working, and that requires the kernal ROM reset vector and handful of instructions to also work.

    After that, it is anyone's guess - but it could possibly fall into the following three classes of problems:

    1. ROM bit rot.
    2. RAM faults (especially page 0 and 1).
    3. A stuck interrupt or non maskable interrupt line (/IRQ or /NMI).

    1 and 2 should be fully testable with my PETTESTER.
    3 can be checked with your oscilloscope on the relevant pins of the CPU. The pins should not be permanently LOW.

    After that, we need to investigate deeper...

    Correct, the PETTESTER doesn't rely on interrupts. It specifically disable interrupts - although I can't disable the Non Maskable Interrupt (as the name implies),,,

    The blanking signal is/was used by the PET firmware to only update the screen during the video blanking period (to prevent the snow). It would, however, be interesting to see a video of what you are actually seeing, as this could (a) be normal for your PET or (b) indicate an abnormality that may account for some of your problems (if the video circuits are accidentally being enabled when they shouldn't be).

    It is highly likely that my initial test screens would create snow, but the screen that shows the ROM checksums and the RAM test screen should not exhibit snow. These screens should spend most of their time calculating ROM checksums and testing the RAMS - and not accessing the screen (until the reporting code at least)...

    Dave
    Last edited by daver2; August 6th, 2020 at 04:19 AM.

  4. #84

    Default

    Haven't had much time to get back to the hardware yet but...

    I was wondering... are there images for the patched versions of basic 1,2,4 anywhere?

    I see that VICE patches the memory on the fly using a long list of bytes to POKE, but are there .bins anywhere? I would like to prepare a set of replacement ROMs that had sensible patches in them; currently I only have the original images from http://www.zimmers.net/anonftp/pub/c...computers/pet/

  5. #85
    Join Date
    Jun 2012
    Location
    UK - Worcester
    Posts
    3,967

    Default

    Essentially, BASIC 2 is the ‘official’ bug-fixed variant of BASIC 1...

    Dave

  6. #86

    Default

    So after a bit of a work related gap I am back....

    Good News...

    I have built a daughterboard that allows me to generate NOPs, replace sections of ROM and replace the RAM (below $8000); it's quite large... I hope it doesn't cover up things we need to get to during the NOPulation.

    RPR.JPG

    In the onboard ROM I have some variations.... PETTESTER, VOSSI Tester, Basic 1 (from VICE), Basic 2 (from VICE) and Basic 4 (from VICE)

    I have tested this quite alot outside of PETunia so I'm reasonably confident it works.... So far I have tried...

    Enable 32K Onboard RAM.... works fine with PETTESTER... recognises 32K and tests pass.
    Enable ROM with PETTESTER set... boots as before.... seems OK but strange K@D
    Enable ROM with VOSSI set... boots as before... seems OK
    Boot with onboard Basic 1 ROM.... same behaviour as before boots to Blank Screen!

    I haven't enabled the NOP generation as I don't know what to do!

    I'm building up a nice set of PET gadgets... ROM replacement, RAM replacement, ... ROM/RAM/NOPPER.... but still don't have a working PET!

    What next? (I can make video if that helps)

    PS
    I noticed what looks like an old fashioned LED on the board.... if it is an LED... it isn't glowing.

    LED.JPG
    Last edited by Nivag Swerdna; August 18th, 2020 at 03:33 PM. Reason: typo

  7. #87

    Default

    There is an address decoder. When running the NOP, you should see non-overlapping decodes for section of address, the 74154. Next look at the address bus and data bus. We are looking for contention issues. Pictures of what it looks like for each decode of the 74154 is what we are looking for.
    Sel 8 is for the video RAM. We can look at the various address and data lines. This is tricky as we need to see it at several different time of the multiplex. There should be two different address sequences. One sequence it the scanning of the display the other is the addressing of the NOP tool. We can talk about that more later.
    With the NOP, we'll likely not be looking at the display so you can unconnect that and lift the board if you need to access from the bottom.
    Dwight

  8. #88

    Default

    I don't have a big bench so this is currently being done in the hall so I cannot easily remove the board as I don't really have anywhere to put it... OK so traces of each pin of the decoder... I'll try and do that.

  9. #89

    Default

    OK... i've decided I'm going to try and take the board out for the next tests to be near my desk.... I cannot physically fit the rest of the PET there... can I power with an external supply? Say 9V DC to the connector? (I guess I will have to solder some wires as I don't have a connector like that)

    PS
    Two things I have tried in the meantime... swapping big blue capacitor for one I had which is similar capacity... no change to behaviour.... put relatively new (from Little Diode) RAM chips in the video slots... think that has solved the K@D problem... at least haven't seen it since.

  10. #90
    Join Date
    Jun 2012
    Location
    UK - Worcester
    Posts
    3,967

    Default

    I am going to have to improve my ‘simple’ memory tests for page 0, page 1 and the VDU RAM. The problem is, I can’t use the memory itself as I don’t know if it works or not! I will have to look at some ‘evil’ coding...

    Ok, so we don’t think it is the large smoothing capacitor. However, did you measure the ac ripple on the +5V supply when you put the new capacitor in circuit? It is no good just seeing if the PET starts to work! The reason we suspected the capacitor was the high level of observed ripple on the voltage rail(s). You need to perform the ripple test and see if the replacement capacitor solves that problem. It would be a bonus if that also fixed the PET!

    Don’t forget, you could have more than one fault...

    Before you start pulling the boards out etc. why not use your oscilloscope to monitor the frequency and voltage levels of each of the address lines coming out of the CPU and the far side of the address buffers first (with the NOP generator in circuit)? Address line A0 should have a frequency of 250 kHz (I think) and each higher address line should have a lower frequency by a factor of 2.

    This should check the address bus from the CPU to the address buffers and the address buffers themselves.

    We can then move on to the 4 to 16 decoder next.

    Yes, you should be able to power your PET board with it out of the case from a 9V dc supply. You will have to make sure you attach the wires to the correct points on the PCB.

    Dave
    Last edited by daver2; August 19th, 2020 at 04:00 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
  •