DFB1 Support thread

[Badwolf]

TOS 4.0x ignores the _FRB cookie. It is a non-system cookie, only observed by disk driver software interested to look for one and use it.

Makes sense.

What I don't understand is the quote about ACSI ports, though.

The TT has TT-RAM and SCSI. Why doesn't it need an FRB? What am I missing?

Do we need to somehow tell HDDriver it should behave like it's on a TT? Obviously with our setup when HDDriver loads it's not yet aware of TT-RAM, so perhaps it doesn't get the memo?

In that case, does the TF536 in an ST work with ASCI & HDDriver?

:stars:

I think I need to spend more time in Anders' source code to get the latest version of MAPROM/FASTRAM working properly with DFB1, as we may be chasing an otherwise fixed problem since v2.2.

BW

3.7.2.579 Cookie, _FRB

Fast-RAM buffer

The cookie points to a 64 kbyte size buffer in ST-RAM that can be used by an Atari TT for ACSI-DMA transfers (the Fast-RAM of the TT can not be used for this).

Device drivers for the ACSI port may use this buffer as temporary storage for transfers into the Fast-RAM; access is coordinated via the system variable flock.

If this cookie is not present, then the computer either has no Fast-RAM, or no ACSI port.

[Badwolf]

... booting without fastram.prg and all works fine !
Same setup with DFB1

Thanks Frank. Good to have a independent corroboration.

BW

[dml]

What I don't understand is the quote about ACSI ports, though.
The TT has TT-RAM and SCSI. Why doesn't it need an FRB? What am I missing?

I'm not sure what TT does about _FRB, if anything. I expect it is not installed by TOS (as is the case with Falcon) and any disk driver software at the time would just need to be TT-aware, and TTRam aware, allocating any buffers appropriately from STRam.

_FRB surfaced as a workaround for systems that are NOT expected to have TTRam by default, but can be added via expansions. So deliberately publishing a STRam buffer for disk access makes sense in these cases (assuming the disk drivers don't just do their own thing anyway, and bother to look for _FRB and make use of it).

[EDIT] actually, re-reading the docs it does seem as if TT publishes this cookie after all. so in the Falcon case, it can use the same cookie but needs to publish it artificially.

[frank.lukas]

Tested a bit more ...

Update my HDDriver to 10.13 and it work with SCSI a bit better but still freezes but not immediately as before!

I suspect a malfunction of TOS 4.04 and the Fastram/DMA buffer ...

[markus0321]

I now have version 11.13 HDDRIVER and I still have the same problems with using the SCSI disk (before that I also tested version 10.12 and 10.3).
I wrote a request to Uwe and he sent me the old version 8.04 which he wrote about in an earlier Exxos post but I won't be able to test it until late in the evening.

[exxos]

I now have version 11.13 HDDRIVER and I still have the same problems with using the SCSI disk (before that I also tested version 10.12 and 10.3).
I wrote a request to Uwe and he sent me the old version 8.04 which he wrote about in an earlier Exxos post but I won't be able to test it until late in the evening.

I think you probably missed this post where 8.04 kept crashing for me , so gave up with it..

[dml]

The version installed on my 040 machine (with FastRAM and installed _FRB - being the important detail) is HDDriver 8.44

While it is running off CFlash now, it used to have a SCSI attached as external storage. I'm assuming that means it used to work in that configuration but YMMV :-p

[Badwolf]

The version installed on my 040 machine (with FastRAM and installed _FRB - being the important detail) is HDDriver 8.44

Has anyone confirmed if MAPROM/FASTRAM2.2 sets _FRB? I would be very surprised if it didn't.

My suspicion is it's not being honoured rather than not being set.

BW

[dml]

My suspicion is it's not being honoured rather than not being set.

That's possible - it's difficult to tell, although HDDriver *should* be using it when present.

From what I gather, HDDriver may even install its own (this could be confirmed by booting clean with it and inspecting the cookie list with the CPX). Assuming it does that, subsequently ignoring its own _FRB would be a bug.

[dml]

The plot thickens - there is also this:

Code: Select all

3.7.2.183 Cookie, hFRB

BIOS driver for Rwabs transfers into/out of Fast-RAM

Intercepts Rwabs, and redirects all accesses to Fast-RAM through the FRB. Required for PAK with Fast-RAM.

Status: PD.

\o/

Presumably that's for pre-TT / 68000 machines which have Pak/030 boards fitted and other software isn't respecting _FRB, so a patch is installed to control disk access, announcing itself with hFRB. Not the same as the _FRB buffer cookie. Still, it's yet another fastram disk indirection thing.


And my own TK040 driver checks for 'XFRB', which is a sized version of _FRB. I don't remember what software defines that one.