exxos's Atari, Amiga & retro forum

Yes, I use them all the time, at least the 16V8 ones.

frank.lukas wrote: 03 May 2022 18:48

Dbug wrote: 02 May 2022 18:21
Seems to be working (found a version 2.30 on the Atari Coldfire Project page)

Use a JPEG that fills the entire free memory ...

Well, I downloaded a high resolution wallpaper, and reduced it to various resolutions from 640 to higher. It loaded fine until 1024x576, but 1280x720 triggered a message box in German which probably meant there was not enough memory. Now, I can probably recurse between 1024 and 1280 to find exactly when it stops loading, but the concept of "jpeg that fills the entire free memory" is not something I can guess not knowing how the program is designed.

I think I found something that could explain quite many problems, just not sure what causes it.

I copied back the Kronos archive from the MegaSTe to the PC, and did a binary compare of every single file with the original archive, most of the files were fine, but four of them have some bytes corrupted, and as far as I can see, it's always only once, and the same 16 consecutive bytes


Are there DMA/Transfer checksum stress-test programs on the ST?

Like something which would busily read and write large amount of data to disk, try to read it back, check if the content match what was written, etc...?

In this case, the corruption was on write, but it technically could also have been a mis-read.

Regarding how these files ended up on my machine, I've been mostly using two methods:
* Sometimes using the NetUSBee with uIPTools to send files from the web browser interface directly to the right location on the MSTE disk
* Most of the time using the UltraSatan second SD card with TOS/Windows compatible format to transfer the files, then copy them to the right location

I guess the possible suspects are
* The SD card
* The NetUSBee/uIPTools
* The UltraSatan
* The long flat cable between the UltraSatan and the internal adapter
* HDriver (11.08)
* The mythical "DMA"

If there is some random corruption happening in some cases when reading files, that could explain things, but then Photoline would probably have shown some corruption when loading the big jpeg files...

Looks like 'bus loading' issues. Too much stuff on the bus. Usually solved by lowering address/databus SILS to 2.2k. Back 'in the day' nobody ran these machines far from stock, these days with all the add-ons we have just pushes it over the edge.

I think I mentioned in perhaps my first couple of posts, can you not try running from SCSI? Just to see if there is a change in behaviour.

Here you go.. the very first reply to this thread:

Secondly the big 'red card' that comes up for me is Ultrasatan, which version are you using. Do you have the ability to try a SCSI drive instead? Reason Ultrasatan worries me is there are some dodgy versions on the market (non-Lotharek) and you're also open to DMA issues with it depending on your hardware.

Steve wrote: 05 May 2022 15:35 Looks like 'bus loading' issues. Too much stuff on the bus. Usually solved by lowering address/databus SILS to 2.2k. Back 'in the day' nobody ran these machines far from stock, these days with all the add-ons we have just pushes it over the edge.

I think I mentioned in perhaps my first couple of posts, can you not try running from SCSI? Just to see if there is a change in behaviour.

Here you go.. the very first reply to this thread:

Secondly the big 'red card' that comes up for me is Ultrasatan, which version are you using. Do you have the ability to try a SCSI drive instead? Reason Ultrasatan worries me is there are some dodgy versions on the market (non-Lotharek) and you're also open to DMA issues with it depending on your hardware.

I would have tried a SCSI device if I had one, but my 1GB Micropolis SCSI har drive has died a long time ago, since then I've only used Satandisk and Ultra Satan (both from Lotharek).

For the bus loading, it looks like not everybody agreed on the thread, but it sure does look like the type of corruption people were talking about on STe.

I'm ok to try things as long as they are not risky for the machine :)

Since we've been discussing this on IRC I'll just add to the thread, for posterity, that 16 bytes is the size of the internal DMA fifo. Also, _Dbug_ has previously had severe DMA issues on this machine and got rid of them (or only mostly?) by changing to the HC CPU. The DMA chip is the square -001 model.

troed wrote: 05 May 2022 18:06 Since we've been discussing this on IRC I'll just add to the thread, for posterity, that 16 bytes is the size of the internal DMA fifo. Also, _Dbug_ has previously had severe DMA issues on this machine and got rid of them (or only mostly?) by changing to the HC CPU. The DMA chip is the square -001 model.

That one actually:


And yes, before replacing the 68000 by the one from the exxos store, I had a lot of fat corruption, filenames with invalid ATASCII characters which could not be deleted, etc... after replacing the cpu, all that disappeared, but I guess it's possible that only solved the worse cases, and that when the graphic card is enabled that adds more stress to the machine and ends up generating the same type of corruption.

One thing that might improve DMA stability is buzz out the GND pin on the chip, when you find it solder a wire to it and connect to the GND around the edge of the motherboard, or whatever convenient point. I did this with my TT's SCSI chip and it improved my SCSI reliability. This reduces ground spiking.

Edit: just remembered I used a 1uf capacitor I think.

The machine I am working on passes every test and bombs randomly. The two things I plan to take a look at are sockets and sil's. Mine has that square DMA chip as well and I am suspicious of it. I was also iffy on the 1772 but I think floppy issues are a symptom, not the problem. These boards are pretty fragile.

atari030 wrote: 05 May 2022 22:29 The machine I am working on passes every test and bombs randomly. The two things I plan to take a look at are sockets and sil's. Mine has that square DMA chip as well and I am suspicious of it. I was also iffy on the 1772 but I think floppy issues are a symptom, not the problem. These boards are pretty fragile.

Regarding the SIL, on my machine I can see 6 of red color (M9-1-102J), and 4 which are black (T1A 103J).


As far as I can see, the black ones are 10 Kohm, and the red ones are 1 Kohm.

Does anyone know what the logic is, like the low TOS chip has a RED one on each side, but the high TOS chip has black ones :?