DFB1 Support thread

[exxos]

Have you guys experimented with the load modules into TT RAm option ?

IMG_0321.JPG

[dml]

Have you guys experimented with the load modules into TT RAm option ?

Hopefully that option means 'prefer' TTRam, and not 'load it here forever always', in the case where TTRam is mapped later than the driver (which is true on AB40 and not sure about DFB1).

[dml]

@Rustynutt I'm a bit too tired tonight to dig into driver source but will take a look tomorrow at the FRB stuff to remind myself how it works, and think of any potential issues with FRB/DMA and loading order etc. on FRB1 and AB40...

[markus0321]

Have you guys experimented with the load modules into TT RAm option ?

This doesn't help me. I made a clockpatch according to your recommendations and it also did not fix the operation of SCSI with HDDRIVER and TOS4.04, there are still errors in the archive and when loading programs.

I wrote to Uwe Seimet a request to send me version 8.04 HDDRIVER maybe it will help.

[Badwolf]

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.

Thank you for testing this thoroughly. So if you're sure that SCSI works with TT-RAM and acceleration under EmuTOS then I think we can tentatively rule out a hardware problem and then focus just falls on the software. Primarly HDDriver or FASTRAM/MAPROM, but perhaps even TOS4.

Now I know Anders wrote an updated MAPROM/FASTRAM (they're the same program, but FASTRAM skips the remapping of ROM with MMU) but it doesn't seem to work properly with DFB1. I did take a look haven't had time to do so properly. It's possible there's a bug in the old 2.2 version regarding the FRB. Unfortunately Anders isn't around at the moment to ask.

It's also possible TOS4.04 simply ignores the FRB because it's not expected to be needed. I had, to be honest, read that it only affected transfers from/to ACSI ports.

It's also possible it's an HDDriver bug.

Depending on the format of your partition table, it may be possible to floppy-load Atari's old AHDI and repeat the read/write tests.

Anyway, if we can figure out the correctly working combination I can update the FAQs.

Thank you again for bringing this up as it's not something I would have found myself & thanks everyone else for their input so far. :cheers:

BW

[Rustynutt]

Thanks all for the patience with my off topic and long post.

[dml]

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.

@Rustynutt I had a quick look at the AB driver software last night and it is installing a 64k _FRB. Which ties with the docs:

Code: Select all

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.

[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.

@Rustynutt I had a quick look at the AB driver software last night and it is installing a 64k _FRB. Which ties with the docs:

Code: Select all

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.

Thanks for looking into this. It looks like Uwe is using a 64K buffer size with his patch.

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

Jumped over to the HD Driver site to see what Use has set his buffer size to, and noticed this.

Guess at this point, a discussion here on the below link could be moved. This sounds very AB specific. I'm not picky that way, but offering courtesy :)

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

[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.

Thank you for testing this thoroughly. So if you're sure that SCSI works with TT-RAM and acceleration under EmuTOS then I think we can tentatively rule out a hardware problem and then focus just falls on the software. Primarly HDDriver or FASTRAM/MAPROM, but perhaps even TOS4.

Now I know Anders wrote an updated MAPROM/FASTRAM (they're the same program, but FASTRAM skips the remapping of ROM with MMU) but it doesn't seem to work properly with DFB1. I did take a look haven't had time to do so properly. It's possible there's a bug in the old 2.2 version regarding the FRB. Unfortunately Anders isn't around at the moment to ask.

It's also possible TOS4.04 simply ignores the FRB because it's not expected to be needed. I had, to be honest, read that it only affected transfers from/to ACSI ports.

It's also possible it's an HDDriver bug.

Depending on the format of your partition table, it may be possible to floppy-load Atari's old AHDI and repeat the read/write tests.

Anyway, if we can figure out the correctly working combination I can update the FAQs.

Thank you again for bringing this up as it's not something I would have found myself & thanks everyone else for their input so far. :cheers:

BW

I hadn't thought of the AHDI driver. I'll try to find AHDI somewhere and install it on the other drive. If I succeed, I will let you know how it works with DFB1 and a SCSI disk. Thanks to you and others, I now understand better how this equipment works! :thanksyellow: :cheers:

[Badwolf]

Guess at this point, a discussion here on the below link could be moved. This sounds very AB specific. I'm not picky that way, but offering courtesy :)
https://www.hddriver.net/forum/viewtopic.php?t=286

Yeah, the 040 problem are really a completely different issue related to PMMU block sizes and cache settings AFAICT.

Cheers,

BW