951

(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 ?

952

(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

953

(251 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?

954

(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

955

(22 odpowiedzi, napisanych Zloty)

jeszcze raz - sto lat @innuendo

956

(19 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 ;)

957

(22 odpowiedzi, napisanych Zloty)

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

958

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

959

(22 odpowiedzi, napisanych Zloty)

będę koło 15:30

960

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

961

(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

963

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

964

(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/

965

(0 odpowiedzi, napisanych Bałagan)

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

966

(19 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.

967

(19 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.

968

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

sqward napisał/a:

Wszystko rozbija się o brak software-u.

jeśli oprogramowanie Audio korzysta z funkcji systemu operacyjnego a nie z rejestrów sprzętowych to powinno zadziałać zarówno na Falconie jak i na Startracku. Oba mają zgodne ze sobą DSP.
Właśnie rzuciłem okiem na LODy Startracka (kod efektów dla DSP), no i kod (instrukcje assemblera) wygląda tak jak na Falconie, używa tych samych przerwań, w taki sam sposób wysyła i odbiera dane.

969

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

saulot napisał/a:

Jeżeli to będzie plug&play i współdziałało z dsp to biorę to w każdej ilości ;-).

jakiś czas temu nie działał za dobrze z DSP, ostatnio autor znalazł błąd i teraz ponoć jest git

970

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

w latach '90 miałem fajną kolorową ulotkę karty dźwiękowej do Atari, chyba właśnie StarTrack (a a może Deesee) z DSP56002


StarTrack wygląda mocarnie: DSP56002 66MHz i 128k słowa SRAM.

971

(8 odpowiedzi, napisanych Bałagan)

Adam, nie pamiętam ale chyba karta Fibre Channel do serwerów kasetowych

972

(8 odpowiedzi, napisanych Bałagan)

@tOri ładny no i ma parę fajnych wbudowanych funkcji: https://datasheet.octopart.com/MC68EN36 … 123288.pdf
Nie chciałbyś zrobić adaptera tego procka do ST? ;)

Ten MC68332ACFC20 też ciekawie wygląda:
https://pdf1.alldatasheet.com/datasheet … CFC20.html

973

(8 odpowiedzi, napisanych Bałagan)

dzięki @tOri
Ja mam kartę z MC68EN360RC25K
http://www.atari.org.pl/forum/misc.php?action=pun_attachment&item=8549

@saulot dzięki za link, z tym że oryginalną wersję mam w PDF,
Do polskiej wersji mam sentyment, gdyż dzięki niej wszedłem w asembler 68000 i duże Atari.

@uicr0Bee
chodził mi o polską wersję bo jest ona troszkę inna, na końcu ma wydruk kodu źródłowego TOS (część uruchamiająca komuputer)
Dodatkowo jest po polsku no i taką mam papierową.


Swoją drogą dobra robota @saulot, @uicr0Bee !