STe - Bad DMA Chip

[tzok]

I have an STE with a "bad" DMA and a MC68HC000FN16 (it runs @8MHz in the STe) and "We Were @" runs just fine on it. Same on TOS 2.06 ad on TOS 1.62.

[czietz]

Edit: We Were @ - another recent trackloader - does not load with an HC installed either. It does run from harddrive (IDE), but it apparently does some crazy stuff because my LCD TV does not like it at all

For reference: I (only) tested the harddrive version of "We were @" on the HC CPU. Closure on the other hand was -- of course -- loaded from a (real) floppy disk during my test.

[joska]

So atleast two people has successfully tested with a HC CPU . tzok has a "bad" DMA, czietz - which DMA do you have in your STE? I have the "good" DMA.

[czietz]

So atleast two people has successfully tested with a HC CPU . tzok has a "bad" DMA, czietz - which DMA do you have in your STE? I have the "good" DMA.

Like tzok, I have the purportedly "bad" DMA in my STE. However, even with the original NMOS CPU I can use my Gigafile with it without any issues. I tried hard to provoke any errors but couldn't, even though my DMA is supposed to be "bad".

Maybe your "good" DMA chip doesn't like the HC CPU?

[joska]

Like tzok, I have the purportedly "bad" DMA in my STE. However, even with the original NMOS CPU I can use my Gigafile with it without any issues. I tried hard to provoke any errors but couldn't, even though my DMA is supposed to be "bad".

The "bad" DMA only has problems with certain hardware. E.g. original Atari disks almost never gave problems. I guess that's why this bug slipped through the engineers' fingers in the first place.

Maybe your "good" DMA chip doesn't like the HC CPU?

Yes, that is possible. Both STE's where closure and We Were fails have the "good" DMA, and (so far) all STE's where these demos works on even with the HC CPU have the "bad" DMA. If this pattern can be confirmed it's bad news for future 68000-based accelerators. But too early to say with only four machines tested.

[czietz]

The "bad" DMA only has problems with certain hardware. E.g. original Atari disks almost never gave problems. I guess that's why this bug slipped through the engineers' fingers in the first place.

Yes, but the Gigafile (along with the Ultrasatan) is known to be problematic in some STEs according to Exxos' research. It just goes to show that every machine is slightly different and having a so called "bad" DMA does not automatically mean that you will have problems.

[tzok]

For the ones having a Gigafile/UltraSatan - do you have any resident programs / accessories loaded? I've found some of the CPXs cause a system crash when loading certain games/demos.

[ijor]

Edit: We Were @ - another recent trackloader - does not load with an HC installed either. It does run from harddrive (IDE), but it apparently does some crazy stuff because my LCD TV does not like it at all

For reference: I (only) tested the harddrive version of "We were @" on the HC CPU. Closure on the other hand was -- of course -- loaded from a (real) floppy disk during my test.

Somebody is familiar with "We were" internals? Does it have its own floppy loader as Closure?

It is conceivable that the CMOS CPU affects the floppy interface negatively. Not saying that it does, just that it is conceivable. And if it does, this will likely affect only code that doesn't have a good floppy retry logic (again, that seems to be a problem with Closure 1.0). So it might be mostly harmless, and then not noted, on most other cases.

Note that the CMOS CPU, besides better DC characteristics as a direct consequence of being CMOS, it also has better AC specifications because it is much faster. Not sure how this could affect the floppy interface that is completely isolated from the CPU though.

[troed]

(joska tested Closure v1.1 and it was the same. That said, my code could still be crappy I hope I also get the error when I put an HC CPU in my "good DMA" STE)

I believe Leonard also has his own floppy DMA code.

[ijor]

(joska tested Closure v1.1 and it was the same. That said, my code could still be crappy
...
I believe Leonard also has his own floppy DMA code.

He has, but why you assume his floppy code is as crappy as yours? LOL, just kidding.

Seems the problem is something else anyway. And I have a feeling it won't fail for you when you put a CMOS CPU ...

[joska]

Yes, that is possible. Both STE's where closure and We Were fails have the "good" DMA, and (so far) all STE's where these demos works on even with the HC CPU have the "bad" DMA. If this pattern can be confirmed it's bad news for future 68000-based accelerators. But too early to say with only four machines tested.

A third successful test with HC and {closure} has been done, again with an STE with the "bad" DMA. The plan is to replace the DMA with a good one and see what happens.

[mlynn1974]

Has anyone checked the serial number ranges for the different ST models and when they changed over to use the newer DMA chips?
Did Atari use both types throughout the whole production run of the STE (1989-1992)?

It might be nice to get the upper and lower bounds on the serial numbers for the following models and work out the DMA chips in each:
1. Early STe models with SIPP modules and TOS 1.6,
2. STe models with TOS 1.6 and SIMM modules (like mine),
3. Later STes with TOS 1.62
I have personally never seen an STe with SIPPS.

I bought my STe from a friend in October 1991 and he said he was selling it at a discount because it didn't work with his hard disk. Another friend said it would work with Atari Hard Disks but not some others, which was the advice by Atari at the time.
This was OK for me because at the time I couldn't afford a hard disk and wouldn't be using one with it.

[dlfrsilver]

the other problem is that the STE got 14 different revisions of motherboards, and the modifications made have never been documented anywhere.
One thing is sure, the STE with MB final revision and final DMA version were built end during 1991. STE machine made between 1989 and 1990 have beta revision of the motherboard and everything that can ensue.

[ijor]

It is strange that STE shipped with the old (Ricoh) DMA chip at all. IIRC, later STF/STFM already shipped with the newer DMA chip even before the STE was announced. You would assume that by the STE time, all the older DMA chips were delivered already, and likely it wasn't manufactured anymore.

[Jeff_HxC2001]

@ijor Closure is syncing to HBL interrupt. What do you think - E-clock differences? I do analyze the E-clock jitter dynamically instead of relying on the fact that's it always the same on ST/STE [with the non-HC CPU]

Don't know. But doesn't seems likely, I wouldn't expect the E clock to be any different than the NMOS part.

That's the first time we hear a report about the HCMOS CPU to be not fully compatible. Although Jeff (HxC creator) did mention that some demos fail some time ago. We asked him which ones, but he never replied. I assumed then it might be a mistake and he was mixing up with the later 68000 SEC part.

@joska. Yes, please, post a picture if possible

This was the Atari ST 32768 Colour Showdown. Some pictures aren't displayed correctly with an hcmos 68k.
I even remember that i was able to change the the displayed picture by touching with the fingers the 68k bus.
These devices have not the same signals rising & falling time & logic switching voltage level so this is not a surprise to me...

Anyway "faster" rising/falling signals on an old layout/motherboard not designed for this is probably not an good idea (say welcome to line impedance & signal ringing issues... )

[tzok]

This was the Atari ST 32768 Colour Showdown. Some pictures aren't displayed correctly with an hcmos 68k.

I haven't noticed anything unusual with this demo on my 68HC000 equipped STe. Maybe I don't know what to look for.

[ijor]

This was the Atari ST 32768 Colour Showdown. Some pictures aren't displayed correctly with an hcmos 68k.
I even remember that i was able to change the the displayed picture by touching with the fingers the 68k bus.
These devices have not the same signals rising & falling time & logic switching voltage level so this is not a surprise to me...
Anyway "faster" rising/falling signals on an old layout/motherboard not designed for this is probably not an good idea (say welcome to line impedance & signal ringing issues... )

Ah, but this is something else, not really an incompatibility. Yes, the timing specifications and the voltage swing are different and conceivable it might affect something. Not sure how much likely this really is though. Consider that the whole custom chipset is CMOS already. And almost every single signal driven by the CPU is also driven by the chipset as well at some point, including the whole address and data bus when performing Blitter DMA. So any analog issues that could be caused by a CMOS CPU should be caused by the chipset as well, and it (normally) doesn't.

I'm not familiar with that demo, but from the name I am guessing that the visual defect might be related to wrong colors when displaying Spectrum 512 effects unsafely. IF that is the issue, it is not that uncommon and can happen with a bog NMOS CPU as well.

[Jeff_HxC2001]

@ijor Closure is syncing to HBL interrupt. What do you think - E-clock differences? I do analyze the E-clock jitter dynamically instead of relying on the fact that's it always the same on ST/STE [with the non-HC CPU]

Don't know. But doesn't seems likely, I wouldn't expect the E clock to be any different than the NMOS part.

That's the first time we hear a report about the HCMOS CPU to be not fully compatible. Although Jeff (HxC creator) did mention that some demos fail some time ago. We asked him which ones, but he never replied. I assumed then it might be a mistake and he was mixing up with the later 68000 SEC part.

@joska. Yes, please, post a picture if possible

This was the Atari ST 32768 Colour Showdown. Some pictures aren't displayed correctly with an hcmos 68k.
I even remember that i was able to change the the displayed picture by touching with the fingers the 68k bus.
These devices have not the same signals rising & falling time & logic switching voltage level so this is not a surprise to me...

Anyway "faster" rising/falling signals on an old layout/motherboard not designed for this is probably not an good idea (say welcome to line impedance & signal ringing issues... )

Got the time to test the demo again :

Original NMOS 68000 :






CMOS 68HC000 :



Touching the bus :









Same motherboard, Same power supply, Same DRAM, and same room temperature !

Tried to change the PSU, DRAM, place the shield : The issue still there with the 68HC000. With the normal 68000 this is rock-solid.
(Tested & verified several times with 68000 & 68HC000 CPU).

I have also see some glitches with the We Were @ demo with the 68HC000.

[ijor]

This was the Atari ST 32768 Colour Showdown. Some pictures aren't displayed correctly with an hcmos 68k.
...
Got the time to test the demo again :

Same motherboard, Same power supply, Same DRAM, and same room temperature !

Tried to change the PSU, DRAM, place the shield : The issue still there with the 68HC000. With the normal 68000 this is rock-solid.
(Tested & verified several times with 68000 & 68HC000 CPU).

Interesting. Just in case, can you post a link to the exact version of the demo you are using?

[tzok]

This demo was working fine on my STe with HC CPU. I've got a slightly older M/B revision (CA4003290), with 2 small ICs under SIMM slots, and a 3rd IC mounted as a "backpack" on one of the existing.

[dlfrsilver]

The problem is more subtile than it is. One of the difficulty to see clear, are the numerous motherboards revisions.... How to do in order to make fixes working on all machines and not some only working on specific MB revisions... Mmhh?

[mlynn1974]

I would say that the problem seen with this demo are unlikely to be caused by problems with the STe DMA Chip.
It should perhaps be mentioned in a separate thread.

There are other factors at play which the programmers didn't know about at that time:
1. It is now known that there are 4 wakeup modes.
2. Could slight differences in clock speeds cause problems? The Alien (Pompey Pirates) mentioned in a scrolltext that maybe Motorola's quality control was sloppy?
3. Has the HCMOS 68000 machine had the pullup resistors fitted as discussed by Mikro and Exxos?
viewtopic.php?f=15&t=28504&p=282046

I remember the old problem of black pixels being present in some Spectrum 512 pictures - even on the STFM.

[troed]

1. It is now known that there are 4 wakeup modes.

Not on STE

[tzok]

Have anyone read this:

We received trouble reports from a few STe's used in combination with a hard drive. The problem that arose was the mutilation of data, directories or the presence of faulty sectors during the work. These effects result from the fact that some brands of SIMM's can influence the line "Acknowledge". The problem can be solved by placing a 30PF capacitor on the CPU (U100) between pins 13 and 16. Then the value of P100 should be decreased to 1K2. This can be done by placing a "second" resistor pack "in parallel with the first while retaining the same value of 2K2. Finally you must connect the pin 9 of the P105 to the pin 1 of the U401. Note that this fitting is existing on the circuit. Check its operation with a universal multimeter! We have written a program of tests specifically designed to control the communication of hard disks. This program works on all Toss systems on ST and TT computers. This program is called HDCHECK and is found in our ATARI-Net Bulletin Board SIG15, under Nos (03473-77584 and 77376) HDCHECK generates "directories", creates the "files" to eliminate them afterwards and check after each creation if the system has received the correct information in the "directories" and the "FATs" This program is especially recommended for burn-in tests.

This is from Atari STe technical bulletin, found at: http://gossuin.be/index.php/520-et-1040-stx (http://gossuin.be/images/schemasatari/N ... E%20FR.pdf)

Best Tech Tips suggested a 30 pF capacitor between pins 2 and 4, but this has no sense, as these are two databus lines (D1 and D3)... the Atari Technical Bulletin mentions pins 13 and 16 which are XBR (Bus Request) and GND, and this has much more sense.

[bulga]

Hi all!

Just joined the Forum as I got my first Atari STe last month and was hoping someone here could help me. I recently found out that my STe has a bad DMA chip and with the ultrasatan soon to be finished I want to try and sort this out before I recieve it.

I do have a STFM and was wondering if it was possible to use the DMA chip from that? If not does anyone no where I can buy one?

Thanks
Mark

I follow this invsestigation: https://www.exxoshost.co.uk/atari/last/DMAfix/index.htm, I've changed the cpu with a Freescale 68HC000.
Problem solved. Bad DMA is a mith.