Re: DFB1 Support thread
Posted: 23 Nov 2022 21:19
Have you guys experimented with the load modules into TT RAm option ?
We welcome retro users & hardware gurus alike! Come and join the party :)
https://www.exxosforum.co.uk/forum/
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).exxos wrote: 23 Nov 2022 21:19 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.exxos wrote: 23 Nov 2022 21:19 Have you guys experimented with the load modules into TT RAm option ?
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.markus0321 wrote: 23 Nov 2022 19:42 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.
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.dml wrote: 24 Nov 2022 08:10 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.
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 wrote: 23 Nov 2022 22:42Thank 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.markus0321 wrote: 23 Nov 2022 19:42 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.
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
Yeah, the 040 problem are really a completely different issue related to PMMU block sizes and cache settings AFAICT.Rustynutt wrote: 24 Nov 2022 08:57 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