Re: Non-working Commodore PET 3016
 

Is the arduino 5v?

I think I found a problem with the plan, as CLKI controls the multiplexers for address on both the dynamic ram and video ram, the arduino would need to read data only when CLKI is high.

We could still use the arduino to exercise the read and write, but use the scope to monitor the ram data lines.

Arduino powered from 6502 5v supply.

No connection to any other 6502 pins except o2, R/W, DA0-DA7, AB0-AB15

o2 set low as soon as possible.
o2 is acting as an active high chip enable.

LoopStart:
R/W set to low
DA0 to DA7 set to output 0 on first pass, FF second pass, 0 third pass, etc.....
AB0 to AB15 set to output 0.
o2 set high
Delay 5us approx
o2 set low
DA0 to DA7 set to inputs
R/W set high
o2 set high
Delay 5us approx
o2 set low
Repeat from LoopStart

This is only going to write and then read from address 0 and repeat, will need to watch the data lines on the dynamic ram chip with the scope.

o2 will not be synchronised to CLKI, so there may be some very short read or write cycles to the dynamic ram, not sure if this will cause bad data to be written.

Re: Non-working Commodore PET 3016
 

No, better to leave them in place and (at the moment) I think better to try to use the 6502 to test the RAM. With each IC that you try to take out intact you run a fair risk of doing some damage to the PCB. Best to try to test them in-situ if we can.

If you are going to take them out, it's better to have an actual good reason to want to do that - so if we run an in-situ test somehow and that shows that yes, there is a RAM fault then you will probably have to start socketing them so you can test them and move them around. We aren't there yet, though.

At the moment I'm trying to disassemble part of the Edit Prom (UD8) to see if I can identify any firmware driven action which we will be able to detect as a hardware event, because if we can see that happening we can have a bit more confidence that the CPU is able to run PROM code.

I've already found what I think is the 'clear screen' routine some way down in that first subroutine in the Edit PROM which the CPU jumps to at E1DE:

But as we know, either the CPU is not getting far enough to execute that code, or it is executing it but the intended effect (of filling 0x8000-onwards with 0x20) is not happening due to a hardware fault somewhere.

Elsewhere in the same subroutine there is a lot of setting up of and writing to the 6520s and the 6522 going on. I'll need to pull down some data sheets to get an idea of what each of those lines is doing. I'm more than happy for others to duplicate what I'm doing and ideally accelerate past me, since I'm not fluent in 6502.

Re: Non-working Commodore PET 3016
 

Is your pet 16k or 32k ?

The best way to test them would be with a diagnostic rom running on the 6502, but with some way of indicating which bit of the RAM was faulty.

As video ram or the buffers are also faulty this is a bit more difficult, as there would be no easy way to indicate the failing bits.

Maybe a diagnostic rom that writes and reads video ram, without using data ram, would help us diagnose the faults in the video system. With that working we could then use a different diagnostic rom to test the dynamic ram.

Re: Non-working Commodore PET 3016
 

Mark, yes, the Arduino is 5V, that's one reason why it is the weapon of choice for reading or interfacing with old silicon.

The difficulties you've outlined make me think that possibly we should just give the 6502 some test code to try to run. I could draw up a 2716 / 28C16 to PET PROM pinout adaptor. I have some spare 28C16s. We might be able to find a Raspi or Arduino based 28C16 programmer so that Colin would have the ability to program and run any test code we can come up with.

Re: Non-working Commodore PET 3016
 

We almost have that code already in the form of the 'clear screen' routine in #982. Just put a loop around that and increment the character code being sent to the screen RAM on each pass. Ideally with a delay, although such things are harder to do when you can't have a counter in RAM - in fact any test code would have to avoid using RAM for variables or counters and would have to be all inline (no subroutines).

Re: Non-working Commodore PET 3016
 

Maybe colin could review the sequence in #981, but with the address changed to 8000, AD0 to AD14 low, AD15 high. Then we could probably get video ram tested and working easier than dynamic ram.

Re: Non-working Commodore PET 3016
 

Just a thought, is there a reason we can't use the Arduino to generate both CLK1 and B02 (Buffered clock-out 2) with the correct phase relationship? None of this has to happen at anything like real machine speed as long as the clocks, writes, reads, etc all have the correct timing relationship.

Re: Non-working Commodore PET 3016
 

Colin has some experience with Raspberry Pi (which is a 3V3 device) but has only owned an Arduino for about 2-3 weeks so we might be asking a lot for him to put that together at this stage. (Mind you, I was really impressed by how fast he had it up and running the PROM reader sketch, but that was something we found online and didn't need to modify very much).

Re: Non-working Commodore PET 3016
 

Oh, wait, maybe it does have to happen at speed - dynamic RAM, I keep forgetting.

Re: Non-working Commodore PET 3016
 

16k.

Colin.

Re: Non-working Commodore PET 3016
 

If UI10 and UI11 (another pair of 74LS244 buffers, being used as 4*2-way; they buffer the data lines to and from the RAM chips) were socketed, you could (fairly) easily substitute the whole of the motherboard's RAM with a 62256.

Re: Non-working Commodore PET 3016
 

I wrote this software to test memory by replacing the F800 ROM in a 2001-8 PET. If the 3016 has 4k roms you could just pad the binary. ROM versions don't matter because it makes no use of the PETs ROMS. I was going to make it scan the remaining ROMs and identify them but thats still on the to-do list....

The zip archive contains the source for the "64ass" assembler, makefile and a binary image of the F800-FFFF ROM. If you have VICE installed then "make run" will run the emulator with the ROM installed (which is how I have tested it). Its a bit minimal though, just tests zero page, the stack area then finds the highest valid memory address above 0300 and below 8000 (the screen memory).

Re: Non-working Commodore PET 3016
 

Link to video showing pet diagnostics running

https://youtu.be/Y1vA95oqQwI

Re: Non-working Commodore PET 3016
 

They're not on my motherboard, but I do have spare sockets and new 74LS244 chips here if we do decide to go down this route.

Colin.

Re: Non-working Commodore PET 3016
 

Regardless of what the CPU, system RAMs and system ROMs are doing (or not) how are you going to get anything other than a checkerboard onto the screen unless F7, F8 and F9 are singing in tune because at the moment they're clearly not?

Alan

Re: Non-working Commodore PET 3016
 

I've looked at Slothie's material (thanks for that, Slothie) and I agree that the drawback is that the UF7/UF8 Video RAM / UF9 latch and UF10 character generator chain all has to be working in order for the results to be visible.

Shall I make a 'command decision', then?

-Remove and socket the video RAM buffers UE7 and UE8 and while they are out, see if that allows what should be the random data in the video RAMs to finally appear on the video RAM data bus.

-If there is still steady high data coming out of the video RAMS even with UE7, UE8, UF9 removed, remove the video RAMS, intact if possible, and either temporarily substitute a 'modern' SRAM like a 6116 for the video RAM by wiring it into UF7 socket and four pins of UF8 socket, or try replacement equivalent 'legacy' devices in UF7 / UF8 position.

Does that sound like a way forward? I feel, like AJ, that we need a working display chain sooner rather than later, if only to aid with other diagnostic activities.

Slothie, a question about your test code - it looks to me as though the hardware devices - the screen RAM, and the PIAs and the VIA - all reside at the same hardware addresses in your original target PET as they do in the 3016 / 3032. Can you confirm this is the case?

I take it that - in UD9 which is a 4K device - I would have to place the code at F800-FFFF and just leave F000-F7FF unprogrammed, the reset vector would still jump to the correct start address in the upper half of the 4K device if I did that?

Julie, the idea about separating the system RAM from the CPU by removing the data bus buffers is a good one, and to be honest I have wanted to replace those data buffers for a while now anyway, ever since the address line buffers - same device, same age, similar purpose, turned out to be bad.

Re: Non-working Commodore PET 3016
 

I think Colin mentioned that he could get direct replacements for the video RAMs at a very reasonable price so why not use those rather than undertake a rewiring exercise? It still puzzles me that the circuit did generate characters at some point.

Alan

Re: Non-working Commodore PET 3016
 

If they are available at reasonable cost then of course use legacy devices. I'm a bit too used to dealing with another legacy system for which the price of legacy RAM seems inherently extortionate.

Re: Non-working Commodore PET 3016
 

I have sockets and chips for UE7/8.

Would it be sensible for me to get sockets/chips for UF8/9 too? That'll take me a few days more but I'm perfectly happy to do it if it's sensible.

Thanks.

Colin.

Re: Non-working Commodore PET 3016
 

Yes, sockets for those too. You only want to have to desolder the video RAM ICs once. This is one case where I might suggest conventional sockets rather than turned-pin because the pins of the desoldered ICs (should you need to desolder them) will be quite short and will have a thin layer of solder on them.

They may be easier to plug into conventional sockets than into turned pin sockets, if you need to refit them for any reason.