TF4060 Beta Program

[terriblefire]

Thanks for finding the issue.
My expectation is that Option #3 will not work, because Ramsey occupies a 64MB address window which will tespond to DMA requests from ZIII cards.

I don‘t think there is no nice solution to this other than setting the DMA Mask.

On the other hand, I personally think there wouldn‘t be any kind of drawbacks if the card shipped with just 128MB of Ram.

My bigger concern here is improving the Chip Ram / ZIII access performance, because THAT actually affects the usability of the Amiga. ;-)

Agreed. Set the mask or update the GAL is the cleanest.

We can look at improving chip next. It will be November before i have time for this now.

[Chritoph]

Mask only lets you detect the issue happening I guess - it doesn't really prevent it. At least this is how PFS behaved, will retest with FFS 47 (3.2) again.

Plus: there were rumors, z3 may move from 0x4000.0000 to 0x1000.0000 in os3.3.

For the time being I will stick to EHIDE, seems most stable solution.

[terriblefire]

Mask only lets you detect the issue happening I guess - it doesn't really prevent it. At least this is how PFS behaved, will retest with FFS 47 (3.2) again.

Plus: there were rumors, z3 may move from 0x4000.0000 to 0x1000.0000 in os3.3.

For the time being I will stick to EHIDE, seems most stable solution.

if they move it to 01000.0000 a lot of cards will stop working
TF536 for starters.

Unless they're doing an OS5 they need to not make breaking changes.

[Oliver_A]

Hmmm, I would have expected for PFS3 to revert to PIO mode for non-DMA memory.

If that is the case, my request would be to perhaps make a Firmware which only supports 128MB.

I‘m perfectly fine with this, as I really don‘t need 256 MB of memory, just a stable, performant CPU accelerator which doesnt make me abandon my SCSI configuration, which is much superior in Handling to IDE thanks to the ZuluSCSI.

[Chritoph]

Memory allocation for the buffer is done by OS before asking the FileSystem (here: PFS3) to fill the buffer.
With the given buffer, PFS can detect mask not matching, show an error message, but that's about it.
As said will retest with modern FFS if that is doing any better, but I doubt it could.

In fact, the architecture here seems wrong to me. There is no OS method to gain a slice of memory fulfilling any mask needs, so how could that ever work at all?

Maybe a good question to some of the OS gurus at a1k - will try.

In the meantime, if option (3) is out, maybe provide a firmware with 128MB only, and a second one with 256MB and that modified U714 GAL .jed?

[Oliver_A]

Memory allocation for the buffer is done by OS before asking the FileSystem (here: PFS3) to fill the buffer.
With the given buffer, PFS can detect mask not matching, show an error message, but that's about it.

But why should it throw an error? The mask exactly tells PFS3 which range is allowed, meaning it needs to make sure that all filebuffers are allocated in this region, and when the destination is outside of the region, using cpu memcopy to copy it. Doesn't seem too complicated, right?

Or does PFS3 allocate memory from top to bottom, and recognizes "whoops, my buffer is outside of the mask" ?
That would be a stupid strategy in any case, since the way how the masking is defined historically assumes that non-DMA memory is at the top of the memory map - which is not at all in all cases correct, because in case of the TF4060, I still might have a BigRam or GottaGoFaZt3r in one of the ZIII slots, which is DMA capable.

Some people write it's an "idiot proofing measure" on behalf of the Filesystem. I have more the feeling that the authors just took the easy way out and just wanted to avoid questions like "duh, why is PFS3 sooooo slow???" and thus plainly sacrificing functionality out of convenience.

Anyway, my recommendation is to limit the memory to 128MB, or at least offering 128MB versions. This way, any broken concepts / frameworks are avoided.

[terriblefire]

Memory allocation for the buffer is done by OS before asking the FileSystem (here: PFS3) to fill the buffer.
With the given buffer, PFS can detect mask not matching, show an error message, but that's about it.

But why should it throw an error? The mask exactly tells PFS3 which range is allowed, meaning it needs to make sure that all filebuffers are allocated in this region, and when the destination is outside of the region, using cpu memcopy to copy it. Doesn't seem too complicated, right?

Or does PFS3 allocate memory from top to bottom, and recognizes "whoops, my buffer is outside of the mask" ?
That would be a stupid strategy in any case, since the way how the masking is defined historically assumes that non-DMA memory is at the top of the memory map - which is not at all in all cases correct, because in case of the TF4060, I still might have a BigRam or GottaGoFaZt3r in one of the ZIII slots, which is DMA capable.

Some people write it's an "idiot proofing measure" on behalf of the Filesystem. I have more the feeling that the authors just took the easy way out and just wanted to avoid questions like "duh, why is PFS3 sooooo slow???" and thus plainly sacrificing functionality out of convenience.

Anyway, my recommendation is to limit the memory to 128MB, or at least offering 128MB versions. This way, any broken concepts / frameworks are avoided.

No we will be offering 256mb. it took me
2 years to get that to work so we are doing it come hell or high water.

The error will happen if we have code that runs in TF rom to check the masks of all the partitions. I thought this was clear.

We will explicitly check and error in the card rom to warn of doom.

BTW with an A3000 and DMAC there is no issue. it's only the 4091/Fastlane type cards that will have any issues

[Chritoph]

4091.device is open source.
https://github.com/A4091/a4091-software
Plan: fixing it.

[pipper]

I don’t think there will be much of a problem with TF536. AFAIK they would only start doling out lower range Z3 space once the regular space is exhausted. This is to support devices with large address space requirements like PCI bridges, RAM expansions Z3660 and so on. This _should_ not happen in TF536 scenarios.

[terriblefire]

I don’t think there will be much of a problem with TF536. AFAIK they would only start doling out lower range Z3 space once the regular space is exhausted. This is to support devices with large address space requirements like PCI bridges, RAM expansions Z3660 and so on. This _should_ not happen in TF536 scenarios.

ah you mean it starts at 0x40000000 and rolls? TF536 is hard coded to that address because it will always be the first Zorro card in the chain. hacky i but never heard anyone having issues