Commodore PET 4016

[ortek_service]

I wonder if having DRAM matrix-ed, mean you only had to read all the row addresses to do the refreshing, with the DRAM refreshing all the columns for you? Rather than having to read through the entire memory locations yourself.
Which if CPU had to do this, then it might impact the speed a bit

- Maybe more on a 6502 (rather than a microcoded Z80 with more execute cycles per machine cycle), especially if video is accessing the DRAM on the CPU's execute cycle, so not delaying it.
Although the video could then effectively refresh the DRAM (In the Beeb, Video Memory was 20K max, but maybe all row addresses of the 32K RAM were accessed?). Although things must have got a bit more complicated with Shadow & Sideways RAM, ensuring all of this was paged-in often enough (However the Master 128 did have quite a few logic arrays to put circuitry in to do this).
And with the Z80 in the Spectrum, the ULA no-doubt extended refreshing to the extra 32K DRAM above the base 16K.

I imagine things were further involved in the SuperPET, although if Commodore stuck to doing it all themselves, then less of a worry about extending more-limited refresh logic built into CRTC's etc.

[Mark1960]

Don’t confuse the number of cycles needed to refresh 64k dram chips and the number of cycles to refresh 64k of dram. Z80 has a 128 cycle refresh counter, which is ok for 4116 type dram, even if the system has 64k of 4116, because all the 4116 dram chips will be refreshed at the same time. The problem starts with 4416, 4464 or 4164 dram which need 256 refresh cycles, so with the z80 the refresh address A7 needs to be toggled for each 128 cycles of the refresh counter. I think the z80 designers didn’t expect memory sizes to increase as quickly as they did, or maybe expected larger dram chips to continue using 128 refresh cycles.

[julie_m]

Asserting RAS refreshes an entire row of static RAM.

The 6502 accesses memory with every single clock cycle. It puts an address onto the bus as the clock goes high; this takes a few tens of nanoseconds to stabilise, and if the memory is being read, the processor will be expecting data on the bus and stable at the instant the clock goes low again.

What the PET does, by means of having multiple copies of the clock signal with precise delays from one another, is:

1. RAS goes briefly low with the refresh counter on the memory address bus -- this causes the whole row to be refreshed.
2. RAS goes briefly low with the low-order bits of the 6502 address bus on the memory address bus -- this selects the row where the processor is going to read or write.
3. CAS goes low with the high-order bits of the 6502 address bus on the memory address bus at the same moment the CPU clock goes low -- and either the contents of that address will change to match the contents of the data bus, if it is a write operation, or else the contents of the data bus will be latched into the processor.

All the while the CPU isn't talking to memory at all, it isn't talking to the display memory; so the CRTC can access it. And what's more, it's static RAM, so doesn't need any refreshing and only takes one operation to read the contents of a location. Oh, and given that each scanline takes 64 µs including the flyback, one memory access per microsecond gives us a 40 character wide screen. Super nice

In the BBC Micro, the memory is clocked at 4MHz, with the processor and CRTC alternately accessing memory effectively at 2MHz each. The CRTC asserts RAS and CAS to read a byte (and refresh the whole row), and then the CPU takes its turn to assert RAS, CAS and read or write a byte. And except in MODE 7, the contents of memory represent not character codes, but individual pixels. So there is actually six-way multiplexing on the DRAM address lines (CPU, CRTC in bitmapped graphics mode with video ULA, and CRTC in Teletext mode with SAA5050; all with variants for the high and low-order bits)!

[ortek_service]

Originally Posted by ortek_service

Yes, I saw that, it was a Model 4032, as on the front RHS (The sold sticker was on the CRT, when I saw it)
- Just as the one here effectively now is.

So I mentioned this (+attached a picture of it) yesterday in this thread, in post #378:
https://www.vintage-radio.net/forum/showpost.php?p=1702043&postcount=378

And yet another 4032 was at the weekend-just-gone (Commodore) ZZap! Live 2025 event - The only PET I saw there this year.
On the lower-front, there was also an old hand-written sticker with the POKE's for changing between Upper & Lower case
- See attached pictures.

[ScottishColin]

Thanks all for the DRAM input. I will try to learn a little (that's the best I can promise - old dog, new tricks and all that) from the posts.

74177s turned up today. I put one into the empty UE6 socket and all signals/frequencies are now present and correct on UE6 and UE7 which were absent before - thanks for the pointer Tony.

Julie's code now runs with no workspace, stack or zero-page errors (see photo attached). I'm running a soak test now.

The next problem is that both PETTESTER and the Commodore Diagnostic clip that I have reckon the PET is only fitted with 16k RAM so I need to work on why that is after thorough testing with ToePost.

Colin.

[TonyDuell]

When you run a diagnostic program that should access the upper 16K block of RAM, does CAS1/ (UD5, pin 11 as on Sheet 6 of the schematic) ever pulse low?

[SiriusHardware]

The next problem is that both PETTESTER and the Commodore Diagnostic clip that I have reckon the PET is only fitted with 16k RAM so I need to work on why that is after thorough testing with ToePost.

And, assuming it's now set up to be a 32K machine, how much memory does the PET OS report it has if you put everything back to standard?

[ScottishColin]

I don't have ROM sockets back in yet, but if I boot the Tynemouth ROM/RAM emulator with only ROM being emulated (ie it uses on board memory only), I get 15359 bytes free.

Colin.

Originally Posted by SiriusHardware

And, assuming it's now set up to be a 32K machine, how much memory does the PET OS report it has if you put everything back to standard?

[ScottishColin]

I have found this which may be worth pursuing:

http://blog.tynemouthsoftware.co.uk/2015/05/commodore-pet-4032-repair-only-16k.html

The Tynemouth diagnostics board gives me lots of High RAM errors right now which chimes with the process he went through. I need to fix the keyboard properly so that I can type some BASIC code as per the link above.

Colin.

[SiriusHardware]

In addition to Tony's requested check in #466:-

Did you at any point do the CAS0 / CAS1 signal swapover to switch banks for diagnostic purposes, and if you did (and you swapped the resistors back again) can you just re-check the CAS1 resistor is really soldered? (The resistor, R11, is 'after' the UD5 / pin 11 output).

Edit: crossed with your post above, so carry on.

[ScottishColin]

PETTESTER does not go low on UD5/11.

Tynemouth diagnostics gives the attached signals when it is testing high RAM.

Colin.

Originally Posted by TonyDuell

When you run a diagnostic program that should access the upper 16K block of RAM, does CAS1/ (UD5, pin 11 as on Sheet 6 of the schematic) ever pulse low?

[julie_m]

Originally Posted by ScottishColin

Thanks all for the DRAM input. I will try to learn a little (that's the best I can promise - old dog, new tricks and all that) from the posts.

74177s turned up today. I put one into the empty UE6 socket and all signals/frequencies are now present and correct on UE6 and UE7 which were absent before - thanks for the pointer Tony.

Welcome back, Colin I had an idea for how to build a "74LS244 in-circuit tester" using just a 74LS86, one transistor and some passives (no 3-input gates), but it now looks as though we won't have to .....

Originally Posted by ScottishColin

Julie's code now runs with no workspace, stack or zero-page errors (see photo attached). I'm running a soak test now.

That's definitely looking healthier! And we know what a refresh fault looks like, which no doubt will be useful to someone in future.

Originally Posted by ScottishColin

The next problem is that both PETTESTER and the Commodore Diagnostic clip that I have reckon the PET is only fitted with 16k RAM so I need to work on why that is after thorough testing with ToePost.

So far, I haven't been testing for the extent to which memory is actually populated. I've seen a strange phenomenon in VICE emulating a 4016, when trying to access specific addresses in memory not fitted, and it would be interesting to see if the same thing seems to be happening on a real, live PET.

What happened under emulation was, the unpopulated memory appeared to work (accesses to the unpopulated memory at addresses &4000-&7FFF probably were affecting corresponding addresses &0000-&3FFF) except addresses ending in &FF always read back as the high-order byte of the address. So, one error in each page tested, and always at addresses ending in FF.

If a real PET does that, it could be intentional and if so, might warrant a deeper dive into the schematics and theory of operation.

EDIT: This just in! Screenshot of an emulated 4016 (Vice xpet 3.6.1) running the latest ToePost and getting past page &3F, into the unpopulated area. What happened on your real hardware?

[ScottishColin]

I'll try it - do you just need the first error screenshotted?

And I had an idea (which I may or may not have mentioned before). Would it be possible to have two rows of the 76543210 characters on the screen - one row for low memory and one for high memory?

EDIT: I do have a 3016 with only 16k fitted - I can try the code on that one (assuming it hasn;t brokwn since I last looked at it).

Colin.

Originally Posted by julie_m

Welcome back, Colin I had an idea for how to build a "74LS244 in-circuit tester" using just a 74LS86, one transistor and some passives (no 3-input gates), but it now looks as though we won't have to .....

That's definitely looking healthier! And we know what a refresh fault looks like, which no doubt will be useful to someone in future.

So far, I haven't been testing for the extent to which memory is actually populated. I've seen a strange phenomenon in VICE emulating a 4016, when trying to access specific addresses in memory not fitted, and it would be interesting to see if the same thing seems to be happening on a real, live PET.

What happened under emulation was, the unpopulated memory appeared to work (accesses to the unpopulated memory at addresses &4000-&7FFF probably were affecting corresponding addresses &0000-&3FFF) except addresses ending in &FF always read back as the high-order byte of the address. So, one error in each page tested, and always at addresses ending in FF.

If a real PET does that, it could be intentional and if so, might warrant a deeper dive into the schematics and theory of operation.

EDIT: This just in! Screenshot of an emulated 4016 (Vice xpet 3.6.1) running the latest ToePost and getting past page &3F, into the unpopulated area. What happened on your real hardware?
Attachment 314792

[julie_m]

Originally Posted by ScottishColin

I'll try it - do you just need the first error screenshotted?

It would be nice to have four or five if you've got the patience, just to see if it's consistently &xxFF addresses.

Originally Posted by ScottishColin

And I had an idea (which I may or may not have mentioned before). Would it be possible to have two rows of the 76543210 characters on the screen - one row for low memory and one for high memory?

I'm not sure how feasible that would be with the code as it stands (though now I'm feeling the need to try even harder); but now we have a working stack and zero page, we can do much better .....

Originally Posted by ScottishColin

EDIT: I do have a 3016 with only 16k fitted - I can try the code on that one (assuming it hasn;t brokwn since I last looked at it).

Can't hurt to try .....

[ortek_service]

Well it would seem that PETTESTER isn't accessing the upper 16K for some reason. Are there multiple version of it, for 16K & 32K etc. machines?
Or is it mis-reading the 16K . 32K jumper configuration?

It does look-like the Tynemouth diagnostics is actually testing the upper 16K of the whole 32K - which you'd expect wouldn't be too difficult to do, once all of the lower 16K, with zero-page & stack is working OK!

And whilst this can be done fairly easily from BASIC (via PEEK & POKE's), any good diagnostic ROM should be able to do this just as well without having to type in small programs, requiring Keyboard all working OK.

6 faulty DRAM IC's does sound quite a lot - I assume you haven't yet changed any in the upper 16K bank?
But then quite a few were changed in the Lower 16K - Although not clear yet if all / any of these were actually faulty if the lack of refresh was the real problem, unless you've now re-testing those on a working PET etc.


Although that / CAS1 waveform looks a little suspect, as < 2Vp-p and has v.long rise-times / falling-edge isn't that sharp either.
However I would suspect 'scope (settings) issues, and I wonder if you still the same if you tried 'scoping / CAS0?

Originally Posted by ScottishColin

PETTESTER does not go low on UD5/11.

Tynemouth diagnostics gives the attached signals when it is testing high RAM.

Colin.

[ortek_service]

Originally Posted by ScottishColin

I have found this which may be worth pursuing:

http://blog.tynemouthsoftware.co.uk/2015/05/commodore-pet-4032-repair-only-16k.html

The Tynemouth diagnostics board gives me lots of High RAM errors right now which chimes with the process he went through. I need to fix the keyboard properly so that I can type some BASIC code as per the link above.

Colin.

I have now read through that, and it seems the lots of High RAM errors he was getting were actually genuine as two DRAM's in the upper 16K were found to be faulty
- Maybe killed by having -6.5V applied to their -5V supply ?
(Where he seems he was lucky that more DRAM's weren't damaged / Lower 16K was still functioning with that voltage being so-far out.
And unusual to have a 7905 regulator fail like that (Not quite s/c, but not that common for these regulators to go over-voltage)

So shouldn't really need to type a BASIC program in, if Tynemouth Test ROM does test this all OK - Although maybe you could temporarily swap the keyboard with your 4032, as presumably easier to do this than take it apart to clean / restore contacts ?

If the only difference in connection between the two 16K RAM banks is [O]CAS0/[O] & [O]CAS1/[O], then it does very-much look like multiple (6off) DRAM IC failures in this bank (as well).
- Assuming all three voltages supplies measure as expected (On a DMM, at least), so as not to risk further failures.

[ScottishColin]

Three error message screens from the 4016 attached fyi.

3016 results to follow.

Colin.

Originally Posted by julie_m

It would be nice to have four or five if you've got the patience, just to see if it's consistently &xxFF addresses.

I'm not sure how feasible that would be with the code as it stands (though now I'm feeling the need to try even harder); but now we have a working stack and zero page, we can do much better .....

Can't hurt to try .....

[ScottishColin]

That was silly of me. It's not going to work in a 3016 as it's a non-CRTC equipped PET.

Colin.

[ScottishColin]

PETTESTER works as-is for 8K, 16K and 32K PETs so that's not it.

I'll get the keyboard in a better state first and see where we are with other suggestions.

No RAM ICs have been changed in the upper bank yet - I'd quite like to leave it 'broken' in order to carry on testing Julie's code.

re CAS0 - see attached with another CAS1 screenshot which looks better. Verdigris on the pins is the claim I'm making for why it's different today, but it's also likely to be operator error.

Colin.

Originally Posted by ortek_service

Well it would seem that PETTESTER isn't accessing the upper 16K for some reason. Are there multiple version of it, for 16K & 32K etc. machines?
Or is it mis-reading the 16K . 32K jumper configuration?

It does look-like the Tynemouth diagnostics is actually testing the upper 16K of the whole 32K - which you'd expect wouldn't be too difficult to do, once all of the lower 16K, with zero-page & stack is working OK!

And whilst this can be done fairly easily from BASIC (via PEEK & POKE's), any good diagnostic ROM should be able to do this just as well without having to type in small programs, requiring Keyboard all working OK.

6 faulty DRAM IC's does sound quite a lot - I assume you haven't yet changed any in the upper 16K bank?
But then quite a few were changed in the Lower 16K - Although not clear yet if all / any of these were actually faulty if the lack of refresh was the real problem, unless you've now re-testing those on a working PET etc.


Although that / CAS1 waveform looks a little suspect, as < 2Vp-p and has v.long rise-times / falling-edge isn't that sharp either.
However I would suspect 'scope (settings) issues, and I wonder if you still the same if you tried 'scoping / CAS0?

[julie_m]

Originally Posted by ScottishColin

That was silly of me. It's not going to work in a 3016 as it's a non-CRTC equipped PET.

Colin.

There's no reason why it shouldn't work in a non-CRTC PET. The CRTC in the 4000 / 8000 series is just a more general-purpose replacement for a whole bunch of TTL chips in the 3000 series. If nothing is listening on its addresses, the initialisation code will not do anything; but it doesn't have to, because the 3000 series video circuit just does what an already-initialised CRTC would do.