PET startup sequence?? (was LF: Commodore PET schematics, troubleshooting info)

[Dwight K. Elvey]

Hi
 If I understand you right, there is a RAM test. Place
this same code in low RAM ( assuming it test going up )
with the initial value such that it doesn't overwrite
your code. If it hanges, it is something that it is
talking to. If it hanges, the ROM problem is likely.
 You migh also look at changing the PS voltage slightly.
Rasing the voltage by 3% should not cause any failures
but if it starts to work, it is an indication.
Dwight


>From: "Dave Dunfield" <dave04a at dunfield.com>
>
>A little more progress...
>
>Here is the BASIC startup code, which is jumped to by the kernel (in F000 ROM) 
if DIAG is
>not pulled low (Basically, it goes either here or the monitor):
>
>; initcz        Initialize BASIC RAM
> D3B6   iD3B6   LDX #$FB
> D3B8           TXS
> D3B9           LDA #$4C
> D3BB           STA $51
> D3BD           STA $00         ; USR Function Jump Instr (4C)
> D3BF           LDA #$73
> D3C1           LDY #$C3
> D3C3           STA $01         ; USR Address [4: C373]
> D3C5           STY $02
> D3C7           LDX #$1C
> D3C9   iD3C9   LDA $D398,X
> D3CC           STA $6F,X
> D3CE           DEX
> D3CF           BNE $D3C9
> D3D1           LDA #$03
> D3D3           STA $50
> D3D5           TXA
> D3D6           STA $65         ; Floating -accum. #1: Overflow Digit
> D3D8           STA $10         ; 3: width of source (unused - from TTY)
> D3DA           STA $15
> D3DC           STA $0D         ; 3: Flag to suppress PRINT or PRINT#
> D3DE           PHA
> D3DF           INX
> D3E0           STX $01FD
> D3E3           STX $01FC
> D3E6           LDX #$16
> D3E8           STX $13         ; Pointer Temporary String
> D3EA           LDY #$04
> D3EC           STA $28         ; Pointer: Start of BASIC Text [0401]
> D3EE           STY $29
> D3F0           STA $11         ; Temp: Integer Value
> D3F2           STY $12
> D3F4           TAY
> D3F5           LDA #$80
> D3F7           BNE $D400
> D3F9           LDA #$00
> D3FB           LDY #$B0
> D3FD           JMP $D41B
> D400   iD400   INC $11         ; Temp: Integer Value
> D402           BNE $D408
> D404           INC $12
> D406           BMI $D417       ; initms        Output Power-Up Message
> D408   iD408   LDA #$55
> D40A           STA ($11),Y     ; Temp: Integer Value
> D40C           CMP ($11),Y     ; Temp: Integer Value
> D40E           BNE $D417       ; initms        Output Power-Up Message
> D410           ASL
> D411           STA ($11),Y     ; Temp: Integer Value
> D413           CMP ($11),Y     ; Temp: Integer Value
> D415           BEQ $D400
>
>; initms        Output Power-Up Message
> D417   iD417   LDA $11         ; Temp: Integer Value
>
>
>On the working PET, I can use 'G D3B6' and it starts BASIC, just as if it
>were running normally. On the bad PET, it hangs, and never prints the message
>which is output by the very next block (D417).
>
>[Interesting side note - this NEVER produces the startup "noise", so it is
>clearly not produced by BASIC either ... a mystery]
>
>Now, on the bad pet, if I do 'G D417', which bypasses this block of code,
>it issues the startup message and comes up in BASIC (somewhat weird because
>various things were not setup, but it's there).
>
>So - thats pretty conclusive proof that this is the block where the problem
>is manifesting itself.
>
>Looking at the block of code, it "shouldn't" hang ... There are only two
>loops, the first is counted by a register (as long as the CPU is good this
>should work, and I have swapped the 6502 with the other machine) ... the
>second goes until RAM fails to verify (this will definately happen by the
>time it reaches the ROM), or the $11,$12 location wraps to a negative
>value (32k max RAM). There are no subroutine calls in this block, so it
>should not depend on a valid stack.
>
>Using my "try BASIC then reset to monitor without interrupting power"
>technique, I see that $11,$12 almost always contains $01,$40, which means
>that it reached the INC $11 once (first time through).
>
>The only way I can see this loop crashing is if the $11 (or $12) location
>does no increment correctly (RAM fauly) - I've manually tested all kinds of
>values in them, or if the ROM "goes bad" during code execution.
>
>[If the $12 location was faulty, I should see "random" values in $11 depending
>on the timing of when I hit reset]
>
>I'm thinking ROM again (this was my "gut feel" when I started because I have
>seen so many PET ROM's go bad) - although it reads OK in my EPROM programmer,
>and also this block dumps correctly from the monitor, both of these accesses
>are fairly laid back - hitting the code is the first time we execute code from
>this device... Timing on execute could be tighter (I haven't checked the
>databook yet), also the frequency of accesses will be much higher ... Perhaps
>if the ROM is marginal, one of these factors is enough to cause a failure.
>
>I think a bad ROM is more likely than a single location in the RAM appearing
>to work for manual tests, but failing during this particular block of code,
>especially considering that the rest of RAM is good enough for lots of other
>stuff to run ...
>
>What do you guys think?  Anyone have experiences with marginal PET roms?
>
>Regards,
>Dave
>
>-- 
>dave04a (at)    Dave Dunfield
>dunfield (dot)  Firmware development services & tools: www.dunfield.com
>com             Vintage computing equipment collector.
>                http://www.parse.com/~ddunfield/museum/index.html
>
>
>