Side3 issues....

[w1k]

my update: i replace u1mb.. problems with freezing and noisy screen are gone.

[Beeblebrox]

2 hours ago, w1k said:

my update: i replace u1mb.. problems with freezing and noisy screen are gone.

could you elaborate?  Did you replace it with a brand new U1MB?  Did you replace the cables also, or just swap in the new U1MB pcb?  thx

[w1k]

18 minutes ago, Beeblebrox said:

could you elaborate?  Did you replace it with a brand new U1MB?  Did you replace the cables also, or just swap in the new U1MB pcb?  thx

i replace only pcb

[Beeblebrox]

1 hour ago, w1k said:

i replace only pcb

which plcc chip is on the old "bad" U1MB and which is on the new one?  Also, assume FJC's Jan 2023 v4.20 firmware was preflashed on both?

[w1k]

23 minutes ago, Beeblebrox said:

which plcc chip is on the old "bad" U1MB and which is on the new one?  Also, assume FJC's Jan 2023 v4.20 firmware was preflashed on both?

both chips are the same, but I had the opportunity to try his U1MB at a friend's house and it helped, so I bought a new one and it works better.

latest firmware

[flashjazzcat]

Fun fact: when I was renovating the 1200XL I recently sold (the one to which I had fitted a PBI connector, etc, some years ago), I was unable to get IDE Plus 2.0 or SIDE3 to work properly at all until I replaced the original U1MB (which has been in that machine for a decade or more) with a new one (with the slightly revised PCB layout and Alliance SRAMs). Same U1MB JED, same U1MB firmware, but different SRAM and amended routing = totally different result. Why? DON'T KNOW.

 

All I can assume is that the pair of 74xx08s originally in the machine (the extra one produces EXTSEL) when I first upgraded it somehow had magical properties that allowed the old board to work, and when I replaced the 08s years later, nothing but the new U1MB would allow things to work properly again.

Edited September 26 by flashjazzcat

[Peri Noid]

<side thought>

I think, it's that "mystical" timing thing. No joking here, it just seems that we are still kind of guessing. And we have no reliable way of checking, what's actually going on there, that prevents different cinfigs from working reliably.

</side thought>

[Piotr D. Kaczorowski]

1 hour ago, flashjazzcat said:

but different SRAM and amended routing = totally different result. Why? DON'T KNOW.

 

You surely remember that I recently checked the signal levels between SRAM and DRAM. The differences between signals level (vertically) are very small—I assume they are negligible. At that time, Candle asked what the measurement was synchronized with. So it's worth noting (something I haven't checked yet, but plan to) that in a "stock" Atari, writing still goes through the Freddie chip or its earlier equivalent, based on delay loops (I'm writing this without checking, so forgive any potential inaccuracies). Therefore, a well-made DRAM replacement in the form of SRAM should also include that part.

The popular SRAM from Vendor is quite a simple circuit (also published in books about 6502), containing the chip and its control without significant management of timing dependencies. Instead, these dependencies are regulated by pull-up resistors, which pull the signal up, changing its edge and, consequently, the operation threshold. One of the service hints suggested by Vendor on Facebook (Peri Noid might remember me pondering this topic) was to reverse the pull-up resistor on the board so it becomes a pull-down resistor.

 

In the 65C816 thread, @reifsnyderb suggests using a PLD to generate synchronization signals. In the case of the SRAM board, this would also be possible, likely providing more control over timing dependencies. There are also several versions of SRAM boards with different memory chips and different arrangements of logic elements. It's hard for me to say whether these boards were simply drawn up or if they considered good design practices. I tend to think they were simplified designs that worked well in certain configurations. For example, O2 itself shouldn't really be used to connect U1MB on these boards.

 

Additionally, I'm now facing a different problem with O2 on IDE+, where a 600XL with SRAM and U1MB connected to SRAM-O2 under SDX cannot launch BASIC. The same issue is happening on an 800XL with DRAM and U1MB connected to BO2 with a 74F08. On an Atari XE with SRAM, without U1MB and with a Rambo memory extension and VBXE, everything works as it should.

[flashjazzcat]

1 hour ago, Piotr D. Kaczorowski said:

You surely remember that I recently checked the signal levels between SRAM and DRAM.

I'm not talking about SRAM as a replacement for DRAM, as should be apparent from careful reading of my post beyond the presence of the acronym 'SRAM'.

[Piotr D. Kaczorowski]

2 minutes ago, flashjazzcat said:

I'm not talking about SRAM as a replacement for DRAM, as should be apparent from careful reading of my post beyond the presence of the acronym 'SRAM'.

You're right.  

[flashjazzcat]

2 hours ago, Peri Noid said:

I think, it's that "mystical" timing thing. No joking here, it just seems that we are still kind of guessing. And we have no reliable way of checking, what's actually going on there, that prevents different cinfigs from working reliably.

The fact SIDE3 was apparently robustly designed to be wholly immune to O2 timing issues but was nevertheless having a nervous breakdown after the latest hardware/JED update on a variety of machines nearly four years later suggests you are correct.

Edited September 26 by flashjazzcat

[_The Doctor__]

Timing, inherent hysteresis of a chip may vary, amplitude, rise and fall times all combine. This isn't a mysterious as it sometimes is made out to be. In a tube of chips it's not always unusual for 8 of 7 to play nice in all machines except one or two, and the 8th chip works in those.

Different runs and manufacturing that ride the edges of tolerance is not uncommon BITD so matching everything up and keeping a scope handy can be key, as you get used to seeing the patterns and duty cycles, a feel for what's correct matched up and is going to work is sometimes developed.

Glue chips matter!

Edited September 26 by _The Doctor__

[flashjazzcat]

I'm sure one of the most experienced and capable hardware designers in the community will have no trouble finally conquering the problem thanks to these insightful and revelatory contributions.