On 7/14/06, Jules Richardson <julesrichardsonuk at yahoo.co.uk> wrote: It's a diagnostic LED. Older ROMs have a built-in diagnostic that you invoke by grounding a particular pin on the user port. The diagnostic will fail unless certain user port pins are wired together and certain keyboard pins are wired together (back in the day, C= technicians had a blue folder with instructions and a couple of dongles to attach. I have a set at home, but won't be able to access them for 6 months). Throw a scope on the /CS pin of zero page - when the machine is running, you should see some activity. Perfect. One possibility, of course, is that the mobo is fine and the video is dark. The largest point of failure for old PET is crappy sockets. There's no single IC (unlike the PLA in an C-64) that one automatically gravitates to on a PET. The video is discrete TTL, so there's no video chip (6545) to replace... as long as the CPU can see ROM and see RAM, even a lack of I/O shouldn't prevent it from getting as far as clearing video memory and putting up the normal banner. You won't have keyboard, tape, IEEE-488 or the user port without the 6520s and 6522s, but at the very least, you should see garbage characters on the screen if the video circuit and the monitor are functional. -ethan

Jules Richardson wrote: sounds like the processor is dead, but the video generation circuits may be alive. When you reset one, the screen is scrubbed by the firmware to blank or black, and as you mentioned this probably means the cpu is not getting to the right place, since you see the power on gibberish. Hopefully tony's other suggestion about the sockets, if you have one with such might produce joy. jim

Ethan Dicks wrote: Just going through the motions of reseating chips (again - tried once, but doesn't hurt to do it a second time!) Does anyone have a photo, PCB layout, or access to a real board so that they can check ROM chip locations for me? The 6540 ROMs in mine are arranged (left to right) as: 018 (PCB loc. H7) 014 (PCB loc. H6) 012 (PCB loc. H5) 016 (PCB loc. H4) 015 (PCB loc. H3) 013 (PCB loc. H2) 019 (PCB loc. H1) (6540 #010 is at the back-right of the board, location A2/A3. Character table, I assume) Seems a bit odd - I'm just surprised that they aren't linear. Odd that there's no 017 either, but then there's no 011 - possibly they did that so the two couldn't be mixed up. Date codes are all in 1978, so presumably I'm looking at a first issue of the ROMs? I'd just like to rule out that someone hasn't pulled the ROMs on this at some point and put them back in the wrong positions :-) (annoyingly the schematic correlates ROM memory location with PCB location, but not ROM part number with PCB location) 6550's in this one... Will give that a go if re-seating everything again doesn't work. And 'scope the /CS line... cheers Jules -- (\__/) (='.'=) This is Bunny. Copy and paste bunny into your (")_(") signature to help him gain world domination.

On 7/15/06, Jules Richardson <julesrichardsonuk at yahoo.co.uk> wrote: Doesn't hurt, but if the sockets themselves are a problem, won't do much good. Alas, no... there's a lot of stuff on zimmers.net (what was formerly on funet.fi), but I no longer have a static PET... sold it years ago. I would say so. BASIC 2 for the newer PETs came out around 1978/1979, ISTR; with the upgrade following on its heels. The only way to be sure is the part numbers, though (which, I think, have already been correctly identified by another list member). -ethan

Dave Dunfield wrote: I didn't see anything first time around (re-seating ICs and connectors was one of the first things I did), but I'm just going through it again to be sure. Hmm, that actually sounds like a wise move anyway if this machine is going to be a runnable display system. It's not one of those things that should detract with the machine... I'll have a look at your images - hopefully there's one where I can make out the correct ROM locations too :) Good plan - will do if needed. From the schematic it looks like they're at least x8 devices, so I should be able to make them look like something that my programmer can read... cheers Jules

I'll try to replace 2114 video ram: on three pet I repaired they were defective. Also, put an oscilloscope on the CPU data and address bus and look if signals are all 0 or 5 volts: if you see some strange value like 2-3 volts or attenuated square waves (near 0 or near 5 volts) then there is some defective chip. Then you can try to remove chips one at times to identify it: you'll find it when the strange wave value goes away. Roberto

Sounds like you are at the "real debugging" point. If you have a logic anaylzer or a storage scope, you should be able to catpture the first few accesses to ROM, and confirm that the CPU is fetching the right opcode from the right address by walking the bus lines on the CPU with your probe. Verify that what happens on the bus matches the code in the ROM contant. That fact that you have a screen full of viewable but random characters means the CPU didn't get as far as clearng the video RAM (or possibly could not write the video RAM). Assuming the former, then one of three things has most likely happened: - The program "crashed" due to reading an invalid opcode (check interface between ROM and CPU) - The program "crashed" due to faulty RAM - this usually happens at the first RTS instruction. (check interface between CPU and RAM). - The program is running, but stuck in a loop waiting for an event that never happens. Get the ROM listings from funet, and logically follow the code until the screen is cleared (iirc this is not terribly far into the code) - then note each hardware device (ROM, RAM, PIO etc.) as the code flows through this path, and using a storage scope match up the hardware accesses you see following a reset with the logic of the code. At some point they will diverge. If the CPU has crashed due to bad ROM, this can happen anywhere. If due to a bad RAM, it will likely happen at the end of a subroutine call). In either case, you will likely see bus activity which is unrelated to the logic of the program (since the program is no longer running). In some cases you may see NO bus activity (if the CPU encounted a HLT opcode). If the program is stuck looping on an event, you should see repeated accesses to the affected device and the program will not proceed past this point. Keep in mind that bad bus tranceivers etc. can make any of the above look like any ot the others, so when you are observing "funnies" on the bus, it's a good idea to verify the signals all the way through the entire address/data path. I don't have the schematics in front of me, however as this is a character oriented display, the CG ROM should sit between the video memory and the video shift register. Removing it should effectivly decouple the video RAM data from the visual display, and I would expect to see all white or all black, however with the ROM removed, the inputs to the shift register are basically undriven, and depending on the device you may just be seeing crosstalk from adjecent lines - as long as you get good recognizable characters with the CG ROM installed (even if they are randomly position around the screen), the display is probably working correctly. Scoping the inputs to the shift register should show you what is happening (and you may see lines on the display come/go as you load the pin). Dave -- dave06a (at) Dave Dunfield dunfield (dot) Firmware development services & tools: www.dunfield.com com Collector of vintage computing equipment: http://www.classiccmp.org/dunfield/index.html