DFB1 Support thread

[markus0321]

@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

I was able to check it quickly.
With the SCS0I drive, this TOS4DFB1 works, but after loading the hddriver, a bunch of bombs pop up when starting NVDI.
But with an IDE drive, this new TOS works fine and you don't need to use MAPROM for TT-RAM to work.

[Badwolf]

Hello. I have a son in the hospital now and I haven't had time for the last few days. :-(

I was able to check it quickly.
With the SCS0I drive, this TOS4DFB1 works, but after loading the hddriver, a bunch of bombs pop up when starting NVDI.

Hi Markus. No rush. Hope all goes well with your son.

Sounds like it's not helping. We need to get down and dirty with those tests Uwe suggested now then.

As and when!

BW

[Rustynutt]

Hello. I have a son in the hospital now and I haven't had time for the last few days. :-(

I was able to check it quickly.
With the SCS0I drive, this TOS4DFB1 works, but after loading the hddriver, a bunch of bombs pop up when starting NVDI.

Hi Markus. No rush. Hope all goes well with your son.

Sounds like it's not helping. We need to get down and dirty with those tests Uwe suggested now then.

As and when!

BW

Boy, started the thread over :)
I'll jump over the to the HD Driver forum, see if I can figure anything out there.

BW, thanks for supplying the modified 4.04 binary. That's a huge effort.

Going to recoup some of what I've read.

Think where users were having Desktop AES troubles booting MAPROM from floppy with fast ram installed is because NVDI isn't running as if from hard disk. TOS 4 needs NVDI (Not CT TOS) if fast ram is used on the Falcon (in my humble experience). It's not just disabling the Blitter, there's some AES enhancements going on. Even with NVDI, occasionally will get an error "unable to alloc blt buffer" when changing certain resolutions (accelerated).

Did manage to run MAPROM this way with a Newdesk.inf file for a VGA desktop, and a copy of sysinfo on floppy.
This way interaction with the AES/Desktop was minimal.

(On Afterburner)
Result: Maprom from floppy no HD Driver _FRB at $00028364 (chicken or egg question)
Result: HDDriver V7.93 Maprom 1st auto _FRB at $0006B7C0
Result: HDDriver V7.93 Maprom 1st auto AB040MMU.PRG _FRB at $000F6000
Result: HDDriver V7.93 AB040TK5.07 _FRB at $000F6000
Result: HDDriver V7.93 Old AB040 Drivers (MMU/RAM) _FRB at $00077DC0 (RAM installation tool installs FRB in this case)

Correct me if wrong, the difference in memory addresses for the _FRB is just from what was sized by the OS when the buffer memory was requested. (ok, messed up wording).
As long as the cookie jar is used, it makes no difference, as long as the address is in ST RAM (for FRB purpose).

From observation, MAPROM does not copy or remap ROM into fast ram. At least benchmarks surely don't indicate it.

MAPROM can locate memory on the AB040 (without additional drivers) and install it from the autofolder.
It seems to only be able to locate the first bank of memory though.

Recall DML saying the AB040 RAM is not congenious (think was the word), and he used some tricks to map both banks together in the tool kit.

MAPROM does not recognize the 68040 (sees it as an 020). This may be due to the electronics of the AB040 itself.
The AB040 tool AB040PMU can however be ran after MAPROM, and successfully builds the MMU, where caches can be enabled.

This is similar to how ExtenDos runs on the AB from file. Can't yet boot the AB with EmuTos in ROM.

Downside is, even though the CPU benches at ~470% (46MHz), the system is still slow as crap.
DML surely did a fantastic job with the original TK5.07 kit :)

[exxos]

I don't think maprom was ever intended for TOS404. It was built with the TF536 in mind.

[Rustynutt]

I don't think maprom was ever intended for TOS404 . it was built with the TF536 in mind.

But it loads alt ram :)

Just caught up on the HD Driver forum.
The last few post look promising, and make sense.

Uwe says no one reported ABFIX didn't work. Thats not entirely true.
I did earlier in the year. I'd requested a patched version for my own testing as I've always had SCSI issues with the AB.
He basically said he wasn't going to create a patch for one user when no one else had issues :) So I dropped it.

It looks like he's identified an issue with the SCSI Driver, and seems willing to address the buffer size there.

While waiting for his release, if any DFB1 users are setup with SCSI (frank_lucas) maybe you can test something I've been doing.
As I understand the DFB1, it runs an independent clock of the Falcon bus.
Could someone run is small program, and try a SCSI transfer?
Regular TOS, or BW's special TOS, either is fine. Any HD Driver.

[Badwolf]

Could someone run is small program, and try a SCSI transfer?
Regular TOS, or BW's special TOS, either is fine. Any HD Driver.

If that switches the bus clock to 8MHz, it won't work with the current DFB1 firmware -- the clock switching routine can't cope at that low a clock rate.

Instant hang if I try to toggle to 8MHz here. Nothing to do with SCSI, mind.

BW

[Rustynutt]

Could someone run is small program, and try a SCSI transfer?
Regular TOS, or BW's special TOS, either is fine. Any HD Driver.

If that switches the bus clock to 8MHz, it won't work with the current DFB1 firmware -- the clock switching routine can't cope at that low a clock rate.

Instant hang if I try to toggle to 8MHz here. Nothing to do with SCSI, mind.

BW

It toggels the the Falcon control register to set the COMBEL to 1/2 bus clock.
Was thinking if the DFB1 uses it's own clock, then only the Falcon bus clock changes.

Here, I get perfect SCSI DMA at around 12MHz. Don't know why. I'm using the Exxos patch. Was curious if the same was seen on the DFB1.

Granted, a fixed HD Driver is the best solution.

[Badwolf]

It toggels the the Falcon control register to set the COMBEL to 1/2 bus clock.
Was thinking if the DFB1 uses it's own clock, then only the Falcon bus clock changes.

DFB1 clock switches.

Here, I get perfect SCSI DMA at around 12MHz. Don't know why. I'm using the Exxos patch. Was curious if the same was seen on the DFB1.

No, this is a driver issue and Uwe is releasing a new version that will address this (albeit with an AUTO folder patch required).

BW

[Rustynutt]

It toggels the the Falcon control register to set the COMBEL to 1/2 bus clock.
Was thinking if the DFB1 uses it's own clock, then only the Falcon bus clock changes.

DFB1 clock switches.

Here, I get perfect SCSI DMA at around 12MHz. Don't know why. I'm using the Exxos patch. Was curious if the same was seen on the DFB1.

No, this is a driver issue and Uwe is releasing a new version that will address this (albeit with an AUTO folder patch required).

BW

Wow, topic locked. Hopefully his solution is the correct one.
Was going to reply to his response on my post, indeed I did report the autopatch not working in another thread earlier this year.
Was cut short on that request.
Since 1996, on the AB SCSI DMA has always been an issue.
Even earlier with the Mighty Sonic.

Think historically, what has happened was too much focus on the Falcon clock patch. If you dive into archives, in the end all discussions turn to testing various clock patches to resolve the SCSI DMA issue now being discussed.

On a stock Falcon, the clock patch (like exxos latest) should be installed and tested before hardware modifications are installed/made.
It's obvious from the technical discussions here and on HDDRIVER forum, this is a very complex issue. One that has likely gone unnoticed, or isolated until now.

It's not that Falcon owners with alt ram haven't had SCSI DMA issues, during my tenure, it's that most just don't use SCSI at all.
I use it for scanning, ethernet, DVD, CF readers, as well as SCSI III device hard disk, so have been aware and cautious in using the bus with fast, er, alt ram enabled.

You put up the good argument, hopefully it brings fruit.

IMHO, your modified TOS, or running HD Driver a second time from the autofolder should cover aspects of an installed FRB.
I'm thinking though, reading his responses, that isn't always the case.
So basically, if yet another autofolder patch is what is provided for the solution, well, wait and see.

[Badwolf]

Wow, topic locked. Hopefully his solution is the correct one.
Was going to reply to his response on my post, indeed I did report the autopatch not working in another thread earlier this year.
Was cut short on that request.

Mmm. Well, sorry it was locked. There is only so many times I'll put up with being publicly insulted as a paying customer and not have a little nibble back. There's a limit to how much I'm willing to put down as lost in translation.

So basically, if yet another autofolder patch is what is provided for the solution, well, wait and see.

Yes, he has special detection for CT2 and CT6x boards and is proposing to remove that and instead have an ABFIX style program for Falcons with accelerators. Seems like throwing the baby out with the bathwater to me. Why not just apply the CT2/CT6x logic whenever you have a Falcon with an FRB?

Oh well.

BW