DFB1 Support thread

[Rustynutt]

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.

Please skip if not "open minded to complete lunacy" :lol:

It's been years since messing with the TT.
From memory, and stand to be corrected, the buffer is built into the TT somehow. So if memory serves...

The cookie only declares fast RAM present in that case for fast RAM aware, or those programs with their flags set to utilize the space.

In other words, the buffer is not soft installed.

IE, with HD Driver prog flags set to use fast RAM, both run from and store data, at boot it will happily run on a TT. So will AHDI and ICD, the latter which does not set up an FRB, but can be loaded into fast RAM by setting it's prg flags.

So in the case of the TT, it's convention.

That same configuration, be it HDD 4x to 11x will fail (to varying degrees, see below) on Falcon with fast RAM when performing SCSI/floppy DMA from fast RAM via an installed FRB. ICD and AHDI also fail in this case. There is not much sense in really going back here. Trust me.

It's fuzzy, and comes back from first working with the Mighty Sonic 32, with fast RAM at the same address as the TT, yet it having the same SCSI issues seen here, where the TT has no such issues.

There, one can discard the 040 side of the topic as the Mighty Sonic used an expansion board located 030. It's fast RAM was mapped to the same address as the TT, in a similar fashion as the DBFX boards do, and loaded into the system in a similar fashion.

At the time of that investigation (1994?), had the help of a pretty knowledgeable assembly programmer (out of Texas) trying different ways around this.

"booting HD Driver "from floppy" after fast RAM is declared"

On Falcon/AB/Mighty Sonic

At power up, TOS (4x in this case) scans for a couple different things.
It does sense if a SCSI controller exist, but does not attempt to log drives.
With the bus at 32MHz (yeah, I know), this does not cause a problem. It will, if a floppy disk is in the drive (with the bus at 32MHz). No floppy, no problem, though a (grinding mechanism sound can be heard, will leave that to speculation). There can also be noticed a "glitch" onscreen (again accelerated bus) during this scan.
Just trying to visually exacerbate the problem here.

So, common practice, even with a 16MHz bus, and the above boards is to set HD Driver (ICD, AHDI 5.x configured) to detect IDE only on initial boot, ie, not to scan the SCSI bus when logging drives.

Here's where newer versions of HD Driver proved problematic during these test, as opposed to V7.93 as it does not allow (my simple understanding, reading CUBASE AUDIO limitations) competing drivers and would just report HD Driver already installed even with (SCSI ID's) added to the setup. Think it's (new to me) use of modules can work around this though.

In the case of the Mighty Sonic, in the autofolder are MHZ32 (double clocks 030 by switching the PLL to draw direct from the COMBEL oscillator), and FAFA32 loads fast RAM into the memory pool, with FRB and cookie.

Then HD Driver can be "safely ran" afterwards to log the SCSI bus and drives (within reason, faster you overclock, the more issues become apparent here).
In practice, it's more reasonable to just relaunch HDD 7.93 from the desktop, as if hanging during autofolder sequence, it's a pain to isolate.

So, we're setting at the desktop, fast RAM loaded from autofolder, or not, it can also be installed after getting to that point to ensure any programs which might violate using the FRB space protocol are safely in ST RAM, and (re) launch HD Driver after loading fast RAM from the desktop. Heck, even set it's flags to not utilize fast RAM. It's not going to matter (much).

I'll leave the AB out of the discussion as it seems to throw the problem here. DML went to great lengths here in TK4x to solve or work around all this. I'll just add, AB stuff, think what Uwe is doing with the PMMU module really is no different than what the original driver's from the GE Soft supporters did. TK5v is still the superior method.

Testing the setup.
The floppy drive suffers the same situation as the SCSI, just not as apparent. And will tell you from experience, just copying a single file, or launching a single application will not be a good indicator. One needs to use Kobold tree check between 2 identical partitions or groups of files, or Correct on a partition. Some smaller block sizes seem to slip through, but definitely the larger a file is, the more apt errors will show up. And once 2 or 3 errors show up, it just starts to cascade.

So why write all this?
Opinion only.
And here it is.

Think the FRB and cookies are property coded, loaded and software sees and utilizes the FRB as they should.

Think there is something in TOS 4 causing the problem.
Reading BadWolfs GitHub docs, specifically about how devices are chained as bus masters, and what actually occurs when they release the bus is possibly something to look into. If at anytime the Blitter decides to "speak up", it's going to cause issue. Even with NVDI loaded, TOS still must do some access NVDI fails to address. I've seen this testing bus acceleration (same as speeding up software IMHO) with screen errors.

The other is, seeing how test with EmuTos seem to "fix" this problem tells me something. AIRC, during CT60 development, Dieter and Patrice ripped a lot of Blitter code out for CT TOS.

Also recall reading EmuTos uses a ""some" of that modified code.

Unfortunately, can not test EmuTos on the AB. Have however used it as a baseline testing COMBEL 64MHz/32MHz bus, and it works without error, everytime where TOS was "flakey".

For the user where EmuTos seems to have "fixed" the SCSI issues, maybe run a disk speed test between TOS (without DFBx fast RAM active), and under EmuTos. Ideally, rates should be the same. If not, then it's possible some overhead in EmuTos, or TOS is hidden there. Just as an indicator to look at differences. Here is where Thorsten would come in handy, though no one seems to really want to debug TOS 4.04 :lol

Something I'd like to propose, if anything out of the above is not useful, is to decrease the size of the FRB. Don't know about data/word sizes and how it correlates with data transfer, but for one would love to test an FRB with a reduced size to both 32 and 16k. Think slowing this down will reflect the same thing I see slowing the bus under SCSI DMA.

For my setup, under clocking the bus solves the SCSI issues. At ~13MHz, all problems go away. Hour long test with Tree Check/ Correct show no SCSI issues.
So for now that's my fix until EmuTos properly can recognize the AB running from ROM, set up the PMMU and allocate fast RAM. Can always set CPU and Data caches with TTP's, but doubt it will perform as fast as TKV5 does with dmls awesome copy back features :D

Merry Christmas, Happy New Year :D

[Badwolf]

I only found version 6.061 and it doesn't see the partition. I will have to prepare everything again on the second SCSI disk and transfer the files for testing.

It's probably not worth repartitioning just to test an ancient bit of software, it was just on the off-chance the partition tables were compatible already.

I think it's time to raise the issue with Uwe.

BW

[markus0321]

I only found version 6.061 and it doesn't see the partition. I will have to prepare everything again on the second SCSI disk and transfer the files for testing.

It's probably not worth repartitioning just to test an ancient bit of software, it was just on the off-chance the partition tables were compatible already.

I think it's time to raise the issue with Uwe.

BW

I did some more testing using the AHDI driver.
It works stably, the system does not hang when I have ALT-RAM memory active in TOS4.04. Too bad AHDI doesn't use more than 1GB of disk space.
EDIT:
I'll try to check if ICD PRO will work properly, I'm not sure but I think it supports drives up to 16GB and certainly up to 10GB, so it should be suitable for old SCSI drives.

[frank.lukas]

Who writes a post in the HDDriver forum?

[Badwolf]

I did some more testing using the AHDI driver.
It works stably, the system does not hang when I have ALT-RAM memory active in TOS4.04. Too bad AHDI doesn't use more than 1GB of disk space.

Oh wow. It really does look like HDDriver then, or a setting within it at least.

Thanks for doing that!

BW

[markus0321]

I wrote an e-mail to Uwe and got information from him that there are modules available in the new HDDRIVER that it can run earlier than the driver itself (HDDRIVER.SYS).
https://www.hddriver.net/en/modules.html
Maybe someone who knows programming better than me and knows English better than me, would contact Uwe about this?
EDIT:
Maybe it would be possible to run MAPROM as a module before the HDDRIVER.SYS driver starts?

[exxos]

HDDRIVER modules are a new concept introduced with HDDRIVER 11. Modules resemble programs for the AUTO folder but when booting are launched before HDDRIVER.SYS.

But how can it launch programs off hard drive if the driver isn't loaded yet. ?!

:dizzy:

[dml]

But how can it launch programs off hard drive if the driver isn't loaded yet. ?!

The bootloader can access the disk - it already loads HDDRIVER.SYS for previous versions, which implements the disk driver.

So the new version installs a module loader in place of HDDRIVER.SYS, which in turn loads and executes the modules, with 'actual' HDDriver being the last module in the chain. It is doing the same thing it already does, just in smaller steps with more 'bits'.

[EDIT]

It may not even need a module loader, if each module itself is a loader, of the next module in the chain. But that's just an implementation detail.

[Badwolf]

…or HDDriver could properly honour the _FRB cookie?

BW

[dml]

Maybe it would be possible to run MAPROM as a module before the HDDRIVER.SYS driver starts?

The 68040 toolkit driver I made for Afterburner solves these problems by running it early in the AUTO folder, where it installs itself and modifies the hardware config, sets up the PMMU, copies ROM to FastRAM, patches the TOS ROM in the process, adds disk intercept patches and so on.....

It them warm-resets and allows the machine to boot again, with all of that still resident. This gives all AUTO software and HDDriver equal chance to see the modified config. I think it does not retain the _FRB but the disk driver can still see that AltRAM is valid at that point - so it can install its own _FRB or just act accordingly with its own STRam buffer anyway.

[EDIT]

I guess it would also be possible to have the patched FastRAM-ROM image make callbacks into the TSR driver to install a _FRB at the 'rom boot' warm reset phase but it probably would need done at a very specific time to be valid (TOS will init the cookie vars and so on later in boot) so not certain that will work. But in any case, AltRAM is already published at that point so any drivers can respond to that information with or without a _FRB.