The PET who never forgets.

[Hugo Holden]

I have been doing some work lately making a non-volatile memory board for my PET. It plugs onto the Dynamic PET's board J4 & J9 and has two additional wires which connect it to the pcb. One is for the 5V power, the other to inhibit DRAM reads. The non-volatile memory then is the one in use.

I wanted to make this board out of period correct parts for the PET (my usual M/O in the spirit of vintage computing). I decided to go with battery backed up SRAM.

There are some very interesting issues that can occur trying to achieve this. They relate to the conditions of the RAM control signals during power up and power down/power failure events. Not only are the address & data lines transiently unstable and indeterminate, but also the chip enable signals including the write control too.

Dallas solved this problem to a good degree with an SRAM controller IC inside their battery backed up SRAM memories. Also one assumption that is made for other non-volatile RAMs is that the power up process is not as problematic, if the CPU is in reset and the write and/or chip select controls are tri-stated and tied high and they follow the rise in power supply voltage and don't cause trouble. However, for any specific computer that assumption may not apply.

I decided to inspect the write control in the PET with the slow scan/storage scope. The +5V power (on both regulators) rises fairly abruptly at power on, and there is a very early write transient. This would corrupt the non volatile memory . At power down , the +5v supply decays over about 100mS with an inverted exponential form and there is a very nasty early write transient in the R/W control line by the time the voltage has dropped to the region of 3v.

Therefore I designed two custom circuits, to deal with these in the PET, using vintage LM111 comparators, so as to eliminate these from the write control signal. The memory contents are then not corrupted by computer power on/off events.

The battery can support the memory for well over 1 year, I decided to use a cordless phone twin AAA style rechargeable battery and there is a battery charge and power-up down system with 4 transistors. This is the battery management system used on the Yang S-100 32k memory board.

Yang used an interesting approach to help preserve the memory contents on power cycling, he interfaced the memory IC's with a number of cmos peripheral chips and powered those from the backed up battery supply, so that the events of power cycling did not corrupt the memory. It resulted in more standby power consumption though and the system would not help the PET's unique case.

I'm still experimenting with this project. The top & bottom pcb foil patterns are finished.

 

[OldPETGuy]

I have been doing some work lately making a non-volatile memory board for my PET. It plugs onto the Dynamic PET's board J4 & J9 and has two additional wires which connect it to the pcb. One is for the 5V power, the other to inhibit DRAM reads. The non-volatile memory then is the one in use.

I wanted to make this board out of period correct parts for the PET (my usual M/O in the spirit of vintage computing). I decided to go with battery backed up SRAM.

There are some very interesting issues that can occur trying to achieve this. They relate to the conditions of the RAM control signals during power up and power down/power failure events. Not only are the address & data lines transiently unstable and indeterminate, but also the chip enable signals including the write control too.

Dallas solved this problem to a good degree with an SRAM controller IC inside their battery backed up SRAM memories. Also one assumption that is made for other non-volatile RAMs is that the power up process is not as problematic, if the CPU is in reset and the write and/or chip select controls are tri-stated and tied high and they follow the rise in power supply voltage and don't cause trouble. However, for any specific computer that assumption may not apply.

I decided to inspect the write control in the PET with the slow scan/storage scope. The +5V power (on both regulators) rises fairly abruptly at power on, and there is a very early write transient. This would corrupt the non volatile memory . At power down , the +5v supply decays over about 100mS with an inverted exponential form and there is a very nasty early write transient in the R/W control line by the time the voltage has dropped to the region of 3v.

Therefore I designed two custom circuits, to deal with these in the PET, using vintage LM111 comparators, so as to eliminate these from the write control signal. The memory contents are then not corrupted by computer power on/off events.

The battery can support the memory for well over 1 year, I decided to use a cordless phone twin AAA style rechargeable battery and there is a battery charge and power-up down system with 4 transistors. This is the battery management system used on the Yang S-100 32k memory board.

Yang used an interesting approach to help preserve the memory contents on power cycling, he interfaced the memory IC's with a number of cmos peripheral chips and powered those from the backed up battery supply, so that the events of power cycling did not corrupt the memory. It resulted in more standby power consumption though and the system would not help the PET's unique case.

I'm still experimenting with this project. The top & bottom pcb foil patterns are finished.

Hugo

I LIKE this idea.

Well done.

Fred

 

[Hugo Holden]

Hugo

I LIKE this idea.

Well done.

Fred

Thanks.

As you can see from the pcb design, it is all very "old school".

When I learnt to design pcb's it was all on clear transparencies, to make pcb's with photo resist methods.

Over the years this is the way I do it. I like to design the pcb and place all the components and pcb tracks myself (in a drawing program these days), because I think of that as the "artistry of the design". (not that I would claim to be an "artist") .

However, when I look at the many pcb track-work designs of the 1970's to 1980's era, when it was done this way, I think many of the creators of these were in fact sorts of artists, because they seemed to care about the way it looked, not just the way it worked.

I have done some projects where the pcb software auto-routed the tracks from the schematic, but in those cases, I never seem to like the result.

Still, by the '80's it was clear that IBM were using computers to help them with their pcb design. In that era, they may have hit the nail on the head.

One vintage pcb track design that has impressed me more than any other I have ever seen, is the one on IBM's original EGA long card, it is like the "Mona Lisa" of pcb track-work, that is if the Mona Lisa was some space age futuristic Robot that escaped from a movie like Metropolis and tried to put on an art display at the Warhol gallery.

In any case if you have a look at IBM EGA card, its pcb it is quite the masterpiece. They created the notion where most of the tracks on one side were perpendicular to the ones on the opposite side and made great use of vias. So they essentially created a grid or matrix system which could conceivably connect everything to everything, then they connected everything up and then deleted the extraneous tracks that went nowhere when they were finished.

Of course when 4 layer pcb's came along, that obscured 50% of the creativity.

 

[Hugo Holden]

I had a punt at drawing up the pcb in Kicad.

Not my usual M/O as I hail from the days of photo-resist and artwork on transparencies.

I did not use the schematic-auto router in Kicad, because I have a belief (probably delusional) that a human can rout pcb tracks better than a computer, but mind you, that opinion was formed in the 1980's, and I'm sure the track routers have got a lot better since then, proving the remark incorrect.

I'm very fussy about the earthing and power supply distribution track design. Also I didn't use any Kicad vias, I like to use plated through component holes as vias, that have masking so I can solder them through for reliability.

I have attached an image (poor focus) of the pcb, I routed in Kicad manually.

 

[Hugo Holden]

The boards are being made now, so it won't be long before I can try it out.

 

[Eudimorphodon]

I'm a little curious what the goal of subbing NV SRAM for the main system memory is? The PET is going to be reset between powering it off and turning it back on again, so it's not going to precisely work to implement seamless "hibernation". I guess it could be useful if you're loading some machine language drivers high that don't do anything with self-modifying code, IE, stuff you'd be able to re-init by resetting the top of memory limit and jumping to the init routines, but might this stuff get damaged by the power-on memory test? (I thought it found the top of memory by running up from the bottom and testing if it gets back the same value it writes to a memory location, does that routine save whatever was at that location and put it back after the test?)

I guess the above observations go away if you're planning to put a modified Kernel ROM in, but it still seems like for a "clean" hibernation you'd need to run a "shutdown" command that saved register state to be restored after power-on reset.

 

[Hugo Holden]

I'm a little curious what the goal of subbing NV SRAM for the main system memory is? The PET is going to be reset between powering it off and turning it back on again, so it's not going to precisely work to implement seamless "hibernation". I guess it could be useful if you're loading some machine language drivers high that don't do anything with self-modifying code, IE, stuff you'd be able to re-init by resetting the top of memory limit and jumping to the init routines, but might this stuff get damaged by the power-on memory test? (I thought it found the top of memory by running up from the bottom and testing if it gets back the same value it writes to a memory location, does that routine save whatever was at that location and put it back after the test?)

I guess the above observations go away if you're planning to put a modified Kernel ROM in, but it still seems like for a "clean" hibernation you'd need to run a "shutdown" command that saved register state to be restored after power-on reset.

I'm not 100% sure yet myself of the benefits of it in terms of saving data with line power cycling. That is the fun part I'm going to experiment with, and see if programs I put in the program area remain intact after power cycling, or not. I should know in the next few weeks. I'm not expecting after a hard power reset that the program/registers etc would return to their pre-power failure state. I'm more interested to see if I can preserve the loaded program in memory and re-run it from scratch again, or not. As you say the power on memory test could corrupt it. Then I can look at that issue later.

But one idea of it is to eliminate the DRAM and its support circuitry entirely, which is helpful in DRAM and DRAM support circuitry fault diagnosis.This card is really like the 2K version I made but extended to 32k.

 

[Eudimorphodon]

Per this thread:

https://forum.vcfed.org/index.php?threads/reset-switch-for-pet-8032.72568/

A hard reset, which is what you’ll get on power-on, clears all memory with &hAA. So without additional mods the battery backup will be useless.

Apparently there *is* a “Diagnostic“ line that if it’s held down along with RESET will cause the computer to go straight to the monitor without clearing memory. Maybe you could add a toggle switch to try holding that when you flip the power on and see if it leaves the battery backed RAM in a recoverable state? To get a BASIC program back you’ll have to jump into BASIC without going through the cold start routine, and then likely do some POKE-ing to set the pointers to see the resident without clobbering things, unless you can find a jump-in point that preserves those values from before power-off. I would guess how successful this might be will depend a lot on the state of the machine when you shut it off.

 

[Hugo Holden]

Per this thread:

https://forum.vcfed.org/index.php?threads/reset-switch-for-pet-8032.72568/

A hard reset, which is what you’ll get on power-on, clears all memory with &hAA. So without additional mods the battery backup will be useless.

Apparently there *is* a “Diagnostic“ line that if it’s held down along with RESET will cause the computer to go straight to the monitor without clearing memory. Maybe you could add a toggle switch to try holding that when you flip the power on and see if it leaves the battery backed RAM in a recoverable state? To get a BASIC program back you’ll have to jump into BASIC without going through the cold start routine, and then likely do some POKE-ing to set the pointers to see the resident without clobbering things, unless you can find a jump-in point that preserves those values from before power-off. I would guess how successful this might be will depend a lot on the state of the machine when you shut it off.

I actually had another plan.

I discovered that with my added memory it can run concurrently with the DRAM. The reason this works is that the write & read data from both is identical and doesn't conflict. But I can activate/deactivate the NVRAM system at any time.

I also found with the other small card I made that I could boot to BASIC in a 1K (or 2k) mode.

I have arranged it that at power down, the current memory state is preserved in the added NVRAM board, but at/after power up, when the PET comes out of its own 1 second reset, clears the memory with AA's & does the memory range test thing, only the lower 1k (or 2k) of the added NVRAM memory is running, so that the data above that in the non-volatile ram is left alone. After about 1.5 seconds, or longer if required (which exceeds the 1 second PET reset system or more time if required for the memory check etc) the entire DRAM then gets deactivated and the NVRAM automatically switches in, so the data alterations initiated by the hard boot to BASIC only affect the deactivated DRAM above the 1k (or 2K) boundary and not the bulk of the NVRAM contents, which remain preserved from the pre-power down state. In effect the idea is sort of like like a shadow ram concept where data (program) is kept at power down in a shadow memory and recovered after power up, but this data does not contain details of the operating system and the system re-initializes normally. The trick is to try to preserve a loaded program.

I'm still working on it, I will post if it works. It might depend on where the pointers are located and if I can preserve them with the process.If all the important things are in the lower 1K (or 2k perhaps) I think it will work. High memory might be a problem.If that happened I might have to screen out the upper 1k or something during the process.

 

[daver2]

Hmmm ...

This will be very interesting if you can get it to work my friend...

Have you thought about a power-fail interrupt (to generate and NMI) and then save the CPU registers into a dedicated area of memory before the power finally dies.

On a power-up, you then have everything to recover from where you left off (irrespective of how the ROM and DRAM is configured). Of course, you will nee a delayed power up interrupt - or some magic key combination - to invoke the PET's restore function.

On our systems at work (although we have never used them as such), we have an NMI handler that can be invoked for a number of reasons. One is power fail (store CPU registers away and halt gracefully) and the other is power restored (recover the CPU registers and restart).

Just giving you a little more food for thought...

Dave

 

[Hugo Holden]

Hmmm ...

This will be very interesting if you can get it to work my friend...

Have you thought about a power-fail interrupt (to generate and NMI) and then save the CPU registers into a dedicated area of memory before the power finally dies.

On a power-up, you then have everything to recover from where you left off (irrespective of how the ROM and DRAM is configured). Of course, you will nee a delayed power up interrupt - or some magic key combination - to invoke the PET's restore function.

On our systems at work (although we have never used them as such), we have an NMI handler that can be invoked for a number of reasons. One is power fail (store CPU registers away and halt gracefully) and the other is power restored (recover the CPU registers and restart).

Just giving you a little more food for thought...

Dave

With the rate that the 5V power rail falls at turn off, I was not 100% sure if I had time to do any register data collection & storage, without adding at least some sort of transiently running UPS (or perhaps large capacitance) to support / extend the time frame. As it is, at power down, the circuit detects when the 5V supply has dropped to around 4.3v after turn off before killing the write functions to the NVRAM to avoid the large write transient. I will be happy if I can preserve the program data area and re-run the program though, which was the goal.

 

[daver2]

Detect the loss of the low voltage AC supply instead of the DC rail.

Dave

 

[Hugo Holden]

Detect the loss of the low voltage AC supply instead of the DC rail.

Dave

Yes that would give a lot more time.

 

[Hugo Holden]

I have had some fun tinkering around with this PET memory project. Always an adventure.

I got it working. I arranged it so that the PET boots in the normal way, using its dynamic RAM. And also completes its RAM assessments and writing AA to the DRAM as usual. Then, after 4 seconds beyond power up, the SRAM is switched in for 0400h and above to 7FFFh , below that though the DRAM is running normally. I found I could then run a program that was stored in the NVRAM.

But, there were some practical complications:

When I designed the pcb, I put in the circuitry to protect the NVRAM from power on-off corruption and the battery management circuit. That used most of the pcb space, and it requires 3 more IC's to make it work. One 555 timer, two IC's for the 1k address decode and switching logic. Unfortunately, I could not use the CS1 chip select from the 74154 and the BA10 address line to create the lower 1k address detector, because the 74154 that creates that, gets disabled when the NVRAM memory deactivates below the 1k boundary to switch in the DRAM. But the extra IC's will fit, if I go to SOIC packages and re-design the pcb.

I found out something interesting too, when I tried to inhibit the write pulses to the SRAM by adding extra gates, about the timing relationships between the buffered address lines BA0-BA15 in the PET and the SRAM chip select signals created by the 74154, and the buffered R/W pulse (BR/W) relative timing. For a simple static memory like this, it is the relative timing of the chip selects and R/W that affects it, there are no other dynamic control signals (unlike DRAM), assuming the address lines have stable data, but of course the lines BA0- BA10 feeding the SRAM chips have no additional delays either. In this case having one signal arriving early is equivalent to the other arriving late etc. The SRAM memory IC only sees the relative arrival time of the pulses. But, the exact nature of the BR/W pulse appears to be just slightly affected by what software is running too and exactly what the CPU is doing.

The chip select IC is a 74154, which simply driven on its 4 inputs from address lines BA11-BA14 and BA15 disables the IC so it does not respond in the upper address area. The 74154 divides the address range of 0000h to 7FFFh up into 16 blocks of 2k, and creates the CS1 to CS16 chip select signals. It could not be more simple. I did put 33R damping resistors in series with the address lines to help reduce any resonant effects.

It is interesting to see that to make an entire 32k compatible PET memory; it only requires one 74154 and the 16 TMM2016 memory IC's. No other IC's required. I guess Commodore could have done this and saved on all the DRAM support IC's, but maybe the 2k static RAMs were not as cheap at the time as the combo of DRAM and many logic IC's ?

Anyway, back to the "timing thing". I found with this simple setup, likely because the chip select circuitry (74154) is running relatively fast with minimal propagation delays it advances the relative Chip select timing, it is making the BR/W pulse relatively late. If the (buffered BR/W) pulse is passed through any more than two standard LS gates, only adding a small delay, the memory malfunctions, even if the BR/W pullup resistor is lowered to help speed it up a little.
When the timing delay is "borderline" odd things happen, for example the computer can boot normally, running small diagnostic programs using sys can work, but some tasks in BASIC fail. One other method that could help solve that is to use a ROM for the chip select signal generation, as it will be slower than the 74154 effectively advancing the relative timing of the BR/W pulse.

In any case, the SRAM works fine, provided the BR/W pulse is connected directly into the the SRAM array's R/W input and no additional delay is added to it. Probably, this problem is not even close in the original PET DRAM system because of the delays with all of the gates in the address multiplexing system effectively advancing the relative timing of the R/W pulse.

For now I simply have this prototype board running in its minimal form, with the 74154 & the 16 memory chips.(see photo) A jumper on it fully deactivates the DRAM and enables the SRAM for the whole 0000h-7FFFh address range. So it is a useful service board to "step in" and rehabilitate the entire PET memory with any kind of DRAM failure.

(Those support posts on the SRAM pcb rear; don't worry I did not drill holes in the PET mobo, they are just sitting there to keep the SRAM board level)

 

[Hugo Holden]

.......as you can see from the photo, I labelled the individual TMM2016 SRAMS with the address range that each covers on the pcb. Wouldn't it be lovely if all manufacturers did that sort of thing on memory pcb's, so if an IC dies, corresponding to some address range, you can see right away exactly where it is.

 

[Eudimorphodon]

It is interesting to see that to make an entire 32k compatible PET memory; it only requires one 74154 and the 16 TMM2016 memory IC's. No other IC's required. I guess Commodore could have done this and saved on all the DRAM support IC's, but maybe the 2k static RAMs were not as cheap at the time as the combo of DRAM and many logic IC's ?

As a general rule of thumb for machines of this vintage you can figure that X amount of SRAM cost between four and eight times as much as the same amount of DRAM(*), since that's roughly the difference in transistor count between the two technologies. So, yeah, you could buy a lot of random TTL logic to support the DRAM and come out ahead, especially a larger memory sizes.

(* I just confirmed this by looking in a 1979 issue of BYTE; if you're looking at complete assembled RAM boards for S100 machines the difference between static and DRAM boards was in the ballpark of 2x instead of 4x, no doubt because of the greater complexity of the DRAM board, but that's still a significant amount of money when you're talking about computers like the PET that were intended to sell for not much more than the price of an S100 RAM board alone.)

The SRAM memory IC only sees the relative arrival time of the pulses. But, the exact nature of the BR/W pulse appears to be just slightly affected by what software is running too and exactly what the CPU is doing.

I think I ran into a similar problem last year when I shoehorned a 6502 onto a prototype video card "thing" I've been fooling with to turn it into a full computer. TL;DR, I've come away from that with not completely warm feelings about how the 6502 Phi clock "thing" works vs. the more explicit bus signals you get from Intel 8080-descended CPUs. I used a GAL state engine to set up the opposite-sides-of-the-clock sharing of common memory between the video system and the CPU, and it "works", but when I say that I have to add the quotes because there's definitely some voodoo related to signal propagation/timing that I haven't invested the time yet in sussing completely out. My "toy" seems to work 100% reliably running simple code from ROM, but writing to RAM seems to be somewhat hit or miss, and it seems to boil down to not having a not-quite-right sequencing between the phi clocks/write pulse/propagation through the RAM controller and bus multiplexers.

 

[daver2]

Just out of interest, are you using phi2 in the address decoding?

Dave

 

[Hugo Holden]

Just out of interest, are you using phi2 in the address decoding?

Dave

No.

The only input data fed into the SRAM board is the buffered address signals BA0-BA15 and the BR/W pulse.

The 74154 generates the 16 /CS signals for the SRAM IC's from BA11-BA15, and the address lines feed all the TMM2016's from BA0-BA10. It is that simple.

The IC outputs connect directly to BD0-BD7 on connector J4.

As I say it works fine, except that it is intolerant of any delay greater than say two inverter gates added in series with BR/W. It works with two added, but no more. So I left these out, so at least there is a timing margin there. I had two gates in the original circuit configuration in series with BR/W for inhibiting write pulses in my quest to make a memory that was immune to line power cycling. This is how I found out about the relative timing issue. Initially I had two open collector inverter gates with 1k pullups, it malfunctioned and recovered function with 300R pullups which reduced the pulse transmission delay via the two gates.

(to make it run in the PET only requires that pin 10 of G7 is grounded, this inhibits DRAM reads and the SRAM board powered by a connection to +5V. But one really interesting curio, is that if you don't ground pin 10 to disable the DRAM, both the DRAM & SRAM memories run together concurrently and there are no conflicts, because their output data is in perfect agreement)

One other thing, the DRAM IC's in my PET are 4116-3 which are 200nS access time parts and they work well. The TMM2016AP-12's I'm using are 120nS parts. I don't think this is having any bearing on the BR/W pulse timing issue I discovered.

Most memory boards I have seen, certainly S-100 types, tend to buffer the address lines coming into the board, with additional buffer IC's. Since the BA0-BA15 signals in the PET on connector J9 were already buffered, by 74LS244's, I figured why add extra buffers ? but I can see that the time delay they would have added, would have meant that more delay could be added (if it was ever needed) to the BR/W pulse without it causing any relative timing issue.
Though in some cases inverting buffers are used and in others it is helpful to tri-state them off, especially on the output side. For the TMM2016, they are effectively uncoupled for reads & writes and output disabled when not selected: