Debugging issues with STE

News, questions and bugs reports about CosmosEx by Jookie. Now we have a Raspberry Pi in our machines!

Moderators: Jookie, Moderator Team

rj1
Atari freak
Atari freak
Posts: 56
Joined: Mon Sep 28, 2015 8:01 pm

Re: Debugging issues with STE

Postby rj1 » Sat Jan 07, 2017 10:33 pm

That's all valid points, with 3.3V CosmosEx high level output we should be fine with 1.3V margin. I still want to try the pull up + high z method though. For now, I'm unable to program the Xilinx with the /ce/update/flash_xilinx script - it says the xsvf file I created with Impact is not ok and it stops. Any hints on how to setup ISE/Impact for this to work, Jookie?

On the other hand, I'm now running tests with both '244 and '245 buffers removed so it resembles ST/Mega configuration now (inputs/outputs shorted). It looks promising - no errors so far with 4.6V supply level, that's the lowest this Mitsumi PSU can go. Before I had to set at least 5.05V for error free test.

If there's anyone out there who has issues with CE and wants to test this solution, let us know the results.

User avatar
Jookie
Hardware Guru
Hardware Guru
Posts: 1245
Joined: Wed Feb 04, 2004 6:54 pm
Location: Kosice, Slovakia
Contact:

Re: Debugging issues with STE

Postby Jookie » Sat Jan 07, 2017 11:43 pm

rj1 wrote:For now, I'm unable to program the Xilinx with the /ce/update/flash_xilinx script - it says the xsvf file I created with Impact is not ok and it stops. Any hints on how to setup ISE/Impact for this to work, Jookie?


I'm using Xilinx WebPack 6.1 (copyright says 1995 - 2003, so it's 14 years old ;) ).

After successful compilation synthesis, fitting, I run the Impact tool, I select Mode -> File mode,
switch to SVF-STAPL-XSVF,
right click to add Xilinx device, Create to - XSVF, write desired file name (e.g. testXilinx.xsvf),
I select the fitted binary - main.jed,
right click on green chip icon, select 'Program',
select 'Erase before programming' and 'Verify', others are unchecked,
press 'OK', close the Impact, and the folder should contain your .xsvf file.

That one should work just fine - maybe they changed something in the newer versions of Xilinx WebPack, which the flash tool doesn't support...

rj1 wrote:On the other hand, I'm now running tests with both '244 and '245 buffers removed so it resembles ST/Mega configuration now (inputs/outputs shorted). It looks promising - no errors so far with 4.6V supply level, that's the lowest this Mitsumi PSU can go.


Now that's an interesting result : :cheers:

Jookie

ijor
Hardware Guru
Hardware Guru
Posts: 3146
Joined: Sat May 29, 2004 7:52 pm
Contact:

Re: Debugging issues with STE

Postby ijor » Sun Jan 08, 2017 3:29 am

rj1 wrote:On the other hand, I'm now running tests with both '244 and '245 buffers removed so it resembles ST/Mega configuration now (inputs/outputs shorted). It looks promising - no errors so far with 4.6V supply level, that's the lowest this Mitsumi PSU can go. Before I had to set at least 5.05V for error free test.


That's extremely interesting, even when difficult to understand. You would expect that the TTL buffers would be more robust and resilient than the DMA chip itself.

When you are talking about VCC supply level, is that for the computer itself, for the CE, or you always use internal power? Because if you are talking about the computer (or both) then it should be the other way around. That is, if the problem is the CPLD high level output not being high enough, then the higher the supply level the worse this problem should be.

May be the TTL buffers are not fast enough? Or may be they sink too much current from the CPLD? The DMA chip is CMOS.

rj1
Atari freak
Atari freak
Posts: 56
Joined: Mon Sep 28, 2015 8:01 pm

Re: Debugging issues with STE

Postby rj1 » Sun Jan 08, 2017 10:29 pm

At the moment I'm using internal STE PSU for both STE and CE.

There is some more interesting facts.

First I noticed that DIL sockets I put in place of '244 and '245 were low quality ones with contact issues (IC was a bit loose when inserted), so I fixed that.
After that, I can rule out the '245 IC (which is data lines transceiver) - it started to work with original 74LS245 in place + a pass through in place of '244 (control signals buffer).
Then I tested 74HCT244 instead of original 74LS244 and it works again (a combination of original 74LS245 for data + a new 74HCT244 for control signals). Interestingly 74F244 I had fails to work.

So the conclusion at the moment is either the 74LS244 is broken (though it tests fine in TL866 programmer's IC test, whatever that test is doing) or there is some other kind of incompatibility between CE and ... 74LS244? something else? - I will check the signals with scope again and also get a new 74LS244 chip and run more tests.

ijor
Hardware Guru
Hardware Guru
Posts: 3146
Joined: Sat May 29, 2004 7:52 pm
Contact:

Re: Debugging issues with STE

Postby ijor » Mon Jan 09, 2017 1:11 pm

rj1 wrote:Then I tested 74HCT244 instead of original 74LS244 and it works again (a combination of original 74LS245 for data + a new 74HCT244 for control signals). Interestingly 74F244 I had fails to work.


Even more puzzling? LOL

In first place, if the problem is indeed related to the '244 buffer, then the problem is at the opposite direction than we though. Not the outputs from the CE to the computer, but the control outputs from the ST to the CE! Honestly, it makes more sense with the voltage issue.

My initial reaction was that the problem is that the 74LS244 is too fast. That would explain why the F fails (F faster than LS, faster than HCT). But then with no buffer at all is, of course, even faster. And in your case without any buffer it works.

It might still be a speed problem, not the propagation delay but the faster transition/slew rate producing ringing or fake pulses. I wonder about the series resistors shown in the STE schematics. May be we need them at the CE side for better impedance matching. Did you kept the resistors when bypassing the buffer?

Only that the "too fast" theory doesn't match the voltage issue. Higher voltage makes chips faster and then it should be worse, not better.

It might be the reduced noise margin, just in the opposite direction than we originally thought. So CMOS outputs, as in the 74HCT244 or the DMA chip directly, work; but TTL level output fails. Even when in this case its 5V outputs driving a 3.3V device, it still applies. The 3.3V CPLD has the same minimum high voltage requirement (2.0V ) as a 5V device.

I wonder how this relates to the (in)famous issue with the IMP DMA chip on the STE.

ijor
Hardware Guru
Hardware Guru
Posts: 3146
Joined: Sat May 29, 2004 7:52 pm
Contact:

Re: Debugging issues with STE

Postby ijor » Wed Feb 15, 2017 3:49 am

Bump .. I'm very curious, rj1. Could you perform more tests on the subject?

rj1
Atari freak
Atari freak
Posts: 56
Joined: Mon Sep 28, 2015 8:01 pm

Re: Debugging issues with STE

Postby rj1 » Wed Feb 15, 2017 8:21 am

I didn't do much anymore.
I simply bridged 244 and 245 over, which just works fine ATM.
I have the inline resistors, yes. Interesting is Atari changed the resistor values at some point in time, according to available schematic: 68R in STE and TT, 68R in MSTE REV2 schematic from April 1990 but then reduced to 10R in MSTE REV B from July 1990 and REV C from Feb 1992.
So I could try 10R also.

Also it could be that the buffers silicon is aging or there was some ESD stress in their lifetime as they are exposed to the world.
I bought some NOS 74LS244/74LS245 so I will try with those.


Social Media

     

Return to “CosmosEx”

Who is online

Users browsing this forum: No registered users and 1 guest