exxos's Atari, Amiga & retro forum

terriblefire wrote: 17 Aug 2024 19:43 Ah no worries.

i really need a 3000T mobo to support it properly.

If anyone is wondering why the 4060 is more expensive it's just because the cost to develop it and test it is so much higher than other cards. A 1200 can't have that many things plugged into it

Sorry to butt in, but when you write about the price, does that mean I can buy a test version of the TF4060 somewhere? I'd like to test how it works on my few "big Amigas" :-) I have A400T and A4000D and 3 working A3000 boards...

There are sales threads over on amibay. One for EU one for UK/Canada

terriblefire wrote: 22 Aug 2024 13:15 There are sales threads over on amibay. One for EU one for UK/Canada

Thanks, I found it on AmiBay :-). I'll try to buy one and then maybe the other.
Are you planning to change the PCB version for the final version? Or will there only be changes in the firmware?

i've not seen a change i need to make yet.

Great. I declared my interest in Chucky on Amibay. If I manage to get the card, I'll let you know how it works for me in various configurations.

markus0321 wrote: 22 Aug 2024 13:40 Great. I declared my interest in Chucky on Amibay. If I manage to get the card, I'll let you know how it works for me in various configurations.

Yeah it will happen if you posted on Amibay

Hi @terriblefire and @Oliver_A ,

I toyed around with @Oliver_A 's observation, WHDLoad hanging when running from a partition on A4091,
I believe at least Olli is testing with an original Commodore A4091, not sure about firmware though.

Well, I am not, ReA4091 here, let me describe my setup...

- Commodore A4000D, RevB, lovely recapped, renovated and pretty stable ever since,
- CV64, P96 3.4.1 (not relevant for the test),
- Triton lite, Poseidon 4.5 (USB stack not loaded, not relevant for the test),
- XSurf-100, RoadShow 1.15 (TCPIP stack not loaded, not relevant for the test),
- ReA4091, ROM 42.29, GALs not really latest, but pretty stable usually, ZuluSCSI installed on it, all partitions use Direct SCSI, boxes ticked in HDToolBox,
- OS 3.2.2.1, Kick 47.111, WHDLoad 18.9

so now the scenarios:
I start Turrican 2 WHDLoad from
- RAM, copied from ReA4091 PFS partition - works fine
- CF Card on EHIDE - works fine
- ReA4091 partition, PDS\03, (PFS 19.2 direct scsi, "Mask" set to 0x7fFFffFE) - machine hangs (!!!)
- ReA4091 partition, FFS\03, (w/ direct scsi, "Mask" set to 0x7fFFffFE) - machine hangs (!!!)
- ReA4091 partition, PDS\03, (PFS 19.2 direct scsi), "Mask" set to 0x0fFFffFE (thus forbidding upper 128MB of TF4060 and all of Z3 memory space) - works fine again (!!!)
- ReA4091 partition, PDS\03, (PFS 19.2 direct scsi), "Mask" set to 0x6fFFffFE (thus forbidding upper 128MB of TF4060 and allowing all of remaining Z3 memory space) - works fine, still (!!!)
Turrican 2 is just a concrete example, the same happens with all WHDLoads I tested, Syndicate, Locomotion, Turrican, ... you name it.

If I try filling up the RAM: from a partition on ReA4091 by copying files.
With a "Mask" set to 0x7fFFffFE, I can reprocduce a similar crash just as above as soon as the fill state of RAM is like 47% (Chip and Motherboard RAM are there, too).
If I try the same with "Mask" set to 0x6fFFffFE, PFS at some point shows: Clicking "OK", so copy continues, leads to an immediate crash.

I guess that kind of proves Buster11 or some other part of your choice does react allergic on DMA Zorro3 to Zorro3 memory in CPU Slot.
Please do not ask me why that triggers it, but... somehow it does.

Recommended fix:
Well, for the time being, put "DMA devices may suffer, use Mask 0x6FFFFFE" into the manual.
Other idea: can we have a test with using areas ?
(see http://oscomp.hu/depot/amiga_memory_map.html)
Would mean TF4060 provides 128+8+104 = 240MB of RAM - who cares about that 16MB missing?
Or: put it in parallel to mainboard RAM and tell everybody to remove mainboard RAM for full 256MB?

Best,

C

Thanks for the testing. This is what i have also observed. There are a few ways to tackle this.

1. Setting the mask as you say... works fine.
2. I could give a new GAL jed for the 4000 Mobo. U714 i think. I have recompiled this but not tested it.
3. we could move the ram down into the lower areas...
4 ?

Open to suggestions. Given that the RAM is useably fine in all cases except a DMA from a zorro slot i'm inclined to find a way to DMA prohibit it.

Can we try #3, please?

If that's not too much work I would love to test that next. ;)

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. ;-)