TF4060 Beta Program

[Oliver_A]

Hello there,

new betatester here, who previously did 2.5 years of additional work on the BFG9060 CPLDs to make them more compatible.

Anyway, just received my card today, and after flashing the most recent firmware posted here, the card started working at 100MHz on my A4000D with ReA4091, X-Surf 100 and Cybervision 64. So far, the machine ran 5 1/2 hours with closed case at hot weather, which is a good sign.

However, what is still flaky is the boot process, I sometimes require multiple resets to get the system booting.

What I would like to point out here is a mechanical issue, because the holes located beside the zorro daughterboard mismatches the location of the A4000D PCB.

I added a picture to illustrate the issue. My recommendation is to take the BFG9060 PCB measurements here as a reference, because they are perfect.

Anyway, great job so far, hope that when the most severe stability issues are ironed out, the chip-ram fand fast ram performance can be improved to match the Cyberstorm / BFG9060 figures. I can certainly be of practical help in this regard.

Best regards,

Oliver

[terriblefire]

Hello there,

new betatester here, who previously did 2.5 years of additional work on the BFG9060 CPLDs to make them more compatible.

Anyway, just received my card today, and after flashing the most recent firmware posted here, the card started working at 100MHz on my A4000D with ReA4091, X-Surf 100 and Cybervision 64. So far, the machine ran 5 1/2 hours with closed case at hot weather, which is a good sign.

However, what is still flaky is the boot process, I sometimes require multiple resets to get the system booting.

Interesting. I have not got that issue with either of my TF4060s. One runs on the A4000CR and one runs on the AA3000+ (booting from SCSI). There was a very recent fw update for fixing a chipram dma issue. Double check you have that?

What I would like to point out here is a mechanical issue, because the holes located beside the zorro daughterboard mismatches the location of the A4000D PCB.

Ah interesting. I can believe this. I got the hole measurements from @chucky from his A3660. I will reassess this for a 5c version of the card.

[alenppc]

However, what is still flaky is the boot process, I sometimes require multiple resets to get the system booting.

This could be related to a reset issue that was fixed in the latest fpga firmware file. Ask Chucky to give it to you to reflash and see if this solves it. Otherwise, I have not experienced any booting issues on my machines.

[terriblefire]

However, what is still flaky is the boot process, I sometimes require multiple resets to get the system booting.

This could be related to a reset issue that was fixed in the latest fpga firmware file. Ask Chucky to give it to you to reflash and see if this solves it. Otherwise, I have not experienced any booting issues on my machines.

This would only be an issue where you are soft loading modules and had reboot cycles mid boot? If your setup does that then you probably need the latest file.

[Oliver_A]

Interesting. I have not got that issue with either of my TF4060s. One runs on the A4000CR and one runs on the AA3000+ (booting from SCSI). There was a very recent fw update for fixing a chipram dma issue. Double check you have that?

Thanks, just got the most recent FW from @chucky, and it seems that the start-up problems are gone now!

Ah interesting. I can believe this. I got the hole measurements from @chucky from his A3660. I will reassess this for a 5c version of the card.

That would be great, because it would allow to mount the card using at least 3 screws for a more secure fit. A 100MHz doesn't get so much hot, however, I prefer to attach a Pentium III cooler to it in order to reduce overall system temperature.

Now doing more stability tests. My next concern:

* Does ZIII DMA work in the upper 128MB memory half? My understanding is that Buster only supports 128MB local memory, but I might be wrong here.
'

[terriblefire]

Now doing more stability tests. My next concern:

* Does ZIII DMA work in the upper 128MB memory half? My understanding is that Buster only supports 128MB local memory, but I might be wrong here.
'

If that were true you wouldn't be able to DMA out of zorro cards! But i can explicitly test it. i cannot see why Buster would have a limitation like this. it's just a counter!

EDIT: the amount of fiction floating about regarding amiga hardware never ceases to amaze me. This stuff is pretty simple. Buster is a bus translator with an arbiter in there for contending DMA requests from different bus masters. It doesn't really do much else. It doesn't even decode addresses from what i can tell.

[Oliver_A]

Now doing more stability tests. My next concern:

* Does ZIII DMA work in the upper 128MB memory half? My understanding is that Buster only supports 128MB local memory, but I might be wrong here.
'

If that were true you wouldn't be able to DMA out of zorro cards!

It depends whether the Bus Cycle is targeting Zorro III address space or 68030 space.
Buster supports 3 types of Zorro III DMA:

* Zorro III <> Zorro III (CPU is not involved)
* 68030 -> Zorro III (68030 Bus master (CPU, or NCR SCSI in A4000T)
*Zorro III -> 68030 space (targeting Chip-Ram, Fast Ram, Local CPU accelerator Ram)

Where the address spaces are is determined by asserting _ADDRZ3 on Buster, which is done by U714.
The problem might arise when the Address space of the upper 128MB TF4060 Ram is marked by U714 as Zorro III Ram.

But i can explicitly test it. i cannot see why Buster would have a limitation like this. it's just a counter!

It's not a limitation of Buster, but a decision by the Amiga System Architects where and how big the Zorro III space is - pretty much like one would decide where the physical PCIe memory space is in modern systems. Buster itself just needs to be told which cycles it needs to generate based on the source and destination addresses.

EDIT: the amount of fiction floating about regarding amiga hardware never ceases to amaze me. This stuff is pretty simple. Buster is a bus translator with an arbiter in there for contending DMA requests from different bus masters. It doesn't really do much else. It doesn't even decode addresses from what i can tell.

Yes, but U714 does.

I attached 2 screenshots from the A4000D schematics and buster specification as reference.

Screenshot 2024-07-30 114920.png (291.63 KiB) Viewed 913 times

Screenshot 2024-07-30 114929.png (262.99 KiB) Viewed 913 times

[terriblefire]

If buster does not generate all cycles then bus masters cannot cache snoop.

but it should not matter unless buster DSACKs something meant for the CPU card.

EDIT: it even says DMA cycles are not special cased in what you posted above. And normal cycles to that ram area are not seen by the 030 bus.

Anyways i can test this very easily

[Oliver_A]

Just made some tests by copying a full "Quake" folder 4x from my ReA4091 into the Ram Disk, so that at the end, 33MB were free.
I can start Quake from all folders, and when the copy finished, no data corruption is observable.
This means that U714 does not assert "_ADDRZ3" for the upper 128MB space, which means that Buster translates the ZIII cycles into 68030 cycles, visible by the TF4060.

However, what I observed instead is that not all copy operations finished without hanging the system. Quake is a good target for copying, since it has large datafiles, putting the bus to test.

Will further investigate...

[terriblefire]

I'm planning to simply test DMAC into upper 128mb of ram using a regression test. it's far less anecdotal about finding any issues.

That is to say i will absalloc exact ram and test the heck out of it.

So long as AS/DS and SIZ are asserted this is converted into an 060 cycle at the fpga and will become a ram access if the correct address is selected. I don't see why it matters if the Z3 bus sees or doesn't see it?