Non-working Commodore PET 3016

[SiriusHardware]

Quite a lot to dissect here, I may not be able to give this due attention until this evening, unfortunately (anyone else, please pitch in).

[SiriusHardware]

Certainly there is a V4 ROM disassembly under your link but in this case what we'd need would be a disassembly of V2.

The results of your other measurements are quite interesting.

This one:

UC7 pin 18 (Video On) pulses between 5V and 0V and does not stop pulsing

Appears to suggest that this pin is being programmed as an output, and then is outputting a regular signal (The circuit diagram has an arrow on it showing 'this pin is used as an output'). If that's true, quite a lot has to be working in order for that to be happening.

However the state of UC7 (19) is less clear cut. I would expect that one to be programmed as an output and then turned on (high) to hold the cassette enable transistor Q6 on, thereby holding the cassette motor? driver pair Q5/Q4 off. UC7 / 19 is applying a high to Q6 to turn it on, but not a very convincing one at 2.7V. That might be the best it can manage into a resistive load of 1K + a transistor junction. Or it might be that pin 19 is still an input and is just floating high.

This:

UC7 pins 2-5 go to 4V for about 1 second then back to 0.

Looks as though those port pins on UC7 are being changed from inputs to outputs and then having an initial value of '0' written to them. This is also something which would only usually happen as a result of some early setup code in the firmware succeeding. However, there should eventually be a running binary up-count on those pins as the machine starts to scan the keyboard. It doesn't seem to be getting that far.

[Mark1960]

If you could check the write to video ram in a bit more detail just to confirm there is no write to ram attempt.

UF1-6
UA5-12
UA5-8
UF6-7

These should all show a burst of activity after reset, just want to confirm with the updated settings on the scope.

[ScottishColin]

OK - new UF9 now in place. Solid checkerboard symbols with the chip in place.

Colin.

[ScottishColin]

UF1-6 - I can see one wave/pulse before it settles back to a zero response after power on.

UA5-12 and UA5-8 and UF6-7 go straight to high and stay there.

Colin.

Originally Posted by Mark1960

If you could check the write to video ram in a bit more detail just to confirm there is no write to ram attempt.

UF1-6
UA5-12
UA5-8
UF6-7

These should all show a burst of activity after reset, just want to confirm with the updated settings on the scope.

[ajgriff]

That's odd. With the old UF9 didn't you have a screen full of semicolons and subsequently reverse @ symbols? By the way, were they really displayed as mirror images do you think?

Alan

[SiriusHardware]

Actually, the checkerboard pattern is a better reflection of what was being presented to the inputs of UF9 - all ones (all high). The old UF9 was replaced, in part, because it obviously was not passing on that 11111111 to the character generator.

The question remains whether that 11111111 input to UF9 is coming from the RAMs or is being imposed on the SD... lines by the video databus buffers.

[ScottishColin]

I started with a normal semi-colon then definitely a reverse @ sign.

Colin.

Originally Posted by ajgriff

That's odd. With the old UF9 didn't you have a screen full of semicolons and subsequently reverse @ symbols? By the way, were they really displayed as mirror images do you think?

Alan

[SiriusHardware]

I think Colin may possibly mean 'inverse' rather than 'reverse'? Black character on white (or green, I guess) background? Or do you really mean that the @ symbol was facing in the opposite direction to normal?

[ScottishColin]

My inverse is your reverse - yes. Black on green.

Colin.

Originally Posted by SiriusHardware

I think Colin may possibly mean 'inverse' rather than 'reverse'? Black character on white (or green, I guess) background? Or do you really mean that the @ symbol was facing in the opposite direction to normal?

[SiriusHardware]

I've just used an online disassembler to take a look at the first few bytes the 6502 should try to execute when it gets going.

The bytes at FFFC and FFFD (which I understand contain the jump-to-on-reset address) contain D1 FC and I'm also assuming that these are stored in address lowbyte, hibyte order so the first address the 6502 actually goes to is FCD1.

This is what I see at FCD1 - on in UD9.

FCD1   A2 FF      LDX #$FF
FCD3   9A         TXS
FCD4   D8         CLD
FCD5   20 DE E1   JSR $E1DE
FCD8   A9 89      LDA #$89
FCDA   85 94      STA $94
FCDC   A9 C3      LDA #$C3
FCDE   85 95      STA $95
FCE0   A9 17      LDA #$17
FCE2   85 92      STA $92
FCE4   A9 FD      LDA #$FD
FCE6   85 93      STA $93
FCE8   A9 F7      LDA #$F7
FCEA   8D FA 03   STA $03FA
FCED   A9 E7      LDA #$E7
FCEF   8D FB 03   STA $03FB
FCF2   58         CLI
FCF3   AD 10 E8   LDA $E810
FCF6   30 03      BMI $FCFB
FCF8   4C 11 FD   JMP $FD11
FCFB   4C 16 E1   JMP $E116
FCFE   6C 94 00   JMP ($0094)

Without trying too hard to understand the code we can see that within a few instructions the code does a JSR (jump to subroutine) at E1DE which is an address within the 'Edit' PROM, UD8.

For that to work, as Mark said earlier, there has to be working RAM so that the subroutine call can push the current program counter address onto the stack (in RAM) so that it can recover it and come back to this point afterwards.

If there is a fault in main RAM, the initialisation could fall apart quite quickly.

I do think this is the genuine reset-vector code because the first few bytes set the Stack pointer to the high end of zero-page ram and explicitly set the 'math mode' of the CPU which would otherwise be indeterminate. And then it's straight off into a JSR as soon as the stack is up and running.

[Mark1960]

Originally Posted by SiriusHardware

For that to work, as Mark said earlier, there has to be working RAM so that the subroutine call can push the current program counter address onto the stack (in RAM) so that it can recover it and come back to this point afterwards.

Just to clarify on this, without working ram the 6502 will still be able to execute the jsr and execute code at the target address, but it won’t be able to return to the correct address after that subroutine tries to return.

[Mark1960]

Is there a way to disable the dynamic ram to allow a static ram to be connected without cutting tracks?

Maybe possible to remove the dynamic ram data buffers and connect a 6264 type static ram on the external expansion.

Anyone able to create a diagnostic rom that could exercise read and write to ram, without depending on ram working? Simple loop with write 0 to ram address 0, read ram address 0, write FF to ram address 0, read ram address 0 then repeat.

[ScottishColin]

Is it possible to do this with an Arduino whilst the PET is powered off? or would each RAM chip have to be removed?

Colin.

Originally Posted by Mark1960

Is there a way to disable the dynamic ram to allow a static ram to be connected without cutting tracks?

Maybe possible to remove the dynamic ram data buffers and connect a 6264 type static ram on the external expansion.

Anyone able to create a diagnostic rom that could exercise read and write to ram, without depending on ram working? Simple loop with write 0 to ram address 0, read ram address 0, write FF to ram address 0, read ram address 0 then repeat.

[buggies]

Excuse the second interruption - I could not find any 3016 disassembly but there are some similarities in the start of the 4032 code listed halfway down (look for "Power-Up RESET Entry") this page:-http://www.vcfed.org/forum/archive/i...p/t-50793.html
You might be able to identify some of the addresses from this - and check the "diagnostics line"?

[SiriusHardware]

Is there a way...

First two may be a bit physically complex to do especially when it may be to no avail - third option I agree is a good idea but 6502 is my least familiar CPU by a long mile. Where are Slothie and Julie when you really need them?

Suggestion, every time the test code writes to RAM and reads back the same data it keeps going through all of zero page (0x0000-0x00FF) round and round. If it writes to RAM and fails to read back the same data then have it intentionally run into a KIL instruction.

Continued activity on A0 etc = zero page RAM is OK
Activity stopped on A0 etc = zero page RAM is not OK.

This is the simplest way I can think of to indicate 'pass' or 'fail' without trying to use any hardware which we don't know works yet. Even so, we could also include a bit of code which will try to wiggle one of the I/O IC port pins each time around the loop so if we can see that happening we can definitely then say the code is being executed.

Of course this also means making an adaptor to allow a common EPROM or EEPROM to plug into UD9 position.

I'll have a look at the subroutine in the Edit PROM (which the initial code jumps to almost straight away) to see how that unfolds. What I really want to find is some definite action which the firmware performs very early on, and then look for some hardware indication that that has actually happened. It would be surprising if the 6520, 6522 etc are not initialised very early on.

[SiriusHardware]

Colin, yes, in theory you can take the CPU out and have your Arduino generate all the signals required to access, write to and read from the RAM and it would be a pretty cool thing to try, but with the memory being dynamic RAM that is apt to be more complicated than it would be if the RAM was static RAM. It would take quite a bit of thought about how to do it.

George, acknowledged, from the sound of it that disassembly is the one of the V4 PROMs which I have also found elsewhere and you are right, if both the V2 and V4 PROMs can run in this hardware then any device I/O addresses referred to in the V4 disassembly should also apply in the V2 code as well. Keep the ideas and observations coming, don't be shy.

[Mark1960]

Originally Posted by ScottishColin

Is it possible to do this with an Arduino whilst the PET is powered off? or would each RAM chip have to be removed

If you remove the 6502 and wire the arduino through an adapter to the socket of the 6502, you could test the dynamic ram or the video ram. This would be a slightly bigger version of your prom reader.

If you continuously cycle the dynamic ram it probably doesn’t need to be refreshed, we’ll need to consider what to do with all the other control signals the 6502 generates, but I think a lot of them could be held inactive. This would stop the pet generating video timing, but still test the video ram and identify if the buffers or the ram are the issue.

Edit: this would be used with the pet turned on, but with the 6502 replaced by the arduino.

[SiriusHardware]

Yep, that's the idea. Can I let you work on the detail of what needs to be held in what state? If we are just testing zero page to begin with A8-A15 could be strapped to 0V, possibly. We could expand it to an 'all RAM' test later.

Ref: The need for refresh or not, bear in mind that the Arduino system has a very clunky way of accessing I/O port pins, namely one bit at a time, so if you have a 16-bit address that you want to output you have to scan the variable holding it and output each individual bit to an I/O pin. That makes it a lot slower than you might originally envisage.

Of course you can abandon the Arduino sphere, go direct to the ports at hardware level and access the ports as 8-bit wide parallel ports but that would all be very new to me, while I've done that with PICs and 8051-series microcontrollers I have not attempted to use Arduino boards at native 'bare metal' level.

Despite all the above, I think a better initial move might be to try to get the 6502 itself to run simple test code. We need to know, one way or another, whether the basic CPU subsystem (CPU reads code from PROM : CPU executes code) is working.

[ScottishColin]

Would it be easier for me to think of selectively replacing the RAM chips then? Is there any way to test them at all?

Colin.