Jookie's home page

Preface:
Some UltraSatan users reported that they are experiencing data corruption and/or partition losses when using their UltraSatan on their STE and/or Mega STE. I would like to highlight the word ‘some’, becuase I think that the most of UltraSatan users have no trouble using UltraSatan on (Mega) STE – I have tested UltraSatan on my STE and Mega STE and also on the Mega STE borrowed from MiKRO and it’s all working fine. But I managed to borrow one problematic STE from one guy from Slovakia (which lives near MiKRO) and did some testing…

Problem:
According to some measurements I made only some STE machines are affected by this problem, and even on those machines reading from UltraSatan is not affected and works fine – the problem is only with writing to UltraSatan (and probably other ACSI devices). You can read more about the faulty DMA chip here:
http://www.atari-forum.com/viewtopic.php?f=15&t=16745

As you can see from the following picture, the DATA lines in ‘DMA write’ phase should move up and down (logical 1 and logical 0) according the written data as on the picture on the left, but they are just not moving (they stay in logical 0) – the picture on the right.

Please note that the first 6 or more ACSI/SCSI command bytes are sent to UltraSatan in ‘PIO write’ mode and this is working fine – the data goes from ST to UltraSatan as it should and the signals can be measured on the ACSI connector and they look like they should. So only ‘DMA write’ is problematic. ‘PIO read’ and ‘DMA read’ are working fine.

The chip in the borrowed and problematic STE is ‘C025913-38′.

Solution:
It seems that when you have the problematic DMA chip (you can find out by the chip signature – C025913-38 == bad, C398739-001A == good) then the only solution seems to be replacing the DMA chip. There was some report / idea to replace the ACSI data bus driver U302 (to replace 74LS245 with 74HCT245) to fix the problem, but after these measurements I believe that this won’t help, because:

• the data goes well from ST to device in PIO mode but not in DMA mode so it does looks like the problem would be caused by the bus driver (the data goes through the same driver in DMA and PIO mode and they go out from the same pins of DMA chip).
• the data before the bus driver and after the bus driver in ‘DMA write’ mode is the same (all logical 0s, not even a sign of trying to get to logical 1) so the 0s are really what’s going in and out of the driver – it’s not like the DMA chip is trying to transmit something and the bus driver is killing it – that’s not happening.

This is what I believe in according to my latest measurements. Please correct me if I’m wrong Please note that I tried this with SatanDisk also (ancestor of UltraSatan) and the problem remained – it’s not really a problem of SatanDisk or UltraSatan, it’s a problem of some STEs – they should be fixed, not UltraSatan.

But why I got problems when I don’t write anything to card?
When ICD Pro driver boots, it reads some information to bootsector and then it writes the (probably modified) bootsector back – this is why it will not be able to boot after one reset – the bootsector contains the first part of the hard disk driver (ICD Pro or HDDRIVER) and also some info about partitions and when this is rewritten by all 0s then it becomes not bootable.
The situation might be different with HDDRIVER – I didn’t check if it writes something during boot to bootsector or somewhere else, so you might survive a reset without data loss, but writing even single small file would result in FAT table corruption and thus data loss.

Have you tried to replace the bus drivers?
Yes, I have tried that on 2010-01-20. I removed the original bus drivers (LS versions, in STE they have part numbers U302 and U307), soldered some sockets there and tried to boot with UltraSatan and with ICD driver on card (and the 2nd boot always fails with faulty DMA chip, as I wrote above). Every test started with power-on of ST (1st boot) and I tried 2 reboots with the reset button on the back, the UltraSatan was connected and turned on all the time.

 

driver types	1st boot	2nd boot	3rd boot
LS (as original)	floppy reads a bit, then boots ICD driver from UltraSatan	floppy reads a bit, then goes to desktop (SD card data corrupted)	same as previous (and for every next boot)
HC	no floppy access, no UltraSatan boot, goes into desktop without icons	floppy reads a bit, then boots ICD driver from UltraSatan	floppy reads a bit, then goes to desktop (SD card data corrupted)
HCT	no floppy access, no UltraSatan boot, goes into desktop without icons	floppy reads a bit, then boots ICD driver from UltraSatan	floppy reads a bit, then goes to desktop (SD card data corrupted)

 

As you can see, there was no improvement of the situation when the bus drivers were replaced in my case (it didn’t fix the STE). There was no difference in effect of the HC and HCT types.