DFB1 Support thread

[exxos]

@frank.lukas same happen without DFB1 fitted ?

[Rustynutt]

V4.x, and possibly to early V7, there is an option to "install FRB" with HD Driver.
This has disappeared at least since V7.93 and above now.

In a conversation with Uwe, he asked if I had an FRB installed knowing we were discussing V11.

So, have no clue if he's depending on TOS, or what, or if we just didn't follow each other.

With the AB, went back to a version which supported the FRB function and tested, with no benefit. It also made me question, in the case of the AB Tool Kit, if one didn't overwrite the other.

Uwe responds quickly on the HD Driver forum. Maybe dml could actually ask an intelligent enough question to garner an answer :)

[exxos]

You can check cookies with sysinfo IIRC. just run that to see if FRB is installed or not. But FRB is for TTram useage anyway.

[frank.lukas]

@frank.lukas same happen without DFB1 fitted ?

... booting without fastram.prg and all works fine !

Same setup with DFB1

[exxos]

... booting without fastram.prg and all works fine !

Same setup with DFB1

Maybe try MAPROM see if the same thing happens ? Sounds like FRB cookie issues, but not sure what fastram.prg does exactly.

[Rustynutt]

You can check cookies with sysinfo IIRC. just run that to see if FRB is installed or not. But FRB is for TTram useage anyway.

Yes, I've checked that.
Only using the AB here (apologies), the Tool Kit softs install an FRB, as did the earlier version of HD Driver tested.
Unfortunately there is no way to tell which program installed the cookie.

The way the AB works is similar to Dave's board, but it boots and loads TOS into RAM and does a soft reset to enable the PMMU and fast RAM (and other dml patches).

The Mighty Sonic 32, much like Dave's board, loaded RAM from an autofolder program,and if desired, loaded TOS into fast RAM at that time as well (his being much more vogue :) ).
It too though, suffered the same SCSI issues.

Been reading the oscilloscope thread :)

[markus0321]

I haven't been able to do all the tests since yesterday. But what I was able to check when I have EmuTOS running tells me that the problem with SCSI and FDD does not occur with EmuTOS.
I even eliminated this strange clockpatch (47ohm) and it still works fine for me with SCSI under EmuTOS. I also tried to program TOS4.04 to the flach memory on the DFB1 board because I thought maybe I had a faulty eprom on the board but it didn't change anything and using TOS4.04 the problems with SCSI come back.
I also noticed that just copying the LHArc archive does not damage the file inside. After copying it several times between partitions on a SCSI disk and later when trying to unpack the last file, but with inactive TT-RAM, the program does not report errors. This is strange because before I thought that the copy operation itself corrupted the archive file. I also tested the archive (option "t") and the errors always appear at the same times and in the same files.

[markus0321]

... booting without fastram.prg and all works fine !

Same setup with DFB1

Maybe try MAPROM see if the same thing happens ? Sounds like FRB cookie issues, but not sure what fastram.prg does exactly.

It's the same for me, and I used MAPROM22.PRG recommended to me by Badwolf

[exxos]

--->> SIDE QUEST

So this is what is running on my Falcon from decades ago....

IMG_0315.JPG

Cannot test more as I don't have a DFB1 Currently as @Badwolf Stole it! :lol: :roll:

[Rustynutt]

I haven't been able to do all the tests since yesterday. But what I was able to check when I have EmuTOS running tells me that the problem with SCSI and FDD does not occur with EmuTOS.
I even eliminated this strange clockpatch (47ohm) and it still works fine for me with SCSI under EmuTOS. I also tried to program TOS4.04 to the flach memory on the DFB1 board because I thought maybe I had a faulty eprom on the board but it didn't change anything and using TOS4.04 the problems with SCSI come back.
I also noticed that just copying the LHArc archive does not damage the file inside. After copying it several times between partitions on a SCSI disk and later when trying to unpack the last file, but with inactive TT-RAM, the program does not report errors. This is strange because before I thought that the copy operation itself corrupted the archive file. I also tested the archive (option "t") and the errors always appear at the same times and in the same files.

Very interesting find :)
To really test the SCSI DMA, using Kobold Correct on large partition is where you'll see file corruption show up.

Unfortunately, on the AB, can't test EmuTos. Think last I'd read from another user, it detects fast RAM, but does not set up the PMMU.