DFB1 Support thread

[mfro]

EmuTOS deliberately makes no attempt to load and execute the root sector program of an attached hard disk (why should it, anyway, with its own hard disk driver loaded already?).

What you can do instead is put HDDRIVER into the auto folder on the C drive. Just make sure "Preserve Existing Drives" is *not* set in "Settings/Devices and Partitions". HDDRIVER will then replace the EmuTOS hard disk driver.

[czietz]

Booting HDDRIVER from a hard-disk root sector is not supported[*] by EmuTOS. If you really need to use HDDRIVER, the easiest option is to boot from a floppy disk (press [Alt] at the EmuTOS boot screen) with HDDRIVER on it. But note that there can be situations where EmuTOS's built-in hard disk driver and HDDRIVER interfere with each other; so this is not a recommended configuration (except perhaps for testing).

[*] Then again, as it's open source, you can always write the required code to support 3rd-party disk driver booting and build your private version of EmuTOS. :)

[Steve]

@markus0321 not sure why you're doing all this testing, you just need to fit a good clock patch. It's common knowledge for falcon hardware.

[Rustynutt]

Booting HDDRIVER from a hard-disk root sector is not supported[*] by EmuTOS. If you really need to use HDDRIVER, the easiest option is to boot from a floppy disk (press [Alt] at the EmuTOS boot screen) with HDDRIVER on it. But note that there can be situations where EmuTOS's built-in hard disk driver and HDDRIVER interfere with each other; so this is not a recommended configuration (except perhaps for testing).

[*] Then again, as it's open source, you can always write the required code to support 3rd-party disk driver booting and build your private version of EmuTOS. :)

I've found anything above V7.93 of HD Driver causes issues if booting from the root sector, then running a different version (7.93) in the autofolder.
Not quoting the documentation, recall reading versions after 7.93 do not allow competing drivers, at least in the sense you mention.
My recommendation with using versions from V4.X to current on expansion CPU boards, is to stick with V7.93 unless using some new bastardization of storage it doesn't support, and then only to configure the device.
My 2 cents.

[exxos]

I've found anything above V7.93 of HD Driver causes issues if booting from the root sector, then running a different version (7.93) in the autofolder.
Not quoting the documentation, recall reading versions after 7.93 do not allow competing drivers, at least in the sense you mention.
My recommendation with using versions from V4.X to current on expansion CPU boards, is to stick with V7.93 unless using some new bastardization of storage it doesn't support, and then only to configure the device.
My 2 cents.

I remember I had a lot of trouble with HDdriver when Trudie was in development. Something changed around 8.47 ish and I even remember emailing Uwe about what changed.. But got nowhere as usual. Had to figure it all out myself in the end. But don't remember the issues offhand now.

Now you say that, I never had issues with my falcon IDE until recently. But had been using a much older version before. So may go back to my original version to see if things behave afterwards.

[Rustynutt]

I've found anything above V7.93 of HD Driver causes issues if booting from the root sector, then running a different version (7.93) in the autofolder.
Not quoting the documentation, recall reading versions after 7.93 do not allow competing drivers, at least in the sense you mention.
My recommendation with using versions from V4.X to current on expansion CPU boards, is to stick with V7.93 unless using some new bastardization of storage it doesn't support, and then only to configure the device.
My 2 cents.

remember emailing Uwe about what changed.. But got nowhere as usual. Had to figure it all out myself in the end. But don't remember the issues offhand now.

:) Same here. I got shot down requesting what I'd thought a simple request for a "special patch" he provides for the AB.
Oh well. Time to disassemble.

[Rustynutt]

Something else to possibly experiment with on the SCSI DMA issues.
Included with version 8 something of HD Driver, Uwe provides an "AB040" specific patch that limits FRB transfer size (my understanding). Don't see why in practice, it wouldn't work with any F030 expansion board using fast RAM, unless the difference between 030 and 040 CPU features are such that the throttling isn't sufficient enough (as I've found using it with my AB setup).

There's a brief readme included in the driver package.

[dml]

Something else to possibly experiment with on the SCSI DMA issues.
Included with version 8 something of HD Driver, Uwe provides an "AB040" specific patch that limits FRB transfer size (my understanding). Don't see why in practice, it wouldn't work with any F030 expansion board using fast RAM, unless the difference between 030 and 040 CPU features are such that the throttling isn't sufficient enough (as I've found using it with my AB setup).

There's a brief readme included in the driver package.

I don't know much about this HDD patch - but the AB40 hardware+driver does have an additional detail that needs to be accounted for regarding FRB.

The 040 maps memory in 8k pages, with caching/write-order control configured on a per-page basis (not globally via a register, as it is on 030).

So a DMA buffer such as that published via FRB should really be 8k aligned and the page(s) either marked non-cache or the cache manually flushed on each transfer (which the disk driver will normally be doing for 030).

However cache flushes on an 040 require specific instructions which don't exist on 000-030. The 030 version will be a no-op on 040. ...which begs the question - are the disk drivers doing anything special for 040/060, or do they assume anything above 030 is CT60 and that everything is set up as non-cacheable from the start, with no need for special flush instructions?

I'll have a look into the 040 configuration side and see what is being set up already. I think it publishes an aligned FRB. But it is more difficult to know what the HDD software is doing specifically on 040/060 and if the current combination of 'stuff' is enough for AB40 with SCSI.

(yes 040 stuff is a bit offtopic here but it is useful to isolate software from hardware DMA issues and there is a bit of overlap with DFB1 regarding the disk drivers and what they are responsible for vs TTRam and how)

[exxos]

I'll dig out my old SCSI drive see if it still works after 20 years. But its getting a bit problematic with the amount of hardware variations and problems going on currently.

Pretty sure my old drive as 8.x on it. Not sure I have any spare SCSI drives anymore to test HD11 etc out on.

Indeed we really need a open source driver then we could just fix things ourselves then. :roll:

I think we may just have to have a minimum criteria when fitting stuff like the DFB1. Like fitting a decent clock patch, recapping the PSU etc. If people are not all starting from a known hardware point, then its pointless to try and diagnose issues with the DFB1 as the stock machine may be malfunctioning to start with.

[frank.lukas]

I check SCSI drives with my Falcon and it do not work. The Computer freezes when I start a program from the SCSI partition or copy files on it.

Atari Falcon, DFB1 /40Mhz, TOS 4.04, Clockpatch, NVDI 5.03, Fastram.prg


... the computer freezes, for example, during a sector test with hddriver or when copying data or even when starting programs. The scsi drive was setup with a atari tt and all works well before.