Re: Non-working Commodore PET 3016
 

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).

Re: Non-working Commodore PET 3016
 

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:

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:

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.

Re: Non-working Commodore PET 3016
 

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.

Re: Non-working Commodore PET 3016
 

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

Colin.

Re: Non-working Commodore PET 3016
 

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.

Re: Non-working Commodore PET 3016
 

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

Re: Non-working Commodore PET 3016
 

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.

Re: Non-working Commodore PET 3016
 

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

Colin.

Re: Non-working Commodore PET 3016
 

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?

Re: Non-working Commodore PET 3016
 

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

Colin.

Re: Non-working Commodore PET 3016
 

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.

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.

Re: Non-working Commodore PET 3016
 

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.

Re: Non-working Commodore PET 3016
 

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.

Re: Non-working Commodore PET 3016
 

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.

Re: Non-working Commodore PET 3016
 

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"?

Re: Non-working Commodore PET 3016
 

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.

Re: Non-working Commodore PET 3016
 

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.

Re: Non-working Commodore PET 3016
 

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.

Re: Non-working Commodore PET 3016
 

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.

Re: Non-working Commodore PET 3016
 

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.