DFB1 Support thread

[Badwolf]

There's no conceptual problem with DFB1 and floppy access. If you're seeing that then it's overwhemingly likely to be a clock patch issue.

It sounds like you've got one of the old 'crowbar' type workarounds. That approach really put a strain on the chips and it's possible the increased frequecny of demand or the increase power draw when running 'fast' (ie. from TT-RAM) is enough to cause instability.

I was going to suggest making sure all 'Blitter' options are disabled within HDDriver, but EmuTOS doesn't have that problem.

EmuTOS is a great way to test these things, by the way. You don't need any patches in the auto folder if you're using a relatively up-to-date version. It will take care of all the FRB buffers and the like.

If you place a jumper on OPTION2 you will block DFB1 from accelerating when using TT-RAM. Things will be slow, but it would be instructive to see if your corruption problems go away. This is not a fix, this is just to provide a data point.

Ultimately you'll need to replace that low value resistor near the SDMA chip with a 150k one and fit a proper clock buffer board.

BW

[markus0321]

There's no conceptual problem with DFB1 and floppy access. If you're seeing that then it's overwhemingly likely to be a clock patch issue.

It sounds like you've got one of the old 'crowbar' type workarounds. That approach really put a strain on the chips and it's possible the increased frequecny of demand or the increase power draw when running 'fast' (ie. from TT-RAM) is enough to cause instability.

I was going to suggest making sure all 'Blitter' options are disabled within HDDriver, but EmuTOS doesn't have that problem.

EmuTOS is a great way to test these things, by the way. You don't need any patches in the auto folder if you're using a relatively up-to-date version. It will take care of all the FRB buffers and the like.

If you place a jumper on OPTION2 you will block DFB1 from accelerating when using TT-RAM. Things will be slow, but it would be instructive to see if your corruption problems go away. This is not a fix, this is just to provide a data point.

Ultimately you'll need to replace that low value resistor near the SDMA chip with a 150k one and fit a proper clock buffer board.

BW

I did the tests.
1. Unpacking lharc with the OPTION jumper on does not fix the problem. There are still errors when unpacking the archive located on the SCSI drive.
2. I removed the OPTION jumper and used EmuTOS instead of TOS4.04 and in this case the archive is unpacked correctly on the SCSI disk.
So I am to understand that TOS has bugs in SCSI support? So I only have to use EmuTOS when I want to use SCSI and DFB1 drives at the same time?
Did changing the clockpatch to the exxos store fix the way SCSI works with TOS4.04?

[exxos]

I think you need to retest. You used OPTION2 in one test and then not another.

You should remove DFB1 and try EMUTOS and TOS in the motherboard directly to do a proper comparison. You also need to test both OS maybe 10 times each.

I would also benchmark SCSI. Code changes can change the noise on the system enough to make or break something. Maybe EMUTOS SCSI driver is slower than when using TOS ? are you using EMUTOS built in driver and then using HDDriver11 for TOS ? EMUTOS may favour TTram and TOS does not. MAybe you have bad ST-RAM ? All factors to consider and test. These things can be a lot more complicated to diagnose than you think. IMO the conclusion that one OS works and another doesn't, is not the case.

Lots of people use SCSI on the falcon with TOS404. problems are outlined by Atari themselves and need a clock patch to solve. I used to use SCSI daily for years on my own falcon without issue .

There are DMA test programs in the software essentials section. You should start there. As I think your stock machine is malfunctioning and this needs to be resolved before using the DFB1.

[Badwolf]

I did the tests.
1. Unpacking lharc with the OPTION jumper on does not fix the problem. There are still errors when unpacking the archive located on the SCSI drive.

OK, that doesn't prove anything in and of itself, but is a data point for later investigations.

2. I removed the OPTION jumper and used EmuTOS instead of TOS4.04 and in this case the archive is unpacked correctly on the SCSI disk.

That's great, and does show that there's not a conceptual problem with SCSI + TT-RAM + EmuTOS under Falcon (which we knew, but is nice to prove).

Of course, now you have to repeat this test many times with both SCSI and Floppy (you mentioned floppy problems -- floppy problems are nothing to do with SCSI and would indicate a failing SDMA clock line).

So I am to understand that TOS has bugs in SCSI support? So I only have to use EmuTOS when I want to use SCSI and DFB1 drives at the same time?

No, this is a massive extrapolation from a very limited data set. We're still trying to pin-point the problem & have not carried out repeat tests nor analysis of floppy reads and writes.

When using TOS, you're using HDDriver to speak to SCSI. You first need to make sure HDDriver is correctly configured to support SCSI access to and from TT-RAM. I don't know how to tell you to do that -- that would be up to you to find out and be convinced is correct. You cannot use blitter acceleration, for example.

I know that might be hard, hence I suggest debugging with EmuTOS.

EmuTOS doesn't use HDDriver and I know it fully supports data transfer to and from DMA devices into TT-RAM, so it's a good base platform to evaluate the hardware before worrying about the software configuration.

Did changing the clockpatch to the exxos store fix the way SCSI works with TOS4.04?

Obviously not, however if it turns out you still have unreliable DMA transfers -- and you need to test the floppy too, you said it had a problem -- to & from TT-RAM when using EmuTOS, then you can be assured it's a hardware problem. If you have a clock buffer patch, then you don't necessarily need to replace it, but you do need to remove the low-value resistor across the end of the SDMA clock line.

In summary: please run repeat tests without OPTION2 under EmuTOS+TT-RAM for both reading and writing to both SCSI and floppy drives to convince yourself that is 100% reliable before moving onto HDDriver & TOS. If this configuration is not 100% reliable, it's the clock patch.

Cheers,

BW.

[markus0321]

Many thanks for the feedback from you and the Exxos.
Now I'm going to do some tests, which will probably take me a long time :)
As for the floppy errors, maybe I didn't notice and I was copying files using a SCSI disk and this could have damaged these files, not the recording itself in the disk drive.
If I do more tests, I'll let you know, but today I copied whole partitions several times on the same SCSI disk with EmuTOS and MAPROM with DFB1 turned on and nothing was damaged. Previously, under TOS4.04, copying files between partitions several times resulted in unstable system behavior, file corruption, or random programs not starting.

[markus0321]

I have one more question.
Is it possible to somehow compile or configure EmuTOS in such a way that it does not use its own disk driver but uses HDDRIVER?

[Badwolf]

I have one more question.
Is it possible to somehow compile or configure EmuTOS in such a way that it does not use its own disk driver but uses HDDRIVER?

In theory it would be possible to alter the boot sector detect code to launch what it found there rather than use the internal driver, but I did look into doing this once and found I didn't understand enough about the hard disc bootstrapping system to achieve it.

There's no easy compile-time option, no.

BW

[markus0321]

I have one more question.
Is it possible to somehow compile or configure EmuTOS in such a way that it does not use its own disk driver but uses HDDRIVER?

In theory it would be possible to alter the boot sector detect code to launch what it found there rather than use the internal driver, but I did look into doing this once and found I didn't understand enough about the hard disc bootstrapping system to achieve it.

There's no easy compile-time option, no.

BW

Well, I was also looking for some option in the compiler configuration but I didn't find it, and I have too little knowledge to understand where and how to modify the code :-(

[exxos]

Didn't they add in a key to press to skip the driver recently ? Or did I dream that ?

[markus0321]

Didn't they add in a key to press to skip the driver recently ? Or did I dream that ?

I looked in the changelog but couldn't find it :-(