Image Map Image Map
Page 9 of 9 FirstFirst ... 56789
Results 81 to 83 of 83

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,874

    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.

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
  •