exxos's DFB1 trials

[Rustynutt]

Assuming by the time HD Driver is ran from the boot sector, the DFBX hardware is all initialized, other than fast ram being loaded into the memory pool.

Uwe with the latest HD Driver versions supports a "trick" (to me) where creating HD Driver "modules", programs can be executed before HD Driver is ran.

A module created for fastram.prg would then run before HD Driver, allowing it then to load into fast ram.

[Rustynutt]

Have you tried running a copy of HD Driver from the autofolder after alt ram had been installed?

You'd have to boot from floppy to do that.

Why?

[stephen_usher]

Because the driver would have already loaded via the boot sector if booted from the hard drive.

[exxos]

The driver running from bootsecor should AFAIK boot into STram as maprom is needed to setup TTram. I've not looked at options but don't know how the driver can even be loaded into TTram as it hasn't been declared to the system yet. Boot sector loading should load into STram. With the blitter off, there should be no problems.

OTOH, if maprom is loaded first and then HD11 booted from floppy with it may well load into TTram. But don't think there's much point. I'm not aware of any other loading methods. Thought not sure there is any point in involving the driver in TTram.

It should only allocate ram to where it's loaded from and correctly declare FRB into STram. If it's copying itself to TTram then it shouldn't be doing that. The whole point of FRB is to allocate 64k STRAM for DMA access so programs in 32bit RAM can access DMA properly. If FRB is ending up in TTram then something is wrong with the driver or how it's being used.

The CPU copies DMA data from TTram and places into the FRB in STram where it's then on the 16bit bus where DMA works as it should. FRB is like a swap file between TT and ST RAM. The blitter simply can't do that function.

I think people need to remember the falcon is only a 16bit machine and using 32bit RAM won't place nice with hardware which is only 16bit capable.

[Rustynutt]

Think outside the box :)

I've done it this way on Falcons with fast ram since 1994.

Using HD Driver V7.93 (not going into later versions here), simply configure it to only log only the bootdrive, minimum cache setting (optional).

Place a copy of HDDRIVER.PRG (configured to needs) in the autofolder, typically after NVDI, but surely after however fast ram is installed.

When HD Driver runs, it will load itself into fast ram (if the fast ram bit is set). You can configure it to run from, use memory from, however.

It works, just try it.

The alternative "might" be to compile an HD Driver module to execute loading fast ram, in the case of the DFBX. It's ran before the boot sector is, and in theory, would then not be required to be ran again in the autofolder.

[Rustynutt]

As far as the FRB, on the Afterburner, the tool kit sets it up. I can look in the cookie jar, and see both the tool kit FRB and HD Driver installed FRB. Really a redundancy.

On earlier versions of HD Driver, it is an option that can be selected.

The AB040FIX(?) Uwe sizes the FRB to something "he" feels is necessary for the AB to work.

AIRC, in his notes on the HD Driver page, he's integrated this into the latest release, and had asked for users to test it.

[Steve]

Place a copy of HDDRIVER.PRG (configured to needs) in the autofolder, typically after NVDI, but surely after however fast ram is installed.

When HD Driver runs, it will load itself into fast ram (if the fast ram bit is set). You can configure it to run from, use memory from, however.

With all due respect Rusty, I think you're missing the fact that if your Atari is already loading files out of AUTO on the C: drive, this means that the hard disk driver (hd driver, from the .sys file on c:) is already loaded into memory, st-ram memory. How else would it access your hard disk without a driver already loaded? Hddriver.prg is basically doing nothing in that scenario. It's the classic chicken and egg problem :) I hope this makes sense.

Edit: (just to add) hddriver.prg is only useful for loading a hard disk driver from floppy.

[Rustynutt]

Place a copy of HDDRIVER.PRG (configured to needs) in the autofolder, typically after NVDI, but surely after however fast ram is installed.

When HD Driver runs, it will load itself into fast ram (if the fast ram bit is set). You can configure it to run from, use memory from, however.

With all due respect Rusty, I think you're missing the fact that if your Atari is already loading files out of AUTO on the C: drive, this means that the hard disk driver (hd driver, from the .sys file on c:) is already loaded into memory, st-ram memory. How else would it access your hard disk without a driver already loaded? Hddriver.prg is basically doing nothing in that scenario. It's the classic chicken and egg problem :) I hope this makes sense.

Edit: (just to add) hddriver.prg is only useful for loading a hard disk driver from floppy.

Yes, HD Driver, before fast ram is enabled is running from ST RAM at that point.
But other than the system coming up, nothing has been executed.
By running it a second time from the auto folder, after fast ram is enabled, it is then located there.

Just do a simple test.
Configure some absurdly large hard disk cache amount and boot "normally", and note the remaining ST RAM.

Reconfigure the sys driver to no cache size.

Place a copy of HD Driver configured with the same "absurdly" large cache setting right after the program that enables fast ram runs. That should be the first program in the auto folder, with HDDriver.prg (program flags set to use fast ram/run from fast ram) immediately after.
At that point, no other auto folder programs have been executed (other than to enable fast ram).

You will then note the difference in ST RAM usage, as the cache is now located in fast ram. Depending in how the program flags are configured, it will either be running from fast ram, or ST RAM.

It's no different than any other program running in the autofolder after fast ram has been installed, be it in the auto folder, or when acc's are loaded before the desktop.

[exxos]

By running it a second time from the auto folder, after fast ram is enabled, it is then located there.

Have you contacted Uwe to make sure that's even supposed to be done ? Loading the driver twice doesn't seem a good idea unless proven safe by its creator.

[Rustynutt]

By running it a second time from the auto folder, after fast ram is enabled, it is then located there.

Have you contacted Uwe to make sure that's even supposed to be done ? Loading the driver twice doesn't seem a good idea unless proven safe by its creator.

Well, it's been "safe" here since the Mighty Sonic was released around 1993 :)

What Uwe is going to tell you is the way to do this it to complie an HD Driver module that loads fast ram. Those are executed before HD Driver starts running the autofolder. This is with whatever version modules were supported by.
In my examples, I'm discussing this assuming the use of HD Driver V7.93.
It's a "smart enough" driver for my taste :)

Assuming you have the source for the code that loads fast ram into the DFBX.
Then, someone (I've asked, with no replies on AF) that knows how to compile a module to do so. They simply set in the root directory.
This is the elegant way of doing what I'm discussing. Being I can barely manage to compile a "hello world" program, I'm not the candidate.

Modules have many applications. For instance, the Sparrow TOS does not have a recognized MCH bit. HD Driver "thinks" it's a TT. So configuration SCSI devices doesnt work until setting the MCH bit as "Falcon".
This can be done with a module before HD Driver runs.

To follow up with what Steve is possibly thinking, launching HD Driver as a program from the autofolder does not reboot the system, it executes and relogs devices, then the next autofolder program is executed as it normally is.

With the new kid arriving (the Rigol), and electrician showing up to install a 220V outlet for some of my Euro hardware, and about a year of trashing the computer room, I don't have a machine on the bench to do screen dumps with.
And I'd only do them if not by doing so is deemed sorcery :lol: