1,226

(29 odpowiedzi, napisanych Sprzęt - 16/32bit)

@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?
http://artik-wroc.pl/pliki/mgx2.jpg

---poprawka---
dobra mam: "MagiCMac Sound Driver v0.97 (MagiCMac, Hades, Aranym) [Nov 23 2003]" https://docs.dev-docs.org/htm/search.php?find=hades

1,227

(29 odpowiedzi, napisanych Sprzęt - 16/32bit)

artik-wroc napisał/a:

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ć.

1,228

(142 odpowiedzi, napisanych Programowanie - 8 bit)

@Adam, jest szansa ale znając moje tempo to na SV 44 :)

1,229

(142 odpowiedzi, napisanych Programowanie - 8 bit)

@tebe ładnie to wygląda i jest szybkie

1,230

(142 odpowiedzi, napisanych Programowanie - 8 bit)

@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).

1,231

(142 odpowiedzi, napisanych Programowanie - 8 bit)

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.

1,232

(142 odpowiedzi, napisanych Programowanie - 8 bit)

@tebe fajne video,
Ciekawostką jest to że opisany tam tryb "fill mode" jest też w Atari TT

1,233

(29 odpowiedzi, napisanych Sprzęt - 16/32bit)

artik-wroc napisał/a:

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

1,234

(2 odpowiedzi, napisanych Fabryka - 16/32bit)

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 ?

1,235

(210 odpowiedzi, napisanych Sprzęt - 16/32bit)

tOri napisał/a:

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

1,236

(253 odpowiedzi, napisanych Fabryka - 16/32bit)

x_angel napisał/a:

No to już oficjalnie chciałbym się pochwalić powstaniem powiedzmy prototypu nowej płyty Atari ST w formacie ATX:
Atari ST ATX

hej x_angel, co słychać w tym temacie?

1,237

(3 odpowiedzi, napisanych Programowanie - 16/32bit)

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

1,238

(22 odpowiedzi, napisanych Zloty)

jeszcze raz - sto lat @innuendo

1,239

(27 odpowiedzi, napisanych Sprzęt - 16/32bit)

artik-wroc napisał/a:

Pojawiły się nowe archiwa. Można sobie zrobić PCB :) Są pliki źródłowe.

Arturex, liczymy na Ciebie!

1. Cyprian ;)

1,240

(22 odpowiedzi, napisanych Zloty)

za krótko, za mało napojów, no ale fajnie że dotarłeś

1,241

(5 odpowiedzi, napisanych Programowanie - 16/32bit)

sqward napisał/a:

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
...
sqward napisał/a:

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?

sqward napisał/a:

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.

1,242

(22 odpowiedzi, napisanych Zloty)

będę koło 15:30

1,243

(5 odpowiedzi, napisanych Programowanie - 16/32bit)

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.

1,244

(22 odpowiedzi, napisanych Zloty)

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:

http://acm.atariportal.cz/index.php

1,246

(5 odpowiedzi, napisanych Programowanie - 16/32bit)

sqward napisał/a:

xxx

Na liści Hatari czytałem że używasz przerwania SCI zsynchronizowanego z SSI.
Ciekawi mnie jakie jest zastosowanie tego przerwania, bo chyba samo SCI nie jest podłączone do niczego w Falconie.

1,247

(13 odpowiedzi, napisanych Kupię / Sprzedam / Zamienię Atari)

Jakby co to jest jeszcze jedno nowe urządzenie do podłączania kart SD do Atari - ACSI2STM
https://atariage.com/forums/topic/31633 ... satandisk/

1,248

(0 odpowiedzi, napisanych Bałagan)

https://www.youtube.com/watch?v=g9HBXHqp-AU

1,249

(27 odpowiedzi, napisanych Sprzęt - 16/32bit)

sqward napisał/a:

To wymień mi jakoś program na Falcona, którzy używa tylko API XBIOS? :)

Dobre pytanie, mentalnie żyję w świecie gdzie programy (nie gry czy dema) używają API a nie rejestrów sprzętowych.
Dla mnie to była zaleta TOS, dzięki której aplikacje niezależnie co jest pod spodem działają na ST / TT/ Falcon / Hades/ Medusa czy Vampire.

API Falcona zostało przeniesione na inne platformy (Aranym, Milan, MagiCMac/PC czy niebawem również Vampire):
https://mikrosk.github.io/xbios/

sqward napisał/a:

Skąd masz informację, że Startrack miał SDMA? Masz jakiegoś linka?

Gwoli ścisłości, SDMA czyli DMA dla audio. Jest też Falconowy Matrix (pewnie by zapewnić zgodność) no i wygląda na to że działają Falconowe urządzenia podłączane do portu DSP.

1) https://web.archive.org/web/20040831024 ... =history12

Die Audiokarte hat bereits alle endgültigen Funktionen enthalten. Sie ist jetzt kompatibel zur Falcon-DMA Matrix und der DSP ist ebenso Falcon-kompatibel in das System integriert. Um alle Möglichkeiten der Hardware nutzen zu können, hat die Audiokarte einen ganzen Haufen unterschiedlicher Betriebsmodi. Da wäre der normale Steromodus bei dem lediglich 2 Kanäle (links/recht) verarbeitet werden, dafür aber bis zu 96kHz und 16 bzw. 24Bit. Man kann wahlweise die analogen und digitalen Anschlüsse parallel betreiben und kommt so auf vier gleichzeitig nutzbare Kanäle. Und natürlich gibt es den Falconmodus für bis zu 8 nutzbare Audiokanäle, die man mit externen Falcon-Audiointerfaces (Analog8 oder JamIn/JamOut) physikalisch über den DSP-Port ausbauen kann.

2) API:
http://toshyp.atari.org/en/004012.html

3) Tak jak wspomniałem LOD StarTraka ma taki sam kod jak ten z Falcona, czyli dane audio odbierane/wysyłane są przy pomocy SSI które w Falconie jest podpięte do DMA (poprzez Matrix).
Oczywiście można założyć że w StarTrak jest inaczej i nie ma DMA. W tym przypadku, każdy sampel musiałby być przekazany do DSP przez procesor co wiązało by się z dużym obciążeniem CPU.

1,250

(27 odpowiedzi, napisanych Sprzęt - 16/32bit)

sqward napisał/a:

Tak, ale Startrack nie ma ma SDMA Falconowego.

Startrack ma API XBIOS w części AUDIO/DSP zgodny z Falconem (sprzętowo ma też SDMA), więc z punktu widzenia aplikacji która używa systemu operacyjnego bez dotykania sprzętu nie powinno mieć znaczenia co jest pod spodem API.

sqward napisał/a:

Pozatym zrobienie czegokolwiek wyrafinowanego/szybkiego na DSP wymaga jechania po rejestrach. Proste efekty, gdzie DSP zarówno próbkuje i wysyła odrazu na przetwornik to jest najbardziej trywialne zastosowanie niestety.

Do obróbki dźwięku wystarczy jedynie szybki kanał DMA z RAM do DSP oraz dostęp do HostPortu DSP.
Ale rozumiem że chodzi o inne zastosowanie niż obróbka audio, np efekty graficzne. No to masz rację, w tym przypadku demo/gra by dotykać bezpośrednio sprzętu musiała by znać architekturę Startrack.