Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
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
4th Atari ASCII Compo - wyniki Dostępne są już wyniki tegorocznego ATASCII Compo.
thing neo 1.60 Olivier Landemarre wydał nową wersję desktopu Thing.
VIII. Basque Tournament of Atari 2600 Kolejna relacja, wśród otrzymywanych od naszego przyjaciela Egoitza z Kraju Basków.
atari.area forum » Fabryka - 8bit » YAMari
Strony Poprzednia 1 2 3 4 5 Następna
Zaloguj się lub zarejestruj by napisać odpowiedź
Planuję sprokurować sobie bo właściwie nic nie jest przelotowe. To chyba powinny być same druty, z tego co się orientuję. Ewentualnie jakiś bufor dla bezpieczeństwa. Nie sprawdzałem czy gniazdo carta na KMK działa jeśli go używam przez PBI (bo mam XL akurat).
Ogólnie zaczyna się dość tłoczno robić.
Mamy 2 rodzaje rozszerzeń:
- montowane do środka
- dołączane z zewnątrz w postaci cartridge
Obszary adresowe (szczególnie cartów) lubią się pokrywać.
Czy istniałaby możliwość zaprojektowania takiego urządzenia, które pozwalałoby przemapowywać obszary adresowe dla urządzeń?
Pośredniczyłoby ono w komunikacji między rozszerzeniami a szyną Atari.
Zalety takiego rozwiązania:
- konstruktorzy rozszerzeń nie muszą się martwić o obszar adresowy - każde rozszerzenie może być projektowane tak, jakby istniało samodzielnie w gołym Atari, bo i tak obszary mapowane byłyby przez to nasze proxy
- carty mogłyby być nieprzelotowe
- w jednym Atari można by naraz podłączać wiele różnych rozszerzeń bez bólu "a czy mi się z czymś nie pogryzie".
Ja takie proxy widziałbym tak:
- mamy pełny 2K obszar adresowy $D000..$D7FF
- mamy n slotów na rozszerzenia (carty czy wbudowywane do środka - to z mojego punktu widzenia nie ma znaczenia)
- każdy bajt w obszarze $D000..$D7FF mogę sobie zamapować na adres w danym slocie
- z poziomu konfiguratora można byłoby w locie połączać dane rozszerzenie/cart lub odłączać
Mógłbym się podjąć napisania konfiguratora (nawet okienkowego :P) do czegoś takiego.
Miło byłoby również mieć możliwość przypisania jakiegoś ID do urządzenia, żeby można było dość łatwo (od strony oprogramowania) zorientować się gdzie mamy skonfigurowane konkretne urządzenie.
Zdaje się, że podobne funkcje ma już Ultimate (ROMy, konfiguracja adresów VBXE i Covox). Może warto by z takim czymś pożenić jeszcze to: http://www.atari.org.pl/forum/viewtopic … 45#p203245 ?
Taka koncepcja stoi za PBI: mamy obszar $d100-$d1fx oraz ewentualnie (zależnie od wersji doca) $d600-$d7ff przeznaczony dla urządzeń, których można mieć na raz osiem, ale w wymienionych miejscach widać tylko to, co jest wybrane w danym momencie (albo nic, jeśli nic nie jest wybrane).
Stąd też pomysły na rozgałęziacze do kart PBI (czyli "1090"). Ogólnie koncepcja z roku 1983, wiecznie żywa.
Z podobnym potraktowaniem całego obszaru $d000-$d7ff jest jedynie (wydaje mi się) ten problem, że spod $d400-$d4ff nie pozbędziesz się Antica bez użycia przecinaka.
Zaczyna się dziać... Ale niestety tak łatwo się nie da tego zrobić - o ile się w ogóle da :) Tak sobie nad tym myślę. Przede wszystkim jest bardzo poważny problem z niepełnym dekodowaniem I/O. To bez przebudowy komputera jest bardzo trudne do ominięcia. Duża rzecz. Raczej bym się za to nie wziął - tak szczerze... Co do obszarów dla rozszerzeń wewnętrznych - już dla A800XL mam przygotowany układ i PCB z dekodowaniem bloków w obszarach $D2XX i $D3XX ale to wiąże się trochę z lutowaniem i przecinaniem ścieżek... Czyli zupełnie w inną stronę niż myślisz - ale to prostsza droga.
drac030 - PBI - OK ale te rozszerzenia muszą być dosyć "inteligentne"
Rozumiem. Nie upieram się przy $D4, ogólnie chodzi mi o to, żeby nie nastręczać konstruktorom nowych urządzeń kłopotów, lecz jednak zrobić proxy, które pozwoli współdziałać nowym (i starym) rozszerzeniom nie projektowanym jako NewDevices.
Edit: Pod "slotami" nie kryje się u mnie poszatkowanie I/O po $20 bajtów, bo są rozzerzenia, jak COVOX, które wykorzsytują raptem 4 bajty, a inne z kolei potrzebują pół strony. Chciałbym, żeby to było dość elastyczne.
Doce od PBI, które mamy po Atari, pochodzą, wydaje mi się, z różnych etapów prac koncepcyjnych i "dzięki" temu są między sobą miejscami sprzeczne. Jasne jest, że lepiej mieć dla siebie całą stronę $d1 (albo przynajmniej pół), niż gnieździć się na niej z wiadrem innych urządzeń, które na dodatek nie istnieją :)
W każdym razie dotychczasowy uzus jest taki, że 1 urządzenie PBI ma dla siebie całą stronę $d1 oprócz może ostatnich 16-32 bajtów, gdzie są rejestry sterujące całością (typu $d1ff & co.)
Dla takiego Covoxa to mało atrakcyjne rozwiązanie, bo znikałby podczas I/O. Stąd pewnie pomysły na poszatkowanie stron $d6-$d7 na stałe "sloty": 32 bajty dla urządzenia nr 0, 32 bajty dla urządzenia nr 1 itd.
Na początek myślę że fajnie by było mapować carta w obrębie $D5xx :) Np. takiego jak YAMari podpiętego pod $D500 przesunąć na atari np. pod $D520. To się chyba powinno dać prostym switchowaniem linii adresowych załatwić?
Niestety - przynajmniej trzeba użyć dekodera 74HCT138 i na niego wpiąć sygnał CCTL ponieważ nawet gdy zmieni się linie adresowe dla YAMari i rejestry znajda się pod, np. $D520 to i tak gdy nastąpi choćby wywołanie adresu $D500 - nastąpi select układu YMF262, ponieważ CCTL jest wpięty bezpośrednio w Yamahę...
OK. Zrobię to, czyli siądę, dodam dekoder, zmienię PCB, zbuduje moduł i powinno być dobrze zamiast przełączalnych zworek dam choćby dip-switch 8, którym będzie można zmienić blok adresowy. Zajmie mi to trochę ale przynajmniej będzie już dosyć rozsądnie...
Pozdrawiam
Dodałem dekoder, który dzieli obszar $D5XX na bloki po $20 bajtów. Switch 8 pozycyjny dostępny po rozkręceniu carta. Podejrzewam, że nieczęsto będą zmieniane adresy, więc zrobiłem to w ten sposób. Druga sprawa to taka, że TYLKO JEDEN z 8 przełączników może być włączony. Jeśli zostaną włączone dwa bądź więcej - może to być szkodliwe dla układu '138 (zwarcie wyjść). Zastosowanie diod na wyjściach z przełącznika usunęłoby to niebezpieczeństwo ale nie widzę sensu pchania coraz większej liczby elementów. Kupię zaraz switche w necie i gdy je dostanę - zrobię PCB i zmontuję taką wersję...
od strony programisty można będzie wykryć gdzie ta YAMari leży?
To przełącznik obrotowy może, w IDE Plus 2.0 ver D jest takowy.
Tego rodzaju.
od strony programisty można będzie wykryć gdzie ta YAMari leży?
O to by było bardzo miłe.
od strony programisty można będzie wykryć gdzie ta YAMari leży?
Tak - da się. Jest procedura testu obecności chipa OPL. Program w Basicu jest u mnie na stronie OPLTEST.BAS. Opis procedury jest w pliku pod linkiem Programming the AdLib/Sound Blaster FM Music Chips - na końcu tekstu.
To przełącznik obrotowy może, w IDE Plus 2.0 ver D jest takowy.
To jest możliwe ale jedynie w połączeniu z komparatorem binarnym. To co podałeś w linku to przykład kodera Binary decimal. Z jednej strony podajesz adresy z linii A5, A6, A7 a z drugiej strony ustawiasz binarnie żądaną kombinację stanów. Gdy stany na liniach adresowych będą takie same jak nastawione koderem - wtedy komparator wygeneruje CHIP SELECT dla układu, który tego potrzebuje. To trochę inny wariant mojej modyfikacji zainspirowanej pomysłem wieczora - nie wiem czy akurat lepszy - w sumie też potrzebuje dodatkowych elementów tyle, że eliminuje pewne ryzyko związane z przełącznikiem 8-pozycyjnym - jest trochę bardziej złożony niż sam dekoder 74HCT138. Tak jak napisałem wcześniej - zmiana adresów jest tak rzadką potrzebą, że w wielu przypadkach raz ustawione - nigdy więcej się nie zmienią. Owszem - w egzemplarzach testowych takie coś jest bardzo przydatne dlatego też wprowadziłem zmiany i zrobię carty z możliwością zmiany adresu. Teraz czekam na elementy bo bez nich trudno cokolwiek na PCB zmieniać.
Pozdrawiam
P.S. OK - przemyślę zarówno Cartridge Port Expander jak i bufory dla nowego 1090. W miarę wolnego czasu. Najpierw dokończę YAMari, później przysiądę nad SIDari - bo też trzeba skończyć, a potem zobaczymy :) W razie gdy będę już miał jakieś wieści - dam znać a forum raczy się wypowiedzieć.
P.P.S. @mono - tak sobie rozmyślałem i doszedłem do wniosku, że czegoś takiego jak opisujesz nie da się w Atari zrobić. Po prostu... Niepełne adresowanie ubija same podstawy. W zasadzie do dyspozycji masz obszar $D5XX i koniec. Bez przeróbek sprzętowych można by wykorzystać $D1XX,$D6XX,$D7XX ale to miejsca dla NevDev i tak lepiej tego nie umartwiać. System jest tak skonstruowany, że w danym momencie w konkretny obszar może być włączone JEDNO urządzenie. Np. może być obecny wyłącznie jeden cart, może by dało się odpalić cart lewy 8kB i cart prawy 8kB ale to byłoby do sprawdzenia. Każde urządzenie może być robione np. pod $D500 ale w Atari muszą być widziane pod różniącymi się adresami i tak też adresowane. najlepszym rozwiązaniem zaś byłoby ustawianie obszaru DIP switchem na rozszerzeniu - tak jak kiedys na PC... Za jakiś czas powinienem przedstawić propozycję takiego extendera, który będzie robił przynajmniej za rozdzielacz cartów. proszę o cierpliwość :)
Trochę się wtrącę. (To z racji że tematem się zainteresowałem, poświęcając mu nieco czasu, ale wiadomo, nie mam "tych" umiejętności, żeby takiemu projektowi "dać radę" w pojedynkę, zakładając w ogóle, że jest do zrobienia.)
Mam taką zasadniczą uwagę:
Muzyczki wydają się niewielkie, ale z dokumentacji na temat formatu A2M wynika, że obszar pamięci na którym rozlokowywane są dane po wstępnym rozpakowaniu pliku z tej postaci, jest wielkości grubo ponad możliwości Atari (także rozbudowane o dodatkową pamięć).
Z dokumentu (http://adlibtracker.net/files/techinfo.htm) wychodzi, że to 1137182 bajty (~ 1.0845 MB) dla ostatniej (11) wersji A2M.
Wolałbym jednak żeby ktoś to zweryfikował, bo, rzeczywiście, dysproporcja między wielkościami pliku w tym formacie, a obszaru pamięci, jaki jest przewidziany do jego przyjęcia, jest drastyczna.
Cześć,
No - niestety ale Adlibtracker2 wrzuca masę swoich "efektów", także zapewne dane potrzebne na song oraz patterny są sporej wielkości.
Może lepiej odstawić A2M i spróbować z czymś prostszym - nie wiem jak to jest z plikami HSC ale to może być skromniejsze w wymiarach. Są także inne formaty.
Na Pigwie jest kolekcja plików. Nie mogę znaleźć opisu formatów ale przyznam, że na siłę nie szukałem. Podejrzewam, że opisy formatów mogą być zawarte w dokumentacjach playerów-trackerów....
ftp://ftp.pigwa.net/stuff/mirror/chiptune.de/adlib/
Może tak wielkie obszary są rezerwowane dla maksymalnych możliwości AT2?
Pozdrawiam
T0RI: Ja chcem kupic 4x YAMARI!
Som zo Slovacie! Komponujem na Adlibtrackery!
No to widzę, że interes się kręci :)
No to widzę, że interes się kręci :)
Ano właśnie że nie :(
Nie mam czasu na zajmowanie się produkcją. Dlatego też w zasadzie wszystko co robię czy wymyślam udostępniam jako otwarty projekt. Musiałem tinctu odmówić...
Obecnie składam 4 cartridge testowe dla koderów, którzy chcieliby podjąć się napisania softu dla nowego muzycznego pudełka (jeden już jest zarezerwowany). Za jakieś 2 tygodnie powinienem mieć carty gotowe i przetestowane. Pytanie czy znajdą się jeszcze chętni aby powalczyć z OPL3 na Atari :)
Poza tym ciągnę jeszcze inne projekty... i czasami, tak przed spaniem, wpadnę na forum, hehe.
Pozdrawiam
Witam,
UPDATE YAMari i zakończenie tworzenia części sprzętowej.
Na stronie zamieściłem wersję, w której jest możliwość ustawienia adresu w obszarze $D5XX co $20 bajtów. Takie rozwiązanie pozwoli na współistnienie z innymi rozszerzeniami o ile te również będą pilnowały swoich obszarów I/O.
TERAZ WAŻNE PYTANIE:
Czy znajdzie się jeden, dwóch albo trzech koderów chcących napisać coś użytecznego dla YAMari? Np. edytor instrumentów albo player jakiegoś popularnego i niezbyt złożonego formatu dla AdLiba?
Dla chętnych będę miał trzy egzemplarze testowe. Kontakt -> PM
Pozdrawiam
Ja bym był na przykład chętny do jakiejś kooperacji z innymi koderami w tym zadaniu, gdyby znaleźli się inni.
Podział obowiązków, jakiś szef projektu, który by koncepcyjnie całość ogarniał i rozdzielał zadania, oraz testował na sprzęcie. Może tak dało by się taki, jednak złożony, projekt skutecznie zrealizować.
Nie wszyscy rozwijający soft musieliby mieć odpowiednie rozszerzenie w takiej sytuacji, tym bardziej że nie wszyscy pewnie potencjalni koderzy mają w dyspozycji działające Atari, bo zadawalają się zwyczajnie emulacją (mój przypadek).
Z mojej perspektywy, player do A2M to ambitne, ale może do zrealizowania, zadanie. Głównie z tego powodu, że jest kod źródłowy. Jest jego sporo i zmieszczenie tego w pamięci Atari razem z danymi modułu, byłoby poważnym wyzwaniem, ale mam wrażenie (a bardziej zgaduję) że da się to zrobić.
Natomiast co do tego w czym mógłbym pomóc teraz już konkretnie ze spraw szczegółowych, to wydaje mi się, że to moduł obliczający/ sprawdzający sumę kontrolną (crc-32) - chociaż to zadanie które można uznać za "nadobowiązkowe" -, depacker apacka, stosowany w późniejszych wersjach formatu a2m (9-11). Kod depackera jest akurat przy podobno względnie dobrej wydajności, mniej złożony, więc to nie jest duże zadanie, aczkolwiek warto możliwie starannie się nim zająć, bo tutaj optymalizacja "czasowa" byłaby bardzo na miejscu.
Pomysł na rozwiązanie problemu jaki sygnalizowałem w poprzednim wpisie do tego wątku (czyli tego że obszar zajmowany przez dane muzyczki nie da się wygospodarować w pamięci Atari), można obejść na zasadzie, że odwołania do "symulowanego" obszaru danych (czyli tak jak one są rozmieszczone w kodzie playera na PC, przy obliczaniu dostępu do szczegółowych danych, np. konkretnego instrumentu) byłyby przetwarzane przy pomocy specjalnej tablicy adresów na wskazania odpowiadające tym jakie wynikły przy depakowaniu na Atari (proponowałbym całość danych muzyczek mieścić w obszarze dodatkowych banków pamięci), przy czym wartości powtarzane wielokrotnie (najczęściej 0), które "normalnie" (tzn. na PC) są depakowane w sposób liniowy, jak pozostałe dane, byłyby "sprytnie" "zapamiętywane" w ramach tej tablicy przeliczeń adresów, o której pisałem wcześniej.
To wszystko co "wymyśliłem". Liczę na jakieś luźne, niezobowiązujące komentarze koderów, którzy z ciekawości "rzucili okiem" na kod playera do A2M i pewnie mogą mieć jakieś własne spostrzeżenia.
nie powinniście publicznie tego roztrząsać, bo po przeczytaniu tego ktoś może sobie wyobrazić już teraz 100% zajętości CPU 6502, dodatkowe banki pamięci na moduł (Avery/Altirra już odpadł w przedbiegach)
Ja osobiście jestem w stanie wyobrazić sobie player pomijający te problemy. PCtowy jest mocno nieoptymalny pod kątem zajętości pamięci, tylko tam nie jest to problem. Zamiast czytać kod playera, trzeba wrócić do źródła, czyli opisu formatu. Poza tym zamiast używać A2M lepiej jest użyć A2T.
@marok - ale żywe Atari to jest lepsza jazda :)
Player jak player ale można spróbować stworzenia czegoś tylko dla Atari+YAMari. Jak pisze wieczor soft na PC to nie jest wiracha optymalności ale ze źródeł warto skorzystać, choćby i BASICowych ;-)
Ja w każdym bądź razie czekam na chętnych podjęcia się zadania. Po stworzeniu jakiegoś fajnego i stosowalnego kodu YAMari rzecz jasna pozostaje u twórcy oprogramowania. Choć tyle mogę dać...
Na AA kolega ze Słowacji już zarzucił temat i jest jakieś zainteresowanie - może i gdzieś indziej ludzie spróbują? FM nie gryzie, hehe...
Pozdrawiam
Ja mogę, jeśli trzeba, udostępnić koderowi fabryczne syntezatory Yamahy oraz "pośrednika" MIDI dla Atari. Dodatkowo sprzętowe MIDI efekty Yamahy - np SPX1000 oraz wypożyczę dla tegoż np. MG12/4FX do kompletu z kablami wedle życzenia.
Bo temat jest rozwojowy.
Edycja: upraszam twórcę - rób karty. Olej karrtidże.
Od lat wiemy, że nie zdaje to egzaminu.
Po grzyba robić kartridże? Tylko dla kaski. Małej kaski. Tymczasowej.
Co z tego że mam SIDE? Dla mnie fajne. Ale niestety nic więcej nie podłącze, bo ciągle konflikty jakieś.
Kartridże tylko do gier i bzdetów.
Jestem za! kontynuacją wizji inżynierów Atari.
Witam,
Ja mogę, jeśli trzeba, udostępnić koderowi fabryczne syntezatory Yamahy oraz "pośrednika" MIDI dla Atari. Dodatkowo sprzętowe MIDI efekty Yamahy - np SPX1000 oraz wypożyczę dla tegoż np. MG12/4FX do kompletu z kablami wedle życzenia.
Bo temat jest rozwojowy.
Edycja: upraszam twórcę - rób karty. Olej karrtidże.
Od lat wiemy, że nie zdaje to egzaminu.
Po grzyba robić kartridże? Tylko dla kaski. Małej kaski. Tymczasowej.
Co z tego że mam SIDE? Dla mnie fajne. Ale niestety nic więcej nie podłącze, bo ciągle konflikty jakieś.
Kartridże tylko do gier i bzdetów.
Jestem za! kontynuacją wizji inżynierów Atari.
Napiszę tak: Możliwe jest jak najbardziej tworzenie Nowych Urządzeń ale jest jeden poważny problem - oprogramowanie :( Popatrz, że nawet w przypadku YAMari trochę czasu minie zanim pojawi się coś użytecznego. Sam hardware to naprawdę mniejsza część każdego projektu. Kto napisze handlery?
Zobaczymy za jakiś czas. Ja osobiście nie mówię teraz tak czy nie. Na razie siedzę też nad innymi sprawami a i praca zostawia mi malutko czasu na "życie po pracy".
Pozdrawiam
Nie ma demo YAMari ale wystarczy, że odpalisz na PC któryś z trackerów z tej stronki http://adlib.wave460.net/trackers.html i będziesz wiedział co to jest i co może :)
TSFM_Tracker to jest spectrumowy tracker dla urządzeń z TurboSoundFM (dosyć ubogi, bo ma jedynie 6 kanałów), skąd płyną dwa wnioski:
- rozumiem, że ta karta ma na pokładzie 6 kanałów FM?
- spectrumowskiej muzyki na TSFM jest bardzo wiele, byłoby skąd konwertować utwory do testowania. Zakładam, że na tej karcie będą brzmiały tak samo?
_________EDIT____________
To w ogóle jest robota Shiru. Tak więc, skoro zostały przeportowane na XL jego wszystkie programy beeperowe, to już wiadomo, do kogo uderzyć, by portował i te drivery. Czyli do XXL. ;)
O ile kawałki brzmiałyby tak samo, oczywiście.
Strony Poprzednia 1 2 3 4 5 Następna
Zaloguj się lub zarejestruj by napisać odpowiedź
atari.area forum » Fabryka - 8bit » YAMari
Wygenerowano w 0.039 sekund, wykonano 68 zapytań