DFB1 Support thread

[exxos]

@markus0321 What clock patch do you have in your machine ? SCSI issues are normally related to problems with the SDMA clock line AFAIK.

[Badwolf]

It's possible this is the first SCSI drive used with DFB1. I for sure haven't tried it with SCSI as I own no SCSI devices.

I would concur with Exxos that a decent clockpatch is the most important thing, especially when loading down the bus further. The other thing that I don't know about is how data transfer from SCSI happens -- if it's a DMA transfer it won't be able to reach TT-RAM nor will the blitter work, so I think the hard disc driver may have something to say about things.

Are you using HDDriver by any chance?

BW

[dml]

If it reliably fails with FastRAM mapped, but works ok with FastRAM disabled (but with everything else still accelerated) then it is most likely the disk driver trying to initiate SCSI DMA transfers from FastRAM, which the hardware can't do.

A FastRAM-aware disk driver should prevent that (HDDriver should cover that). I think floppy access can have the same issues - I use an AUTO patch to get around that on the AB040 board.

[markus0321]

@markus0321 What clock patch do you have in your machine ? SCSI issues are normally related to problems with the SDMA clock line AFAIK.

I had a 47-100ohm resistor mounted next to the clock line next to the SDMA chip. But it seems to me that if the clock signal was to be bad, the disk would not work always and not only how would I start TT-RAM?

[markus0321]

It's possible this is the first SCSI drive used with DFB1. I for sure haven't tried it with SCSI as I own no SCSI devices.

I would concur with Exxos that a decent clockpatch is the most important thing, especially when loading down the bus further. The other thing that I don't know about is how data transfer from SCSI happens -- if it's a DMA transfer it won't be able to reach TT-RAM nor will the blitter work, so I think the hard disc driver may have something to say about things.

Are you using HDDriver by any chance?

BW

Yes, I used HDDRIVER, I also tried using EmuTOS and then there are also problems. DMA transfers seem to work because otherwise it would not read the disk at all and here it works ok, but from time to time there are distortions in the transmitted data.

[markus0321]

If it reliably fails with FastRAM mapped, but works ok with FastRAM disabled (but with everything else still accelerated) then it is most likely the disk driver trying to initiate SCSI DMA transfers from FastRAM, which the hardware can't do.

A FastRAM-aware disk driver should prevent that (HDDriver should cover that). I think floppy access can have the same issues - I use an AUTO patch to get around that on the AB040 board.

Yes, it is enough that I do not use MAPROM or FASTRAM and with active DFB1 the scsi disk works properly. I also had a problem with copying files from the IDE to a floppy disk, sometimes the files got corrupted. :-(
Earlier I thought I had old damaged floppy disks but now I think these floppy disk problems are similar to those with a SCSI disk.
It's as if the read/write doesn't work properly when the program that handles it is running in TT-RAM.
Can this be fixed somehow?

[markus0321]

If it reliably fails with FastRAM mapped, but works ok with FastRAM disabled (but with everything else still accelerated) then it is most likely the disk driver trying to initiate SCSI DMA transfers from FastRAM, which the hardware can't do.

A FastRAM-aware disk driver should prevent that (HDDriver should cover that). I think floppy access can have the same issues - I use an AUTO patch to get around that on the AB040 board.

What is this patch in AUTO, maybe it will also work with DFB1? Can I try to test it?

[dml]

What is this patch in AUTO, maybe it will also work with DFB1? Can I try to test it?

I am not sure - I just remember seeing it flash by recently while booting the AB40 and remembered that floppy DMA access probably needs help to avoid FastRAM. I think it patches the GEMDOS DTA buffer or something to keep it in STRam.

Anyway I'll dig it out and post a link today sometime.

[markus0321]

What is this patch in AUTO, maybe it will also work with DFB1? Can I try to test it?

I am not sure - I just remember seeing it flash by recently while booting the AB40 and remembered that floppy DMA access probably needs help to avoid FastRAM. I think it patches the GEMDOS DTA buffer or something to keep it in STRam.

Anyway I'll dig it out and post a link today sometime.

Cool. I will be grateful, and next time I will test if it helps and write back here on the forum. If it works, I'll let you know.
In the meantime, I'll make some 1.44MB ZIP files for testing.

[dml]

Yes, I used HDDRIVER, I also tried using EmuTOS and then there are also problems. DMA transfers seem to work because otherwise it would not read the disk at all and here it works ok, but from time to time there are distortions in the transmitted data.

That seems a bit weird, for sure.

The location of the file transfer buffers will affect SCSI and floppy access when FastRAM is present. If the buffers are in FastRAM, the disk transfer will always fail. They might move around depending on what is in your AUTO folder and how things are configured, but won't move around between disk accesses. That would be an easy test to confirm.

If transfers work most of the time but fail intermittently (and with HDDriver, which should be safe re: FastRAM) it does seem more like a signals issue.

The CPU data cache can corrupt DMA transfers if not flushed but TOS & HDDriver should also protect against that since it is a property common to all 030 machines.

[EDIT]

I had to deal with some of these issues in the AB040 driver I made years ago - the 040 just makes all the same problems worse (bigger data cache, TOS mapped to FastRAM etc. etc.). But its basically the same set of problems, including potential signals issues for SDMA.

I'll have a look through the code and see what patches it makes for disk access safety. Maybe something useful there.