DFB1 Support thread

[stephen_usher]

One of the missing pieces of the jigsaw here, which I've been briefed on off-thread is that the TT, which is obviously the archetypeal TT-RAM wielding SCSI machine, can DMA into TT-RAM, so _FRB is not required here.

From what I can remember from the Atari developer documentation for the TT (which I still have in the corner somewhere but I can't tell you about because of the NDA I signed ;-) ) the machine can still only DMA to/from ST-RAM.

[Badwolf]

One of the missing pieces of the jigsaw here, which I've been briefed on off-thread is that the TT, which is obviously the archetypeal TT-RAM wielding SCSI machine, can DMA into TT-RAM, so _FRB is not required here.

From what I can remember from the Atari developer documentation for the TT (which I still have in the corner somewhere but I can't tell you about because of the NDA I signed ;-) ) the machine can still only DMA to/from ST-RAM.

Well, the TT's DMA controller chip does appear to have 32 address lines into it.

And it looks like EmuTOS allows 32-bit DMA on the TT, but uses _FRB for Falcon:

https://github.com/emutos/emutos/blob/5 ... #L387-L403

BW

ttdma.png

[Badwolf]

OK, I've decided to ask the question of Uwe as an interested third party.

https://www.hddriver.net/forum/viewtopic.php?t=287

BW

[stephen_usher]

The TT's ST-RAM is 32 bit wide.

[Badwolf]

The TT's ST-RAM is 32 bit wide.

It's the address bus that's 32 bits in the schematic.

BW

[Badwolf]

So some feedback from Uwe,

HDDriver checks for _FRB on on the Falcon on the first SCSI access beyond STRAM.

That should, in theory, work fine with our set up as there ought to be no SCSI read into TT-RAM before MAPROM/FASTRAM has even declared it! Since it's the same program that sets up _FRB, we should be fine.

Additionally this test:-

viewtopic.php?p=94439#p94439

Does seem to suggset it's not an ordering problem.

So with Uwe confirming _FRB is honoured for SCSI under a Falcon with TT-RAM (which he insists is AltRAM -- YMMV), we're at least more enlightend, but no closer to the actual solution.

He does suggest some tests. If anyone experiencing this problem would like to look into it, I'll point you to the second half of the post here:- https://www.hddriver.net/forum/viewtopic.php?p=951#p951

Furthermore we can set up Hatari to simulate this configuration, although my hatari debugger-fu is not the best. Basically, does it use FRB properly or not is the question?

BW

[stephen_usher]

For further information:

ST + TF536 + PAK/3 TOS 3.06 + HDDriver: _FRB = $0000e6fc

HD10.10 hangs the system if it tries to boot off the UltraSATAN though but works if run from floppy with the US turned off during boot.

P.S. If I set the PRGFLAGS on A:\AUTO\HDDRIVER.PRG to either be that the program or memory as TT-RAM then finding the US partitions is unreliable, often only seeing C, CD but never CDE. Loading into ST-RAM only gives consistant results of seeing all drives.

Of course, this isn't the SCSI issue that the DFB1 is seeing but it does show some of the general issues which may be at play.

[Badwolf]

Of course, this isn't the SCSI issue that the DFB1 is seeing but it does show some of the general issues which may be at play.

Interesting, though.

Uwe has given us an idea of how HDDriver handles an FRB in a Falcon environment. I think we're fairly compliant with that, although the only way to be sure would be to run through the SCSI debug tests he also documents for us.

So I'm afraid this is over to the guys experiencing the problem. If you want to get to the bottom of it, please have a read of Uwe's post on his forum about how to go about debugging what SCSI transfers are occurring.

I will try to look into the Hatari emulation of a Falcon with TT-RAM + HDDriver when I get a chance.

BW

[Badwolf]

@markus0321, do you want to have a try with this?

This is a nasty hack, but might be a good data point.

This is a version of TOS404 that:-

1. Detects TT-RAM
2. Maddalt()s the TT-RAM
3. Reserves an FRB
4. Sets the _FRB cookie

You do not need MAPROM or FASTRAM with this version of TOS.

So the question is: does HDDriver bootstrap itself from C: now?

BW

EDIT: see next post.

[Badwolf]

@markus0321

Quite a stark bug in that last patched TOS version -- messed up the cookie jar.

Here's a (hopefully) better one (it's still a nasty hack, mind).

BW