nubus pds graphics card for 5200?

[pizzigri]

im confused, Zizagjoe, what was the rationale in making such an expensive piece of kit back in 1993, using arguably ”performance” components if the LC III slot is so slow? I think it was around 550 $… and it was indeed accelerated, I have the original manual, it lists lots of features and figures, unfortunately I am not home to look it up though.

 

[noglin]

I think you're being wildly optimistic .... remember, this is a slot intended for compatibility with legacy IO cards, not for peak performance.

Again, I do not see anything to suggest that the PrimeTime is implementing a posted write buffer where it is not waiting for completion on writes. Apple is saying buffered because it is electrically buffered by the PrimeTime chip. PrimeTIme certainly has registers as they are required for the 030 dynamic bus sizing implementation, but given that bus errors need to be implemented for the 030 bus it could never assume incoming writes are always valid. There would be no way to propagate a bus error back to the system bus. At best for a write to an 8 bit port it could assume if the first write was valid, then subsequent writes ought to be, but that is all, and no help for a 32 bit port.

That makes sense, OK so it won't ack until the PDS device acks it.

There will be additional clock delays on both the 601 to 040 and 040 to 030 for synchronization between different clock domains and bus translation. It's hard to say how quickly 030 bus cycles could be issued back-to-back for that reason without measuring. 030 bursts are highly unlikely to be implemented due to that; it would be a synchronization nightmare and it was never an often used feature for IO. Further, the LC3 connector would be required, not the 96 pin LC connector on that Micron card.

Disclaimer: I really don't know much about the bus transfers.. I just saw you made your own graphics cards... respect!

The extra clock delays for 603 to 040 is the same for the valkyrie chip. The PPC can do 64 bit writes, assume it is aligned. The 68040 data bus latches on the 603 data bus, the address bus of the 603 goes to Capella IC which translates to 68040. A 64 bit write on 603 will (likely?) be translated to something like long word: start, address, 4bytes, 4bytes. (idk the 68040 protocol)
PDS A31-2 is on the 68040 address, so it already sees it (the gfx chip could already now prepare, I'm optimistic, probably), PrimeTimeII would get the address and the first 4 bytes, it would then send those of on 68030 bus, if it is a 16 bit device (which I think this older card is?) then it would be 2x16 cycles, and then another 2x16. Then there must be acks per each 2b, and then from PrimeTimeII an ack for each 4byte. Hmm definitely won't be able to write 2 bytes each cycle of the possible 16mhz. And so hmm yes unlikely to reach 17mb/s? But *maybe* with a 32bit interface card? (are we sure this card is not 32 bit interface?)

 

[zigzagjoe]

im confused, Zizagjoe, what was the rationale in making such an expensive piece of kit back in 1993, using arguably ”performance” components if the LC III slot is so slow? I think it was around 550 $… and it was indeed accelerated, I have the original manual, it lists lots of features and figures, unfortunately I am not home to look it up though.

Keep in mind those posts are written to address noglin's question to get more framebuffer throughput on a non-68030 machine. That is a separate application from the designed use-case for a LC1/2 video card.

Your main reasons to use a video card on those would be for higher resolution and bit depth support over the integrated graphics. Acceleration is a bonus, while simultaneously essentially being a requirement for sane 24 bit color support. I would expect it to be a reasonably quick framebuffer too. Those were important considerations for 030 based machines.

These became less relevant on the later machines. While I'm aware the valkyrie isn't as performant as the memc-based framebuffers, I'm still of the opinion that it is unlikely you'd see greater performance on any machine 040 or PPC based accessing an 030 PDS LC card.

That makes sense, OK so it won't ack until the PDS device acks it.

Disclaimer: I really don't know much about the bus transfers.. I just saw you made your own graphics cards... respect!

The extra clock delays for 603 to 040 is the same for the valkyrie chip. The PPC can do 64 bit writes, assume it is aligned. The 68040 data bus latches on the 603 data bus, the address bus of the 603 goes to Capella IC which translates to 68040. A 64 bit write on 603 will (likely?) be translated to something like long word: start, address, 4bytes, 4bytes. (idk the 68040 protocol)
PDS A31-2 is on the 68040 address, so it already sees it (the gfx chip could already now prepare, I'm optimistic, probably), PrimeTimeII would get the address and the first 4 bytes, it would then send those of on 68030 bus, if it is a 16 bit device (which I think this older card is?) then it would be 2x16 cycles, and then another 2x16. Then there must be acks per each 2b, and then from PrimeTimeII an ack for each 4byte. Hmm definitely won't be able to write 2 bytes each cycle of the possible 16mhz. And so hmm yes unlikely to reach 17mb/s? But *maybe* with a 32bit interface card? (are we sure this card is not 32 bit interface?)

The 040 does bytes, word, long, and 4x long transfers, so the 040 translation chip is likely issuing long transfers only and each PPC 64 bit access becomes two long bus cycles.

The micron card is probably 32 bit wide. It would be surprising if it wasnt. I doubt it would be taking any action before /AS is issued on the 030 bus ie in response to changing address as this would lead to a lot of wasted effort (so to speak). The best case scenario for a 32 bit card would be if it were able to acknowledge using /STERM in 2 clocks total, but a LC1/2 card doesn't have access to /STERM so the minimum is 3 clocks plus however many 16mhz clocks until the bus translator can issue a second cycle. There's still going to be synchronization required for crossing clock domains twice, too... you see how this starts to add up.

Unfortunately I didn't capture anything from the logic analyzer when I stuck one of my NuCF cards in a 605 for testing, but I might try at some point to see how quickly bus translation in that machine works.

 

[noglin]

Keep in mind those posts are written to address noglin's question to get more framebuffer throughput on a non-68030 machine. That is a separate application from the designed use-case for a LC1/2 video card.

Your main reasons to use a video card on those would be for higher resolution and bit depth support over the integrated graphics. Acceleration is a bonus, while simultaneously essentially being a requirement for sane 24 bit color support. I would expect it to be a reasonably quick framebuffer too. Those were important considerations for 030 based machines.

These became less relevant on the later machines. While I'm aware the valkyrie isn't as performant as the memc-based framebuffers, I'm still of the opinion that it is unlikely you'd see greater performance on any machine 040 or PPC based accessing an 030 PDS LC card.



The 040 does bytes, word, long, and 4x long transfers, so the 040 translation chip is likely issuing long transfers only and each PPC 64 bit access becomes two long bus cycles.

The micron card is probably 32 bit wide. It would be surprising if it wasnt. I doubt it would be taking any action before /AS is issued on the 030 bus ie in response to changing address as this would lead to a lot of wasted effort (so to speak).

That makes sense!

The best case scenario for a 32 bit card would be if it were able to acknowledge using /STERM in 2 clocks total, but a LC1/2 card doesn't have access to /STERM so the minimum is 3 clocks plus however many 16mhz clocks until the bus translator can issue a second cycle.
There's still going to be synchronization required for crossing clock domains twice, too... you see how this starts to add up.

Unfortunately I didn't capture anything from the logic analyzer when I stuck one of my NuCF cards in a 605 for testing, but I might try at some point to see how quickly bus translation in that machine works.

Thank you!

Well even if it doesn’t sound that it is plausible, it might still be faster. Valkyrie ends up getting its entries filled up and takes quite some time to empty. If the gfx card on the pds is fast vram it might still win. Hope someone will be able to try it out one day.