Re: Let's build a CTPCI!
Posted: 14 Mar 2023 12:51
Do you mean the dma problems?Cyprian wrote: 14 Mar 2023 11:50 btw. some times ago I heard about some problems with CTPCI. What kind they were and were they resolved in that version?
We welcome retro users & hardware gurus alike! Come and join the party :)
https://www.exxosforum.co.uk/forum/
Do you mean the dma problems?Cyprian wrote: 14 Mar 2023 11:50 btw. some times ago I heard about some problems with CTPCI. What kind they were and were they resolved in that version?
I just read some opinion over Atari-Forum but without the context. I don't know the details, hence my previous question.
Code: Select all
Hardware CTPCI bugs list:
-------------------------
- PCI 33MHz boards not works, for example USB generic NEC board
go to "unrecoverable PCI error" and set "Parity error".
=> use only graphics boards who are 33/66 MHz compatible (more
signal tolerance).
- Interrupts not works, to confirm (maybe the real cause is the first
problem). Local interrupts can't work.
- DMA writing sometimes freeze the system (easy to create with
MagiC/NVDI real time moving window.
=> disable DMA with CT650CONF.CPX.
- DMA reading crashes the system (not used actually).
- Bus mastering for works for same reason.
- PCI arbitration not works, for example if you want use Video RAM
with USB board (maybe the real cause is the first problem).
So actually the best is to install ONLY the Radeon board.but ending with the pessimistic note from November 2012:On CTPCI fixed PEND register bits test inverted, and finally revoved this test who can caused loop inside a PCI interrupt
Tried again, with the latest jedec file for the CTPCI (CTPCI_1L), the PCI/PCIe adapter and the USB2 PCIe board. It's better, interrupts works fine and the ethernet OZK RTL8139 driver runs, but I have freezes with ethernet and the USB Mass Storage (most of time when the DMA writes to the local RAM). Add delays loops seems reduce problems but slow down transfers, for example on USB you must replace the 1uS delay between two status register reading by a 10 mS delay, and for ethernet I used (just for test) an interrupt task with the OZK RTL8139 driver who add a delay after the interrupt. It's not a reliable solution for a final release (too hardware dependent).
Hopefully, the 1N he is talking about is the same I found in Rodolphe's archive: https://mikrosk.github.io/ct60tos/ctpci/english/dev.htmHardware update with the latest jedec file CTPCI_1N.JED, but the hardware dma lock workaround not fix the problems with USB Mass Storage transfers or an Ethernet PCI board.
thanks mikro