Learned something new: RAM type/batch matters when using an EPROM OS with respect to a quick power cycle

[ACML]

For years I have been modifying 1200XLs to accept 28 pin EPROMs so I can replace the crappy Rev 10 with a pair of 27128 EPROMS that hold both the 800XL and Omniview OSs.  I repurpose the channel 3/4 selector switch as my OS selector.  Every once and a while I find a board that just doesn't want to play 100% with these EPROMs.  It will run fine, but when I cycle the power for say a second or less (time OFF), it acts flaky.

 

Possible responses with short power cycle:

1) Cold boot correctly (pause and fart sound)

2) Pseudo warm boots, not normal cold start (blue screen appears immediately, no pause, no fart sound)

3) Nothing, no sound, just solid black screen

 

It only happened to me about 1 in every 10 units, so I just chalked it up to the theory that some boards for whatever reason have tolerance or start up characteristics that are on the edge of reliable.  Mind you, an offending unit would not have the behavior with original Rev 10 ROMs, only with 27128 EPROMs.  My theory was correct, but I never gave it enough thought as to why and could it be just one offending component?  I'd swap CPU and it did not matter.  Yesterday I was thinking, "is it that the RAM has not bleed off sufficiently" and the quick power cycle catches it in bad state?  I swapped the RAM and the problem went away.  So, just swapping the RAM fixed the flaky power cycle behavior.  Anyone know what might be happening here?

 

[Peri Noid]

XE-series machines using 64Kx1 chips sometimes have this weird behavior that they do not want to power-reset properly or you have to wait quite long before you turn it on again. It's due to long for time they need to loose the data and the cold boot procedure, where 3 memory locations are checked for certain data. A solution to it was to replace one ram chip (not any though) with something else, of a different brand/latency - actually something that looses data quickly. Maybe in your case a similar approach would also work? 

Edited September 1, 2023 by Peri Noid

[thorfdbg]

This due to the way how the XL ROM detects a hard reset. If three memory cells contain some well-defined values, the Os assumes a warm start and does not go through the full initialization sequence. If the power cycle is short enough, the RAMs retain their value and the Os does not initialize itself completely. However, as some other RAM content may have been damaged anyhow, the shortened initialization sequence fails to bring up the machine properly. As far as I recall, this is the reason why Atari used for the 8 RAM chips one rather poor uT chip that looses its contents more quickly while the 7 other chips are better quality chips that retain their contents longer.

Edited September 1, 2023 by thorfdbg

[TGB1718]

2 minutes ago, thorfdbg said:

As far as I recall, this is the reason why Atari used for the 8 RAM chips one rather poor uT chip that looses its contents more quickly while the 7 other chips are better quality chips that retain their contents longer.

I always wondered why one RAM chip was different in my 130XE, this probably explains why

 

[Rybags]

Why would the OS being changed or being on Eprom matter?

As long as the magic number algorithm is used (which I believe every XL/later OS and 3rd part derivatives would use) the behaviour of the Ram chips should be the deciding factor with incorrect powerups.

[_The Doctor__]

During the acquisition of ram over time, the ram's retention time increased (which is normally a good thing, requiring less refresh cycles). The oddball single ram in the XE was put in place and was a higher quality ram but with a lower retention time, and was also ready quicker than the cheaper chips. That oddball single ram helped the Computer power up more quickly and power cycle more quickly. The other issue was capacitive. This was covered a bit in previous thread on this and other forums. Those discussions also covered tweaks to cure the time to wait and other suggestions including replacing ram.

Edited September 1, 2023 by _The Doctor__

[+x=usr(1536)]

1 hour ago, Peri Noid said:

XE-series machines using 64Kx1 chips sometimes have this weird behavior that they do not want to power-reset properly or you have to wait quite long before you turn it on again.

To be fair, it's not just XEs that this happens to - I've also seen it happen on XLs, both stock and modified.  My 600XL with an internal 64K upgrade (41464s with a 100ns refresh rate, IIRC) is particularly touchy in this regard, but I've also seen it affect both the 800XL and 1200XL with stock RAM.

1 hour ago, Rybags said:

Why would the OS being changed or being on Eprom matter?

All of the machines showing this behaviour that I've described above are using the stock mask ROMs.  As you point out, EPROM shouldn't be a factor.

[Rybags]

Another point though not relevant and not something that could have been changed easily - the number of refresh cycles.

C64 and Plus4 generally use the same RAM technology as XL/XE and only needed 5 cycles refresh per scanline vs our 9.

Potentially that could have equated to a worthwhile performace boost though you'd have wanted it switchable to remain compatible with older software.

[Peri Noid]

Actually refresh cycles can be skipped completly with a modern SRAM memory upgrade. And then, theoretically, we could regain all the "wasted" clock cycles.

Edited September 1, 2023 by Peri Noid

[Mathy]

Hello guys

 

IIRC CSS/Bob Puff's UltraSpeedPlus OS has something inside that shortens the time the computer needs to successfully reboot shortly after powering it down.  It's been a while but I guess I asked Bob about this, but he wasn't very clear about this.  Again, that is IIRC.  So there has to be a way to get the computer to reboot successfully after a very short power cycle.  And if it really already is in the US+OS, it should be possible to do so without replacing the RAM.

 

Sincerely

 

Mathy   (who's own bio-RAM also misses a few refresh cycles from time to time)

 

 

[ACML]

A lot of great information, but the fact that when using stock Rev 10 ROMs, it does not exhibit this behavior.  A key piece of info I should have included is that it's when I have the Omniview OS selected that this happens and not with the 800XL rev 2 OS.  The Omniview OS is based off of the 400/800 OSb, but still allows access to 64K, fast math and 80 column option.  So maybe there is something in the Omniview start up that's different than the rest?

 

[Rybags]

The magic numbers are 3 contiguous bytes so I'm guessing the row or column would be same for all.

Maybe better success can be had by using locations that are more spread out.  Or maybe different values in the used addresses.

The only other way I can think of for the OS to distinguish between a warm reset and a powerup might be through Pokey, though I'm not sure if it's powerup state is in init mode or some random/indeterminate state.

 

A quick look/compare of the OS - 1200XL Rev 10 vs later XL - the Rev 10 doesn't seem to have the delay loop right at the start, otherwise the initial powerup seems the same.

Edited September 1, 2023 by Rybags

[reifsnyderb]

2 minutes ago, Rybags said:

The magic numbers are 3 contiguous bytes so I'm guessing the row or column would be same for all.

Maybe better success can be had by using locations that are more spread out.  Or maybe different values in the used addresses.

The only other way I can think of for the OS to distinguish between a warm reset and a powerup might be through Pokey, though I'm not sure if it's powerup state is in init mode or some random/indeterminate state.

The 800XL and XE's use one DRAM chip per bit as one data line goes to each chip.  i.e.  D0 is on one chip, D1 on the next, etc.  So an event the affects an entire DRAM chip will corrupt all of a 64k section of DRAM.  The 3 power up bytes can be anywhere and aren't always contiguous as it depends on which version of the OS is being used.

[Rybags]

How do you mean "anywhere" - they're in constant locations and seem to use the same values in the XL OSes that I've looked at.

$3DC - $3DF with values $5C $93 $25

[reifsnyderb]

13 minutes ago, Rybags said:

How do you mean "anywhere" - they're in constant locations and seem to use the same values in the XL OSes that I've looked at.

$3DC - $3DF with values $5C $93 $25

In most XL/XE OS's, Atari had them at the following locations and they do contain the same values:

 

PUPBT1    EQU    $033D    ;1-byte power-up validation byte 1
PUPBT2    EQU    $033E    ;1-byte power-up validation byte 2
PUPBT3    EQU    $033F    ;1-byte power-up validation byte 3

 

This created a bug with HATABS that was probably rarely, if ever, experienced because the HATABS table was never filled up.  But, if it was filled up, PUPBT1 would be overwritten.

 

Atari discovered this and, in OS R5, V0, moved PUPBT1....

 

PUPBT1    EQU    $02DF    ;1-byte power-up validation byte 1

 

 

But it really doesn't matter where the power up validation bytes are are as if one of the 8 DRAM chips that handle a "bank" of 64k is damaged badly enough, or removed, the bit handled by that chip will be corrupted.  I have the DRAM section of the 800XL schematic below...

 

 

 

 

 

[ijor]

This is a very common effect, not a defect, that happens in several other platforms that use the same, or similar, method to distinguish between hardware reset and power on. That's why it was common to recommend, again, on many platforms, to wait a few seconds between powering off and powering on.

 

This doesn't depend only on the actual ram chips. It also depends on the system capacitance that retains some voltage even after power off. System capacitance might be affected by just anything in the computer, or even connected peripherals.

 

On 9/1/2023 at 11:59 AM, reifsnyderb said:

So an event the affects an entire DRAM chip will corrupt all of a 64k section of DRAM. 

This is not something that affects a specific chip, at least not necessarily. It might affect individual bits in multiple chips instead. It is very possible that some particular chip is more affected than the others, but also probably depends on the last time that a particular row was refreshed. Anyway, it is certainly a non-deterministic behavior.

 

[ClausB]

Patient: it hurts when I do this.

Doctor: don't do that.

Me: don't do quick power cycles.

[+kheller2]

I think what @reifsnyderb was referring to is that if RAM chip #3 is faulty/failing then D2 is gone and not to be trusted, since all 64K bits of D2 are on that chip.

 

As we all know, anyone that has done a 256K upgrade has been told to wait during power off/on.  Even those 130XEs need to wait.

 

@ijor it is interesting that the system capacitance with regards to keeping voltage plays a role (and is obvious in hindsight), but I've always heard it depends mostly on the RAM chip in how fast it forgets once power is removed... again, caps are going to play a role in that.

[reifsnyderb]

26 minutes ago, kheller2 said:

I think what @reifsnyderb was referring to is that if RAM chip #3 is faulty/failing then D2 is gone and not to be trusted, since all 64K bits of D2 are on that chip.

Yes.

Edited September 4, 2023 by reifsnyderb

[ACML]

31 minutes ago, kheller2 said:

", but I've always heard it depends mostly on the RAM chip in how fast it forgets once power is removed"

Yes, this is what I'm finding.  The problem for me was when I used Samsung 64K x 1 Bit DRAM w/ Page Mode KM4164B-12.  They usually work fine in non-OSb based OS machines, but say when used with Omniview, you have to wait sometimes 3-4 seconds to guarantee a proper power cycle cold start. Mind you, I have the 600/800XL Rev 2 OS on the same EPROM and in the same machine and RAM, I can reliable do one second power cycles like the stock machine.  For a machine with this issue, I put in old Atari sourced 64Kx1 DRAMs and even with Omniview, I get reliable one second power cycles.  So, its the brand and type of 64K DRAM that makes the difference.  The retained capacitance of the machine is the same, the only variable is the DRAM.

 

If you have:

1) 400/800 OSb, Omnimon, Omniview or 1200XL Rev 10 OS, you might have this issue due to the lack of delay in boot up.

2) 1200XL Rev 11, 600/800XL, XE OS, you likely won't have this issue due to the delay built into the boot up.

 

Why some 64Kx1s have the issue and some don't, it's a mystery to me.  I've had only a couple 1200XL boards that flat out refuse to boot (solid green screen) with the newer Samsung DRAM, while 1200XL boards with same date code (193) like them just fine.  One thing is for sure, the 1200XL can be finicky between the CPU and RAM requiring you sometimes to swap out one or both to get them to play 100% reliably.

 

[+-^CrossBow^-]

All this talk of the start up errors has finally answered a question I've had in my head since I replaced all of the RAM in my 130xe about a year or 2 ago. It will frequently start up with just a blue screen and static cursor but no audio and appear hung. It will always come up this way until I leave it off for like a min and then try and boot it up again. I replaced all of the original MT ram with Samsung that was given to me sometime back. I'm guessing that even my replacing out that first NCR RAM with one of these is why my 130xe frequently comes up in this state when powering off/on? Maybe I need to pop that NCR back into the first bank again?

 

[_The Doctor__]

Can't hurt to give it a shot, NEC or NCR chips sometimes help.

[+-^CrossBow^-]

13 minutes ago, _The Doctor__ said:

Can't hurt to give it a shot, NEC or NCR chips sometimes help.

It was an NEC and I already had in that spot. I went ahead and pulled it and replaced it with a matching Samsung same as the others, and the FujiNet seems to boot up more reliably as a result now? I don't know, I'm not touching it at this point LOL! I feel like my 130xe has it out for me.

 

[ijor]

4 hours ago, kheller2 said:

I think what @reifsnyderb was referring to is that if RAM chip #3 is faulty/failing then D2 is gone and not to be trusted, since all 64K bits of D2 are on that chip.

 

I see. Sorry for the misunderstanding.