długość kabla DMA może mieć wpływ na działanie karty ISA przez VOFA w ST:
Otóż o linia RESET w ACSI nie jest buforowana więc długość kabla ACSI może wpłynąć na sygnał RESET w porcie ISA:
https://www.atari-forum.com/viewtopic.p … mp;t=41428
Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
Fujisan 1.1.8 Nowa wersja emulatora Fujisan przynosi wsparcie dla FastBasic oraz poprawki błędów w obsłudze dźwięku.
Wyniki 24h Compo: System Error Poznaliśmy zwycięzców 24h Compo: System Error.
Gearlynx 1.2.1 Gearlynx to wieloplatformowy emulator konsoli Atari Lynx, który właśnie doczekał się ważnych poprawek.
II. Baskijski Turniej Atari 8-bit Relacja z drugiej edycji retro zawodów Atari 8-bit zorganizowanych przez Euskal Retro w Bilbao.
Fujisan 1.1.7 Najnowsze wydanie Fujisan przynosi poprawki dla FujiNet oraz nowe funkcje sterowania emulacją.
atari.area forum » Posty przez Cyprian
długość kabla DMA może mieć wpływ na działanie karty ISA przez VOFA w ST:
Otóż o linia RESET w ACSI nie jest buforowana więc długość kabla ACSI może wpłynąć na sygnał RESET w porcie ISA:
https://www.atari-forum.com/viewtopic.p … mp;t=41428
na 68000 jest wersja MiNT bez obsługi MMU, chyba "MINTNP".
Może ona zadziałav poprawnie?
@artik-wroc
na dzień dziejszy temat wygląda dobrze, mam odpowiednie źródła, mam wiedzę, teraz muszę siąść i przetestować w praktyce MMU.
Kroll ma wszystko albo i więcej :)
nice idea, I'll try join the call
@artik-wroc Spokojnie, mogę to ogarnąć. Na kiedy to potrzebujesz?
MMU2.pdf - to jest z Profibuch?
Jeśli chodzi o PMMU.pdf to pierwsza część jest https://mikro.naprvyraz.sk/docs/Coding/ … ie/MMU.TXT a druga skąd (od 16 strony)?
@Kroll, @artik-wroc dzięki za linka,
zdebugowałem i jest to akcesorium dla 68040 które ma inne MMU niż 68030, więc nie da się przenieść kodu i trzeba napisać od nowa.
Sprawdziłem pod Hatari z 68040 i widzę tylko komunikat: "Keine Hades!"
@artik-wroc, mogę spróbować napisać program od przełączania, z tym że MMU znam tylko teoretycznie i do tej pory jeszcze go nie kodowałem więc muszę się w nie wgryźć.
Pod jakimi fizycznymi adresami będą widoczne te trzy porty?
Co to za akcesorium? Masz może jego źródło?
---poprawka---
dobra mam: "MagiCMac Sound Driver v0.97 (MagiCMac, Hades, Aranym) [Nov 23 2003]" https://docs.dev-docs.org/htm/search.php?find=hades
Akcesorium dla Hadesa jest, można tam włączyć jeden z ROMów. Źródeł to raczej nie będzie
masz to akcesorium?
Może da radę je zdeasemblować.
@Adam, jest szansa ale znając moje tempo to na SV 44 :)
@tebe ładnie to wygląda i jest szybkie
@Adam, ten tryb działa i jest tak prosty że nie trzeba żadnej dokumentacji. Nikt z niego jeszcze nie skorzystał bo na TT jest zaledwie parę dem.
Parę lat temu zrobiłem prosty przykład/demo dla zespołu Hatari. W sumie to też dodałem do Hatari obsługę tego trybu "smear"/"samplehold" oraz "hypermono"/"duochrome" (256 odcieni szarości). W międzyczasie Hatari zmieniło metodę renderowania danych, no i muszę te tryby do niej ponownie dostosować: https://hatari.tuxfamily.org/doc/authors.txt
W sumie to obsługuje się go w niemalże identyczny sposób co blitterowe wektory na Amidze - 1) czyszczenie ekranu; 2) rysowanie linii; 3) wypełnianie, ale z pominięciem punktu 3).
Wypełnianie działa per jedna linia, nie zmienia zawartości pamięci RAM, tylko sygnał wysyłany do monitora.
Przykładowo, cała linia wstępnie jest wypełniona wartością 0.
Jeśli ustawiasz piksel x:10 y:10 na kolor o wartości 12, piksel x:110 y:10 na kolor o wartości 5, to układ graficzny dla linii 10, pomiędzy x:10 a x:109 wyświetli linię koloru 12, a od x:110 do końca prawej ramki linię koloru 5.
Czyli z punktu widzenia procesora, rysowanie linii to postawienie dwóch punktów - na początku (w kolorze linii) i na końcu linii (w kolorze tła), oraz upewnienie się że RAM pomiędzy punktami jest wyzerowany.
@tebe fajne video,
Ciekawostką jest to że opisany tam tryb "fill mode" jest też w Atari TT
Jak to wygląda od strony programowej. Chodzi mi o mapowanie, aby adres jednego portu zmapować pod adresem portu ROM ?
tak jak zauważyłeś to mapowanie robi MMU procesora. Trzeba napisać apkę tworzącą nową tablicę MMU albo wykopać istniejącą apkę.
Z tego co widzę "MagiCMac Sound Driver" ma sterowniki dla RoPoCop:
https://didierm.pagesperso-orange.fr/magxsnde.htm
Tutaj jest więcej plików do RoPoCop dla Milana:
https://github.com/mschwingen/milan/tree/main/RoPoCop
Tutaj ciekawy wątek o MMU 68030: https://www.atari-forum.com/viewtopic.php?t=31252
great idea,
What about existing solutions like CosmosEx, which has embedded RPI and supports STinG/STicK (internet access for the ST) https://github.com/atarijookie/ce-atari ?
Cześć,
Najpierw przeprojektowałem interface Pera Putnika wrzucając wszystko do CPLD Xilinx 9536XL. Zdjęcie w załączniku. Wymiary bez wtyku DB19 - około 75mm x 55mm. Jest to wersja, która działała połowicznie. Odczyt działał, zapis - nie. Zacząłem ogarniać temat i po miesiącu rozmyślania znalazłem pomyłki autora, które powodowały te wszystkie opisywane w innych wątkach problemy z błędami kopiowania danych. Do testowania zaprosiłem _tzoka_ (dzięki wielkie za pomoc!) ze względu na to, że mogła powtórzyć się sytuacja gdzie mój interfejs na moim komputerze działa a na innym komputerze - nie działa. _tzok_ dysponuje wersją zaprojektowaną przez Mq - na układzie GAL - tak jak w oryginale.
Finalnie okazało się, że nie jest potrzebny przerzutnik monostabilny 74HCT221 i trzeba było poprawić logikę "zaszytą" w GAL. W moim wariancie na układzie Xilinx naniosłem dokładnie takie same poprawki.
Testy wykonywałem na różnych kartach i na dwóch różnych maszynach.
Karty to oczywiście Sandisk: ULTRA II - 2GB, EXTREME III - 2GB, ULTRA II - 4GB, ULTRA II - 1GB
Na 1040STe TOS 1.62 był kopiowany plik 18MB pomiędzy partycjami C->D->E->F->G->F->E->D->C i po ostatnim kopiowaniu porównywany z oryginałem. Na wszystkich kartach test przeszedł bezbłędnie co oznacza bezproblemową i stabilną pracę interfejsu. Na 1040STFM TOS 1.02 użyłem tylko jednej karty - ULTRA II - 1GB - też wszystko przeszło bezbłędnie.
_tzok_ tak jak i ja nie miał problemów z poprawionym interfejsem na 1040STe. Na 1040STFM miał dużo błędów. Znalazł rozwiązanie w postaci DMA fix zaproponowane przez exxosa. Ale najlepiej będzie gdy sam może o tym napisze. Podejrzewam, że może grać tu także rolę to, że wejścia/wyjścia w moim interfejsie działają na poziomach 5V wejście / 3,3V wyjście i zakłócenia w interfejsie TTL powodują jakieś problemy na szynie danych DMA Atari czego nie ma od strony Xilinxa.
Kończąc - jest jeszcze kilka rzeczy do dogrania. Między innymi z autorem - P.Putnikiem. Myślę, że za jakiś czas będą dostępne PCB tego projektu. Być może zmontowane interfejsy, a i opis powinien pojawić się u mnie na www. Mam na oku obudowę pasującą do projektu więc może być w pełni profesjonalnie :D
Interface osiąga transfery na poziomie 1,8...1,9 MB/s - to rzeczywiście jest "demon szybkości".
Osobiście cieszy mnie, że udało się dorzucić kolejną zabawkę do świata Atari. Przy tej okazji sporo się także nauczyłem siedząc nad Atari DMA (ACSI)
Pozdrawiam
tOri
Pera zrobił ciekawą podstronę o ACSI i DMA: http://atari.8bitchip.info/AcsiDmaExD.html
Wspomina tam że znalazłeś błąd związany z sygnałem DRQ dla ostatnich dwóch bajtów.
Rozwinął byś trochę ten temat? Dzięki
No to już oficjalnie chciałbym się pochwalić powstaniem powiedzmy prototypu nowej płyty Atari ST w formacie ATX:
hej x_angel, co słychać w tym temacie?
Thorsten Otto, bazując na szczątkowych kodach źródłowych odtworzył (dopisał brakujące części) źródła TOS 1.04: https://github.com/th-otto/tos1x
Wcześniej skompletował oryginalne kody źródłowe do TOS 2.06 / 3.06: http://tho-otto.de/download/tos306de.tar.bz2
Po kompilacji Alcyon'em wynik jest binarnie kompatybilny z TOS 1.04 / 2.06 / 3.06
Wcześniej ograniczone zmiany w TOS można było robić TosPatch'em ( https://www.markusheiden.de/atari/tospatch.html ). Teraz whętni mogą sobie przerabiać dowolnie system do Atari.
Więcej tutaj: https://www.atari-forum.com/viewtopic.p … mp;t=41354
-- dopisek 2024.11.16 --
źródła TOS 2.x/3.x
https://github.com/th-otto/tos3x/
Poprawki w części "Patches":
https://www.atariuptodate.de/en/system
jeszcze raz - sto lat @innuendo
Pojawiły się nowe archiwa. Można sobie zrobić PCB :) Są pliki źródłowe.
Arturex, liczymy na Ciebie!
1. Cyprian ;)
za krótko, za mało napojów, no ale fajnie że dotarłeś
Przerwania $0c/$10 są tylko do wysyłania danych przez SSI do odbiorcy (SDMA albo CODEC).
do odbierania i wysyłania przez SSI mam taki kod:
org $C
jsr SSIRX
org $10
jsr SSITX
SSIRX:
...
movep X:RX,X:(r0)+
...
SSITX:
...
movep Y:(r1)+,X:TX
...SDMA ma dwa tryby przesyłu danych: synchorniczny i z handshakiem. Ostatecznie to się sprowadza do tego, że w synchronicznym dane przepływają z predkością próbkowania (razy ilość kanałów). W przesyle z handshakiem to DSP kontroluje czy chce dostać kolejną porcję danych.
ok, tego mi brakowało - handshake mode. kiedyś nawet o tym słyszałem ale nie dotarłem do działającego przykładu. Masz może link do źródła playera MP2?
Ciekawostką jest to, że Atari w dokumentacji wspomina, że przesył synchroniczny nie gwarantuje bezbłędnego dostarczenia danych. Efekt tego widać w Falcampie, gdzie czasem program się po prostu zawieszał. Player mp2 nigdy nie miał takiego problemu bo używa innego trybu przesyłu danych. Nikogo chyba nie zaskoczy, że problem ten znika całkowicie po instalacji clock patcha? :)
ciekawe.
Próbowałeś może sprawdzić ile maksymalnie można przepchnąć danych w trybie handshake?
Mail wysłany.
będę koło 15:30
napisałbyś coś więcej na ten temat?
Do tej pory miałem jedynie kontakt z odbieraniem / wysyłaniem danych SDMA na przerwaniach SSI - $0C / $10
Rozumiem że trzeba inaczej skonfigurować transfer. Pytanie tylko jak.
Ja też się wybieram.
@as, @PeriNoid będę miał kabelki AVG
@Lizard jeśli się wybierasz to dałbyś radę zabrać śrubki?
Fajna strona z opisami i graficzną prezentacją złączy dla wszystkich modeli Atari 8, 16, 32, 64 bit.
Są tam też opisy różnych przejściówek / kabli:
atari.area forum » Posty przez Cyprian
Wygenerowano w 0.435 sekund, wykonano 9 zapytań