Przejdź do treści forum
atari.area forum
Twoje polskie źródło informacji o Atari
Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
Aktywne tematy Tematy bez odpowiedzi
Aktualności ze świata Atari
TURGEN 9.3.0 Kolejna wersja multiplatformowego narzędzia do zarządzania obrazami taśm.
SV 2024 WE - program imprezy Już za tydzień odbędzie się zimowa edycja Silly Venture
Nowa obudowa dla 800XL - zostało 36 dni Niewiele ponad miesiąc do końca kampanii.
Zmarł twórca języka BASIC Zmarł Thomas E. Kurtz twórca języka BASIC
Zmiana serwera atari.area Serwis przeszedł właśnie ważną aktualizację infrastruktury
Opcje wyszukiwania (Strona 50 z 59)
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
Karta trafiła mi się przypadkiem. Opis HDL (funkcje) do GALa jest taki sam, tylko przepisany i skompilowany w CUPLu. Jak się wczytałem w opis tego JED to kluczowe elementy połączeń makroceli są jednak takie same.
Name ACSI CF ;
PartNo 00 ;
Date 2019-02-26 ;
Revision 01 ;
Designer TzOk ;
Company None ;
Assembly None ;
Location None ;
Device G16V8AS ;
/* *************** INPUT PINS *********************/
PIN 1 = A1 ; /* */
PIN 2 = CS ; /* */
PIN 3 = RW ; /* */
PIN 4 = ACK ; /* First 4 lines from ACSI bus */
PIN 5 = IRQ ; /* from IDE - just to invert it */
PIN 6 = DMAON ; /* Latch */
PIN 7 = DMARW ; /* Latch */
PIN 8 = DMARQ ; /* From IDE - active HIGH */
PIN 9 = RESET ; /* From ACSI - latch init */
PIN 11 = ENABL ; /* Latch bit 7 - 0 DISABLED */
PIN 12 = MONOST ; /* Trgd' by ACK - tw~180ns */
/* *************** OUTPUT PINS *********************/
PIN 13 = IRQA ; /* To ACSI via diode */
PIN 15 = DRQA ; /* To ACSI via diode */
PIN 17 = IORD ; /* ToIDE */
PIN 18 = IOWR ; /* To IDE */
PIN 19 = LAC ; /* Need rising pulse for '574 write*/
/* *************** BOOLEAN-EQUATIONS *********************/
LAC = !A1 & !CS & !RW & RESET; /* raising pulse for latch set */
/* Reset signal because it sets by power on, it seems */
!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 ;
!DRQA = DMARQ & ACK & ENABL ; /* Very fast work - off when ACK activates. 2 MB/sec peak ! */
!IRQA = IRQ ; /* Invert it - need via diode to ACSI */
No i jeszcze w STe mam "bad-DMA" (-38) ale mam też 68HC000 i TOS w kościach Flash. STf jest mniej więcej w oryginalne (tylko recap i niefabryczne PSU).
Odczyt jest na poziomie 1800kB/s
Karta jak na zdjęciu:
GAL16V8-35LP (Lattice)
DM74LS221N (National Semiconductor)
SN74HCT574N (Texas Instruments)
GAL zaprogramowany moim wsadem "skompilowanym" pod WinCUPL. Wynikowy plik JED jest inny niż ten od Putnika.
Mój:
CUPL(WM) 5.0a Serial# 60008009
Device g16v8as Library DLIB-h-40-2
Created Sun Mar 03 15:41:56 2019
Name ACSI CF
Partno 00
Revision 01
Date 2019-02-26
Designer TzOk
Company None
Assembly None
Location None
*QP20
*QF2194
*G0
*F0
*L00000 10101011111111111111111111110111
*L00256 10011011111111111111111111111101
*L00288 11111111101111111011101101011101
*L00512 10010111111111111111111111111101
*L00544 11111111101111111011011101011101
*L01024 11111111011111111111111101111101
*L01536 11111111111101111111111111111111
*L02048 10000000001100000011000000100000
*L02112 00000000000101011111111111111111
*L02144 11111111111111111111111111111111
*L02176 111111111111111110
*C2298
*A245
Putnika:
25.09.2010, 10:15:56
ACSICF5.GAL assembled to ACSICF5.JED
with GAL-Assembler V1.2, (c) May 17 1992 by Ulrich Hack *
F0 *
N pin 19 = 'LAC' = function19 *
L0000 1010 1011 1111 1111 1111 1111 1111 0111 *
N pin 18 = 'IOWR' = /function18 *
L0256 1001 1011 1111 1111 1111 1111 1111 1101 *
L0288 1111 1111 1011 1111 1011 1011 0101 1101 *
N pin 17 = 'IORD' = /function17 *
L0512 1001 0111 1111 1111 1111 1111 1111 1101 *
L0544 1111 1111 1011 1111 1011 0111 0101 1101 *
N pin 16: not connected *
N pin 15 = 'DRQA' = /function15 *
L1024 1111 1111 0111 1111 1111 1111 0111 1101 *
N pin 14: not connected *
N pin 13 = 'IRQA' = /function13 *
L1536 1111 1111 1111 0111 1111 1111 1111 1111 *
N pin 12 = 'MONOST' = function12 *
N XOR(19..12) bits: *
L2048 10010101 *
N user ID: "ACSICF05" *
L2056 01000001010000110101001101001001
01000011010001100011000000110101 *
N AC1(19..12) bits: *
L2120 00010101 *
N enable product terms: *
L2128 11111111111111111111111111111111
11111111111111111111111111111111 *
N SYN bit: *
L2192 1 *
N AC0 bit: *
L2193 0 *
0000
Karta dotarła, nie zwróciłem na to nawet wcześniej uwagi ale to jest SanDisk Ultra, a nie Ultra II... niemniej działa. Nie testowałem jeszcze zapisu, ale uruchomiłem kilka demek i chodzą bez problemu, w tym Bad Apple, które stawia wysokie wymagania kontrolerom pamięci masowej - działa bez zająknięcia.
Mq napisał/a:teraz robię kosmetykę, wybielam obudowę etc. Następnie będę w nadchodzącym tygodniu rozszerzał pamięć, już trochę pod nią rozgrzebałem płytę, więc Atari na ten moment jest nieuruchamialne.
Hehe... poprawka w następnym tygodniu to będziesz malował obudowę, bo jeszcze nie widziałem, żeby komuś ładnie wyszło wybielanie obudowy z ST ;)
Pierwsza rzecz jaka rzuca mi się w oczy to w na Atarowych schematach SH/MegaFile między liniami D0..D7 portu ACSI a wewnętrzną magistralą danych są rezystory 100R. W tej (i nie tylko tej) przejściówce ich brakuje.
W egzemplarzu z Twoich zdjęć siedzi GAL16V8B-7LP, czyli jeden z najszybszych jakie są (a raczej były) - 7ns.
Problemem tego interfejsu jest niestety uruchamianie go... nad nim trzeba odczyniać jakieś czary, żeby ruszył z konkretnym egzemplarzem ST. Na STf "prawie" mi działa, na STe powoduje natychmiastowe wysypanie się DMA. Jak będę miał właściwą kartę to będę kontynuował eksperymenty. Swoją drogą czy on czasem nie powinien się przełączać w inny tryb (PIO) po włożeniu karty, która nie obsługuje 8-bit DMA?
Dzięki uprzejmości kolegi Mq wszedłem w posiadanie płytki jego projektu do interfejsu ACSI-CF autorstwa Petera Putnika (http://atari.8bitchip.info/acsicfs.html). Jest to podobno najszybsza istniejąca pamięć masowa dołączana do ST przez port ACSI. Miałem się zabrać za montaż w wakacje ale jakoś nie wytrzymałem...
Interfejs z tą kartą nie działa i nie ma szans działać (działa tylko z kartami SanDisk Ultra II) ale ją wykrywa. Potrzebna karta już do mnie jedzie...
P.S.
Zasilanie jest podpięte dobrze, tylko tak jakoś wyszło, że czerwony kabelek to... minus, a czarny to plus :/ ostatnio z samymi Spectrumami i Timeksami grzebałem i jakoś tak mi się podłączyło.
Rozszerzenie zakładane na Shiftera... ale ceny to Exxos ma z kosmosu.
Tylko nie kupuj byle czego, bo te co tam siedzą wcale takie najgorsze nie są i najtańsza chińszczyzna prosto ze sklepu może mieć gorsze parametry niż te dwudziestoparoletnie które tam są. Wszystkie po stronie wtórnej Low ESR na 105°C i jakiegoś przyzwoitego producenta, jak Rubycon, Jamicon albo lepiej Sanyo, Vishay, Nichicon.
To zabrudzenie, nie korozja. Na ile byłem ją w stanie sprawdzić, nie mając Atari 400 to wygląda, że jest sprawna.
Znalezione posty [ 1,226 do 1,250 z 1,467 ]
Forum oparte o: PunBB
Currently installed 7 official extensions. Copyright © 2003–2009 PunBB.
Wygenerowano w 0.059 sekund, wykonano 30 zapytań
