DFB1 Support thread

[dml]

I have a suggestion on how to get around this stuff - and not a new method, except where _FRB is concerned.

a new MAPROM tool with some additional features.

- HDDriver spins up, no TTRam resident, no _FRB resident
- new MAPROM tool runs from AUTO folder (first to run)
- copies ROM to RAM, applies any patches needed, marks it as 'valid' for warm resets
- allocates TTRam at the same time, marks it as 'valid' for warm resets
- installs itself on warm-reset vector
- warm-resets itself

Reset vector wakes up, installs _FRB (or more likely done with a ROM patch). Machine resumes booting, second pass.

- HDDriver spins up, this time both TTRam and _FRB are resident simultaneously
- new MAPROM tool runs from AUTO folder
- recognises itself as resident (reset vector or other means), immediately exits
- other AUTO programs run
- desktop!

I already do 90% of this on Afterburner for the boot process so it doesn't seem like a stretch to do it on 030.

The hard part I think is finding the right time/place to install the _FRB via a ROM hook. It's maybe not that hard, but it is an unknown. I expect the point where the user TPA is set up, just after it, by adjusting the TPA. However there are probably other ways - have not been near this stuff in a few years.

Also in the 040 version I don't repoint the ROM image in RAM, I copy it to RAM and use the PMMU to logically map it back to the ROM address range and write-protect it so it looks like genuine ROM, no address changes. But really it's physical FastRAM. I don't think this is necessary (since MAPROM doesn't do this I think?) unless it is required to survive a warm reset. Perhaps not required at all.

[Badwolf]

I have a suggestion on how to get around this stuff - and not a new method, except where _FRB is concerned.

a new MAPROM tool with some additional features.

... snip hard programming ...

I prefer my solution: get Uwe to honour an _FRB if it's set up after HDDriver runs! :lol:

MAPROM's absolutely ripe for expansion. Anders has done a great job in unpacking it into a readable C project with good comments and allsorts. We have one significant problem at the moment, though: it doesn't work properly in its current incarnation which is why we're using v2.2.

https://github.com/agranlund/tftools

I need to find time to look into that too. :cry:

Also in the 040 version I don't repoint the ROM image in RAM, I copy it to RAM and use the PMMU to logically map it back to the ROM address range and write-protect it so it looks like genuine ROM, no address changes. But really it's physical FastRAM. I don't think this is necessary (since MAPROM doesn't do this I think?) unless it is required to survive a warm reset. Perhaps not required at all.

MAPROM is a proper PMMU-based remapper rather than a copy-n-correct approach. That mapping not surviving a warm boot is currently one of the problems with DFB1, though.

MAPROM was originally intended for TF536, so targets 2.06. Possibly TOS4 reinitialises the PMMU tree but TOS2.06 doesn't? Not sure, guessing there.

BW

[dml]

I prefer my solution: get Uwe to honour an _FRB if it's set up after HDDriver runs! :lol:

I am not certain he will agree, because he would have to constantly scan for the cookie on each disk access until it materializes (since that is when he gets his chance to intercept and make changes). I mean it is possible, but I have a feeling I know what he will say to it.

There is also the ambiguity of when FastRAM appears on different systems. So long as FastRAM appears simultaneously with _FRB then it should be safe. If FastRAM appears before _FRB and there is disk access (from SCSI) in between (e.g. FastRAM surviving warm reset, but _FRB not), all bets are off.

MAPROM is a proper PMMU-based remapper rather than a copy-n-correct approach. That mapping not surviving a warm boot is currently one of the problems with DFB1, though.
MAPROM was originally intended for TF536, so targets 2.06. Possibly TOS4 reinitialises the PMMU tree but TOS2.06 doesn't? Not sure, guessing there.

I do have to recover the PMMU config on a warm reset, which sounds like all that is missing here. At least for this bit.

The installation of _FRB on reset is more tricky, since it is not something I have tried to do. I might look into that for 040 since I can see similar issues if booting from SCSI. Although by now, I expect nobody even tries :-P

[exxos]

I prefer my solution: get Uwe to honour an _FRB if it's set up after HDDriver runs! :lol:

I am not certain he will agree, because he would have to constantly scan for the cookie on each disk access until it materializes (since that is when he gets his chance to intercept and make changes). I mean it is possible, but I have a feeling I know what he will say to it.

I'm a little bit behind on the discussions here but if HDdriver is installing FRB.. Surely it only needs to check when it loads if FRB has already been allocated or not ? HDdriver shouldn't just forces will upon the world willy-nilly ?

On this basis either FASTRAM.PRG or MAPROM would setup the RAM and FRB itself.. and then HDdriver shouldn't do anything then ?

[Rustynutt]

Exxos, think they've been down the list of drivers, and are just focusing on HD Driver.

Wonder if making a (test) boot floppy and changing the MCH ID to TT before HD Driver boots wouldn't work.

I basically use this same idea on the Sparrow. HD Driver sees it as a TT. Problem is, that's a different SCSI controller. Setting MCH ID to Falcon, HD Driver works properly.

At least SYSINFO could be checked to see if the FRB has been installed after DFB has booted.

[Badwolf]

I prefer my solution: get Uwe to honour an _FRB if it's set up after HDDriver runs! :lol:

I am not certain he will agree, because he would have to constantly scan for the cookie on each disk access until it materializes (since that is when he gets his chance to intercept and make changes). I mean it is possible, but I have a feeling I know what he will say to it.

Since we're not seeing a barage of TF536 users complaining their ultrasatan cards don't work, my working assumption is that HDDriver does honour a post-installation _FRB cookie. But perhaps only for ACSI.

I'm a little bit behind on the discussions here but if HDdriver is installing FRB.

We've tested that -- it doesn't.

• Declaring TT-RAM before HDDriver runs yields no _FRB cookie, so HDDriver does not set one up itself;
• Declaring TT-RAM after HDDriver runs with MAPROM/FASTRAM, we get _FRB, but it doesn't seem to be used;
• AHDI works as expected with MAPROM/FASTRAM.

This is directly analogous to TF536+MAPROM/FASTRAM but with SCSI instead of ACSI. Can anyone categorically verify that ACSI transfers work on a TF536+HDDriver+MAPROM/FASTRAM ST configuration?

BW

[stephen_usher]

Since we're not seeing a barage of TF536 users complaining their ultrasatan cards don't work, my working assumption is that HDDriver does honour a post-installation _FRB cookie. But perhaps only for ACSI.

I don't know if HDDriver on the TF536 actually notices the TT-RAM at all, let alone loading into it. I've not tested this.

However, I think this is all probably a red herring. You can tell HDDriver in the options not to load into TT-RAM (loading into TT-RAM is not the default in the configuration in version 10, you have to set the option in a menu). If there's a problem it's probably elsewhere, maybe an interrupt timing issue etc. Does access to the the NCR5380 SCSI chip actually go through DMA at all?

[Badwolf]

However, I think this is all probably a red herring. You can tell HDDriver in the options not to load into TT-RAM (loading into TT-RAM is not the default in the configuration in version 10, you have to set the option in a menu). If there's a problem it's probably elsewhere, maybe an interrupt timing issue etc. Does access to the the NCR5380 SCSI chip actually go through DMA at all?

Hi Stephen,

It's nothing to do with loading into TT-RAM, it's a DMA issue.

IDE doesn't use DMA, SCSI and ASCI does. On the Falcon and ST you can't DMA to TT-RAM.

The workaround for ACSI is the _FRB cookie. I strongly suspect, but have not had it publically confirmed yet, that HDDriver support _FRB for ACSI transfers. It appears not to for SCSI transfers.

One of the missing pieces of the jigsaw here, which I've been briefed on off-thread is that the TT, which is obviously the archetypeal TT-RAM wielding SCSI machine, can DMA into TT-RAM, so _FRB is not required here.

I therefore theorise that HDDriver (at least in its default configuration) sees no need to use an FRB for SCSI transfers as no Atari hardware would be capable of needing it.

We need to ask Uwe about it.

BW

[exxos]

So has nobody used the CT60 with SCSI then for example ? There have been other weird accelerators for the Falcon in the past. Just would seem odd that this problem would go unnoticed for so long. But I guess it could be possible if nobody is actually using SCSI with other boosters.. Maybe never got tested but find it a little hard to believe. :shrug:

[Badwolf]

So has nobody used the CT60 with SCSI then for example ? There have been other weird accelerators for the Falcon in the past. Just would seem odd that this problem would go unnoticed for so long. But I guess it could be possible if nobody is actually using SCSI with other boosters.. Maybe never got tested but find it a little hard to believe. :shrug:

Or maybe there's a specific check in HDDriver for CT60? Or maybe we're well off base, but again, these are questions for Uwe. I'm reluctant to raise them as theoretical as I'm sure he's a busy man and would rather speak to someone actually trying to use his product in that way*.

Also AHDI and EmuTOS work, so I don't know where else I'm meant to look.

BW


* I said something else here earlier and I don't think it was constructive