Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
Jak stworzyć składankę gier na kasecie? Dziś, dzięki nowoczesnym narzędziom, jak program Turgen, ten proces jest znacznie łatwiejszy.
HDDRIVER 12.71 Nowa wersja najbardziej rozbudowanego sterownika pamięci masowych dla 16- i 32-bitowych Atari, z mnóstwem usprawnień i nowości.
Elite - port z BBC Micro na Atari XL/XE Wczesna beta portu kultowego Elite z BBC Micro na 8-bitowe Atari.
sAIOnara v3.0 Zaawansowany układ wideo Pancia, sAIOnara v3.0, bazujący na chipie CXA2075, jest już dostępny.
Altirra 4.40 test 20 Nowa wersja rozwojowa popularnego emulatora Altirra zawiera szereg usprawnień i poprawek błędów.
atari.area forum » Posty przez _tzok_
Właśnie takiej taśmy użyłem - 80-żyłowej. Niestety na płytce nie ma miejsca by wstawić jednocześnie kondensatory i rezystory, na drugiej płytce wstawiłem tylko kondensatory. Będę testował w wolnej chwili, na dzisiaj mam już dość.
Wersja z rezystorami:
Wersja z kondensatorami (22pF):
...no i jeszcze muszę ogarnąć to:
Tu nie chodzi o przejściówkę, lecz o taśmę IDE. To dołożenie taśmy pomogło (być może wraz z szeregowymi rezystorami 33R). Taśma wprowadza do układu dodatkową pojemność, która eliminuje "dzwonienie" linii. Wypróbuj to u siebie, być może okaże się, że pozostałe karty również zaczną działać prawidłowo.
Myślę, że mogę ogłosić zwycięstwo! Zapis działa poprawnie i jest to powtarzalne. Winna była... przejściówka.
Dzięki temu, że kupiłem drugą przejściówkę i na niej w ogóle nie działało, za radą Mq postanowiłem ją sprawdzić. Poszedłem po najmniejszej linii oporu i wstawiłem ją do starego PC. Efekt - błąd dysku... ale coś mnie tknęło i wpiąłem przejściówkę, którą dostałem od Mq wraz z PCB, efekt - zwis komputera na wykrywaniu dysku (żadnego błędu, po prostu wisiał na wykrywaniu dysku). Włożyłem kartę Elite Pro - działa (ta karta nie obsługuje DMA w ogóle). Miałem jeszcze jedną przejściówkę, taką nie wpinaną w port tylko do podłączenia przez taśmę - na niej w PC działały wszystkie moje karty CF (Kingston CF Elite Pro, Transcend CF Ultra, oraz SanDisk CF Ultra)... no więc wytargałem taśmę IDE z PC, włożyłem wraz z przejściówką i kartą do Atari i... nic ;) No tak, ta przejściówka nie podaje zasilania na kartę. Szybko to naprawiłem podłączając zewnętrze zasilanie i... działa!!! Zarówno odczyt jak i zapis jest bezbłędny.
W sumie dobrze odpowiedział... na tym polega DMA, że nie angażuje CPU w transmisję. Ale jednak przy zapisie kolejka do wysyłki jest zapełniana programowo.
...sprawdzę, ale prędzej to przelutuję cyną ołowiową z fluxem, niż będę próbował przedzwonić miernikiem ;). Coś tam działa, bo kartę w niej wykrywa, tylko partycji nie widzi, czyli tak jak w przypadku kart bez WDMA.
Ta ma, PCB wygląda identycznie, wszystkie piny są podłączone.
Kupiłem Microdrive'a... zobaczymy czy z nim zadziała.
8-bit DMA jest (a raczej był) w standardzie ATA. Stracił się gdzieś w okolicy ATA-3. Oficjalnie ten tryb nazywa się (Single)Word DMA albo WDMA. Interfejs Putnika pracuje w trybie WDMA-0... albo coś "koło tego", jak większość jego rozwiązań.
W akcie desperacji może wydam te 200+ PLN na 16-kanałowy analizator i wtedy poznamy odpowiedź co jest winne - karta czy sterownik.
P.S.
Kupiłem (prawie) identyczną przejściówkę i na niej tryb DMA nie działa w ogóle... wizualnie różni się kolorem nadruku i tym, że przy złączu CF (13 CF do 26 pin IDE) ma kondensator 10n zamiast rezystora 2k7 (czyli w sumie prawidłowo bo to jeden z pinów Vcc po stronie karty, do pinu GND po stronie IDE).
Dzisiaj dołożyłem rezystory szeregowe zgodnie z w/w dokumentem... bez wpływu na występowanie błędu.
Dane nie są zatrzaskiwane w interfejsie, zatrzask przechowuje jedynie bajt sterujący.
Gdyby powtórzony był przedostatni bajt to bym jeszcze zrozumiał, ale powtórzony jest bajt przed przedostatni (n-2), poza tym transmisja jest synchroniczna (i równoległa).
Bardzo ciekawa lektura, jednak nadal nie pasuje mi to powtórzenie trzeciego od końca (n-2) bajtu sektora na pozycji ostatniego bajtu.
Pamiętaj, że dla interfejsu IDE musisz podmienić początkową część obrazu stosownym plikiem. Główny plik BIN ma autoboot dla ACSI. Putnik stosuje bardzo dziwny opis partycji w tym obrazie. Niby jest to FAT16 i PC/Windows widzi partycje i dane nich na tym obrazie (1 x podstawowa, 1 x rozszerzona z dwoma dyskami logicznymi) ale już żaden program do partycjonowania ani nawet DMDE nie rozpoznaje prawidłowo typu tych partycji.
Tu masz gotowy obraz:
https://we.tl/t-OofarNMBXH (link wygaśnie za 7 dni)
Jak nikt inny się nie znajdzie mogę się podjąć naprawy.
Negacja DMARQ to żądanie przerwania transmisji.
If the Card cannot sustain continuous, minimum cycle time DMA transfers, it may negate DMARQ within the time specified from the start of a DMA transfer cycle to suspend the DMA transfers in progress and reassert the signal at a later time to continue the DMA operation.
(...)
This signal (DMACK) may be negated by the host to suspend the DMA transfer in progress.
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:
Przyszedł mi czytnik i mogę po ludzku pracować na laptopie z Win10 (widzi partycje na kartach Flash). Każdy 512 bajt jest powtórzeniem bajtu 510, to nie jest kwestia szumów... dokładnie każdy i bezbłędnie.
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.
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
Równania są prawidłowe, ale dopiero po przestudiowaniu dokumentacji ACSI je zrozumiałem. Problem jest w jednej z następujących rzeczy:
- sygnał MONOST (opóźnione i zanegowane ACK) jest niezbyt sensownie generowany. Tak naprawdę wykorzystywane jest opóźnienie tego sygnału wprowadzane przez czas propagacji '221, a nie długość generowanego impulsu ustalana przez RC. Komentarz w pliku GAL mówi o 120ns, a dla 180pF i 750R jest to 95ns, właściwy czas jest uzyskiwany dla 1k, ale jak pisałem czas trwania tego impulsu jest bez znaczenia, byle był krótszy od !ACK.
- Zapis !ACK & MONOST zasadniczo też jest bez sensu, wystarczy MONOST, chyba że mogłaby zaistnieć sytuacja gdzie stałej długość sygnał MONOST nie kończy się przed wygaśnięciem !ACK.
- Zagadką pozostaje opóźnianie sygnałów IORD i IOWR, bez opóźnienia DRQA.
- W moim egzemplarzu nie ma różnicy czy używam sygnału MONOST czy nie... jego usunięcie z równań nie zmienia niczego.
- Muszę to sprawdzić ale wygląda jakby mylony bit (bo to są przestawione pojedyncze bity w bajcie) pochodzi z poprzedniego cyklu polecenia.
Mój egzemplarz działa prawidłowo zarówno z GALem 15ns, jak i 35ns. Najprostszym rozwiązaniem byłoby skłonienie Putnika by przepisał sterownik tak, aby tylko odczyt odbywał się w trybie DMA, natomiast zapis - w PIO. Niestety nie odpowiada na żadne wysyłane do niego maile, a na jego forum nie da się zarejestrować.
Spójrzcie na te równania:
!IORD = A1 & !CS & RW & ENABL # !DMAON & ENABL & DMARQ & !ACK & MONOST & DMARW ; /* must close before ACK !!! */
/* so, needs monostable again */
!IOWR = A1 & !CS & !RW & ENABL # !DMAON & ENABL & DMARQ & !ACK & MONOST & !DMARW ;...coś mi tu nie pasuje. Sygnały IORD i IOWR mają być blokowane (=1) przed wystąpieniem ACK, przy pomocy sygnału MONOST... no i pięknie, tylko że ten sygnał pojawia się po ok 30ns od zbocza opadającego ACK i trwa 85ns :/ Poza tym mamy problem z podwójną negacją... równanie niby jest w odwróconej logice, ale wtedy to blokowanie nie działa... albo jest już późno i źle myślę :/ bo żeby zablokować to ma być IOWR = 1, a nie !IOWR = 1...
To są oscylogramy Chrisa, u siebie aż takiego dzwonienia nie zaobserwowałem, występuje natomiast szereg innych dziwacznych zjawisk na magistrali danych portu ACSI...
W układach TTL i HCT na wejściach są już tak włączone diody.
Diody zabezpieczają przed przed impulsami, które pojawiają się poniżej poziomu masy.
https://www.exxoshost.co.uk/atari/last/DMAfix/index.htm (tutaj akurat puszczony przez rezystor 100R):
Niestety diody u mnie nic nie zmieniają. Natomiast obserwując na oscyloskopie linie portu ACSI to jest w ogóle cud, że cokolwiek działa. Ciężko dojść co jest transmisją a co zakłóceniami.
Przekopiowałem kilkakrotnie folder z kilkoma setkami plików i na pierwszy rzut oka wyglądało, że wszystko jest ok. Niestety dokładniejsze oględziny pokazują, że pojedyncze bity są zamienione :(
https://www.youtube.com/watch?v=UqliWRjLclE
atari.area forum » Posty przez _tzok_
Wygenerowano w 0.112 sekund, wykonano 10 zapytań