Non-working Commodore PET 3016

[SiriusHardware]

The character ROM is the only one that has not been checksummed - I'm still not 100% convinced by my Arduino wiring so is it worth me sending it to you for a check?

You can do that of course, but I am 99% certain there is no need, the video RAM test (your post #1350) is working too well for there to be a serious problem with the display / character generator. The most that could be wrong is the odd bad bit causing one or two corrupt characters, not critical at this moment.

The last post in this thread, despite the thread title, has another version of the Arduino reader sketch you were using attached, the difference being that it also checksums the PROM as it reads it, unlike the original sketch you were using.

https://vintage-radio.net/forum/showthread.php?t=176772

I found that if I used the 'Dupont' type of jumper leads with square plastic connector covers and square pins / sockets, it worked well enough unlike the spindly round-pin 'Arduino' type jumper with round rubber bodies. They would need to be male at the breadboard end and female at the Arduino end, of course. (They are available in all 'sexes').

Ironically one of the checks that Daver2's code does if it gets that far is to checksum UD6, UD7, UD9, but not UF10 because the CPU has no direct read-access to that one.

[ortek_service]

Originally Posted by ScottishColin

So if we did decide on this, get 16 x sockets and 16 x 4116 and replace all existing RAM with 4116?

Stupid question - would this affect the amount of RAM available to the PET and therefore need any jumper changes?

Colin.

Well you could either get 16off and upgrade yours to a 3032, or just fit 8 to start with (but might need to remove the other 8off 4108's) and keep it at 16K - And it does seem that Commodore themselves did this, but there will probably be some link changes required (certainly for going to 32K). But it might work with links unchanged (at least as 8KB?), with just 8x 4116 fitted in lower row instead of the 4108's.

However, it would be nice to try to narrow down the fault in the system RAM Memory circuitry first. And should be possible with the right diagnostic ROM.

But I'm struggling to find where the 'daver2' PETTEST(4?) one / documentation on it came from - do you have a link, as I couldnt see one in this thread?

Although I did stumble across this I hadn't seen before: http://www.inchocks.co.uk/commodore/...T_Computer.pdf
- It does load diagnostics from tape, so not too helpful if not mostly working, but it does give some more info on the original diagnostic connectors (I still haven't found much about the built-into-original ROM's Diagnostic test, activated by pulling Diagnostic Sense line low.


I have found the daver2 PETTEST(4?) ROM discussed in this thread long thread, where he took someone else through many steps of fault finding on their 3032: http://www.vcfed.org/forum/showthrea...of-lines/page4

And I did note that it was said it would still function without zero page working, and there were long delays between tests. But the mentioned manual about the latest version would be very helpful - I assume you're using the latest v4 one?

[SiriusHardware]

While we ponder the mysteries of what's going on with the RAM, I wonder if we can ask yet another favour of Slothie, which is:

Slothie: Could you make us a bit of code (or a modified version of your existing code) which just tries, repeatedly, to write AA to Ram location 0000, attempts to read it, writes 55 to location 0000, attempts to read it, just that, over and over again?

We need this so that we can properly see what's happening with the RAM read / writes, system RAM chip selects (RAS / CAS etc), plus the data passing (or maybe not passing) through the buffers.

If you would be kind enough to do that, I'll pop it into another EPROM and whizz it up to Colin.

[SiriusHardware]

I assume you're using the latest v4 one?

We are, Owen, the test code and the manual are a matched set.

[ortek_service]

Originally Posted by SiriusHardware

We are, Owen, the test code and the manual are a matched set.

Is there somewhere this can be downloaded?
(Maybe it's on vcfed, but you have to be logged in to see it)

- As Colin was also trying to understand what this one should do, and I did read that it could still work without zero page (and presumably stack) area working, before it went on to test the zero page.
So it would be useful to see exactly what it should report, as if it does report the data bits that failed & location (which Slothie was considering adding to his, and probably still worth doing as well as what you've requested it to do), then that might be very useful in seeing how much is wrong.

[ScottishColin]

Here you go - link to code and manual here.

https://drive.google.com/drive/folde...13&direction=a

Colin.

Originally Posted by ortek_service

Is there somewhere this can be downloaded?
(Maybe it's on vcfed, but you have to be logged in to see it)

- As Colin was also trying to understand what this one should do, and I did read that it could still work without zero page (and presumably stack) area working, before it went on to test the zero page.
So it would be useful to see exactly what it should report, as if it does report the data bits that failed & location (which Slothie was considering adding to his, and probably still worth doing as well as what you've requested it to do), then that might be very useful in seeing how much is wrong.

[julie_m]

Originally Posted by ScottishColin

If we decide for the 62256 bodge, I'm happy to give it a go - we've come this far. I'll need a bit more detail though.....sorry.

Colin.

OK. If you look at the 62256 data sheet, you'll see it's a 28-pin chip; but the bottom pins (that is to say, numbers 3-14 and 15-26) correspond pretty closely to the functions of pins 1-12 and 13-24 respectively of a 24-pin PROM.

This is lucky because it means we can fit the 62256 with most of its pins into one of the PROM sockets, with just a few leads hanging out that we will have to wire to other places on the motherboard.

UI10 and UI11 are three-state (i.e. low, high and not connected) buffers that disconnect the on-board RAM chips from the data bus when not being accessed. The 62256 has equivalent buffers built into itself, so these can simply be snipped out to disconnect the on-board RAM permanently.

Pins 3-10 of the 62256 are address lines A7-A0 respectively, and will go into positions 1-8 of the PROM socket, which connect to BA7-BA0 respectively -- the PET's buffered address bus.

Pins 11-13 and 15-19 of the 62256 will go into positions 9-11 and 13-17 of the PROM socket, which connect to the BD lines -- the PET's buffered data bus.

(We missed pin 14 of the 62256, which went into position 12 of the PROM socket. It was 0V.)

That's most of the left hand side of the 62256 accounted for. On the right, pin 20 is chip select, which will need to connect to an extra board with a 74LS00 on it to generate the chip select signal from BA15 and the CPU clock. Pin 21 is A10 and goes to pin 19 of the PROM socket. Pin 22 is output enable, which we can connect to A15 on the chip select board. Pin 23 is A11, which needs to go to pin 18 of the PROM socket. Pins 24 and 25 are A9 and A8 respectively, which need to go to pins 22 and 23 of the PROM socket.

Now pins 2, 26 and 1, in that order, need to go to BA12, BA13 and BA14 respectively, somewhere on the motherboard. Pin 27, write enable, needs to go to BR/W; and pin 28 needs to go to pin 24 of the PROM socket, which is +5V.

Probably the easiest way to arrange this is to make another adaptor with a stack of two 24 and one 28-pin socket, with some pins and plastic removed from the "middle" socket to allow access to the connections above and below.

You will also need a piece of "Veroboard" copper-strip breadboard with 9 tracks, about 14 holes long, on which to build the chip select circuit; which consists of a 74LS00, five 4.7K resistors and a 100nF ceramic capacitor. The copper track connecting pins 3 and 12 of the IC should be left uncut, as should the outermost two tracks which should be used for +5V at the pin 1/14 end and 0V at the pin 7/8 end. The connections are: pin 1, 4k7 resistor to +5V; pin 2, BA15; pin 3, connected to pin 12; pin 4, 4k7 resistor to +5V; pin 5, 4k7 resistor to +5V; pin 6, no connection; pin 7, 0V; pin 8, no connection; pin 9, 4k7 resistor to +5V; pin 10, 4k7 resistor to +5V; pin 11, chip select; pin 13, Bø2; pin 14, +5V. 100nF capacitor from pin 14 of IC to 0V. (I'll draw this out and post a picture when I get a chance.) Stick this somewhere convenient with a stack of self-adhesive foam pads, and pick up +5V and 0V from the nearest IC.

You can practise tack-soldering a wire to an IC pin on UI10 and UI11, which will have to be cut out to disable the on-board RAM.

I hope that's clear enough, but ask if there is anything you are not sure about. I'll post a drawing of the chip select board as soon as I can get one made.

[ortek_service]

Originally Posted by ScottishColin

Here you go - link to code and manual here.

https://drive.google.com/drive/folde...13&direction=a

Colin.

Thanks very much for this - I can see why it was so hard to find via Google search etc.!
I started off looking through the .a65 assembler code, as it is very well commented, to see what it was doing. But then had a look at the manual, as that did clear-up why he choose to put it in the Edit ROM (meaning the Kernal one had to be working OK), as well as having good screenshots and explanations.

What I couldn't understand to start with, was why if you were getting a counting PETSCII sequence appearing on the screen OK, then why it then didn't proceed to doing the Zero-page memory test, after a short delay - Which it should do, provided it reads back OK what it wrote to the screen RAM, otherwise it just keeps repeating the screen RAM Write/Read test forever, until it passes.

So I thought there may be an issue with the hardware, affecting reading back. And I couldn't see why you'd originally (in post #1301) got 2 different generated displays of characters. But then (after finding the PETSCII codes earlier, that I posted a link to) I noticed that although the second screenshot you'd originally posted looked correct (apart from that it seems to default to Alternate rather than Standard character set, as they don't seem to setup the 'GRAPHIC' latch), the first screen starts <Space> ! " etc. And crucially this is actually shifted-up by +32 (So was the previously identified 'D5' stuck high problem!)

And the random alternating between the 2 different displays was a result of this fault coming and going !
Now if the changing of the Kernal ROM socket appears to have fixed this issue, that was identified with the Slothie Kernal IC, I'm wondering how the daver2 PETTEST2KV04 would now run - I have discovered that not only does it display G or B for each byte in Page 0 and Page 1, it also displays '.' if Ok or the actual byte readback as a PETSCII character if bad (so you can then work out which datalines are at fault).


So I was going to suggest temporarily removing the current Slothie Diagnostic ROM Kernal replacement IC (may be able to leave extra tap-off wire, if all pins isolated), refitting the original Kernal one in its place. And then remove the Edit ROM, and fit the daver2 PETTEST2KV04. And see what you now get, if the screen RAM D5 issue has now gone away!
- However, it does appear you have done this in post #1350!

But it might be worth trying again a few times, and waiting a while to see if it does move onto the page-zero RAM test.

I'll take a close look at the screenshot you did get, and see if there might be an odd stuck video memory dataline issue, but it doesn't look like this is the first case at first glance. One of those cheap > 8 ch. logic analysers on the data and R/~W lines etc. may be useful,to see exactly what is being read back from the screen RAM and how it different to what is being written to it.

[ortek_service]

I've just been trying to work out that if the screen uses 25 rows of 40 chars = 1000 Bytes, what happens to the remaining 24 Bytes in the screen RAM. And with some searching, I found a copy of this book which might be useful to PET enthusiasts on here:

http://www.primrosebank.net/computer...Raeto_text.pdf

And on page 4, it confirms that the last 24 Bytes are not used. However, the daver2 PETTESTE2KV04 program writes, then reads all 1024 Bytes.

So you could have the situation that there is some faulty bytes in only these last 24 Bytes, that do not appear to actually be required to work OK, but the test would fail and you wouldn't be able to see why.
And it might have been better if it hadn't checked these / showed a screen RAM read-back failure in a different way (maybe after a delay, clear screen and display a faulty locations list (but would need most to work OK, to see this)

[ortek_service]

I couldn't spot anything obviously-wrong with the later screenshot from running the daver2 PETTEST. But it would seem that it's not happy with something it's reading back from one of the two 2114 video-RAM's
- although not too helpful, if there is an issue with just readback or the odd byte that's not visible in the screen area.


I have just been looking through this one again:
http://www.zimmers.net/anonftp/pub/c...ynamic_pet.pdf

And I note there is some more info about what the internal diagnostic seem to do, that can identify individual main memory IC faults, when the diagnostic plugs are used (although not clear if it does require zero page / stack RAM to work OK). So it might be useful to try the in-built diagnostics, with the original Kernal ROM reinstated, by grounding the diagnostic sense line / conneting some loopback connectors instead of keyboard etc.

That pdf does also mention lifting one end and temporarily crossing swapping over R41 & R42 to swap over the banks, if you do have RAM IC faults in just the first Bank containing zero-page.
So this could be a fairly-quick 'zero-cost' option to try, with the Slothie Diagnostic EPROM still in place, to see if the zero page error message changes. Getting some 'Good' memory in page0&1 would be a bit of a help in starting to get it running - especially as if you could get it going into BASIC, you could then write various programs to test the other main / screen memory.

[ScottishColin]

I've tried to write this a few times and the words below are the best I can get. I don't want anyone to take these words as meaning I don't really need/want/value your help, it's just that at times, I get a little confused about direction. I need all the help I can get.


There is absolutely no way I would have got this far without all of your help, in particular with Sirius' help who has been with this monster 1360 post thread from the beginning. I might have learnt a bit about soldering, sockets, meters, scopes and schematics but I'm nowhere near what you lot know.

As a bear of simple brain, I don't have confidence sometimes with what to do next and I need direction. Having been a PM, I recognise that I need one voice to tell me what to do next and for me that's Sirius. I'm not asking anyone to stop, and I really really appreciate and value everyone's freely given time and assistance, but I'll not move until Sirius says so (with the input of all of you).

Thanks to all again.

Colin.

[Slothie]

Thats a good idea. You only need to get a little over 1k of working memory for the PET to boot up and to be able to run small programs, so 2K of working RAM would be plenty.

[ScottishColin]

That's good sleuthing - thanks.

All of the tests that have ended up with the Daver3 screenshots I have posted have been with the Slothie EPROM out and the original EPROM back in UD9. Hopefully that makes sense.

Colin.

Originally Posted by ortek_service

Thanks very much for this - I can see why it was so hard to find via Google search etc.!
I started off looking through the .a65 assembler code, as it is very well commented, to see what it was doing. But then had a look at the manual, as that did clear-up why he choose to put it in the Edit ROM (meaning the Kernal one had to be working OK), as well as having good screenshots and explanations.

What I couldn't understand to start with, was why if you were getting a counting PETSCII sequence appearing on the screen OK, then why it then didn't proceed to doing the Zero-page memory test, after a short delay - Which it should do, provided it reads back OK what it wrote to the screen RAM, otherwise it just keeps repeating the screen RAM Write/Read test forever, until it passes.

So I thought there may be an issue with the hardware, affecting reading back. And I couldn't see why you'd originally (in post #1301) got 2 different generated displays of characters. But then (after finding the PETSCII codes earlier, that I posted a link to) I noticed that although the second screenshot you'd originally posted looked correct (apart from that it seems to default to Alternate rather than Standard character set, as they don't seem to setup the 'GRAPHIC' latch), the first screen starts <Space> ! " etc. And crucially this is actually shifted-up by +32 (So was the previously identified 'D5' stuck high problem!)

And the random alternating between the 2 different displays was a result of this fault coming and going !
Now if the changing of the Kernal ROM socket appears to have fixed this issue, that was identified with the Slothie Kernal IC, I'm wondering how the daver2 PETTEST2KV04 would now run - I have discovered that not only does it display G or B for each byte in Page 0 and Page 1, it also displays '.' if Ok or the actual byte readback as a PETSCII character if bad (so you can then work out which datalines are at fault).


So I was going to suggest temporarily removing the current Slothie Diagnostic ROM Kernal replacement IC (may be able to leave extra tap-off wire, if all pins isolated), refitting the original Kernal one in its place. And then remove the Edit ROM, and fit the daver2 PETTEST2KV04. And see what you now get, if the screen RAM D5 issue has now gone away!
- However, it does appear you have done this in post #1350!

But it might be worth trying again a few times, and waiting a while to see if it does move onto the page-zero RAM test.

I'll take a close look at the screenshot you did get, and see if there might be an odd stuck video memory dataline issue, but it doesn't look like this is the first case at first glance. One of those cheap > 8 ch. logic analysers on the data and R/~W lines etc. may be useful,to see exactly what is being read back from the screen RAM and how it different to what is being written to it.

[Slothie]

Originally Posted by ScottishColin

As a bear of simple brain, I don't have confidence sometimes with what to do next and I need direction. Having been a PM, I recognise that I need one voice to tell me what to do next and for me that's Sirius. I'm not asking anyone to stop, and I really really appreciate and value everyone's freely given time and assistance, but I'll not move until Sirius says so (with the input of all of you).

Thanks to all again.

Colin.

Thats understandable. Sirius has a very methodical approach that has been working well so far. You don't want to be darting off in all kind of directions.

[ScottishColin]

Thanks for understanding.

Colin.

Originally Posted by Slothie

Thats understandable. Sirius has a very methodical approach that has been working well so far. You don't want to be darting off in all kind of directions.

[Slothie]

I've made a small change to the diagnostic program on request, if the zero page and stack tests are OK it will then test the memory, when it finds an error it will loop continually reading that bad memory location. (This will be the first error address - $4000 on a fully working 16k PET, $8000 on a 32k PET, $2000 on a 8k PET, or the first invalid memory address over $0300 on PET with a bad memory chip).
Otherwise identical to v0.1

[Mark1960]

Originally Posted by Slothie

I've made a small change to the diagnostic program on request, if the zero page and stack tests are OK it will then test the memory, when it finds an error it will loop continually reading that bad memory location. (This will be the first error address - $4000 on a fully working 16k PET, $8000 on a 32k PET, $2000 on a 8k PET, or the first invalid memory address over $0300 on PET with a bad memory chip).
Otherwise identical to v0.1

It might help debug using a scope if it would loop writing and reading, so the R/w controls can be verified. Also if it could do the same for zero page and stack.

Possibly with some way to flag if it passed during retest.

Colin’s PET seems to have a zero page fault, but he has a problem testing if that is a write fail or a read fail.

[SiriusHardware]

As the current version is actually failing on the Zero-Page test it will presumably never get to the 'general' RAM test, so as Mark says it really needs to generate continuous activity on failure to initialise the stack or failure to write to / read from Zero Page as well.

If, on detection of any such error, it would signal the error by displaying a text message and then continue to retry the operation which failed, that would be really helpful. It also needs to do writes to the failed location as well as reads from, in case it is in fact the write side of the test which is failing.

[Slothie]

Originally Posted by SiriusHardware

As the current version is actually failing on the Zero-Page test it will presumably never get to the 'general' RAM test, so as Mark says it really needs to generate continuous activity on failure to initialise the stack or failure to write to / read from Zero Page as well.

If, on detection of any such error, it would signal the error by displaying a text message and then continue to retry the operation which failed, that would be really helpful. It also needs to do writes to the failed location as well as reads from, in case it is in fact the write side of the test which is failing.

Oh OK, sorry I've been offline for a week so I'm really not up to date on where you are with this. I'll have another stab at this, alt least get some kind of read loop into ZP for you, with a possibility of read/write loop.

[Slothie]

Here we go. On ZP or stack error, it will continue to write and read to the failed address, writing $55 and $AA alternately.