Moderators: Mug UK, Zorro 2, Greenious, spiny, Moderator Team
joska wrote: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
joska wrote: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 wrote: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".
czietz wrote:Maybe your "good" DMA chip doesn't like the HC CPU?
joska wrote: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.
czietz wrote:joska wrote: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.
troed wrote:(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.
joska wrote: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.
ijor wrote:troed wrote:@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
Jeff_HxC2001 wrote:This was the Atari ST 32768 Colour Showdown. Some pictures aren't displayed correctly with an hcmos 68k.
Jeff_HxC2001 wrote: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...)
Jeff_HxC2001 wrote:ijor wrote:troed wrote:@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...)
Jeff_HxC2001 wrote: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).
mlynn1974 wrote:1. It is now known that there are 4 wakeup modes.
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.
blackpanther wrote: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
Users browsing this forum: No registered users and 10 guests