Piszę z głowy, bo już nie mam tych testowanych plików, które były uszkodzone, ale wydaje mi się z tego co pamiętam, że było u mnie tak samo - właśnie tak jak piszesz.

Ale rozumiem, że masz na myśli tutaj tylko odczyt? Przy odczycie działa prawidłowo, natomiast przy zapisie występują błędy.
Przy swoich testach kopiowania dużych ilości danych i porównywania ich, potwierdziłem na 100% że błędy następują tylko i wyłącznie przy zapisie. Zrobiłem to w taki sposób, że kopiowałem dane pomiędzy kartą CF, a "dyskietką" w Goteku - to dało mi ostateczny 100% rezultat, że przy kopiowaniu z karty na Goteka zawsze było wszystko w porządku, natomiast przy kopiowaniu z Goteka na kartę CF występowały błędy.

Niestety z Putnikiem rozmowa to jeden z najcięższych przypadków kontaktu międzyludzkiego z jakim spotkałem się w obrębie naszego hobby:-)
Bardzo długo go męczyłem żeby dał mi sterownik, który działa z tym interfejsem tylko w trybie PIO, bo twierdził, że ma taki sterownik. Chciałem sprawdzić, czy w trybie PIO będą jakieś błędy przy takiej samej konfiguracji sprzętowej. Nie doprosiłem się, jedeyne co uzyskałem, to przesłany mi dokładnie ten sam driver który jest na stronie, tylko pod inną nazwą, oraz innym razem przesłał mi też inny driver (ten, który wysłałem Ci na maila), ale on też działa identycznie, nie jest to driver w PIO. Za kolejnymi naciskaniami na driver, Putnik się już obraził, kazał mi lutować diody, uparł się, że driver jest na pewno dobry, i już nigdy nic więcej mi nie wysłał. Ostatecznie rozmowa z nim doszła do etapu, kiedy zaczął na wszystkich narzekać (podobnie jak w wielu wątkach na forach) i temat interfejsu się urwał... Ja się poddałem i przestałem korespondować z Putnikiem.

Przepisałem plik GALa z oznaczeniami zgodnymi z powszechni stosowanymi i w miarę sensownymi komentarzami (tak mi się wydaje):

Name     ACSICF05 ;
PartNo   00 ;
Date     2019-02-26 ;
Revision 01 ;
Designer TzOk ;
Company  None ;
Assembly None ;
Location None ;
Device   G16V8AS ;

/* *************** INPUT PINS *********************/
PIN  1    = A1                        ; /* From ACSI - cmd LOW, data HIGH  */
PIN  2    = CS                        ; /* From ACSI - active LOW          */ 
PIN  3    = RW                        ; /* From ACSI - write LOW, read HIGH*/ 
PIN  4    = ACK                       ; /* From ACSI - active LOW (~DMACK) */ 
PIN  5    = INTRQ                     ; /* From CF - active HIGH           */ 
PIN  6    = DMAON                     ; /* From DRIVER - active LOW        */ 
PIN  7    = DMARW                     ; /* From DRIVER - active LOW        */ 
PIN  8    = DMARQ                     ; /* From CF - active HIGH           */ 
PIN  9    = RESET                     ; /* From ACSI - active LOW          */
PIN 11    = ENABL                     ; /* From DRIVER - active HIGH       */ 
PIN 12    = DNACK                     ; /* Del'd ACK tw~85ns - active HIGH */

/* *************** OUTPUT PINS *********************/
PIN 13    = IRQA                      ; /* To ACSI via diode - active LOW  */ 
PIN 14    = DMACK                     ; /* To CF - buffered ACK            */
PIN 15    = DRQA                      ; /* To ACSI via diode - active LOW  */ 
PIN 16    = RESETF                    ; /* To CF - buffered RESET          */
PIN 17    = IORD                      ; /* To CF - active LOW              */ 
PIN 18    = IOWR                      ; /* To CF - active LOW              */ 
PIN 19    = LAC                       ; /* To '574 CK pin - active RISING  */ 

/* *************** BOOLEAN-EQUATIONS *********************/
                              
   LAC = !A1 & !CS & !RW & RESET ;        /* raising pulse for command latch */

   !IORD = A1 & !CS & RW & ENABL # !DMAON & ENABL & DMARQ & !ACK & DNACK & DMARW ;    /* READ # DMA_READ */
 
   !IOWR = A1 & !CS & !RW & ENABL # !DMAON & ENABL & DMARQ & !ACK & DNACK & !DMARW ;    /* WRITE # DMA_WRITE */

   !DRQA = DMARQ & DMACK & ENABL ;        /* off when ACK deactivates */
 
   !IRQA = INTRQ ;                /* invert for ACSI */

   DMACK = ACK ;                /* buffer for CF */

   RESETF = RESET ;                /* buffer for CF */

W którym trybie działa ta karta na driverze Putnika? DMA-MW 0? Jeśli tak to sygnały IORD i IOWR są stanowczo za krótkie - trwają ok 85ns, a powinny co najmniej 215ns.

W sumie ten dokument od GOOD-RAMa jest o wiele bardziej użyteczny, niestety opis nie do końca zgadza się z rysunkiem.

O wiele bardziej wyczerpująca dokumentacja: http://thiim.com/TradePoint141/ItemImag … 90917).pdf
https://produktinfo.conrad.com/datenbla … AL_150.pdf
...a tutaj całkiem inaczej, ale o wiele sensowniej: https://cpi-tec.jp/cpcf/pdf/CPCF_SI%e3%80%80TYPE.pdf

Ostatnio edytowany przez _tzok_ (2019-03-08 23:28:12)

Kombinuję z buforowaniem sygnałów, dwa wolne wyjścia wykorzystałem do buforowania sygnałów ACK (DMACK) i RESET dla karty CF, tak by nie było bezpośrednich połączeń między liniami ACSI i karty CF. Użycie zbuforowanego sygnału ACK dla generowania sygnałów IORD/IOWR powoduje, że pojawiają się zbyt późno, sygnałowi DRQA jest "wszystko jedno".

Jeden z powyższych dokumentów częściowo odpowiada na pytanie co robi tam ten multiwibrator - sygnały IOxx muszą być wystawione przez określony, czas... te 180ns z komentarza w oryginalnym pliku GAL Putnika (prawie) pasują do czasu wymaganego dla DMA-MW 0 (215ns)... tyle, że przy wartościach elementów RC jak na schemacie jest to 85ns, a nie 180ns. Co więcej, ten sygnał musi przestać być aktywny przed końcem transmisji danych.

Większość kart obsługuje tryby DMA-MW 3 i 4, driver Putnika wykorzystuje prawdopodobnie tryb 0 lub 1.

Ostatnio edytowany przez _tzok_ (2019-03-08 23:45:38)

Obstawiałbym zatem błąd typu "off by one" w kodzie drivera ... gdzieś sprawdza licznik<512 i używa licznik-1 zamiast licznik

Masz 99,99% racji :) i tak jak BartoszP obstawiałbym obsługę DMA w kodzie drivera. Dlatego też Mq chciał wyciągnąć od PP inny sterownik ale się nie udało. Teraz trzeba by zdizassemblować sterownik, przeanalizować co i jak się dzieje no i może poprawić? Ten interface ma szansę działać prawidłowo...

Pozdrawiam

Dziwne te timingi... raz DMA jest synchronicznie z DMACK, a raz są przesunięte o 42ns... a to jest ten sam sygnał buforowany w GALu. W załączniku timingi zebrane przy kopiowaniu pliku z jednej partycji na drugą. Niestety mój analizator ma tylko 8 kanałów. Do otwarcia potrzebny program Saleae Logic.

Tak przy okazji - cóż za zaskoczenie - zobaczcie co ile taktów pojawia się sygnał DMARQ wstrzymujący transmisję... no jak obstawiacie?

Rozwiązanie zagadki:

Ostatnio edytowany przez _tzok_ (2019-03-10 00:24:51)

Negacja DMARQ to żądanie przerwania transmisji.

Czy przypadkiem nie będzie to problem opisany w tym dokumencie w sekcji C.2 Termination?

To powtórzenie może być problemem z synchronizacją zegara, która na początku przesyłania danych jest ok, a potem delikatnie dryfuje, tak że na ostatnim bajcie akurat komputer odczytuje dwa razy to samo.

Ale pamiętaj, że transmitujemy po 16 bitów, tylko w dwóch paczkach po 8. Dlatego w zasadzie jest to bajt przedostatni w stosunku do tego ostatniego, gdyby transmisję rozpatrywać w podziale na HI i LO.

Dzisiaj dołożyłem rezystory szeregowe zgodnie z w/w dokumentem... bez wpływu na występowanie błędu.