Hej!
Standardowy 8K cart działający w przestrzeni $A000-$BFFF nie wymaga żadnych komponentów oprócz EPROMU odpowiednio połączonego do gniazda cartridge.
pozdrawiam
Seban
Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
Silly Venture 2k25 SE - już wkrótce! Tylko do 21 lipca możesz zamówić koszulkę z okazji SV 2k25 SE
Nowy firmware 1.5 dla SDrive-MAX Ulepszony tryb szybki i poprawki kaset w nowej wersji firmware
Ice-T 2.8.2 Nowa wersja Ice-T dla 8-bitowego Atari już dostępna - poprawki i nowe funkcje
Galactic Panic - nowa przygodówka na ST Darmowa gra point and click na Atari ST - ponad 100 ekranów przygody.
Nowa wersja ARIFE Tool od PVBest73 Uaktualniono uniwersalne narzędzie do analizy obrazów ROM i dysków Atari
atari.area forum » Posty przez seban
Hej!
Standardowy 8K cart działający w przestrzeni $A000-$BFFF nie wymaga żadnych komponentów oprócz EPROMU odpowiednio połączonego do gniazda cartridge.
pozdrawiam
Seban
Hej!
Wydaje mi się iż ktoś próbował to już robić:
http://www.myatari.com/nirdary.html
Modyfikacja polegała na zamianie ANTICA na PAL-owski i podmianie ROM-u na patchowany. Nie wiem jak to działa bez wymiany rezonatorów kwarcowych. Ale podobno działa.
Mam jeszcze jedną wątpliwość... GTIA pozostaje niezmieniona i tworzy się taka hybryda PAL ANTIC + NTSC GTIA. Naprawdę nie wiem jak to może działać :) I jaki de facto jest obraz generowany :)
W dodatku podmiana OSROM nic nie daje dla programów które sprawdzają czy GTIA jest PAL czy NTSC. Tutaj GTIA zwraca iż jest NTSC, ANTIC jest PAL-owski.
Fox wspominał iż jedynym sposobem na wykrycie takiej maszyny jest sprawdzenie do jakiej max. wartości dochodzi licznik w $D40B.
Soft który nie sprawdza na jakiej maszynie chodzi podobno działa, taki co sam wykrywa jakie masz GTIA pisze że masz NTSC. Tak więc jedyny ratunek to "zapatchowanie" takiego programu :)
pozdrawiam
Seban
zyga, dely: faktycznie namieszałem :) Macie racje :)
pozdrawiam
Seban
Zyga, a nie jest odwrotnie? tnz. LOAD "...",8,1 ładuje zawsze pod $0801, a LOAD "...",8 ładuje pod adres wskazany w dwóch pierwszych bajtach?
Co do Atari to jeszcze możesz podejrzeć strukturę pliku, używając programu Jindrich Kubec-ki:
http://jindroush.atari8.info/data/asoft/chkexe_bin.zip
odpalasz chkexe.exe twój_plik.xex i wypluwa na ekran strukturę pliku, dla przykładu jak to wygląda:
chkexe.exe zorro.xex
ChkExe v2.71 (c) 1998-2000 Jindrich Kubec <kubecj@asw.cz>
Binary file: zorro.xex
[0002] Block: 8000-8062 (0063)
[0069] : Unexpected second 0xffff format header
[006B] Block: 4000-49FF (0A00)
[0A6F] Init : 8012
[0A75] : Unexpected second 0xffff format header
[0A77] Block: 4A00-53FF (0A00)
[147B] Init : 8012
[1481] : Unexpected second 0xffff format header
[1483] Block: 5400-5DFF (0A00)
[1E87] Init : 8012
[1E8D] : Unexpected second 0xffff format header
[1E8F] Block: 5E00-67FF (0A00)
[2893] Init : 8012
[2899] : Unexpected second 0xffff format header
[289B] Block: 4000-48FF (0900)
[319F] Init : 8012
[31A5] : Unexpected second 0xffff format header
[31A7] Block: 4900-4EFF (0600)
[37AB] Init : 8012
[37B1] : Unexpected second 0xffff format header
[37B3] Block: 1480-4D7F (3900)
[70B7] : Unexpected second 0xffff format header
[70B9] Block: 5BE8-84E7 (2900)
[99BD] : Unexpected second 0xffff format header
[99BF] Block: 5000-5030 (0031)
[99F4] Run : 5000
Ok!
Bardzo dawno temu (za czasów Code3) napisałem dwa prościutkie tego typu programy dla Atari. FileTracer (FT.COM) oraz Fast FileTracer (FFT.COM). Funkcję spełniały one ta samą, różniły się prędkością działania. Pierwszy czytał analizowany program bajt po bajcie (nie miał dużego zapotrzebowania na pamięć), drugi używał bufora przez co odczyt poszczególnych bloków był szybki - lecz kosztem zajęcia całego RAM od MEMLO to $BC1F.
pozdrawiam
Seban
Jeżeli chodzi o C64 to z tego co pamiętam to program typu .PRG zawsze ale to zawsze ładuje się u nich pod $801, i może mieć maks. rozmiar 38911 bajtów. Programy wykonywalne na commodore muszą udawać program BASIC-owy. Ładowane są BASIC-ową komendą:
LOAD "nazwa",8,1
Każdy program składa się więc z nagłówka identycznego, wskazującego na adres ładowania $0801 (dwa pierwsze bajty), potem następuje kawałek stokenizowanego programu w BASIC-u, najczęściej jest to coś w stylu:
SYS 2069
Na instrukcja pozwala na uruchomienie wczytanego programu od podanego za SYS adresu. Potem już leci program, najczęściej spakowany różnymi cruncherami, packerami. Wydaje mi się iż właśnie przez ograniczenie, iż ładowane programy muszą się mieścić w buforze interpretera BASIC-a na Commodore powstało tyle programów pakujących :)
pozdrawiam
Seban
draco030: naprawdę potrzebujecie flash carta? normalnie bankowanego, np. przełączanego jednym wpisem do wybranego przez was rej. $d5xx? (no może dwoma bajtami jeżeli chcecie więcej niż 128 banków). Jeżeli tak trzeba było mówić ;)
Każdy daje się załadować od czasu do czasu ;) To tylko kwestia kiedy to nastąpi :) Za każdą wtopą człowiek co prawda jest uważniejszy, ale czasami jeszcze udaje się mu coś wkręcić :)
Jak to powiedzieli panowie z kabaretu "Ani Mru Mru":
- to chyba jakiś chiński "chłyt" marketingowy!
- ale "dzjała"
Pajero: ja czytałem ten tutorial: http://www.atarimax.com/flashcart/docum … pter8.html
Z niego wynika że każdy program który dotknie $D301 lub włączy ROM, wymaga modyfikacji aby uruchamiał się z ich carta. Mozolnie opisują super prosty sposób modyfikacji gier BLACK LAMP i Zorro. Dlatego napisałem że to jakiś "żart".
pozdrawiam
Seban
Pajero: dobrze wnioskujesz: 1Mbit to 128K.
wklejam z ich doc-a na WWW:
Capacity
* 1Mbit flash-memory device arranged as 16 banks of 8KB. (1Mb Cartridge)
* 8Mbit of flash-memory arranged as 128 banks of 8KB. (8Mb Cartridge)
16 banków po 8Kbajtów = 128Kbajtów
128 banków po 8Kbajtów = 1Mbajt
Hej!
Obawiam się iż dostaniesz cartridge o pojemności 1Mbajta :) Panowie z ATARI-MAX napisali małymi literkami 8Mbit :) Co daje w efekcie 1Mbajt.
Co do reverse engineering to nie ma czego kopiować, zwykły FLASH, trochę logiki i odpowiedni soft. Wydaje mi się iż napisanie odpowiedniego softu to jedyny problem (czas, czas, czas).
update: przeczytałem "tutorial" jak konwertować gry aby można było je uruchomić z tego carta. To chyba jakiś żart. Żaden normalny użytkownik nie mający choć minimalnego pojęcia o assemblerze 6502 nie poradzi sobie.
Aby być w pełni fair napiszę jeszcze iż być może się uprzedziłem, jakoś nie firma atarimax.com nie zyskała nigdy sympatii w moich oczach. Jakoś za nimi po prostu nie przepadam ;) Oczywiście pełny szacunek ale Stevena J. Tuckera za APE dla DOS. To co wyprodukowali dla Windows zawsze działało mi na nerwy.
[offtopic mode=ON]
Gdy muszę pod Windows SIO emulować to korzystam z atari810, jest darmowy i spełnia moje oczekiwania :) Do pobrania tutaj: http://retrobits.net/atari/atari810.shtml (i na szczęście można wyłączyć ten "skin").
[offtopic mode=OFF]
pozdrawiam
Seban
Meśka co ty miałaś za napis na tej koszulce... na fotkach dostrzegłem jedynie słowo "wyjeb*#*(#". ;)
Wow! Po raz pierwszy zobaczyłem drugi poziom :) Dobrze że w drugim poziomie nie zrobili już czasu w którym trzeba dojechać... to mogłoby już doprowadzić do samobójstw :D
widzę iż bardzo niesympatycznie się ta aukcja zakończyła, szczególnie dla potencjalnych kupujących.
Hej!
Co do DFC (Digital Fine Contrast) i DFI (Digital Fine Image czy Digital Adaptive Fine Image) to nie mam pojęcia jak one działają w przypadku monitorów LG. W polskim czy angielskim wiki na temat DFC piszą jakieś ogólniki, w zasadzie to marketingowy bełkot ( http://pl.wikipedia.org/wiki/Digital_Fine_Contrast ), a o DFI nic praktycznie nie ma. Ale faktem jest iż owe "polepszacze" obrazu mogą człowieka doprowadzić do szału w przypadku sygnału jaki generuje 8-bit ATARI :) Natomiast w przypadku sygnału generowanego przez PC-ta czy nawet wewnętrzny tuner TV nie mogę narzekać owe technologie sprawdzają się doskonale. Nie jestem żadnym profesjonalistą jeżeli chodzi o grafikę i dla mnie monitor z matrycą TFT jest na szczęście wystarczający :)
Ale wracając do tematu i nie wnikając w zasady działania tych technologi widać dokładnie iż układ scalony odpowiedzialny za przetwarzanie wizji robi z sygnałem PAL parę zabiegów które mają spowodować aby taki sygnał wyglądał jako tako na matrycy LCD o dużej rozdzielczości i działającej tylko w trybie progressive, ale w przypadku sygnału z ATARI występują niestety owe efekty uboczne. Procesor wizyjny przetwarzając kolejne klatki obrazu bierze pod uwagę wcześniejsze klatki i stąd zapewne opóźnienie w pokazywanym obrazie.
Oglądając schemat monitora można zauważyć że procesor wizji ma do swojej dyspozycji spory kawałek pamięci SDRAM :) Nie pamiętam już ile konkretnie, ale widać że monitor ostro pracuje nad wizją skoro potrzebuje frame buffera na kilka klatek ;)
Co do uwagi od Piguły:
Masz rację... ja może opisze to na przykładzie ATI All In Wonder 128. W przypadku systemów Win9x, karta ta przy zgrywaniu obrazu tworzyła plik MPG który był typu "interlaced", czyli de facto 50fps. Odtworzenie tego pliku pod tym samym Win9X dawało świetne wrażenie, obraz był dynamiczny i nie było żadnych nieprzyjemnych efektów (może poza delikatnym migotaniem związanym z interlacem). Do tego jeżeli mialo się ustawiony screen refresh na 100Hz... Panowie obraz malina! Karta idealnie synchronizowała się z Vblank, wyświetlała pięknie interlacowany materiał.
Jakież było moje zdziwienie i załamanie gdy po migracji na Win2000 i zainstalowaniu nowych driverów wszystko się zmieniło... materiał z zgrywany kartą miał już 25FPS i był już progressive... no kicha na maksa, obraz stracił na dynamice i kolorach. Drivery już nie mogły sobie pozwolić na wstrzymanie systemu do Vblank, zaczęły robić jakiś durny fatalny w skutkach deinterlaceing. Materiał zgrany wcześniej na Win9x również tracił na jakości i dynamice. Strasznie się wtedy wkurzyłem...
Te zakłócenia o których wspomina Piguła to mogły być efekty nieudolnego softwarowego usuwania interlace, bo takiego formatu obrazu (tylko progressive) wymagał już nowy Windows. Podobno MS wprowadził taki standard obsługi tunerów i streamów video. Nie znam się na tym i mogę powtarzać niechcący jakieś stado bredni... jednak po tym wypadku przeszło mi zamiłowanie do kart serii All In Wonder.
Później ponownie spróbowałem (jak jeszcze miałem monitor CRT) kart ATI opartych o nowe scalaki Rage Theatre 550/650 PRO, ale okazało się iż te karty mimo iż mają obraz całkiem dobrej jakości to w przypadku WinXP mają strasznie duże opóźnienie. Niestety tu znowu MS wymógł na producentach chipsetów do obsługi video aby materiał dostarczany przez kartę był już w formacie MPEG. Tak więc biedne chipy RT 550/650 mają na pokładzie sprzętowy enkoder do formatu MPEG, trochę pamięci SDRAM. Przechwytują klatki, pakują je do bufora a potem już system operacyjny (WinXP) sobie czyta stream przygotowany przez kartę. Efekty uboczne są dwa:
1) opóźnienie od kilku do kilkunastu klatek w pokazywanym obrazie (w przypadku TV nie ma to znaczenia). W przypadku komputera dźwięk i obraz pojawia się z ponad 0,5sek opóźnieniem.
2) mimo ustawienie jakości kompresji na high widać czasami artefakty spowodowane kompresją MPEG :(
W dodatku karta oparta na tym chipsecie nie chciała mi pracować poprawnie z DSCALER-em, jedynie stary poczciwy VirtualDub potrafił z niej pokazywać obraz bez denerwującego opóźnienia. Rozwiązanie takie jednak nie było dla mnie zadowalające i szybko z używania tej karty zrezygnowałem.
Należy jeszcze wspomnieć iż karty te doskonale radzą sobie jako tuner TV czy karta do zgrywania materiału video do postaci cyfrowej. Jednak nie mogę ich polecić jako urządzenie z którym ATARI współpracuje bez zarzutu :( No cóż ale takie rozwiązania narzucił producentom sprzętu Windows Media Center i dla zwykłych użytkowników nie ma to chyba znaczenia. To my dziwacy jesteśmy skazani na efekty uboczne tej technologi :(
W przypadku starego PC-ta pozostałem przy starym Radeonie serii 9250 w wersjo VIVO (ma na pokładzie scalak jeden z pierwszych wersji układów Rage Theatre jeszcze bez kompresji MPEG). W przypadku nowszego zmuszony jestem do używania wejścia S-Video In w monitorze LG. Na szczęście u mnie nie występują efekty które zaprezentował nam kolega Lotharek (mówię o dziwnym zachowaniu się monitora z ATARI)
pozdrawiam
Seban
Lotharek: do LG mam podłączoną moją starą wysłużoną 130XE (Pamięci 8x1bit). Do do efektu który opisujesz to owszem jest obecny. Nawet niekoniecznie przy zmianie trybu graficznego, wystarczy przesunąć kursor w GR.0 aby zaobserwować ten efekt, takie zachowanie to już wina "inteligencji" procesora wizji zaszytego w tym monitorze. Widać to nawet oglądając TV. Obiekty ruchome są dość rozmazane, gdy coś staje się nieruchome układ obrabiający wizję stara się dany fragment wyostrzyć i zniwelować efekt interlace. Ale na taką full automatykę to już nic nie poradzimy chyba :)
Ale to nie jest najbardziej wkurzające, najbardziej wkurzające jest opóźnienie kilku ramek w wyświetlanym przez monitor obrazie. To może doprowadzić do szału w niektórych przypadkach.
pozdrawiam
Seban
Ostatnie pytanie sake: ustawiłeś w dscalerze standard na PAL_B i rozdzielczość 720x576? (po ustawieniu reset card z menu DShow).
Lotherek co ciekawe ja również mam LG 228WA i wszystko działa mi OK! jak to wytłumaczysz? mam zrobić Ci film? (podłączone bezpośrednio do S-video)
I moim zamysłem nie jest negowanie twoich opinii ani doświadczeń, tylko przedstawienie sprawy tak jak wygląda u mnie. Faktem jest że na kartach opartych o conexanta są problemy z wizją... ale nie wiem dokładnie z jakiego powodu... nie posiadam żadnej karty na tym chipsecie. Nie mogę tego sprawdzić.
I dalej się upieram iż comb-filter działa tylko w przypadku sygnału composite-video. Być może moja opinia jest błędna. Jest prawdopodobne iż źle interpretuję fakty... lub o czymś nie wiem, ale wydaje mi się że jeżeli istnieje problem w sygnałem s-video to wina nie leży po stronie tego filtru, tylko raczej czegoś innego.
btw. nie wiem o co my sie sprzeczamy :) rozwiązaniem problemu jest VBXE od Electrona :D Mamy wtedy wyjście RGB i żaden durny dekoder PAL, który źle interpretuje sygnał z Atari nam nie podskoczy :) Należy przyznać iż sygnał generowany przez ATARI jest daleki od norm standardu PAL :) Dawne analogowe dekodery jakoś sobie z nim radziły a dzisiejsze cyfrowe konstrukcje które próbują "ulepszać" otrzymany sygnał video, kończą tak jak to widzimy na załączonych przykładach (zarówno u Sake jak i Lotharka).
Od zawsze używałem kart ATI, i przypomniało mi sie iż miałem na początku "ATI All In Wonder 128" (tam był dekoder video oparty na BT829). I muszę przyznać iż tam obraz to była istna sieka, brak koloru lub kolorowe prążki i inne dziwne efekty. Potem BrookTree nabył Conexant chyba. Widzę że problem z chipsetami BT pozostał i przeniósł się conexanty :)
pozdrawiam
Seban
A ja mam kilka kart z comb-filter i nawet po composite video obraz mam OK (tochę mniej ostry). Co prawda mam tylko karty oparte o układy ATI Theatre oraz Philips SAA. Poza tym jak już mówiłem w przypadku S-Video (oddzielnie chroma + luma) nie ma to żadnego znaczenia comb filter w tym wypadku NIE JEST wykorzystany.
Lotharek: już pierwszy post tego wątku na AAge mówi nieprawdę. GTIA+ANTIC generuje w obu pół-obrazach tą samą zawartość. Nie generuje żadnych pustych/czarnych linii. Jak znajdę trochę więcej czasu to przeczytam cały wątek. Ale post #1 (na AAge) to wierutna bzdura w/g mnie.
pozdrawiam
Seban
hmmm... czyli kabel masz pewnie OK, martwi mnie trochę to zrywanie synchro poziomego... może temu wspaniałemu conexantowi na twojej karcie nie pasuje poziom sygnału podawanego na jego wejście... niestety nie mam nic z chipsetem conexant... tutaj musiał by się wypowiedzieć ktoś kto ma kartę/tuner z tym chipsetem.
Spróbuj jeszcze pobawić się programem dscaler (w wersji 4): http://dscaler.org/downloads.htm zobacz czy będziesz miał podobne efekty.
Hej!
No to jeżeli S-Video to cobm-filter w ogóle nie ma znaczenia czy jest czy nie ma :) Problem musi być gdzie indziej. Jakiego rodzaju kabel zastosowałeś do połączenia Atari z Tunerem? (jakiś kabel w ekranie?)
Hej!
Lotharek o czym Ty mówisz? Nie strasz kolegi Sake... jak to napisałeś "filtr grzebieniowy" (ang. comb filter, więcej info dla zainteresowanych tu: http://en.wikipedia.org/wiki/Comb_filter ), może mieć tylko pozytywny wpływ na jakość obrazu :) Redukując znacznie zakłócenia w obrazie spowodowane nałożeniem na siebie sygnału chrominancji i luminancji. (przykład jest tutaj: http://en.wikipedia.org/wiki/Dot_crawl)
Comb-Filter nie powinien w niczym przeszkadzać, no chyba że implementacja filtra byłby jakaś nieudolna. To co zaprezentował sake (screen shot) może świadczyć co najwyżej o braku tego typu filtra jeżeli już :)
sake napisz proszę dokładniej jaki kabel wykonałeś? to znaczy czy wykonałeś kabel typu composite-video czy s-video (oddzielnie chrominancja i oddzielnie luminancja).
Jeżeli wykonałeś kabelek s-video to w ogóle comb-filter nie bierze udziału w obróbce sygnału, ponieważ mocno upraszczając działa on tylko w przypadku pracy z sygnałem "composite-video".
Na mojej starej karcie ATI ze scalakiem Rage Theatre obraz po s-video wygląda tak:
pozdrawiam
Seban
A gdzie są zdjęcia? ;)
odbiegnę nieco od zasadniczej koncepcji - czy kawałek był konwertowany z .MOD-a i czy w tej sytuacji istnieje w pamięci nazwa tego .MOD-a lub od razu link skąd można go pobrać?
niestety był konwertowany z mod-a i jest w wewnętrznym formacie playera SoTe. Jeżeli bym pamiętał tytuł pliku .MOD od razu bym go zapodał, niestety latka lecą a skleroza postępuje ;)
z SAP Playerem sprawa jest taka iż tylko jeden z liczników POKEY-a zgłasza IRQ, wiec muzaki wykorzystujące inne liczniki nie będą działać poprawnie na SAP Playerze. Prawda jest taka iż to ASAP jest najodpowiedniejszy obecnie do odrywania SAPów :)
pozdrawiam
Seban
atari.area forum » Posty przez seban
Wygenerowano w 0.093 sekund, wykonano 20 zapytań