Sprawdź jeszcze, czy dźwięk wychodzący z laptopa nie jest za głośny albo za cichy - to też ma wpływ.
Poza tym, łatwiej nam będzie jak powiesz, z jakiego pliku CAS korzystasz.
Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
Bubble Bobble dla Atari 8-bit Wersja ta bazuje na edycji BBC Micro, jednak została napisana niemal od podstaw, by maksymalnie wykorzystać możliwości Atari.
Silly Venture 2024WE - wyniki Ponad sto prac wzięło udział w compo SV2024WE
Trwa Silly Venture 2024 w Gdańsku! Party się rozpoczęło, zajrzyj po link do streamów.
Flop 68 Po dwuletniej przerwie wraca Flop!
TURGEN 9.3.0 Kolejna wersja multiplatformowego narzędzia do zarządzania obrazami taśm.
atari.area forum » Posty przez Krótki
Sprawdź jeszcze, czy dźwięk wychodzący z laptopa nie jest za głośny albo za cichy - to też ma wpływ.
Poza tym, łatwiej nam będzie jak powiesz, z jakiego pliku CAS korzystasz.
No i z niedzieli zrobił się wtorek. W każdym razie,
Nie rozważałem jeszcze w jaki sposób rozszerzyć format .CAS tak, aby możliwe było stosowanie zabezpieczeń zapisu. Może faktycznie będzie to zapis surowych impulsów, chociaż to zajmie więcej miejsca.
Właśnie takie rozwiązanie przyjąłem - do formatu CAS dodałem nowy typ rekordu (obok istniejących 'data' i 'baud'): 'fsk ', który zawiera długości kolejnych impulsów w milisekundach (16 bitów na każdy impuls). Podczas kodowania do CAS każdy blok którego nie uda się rozpoznać jako 'data', jest zapisywany w formie 'fsk '.
Takie rozwiązanie w zupełności wystarczało w przypadku zabezpieczeń, na które się natknąłem - a natknąłem się tylko na jeden typ: gdy pomiędzy normalnymi rekordami na taśmie znajduje się sekunda albo dwie ciągłego sygnału '0'. Taki sygnał zapisuję w bloku 'fsk ' jak poniżej:
66 73 6B 20 ; nagłówek 'fsk '
02 00 ; długość bloku, 2 bajty
00 00 ; pomijane - każdy nagłówek w CAS ma 8 bajtów
5F 06 ; 1631 milisekund sygnału '0'
Być może to rozwiązanie nie wystarczy dla bardziej zmyślnych zabezpieczeń (rozdzielczość w milisekundach może być za mała), ale jeszcze takich nie widziałem.
Zapis surowych impulsów oczywiście zajmuje więcej miejsca, ale ma tę zaletę, że da się to prosto oprogramować. Praktycznie bowiem nie ma 100% skutecznej metody rozpoznawania typu rekordu ('data' czy jakiegokolwiek innego) - gdy napotkasz na jakiś nietypowy rekord, warto mieć w zanadrzu możliwość zapisania go w formie czystych impulsów.
Zresztą ten wzrost zajmowanego miejsca nie jest tak tragiczny. Np. taka "Misja" Avalonu ma ponad 300 rekordów, po konwersji do CAS zajmuje ok. 40 KB. Ale plik ten zawiera ok. 200000 impulsów, czyli gdyby zakodować go w formie "surowej" po 2 bajty na impuls, to mielibyśmy ok. 400 KB, więc wzrost rozmiaru jest raptem 10x. I ciągle jest to mniej niż choćby nagranie mp3.
Do niezabezpieczonych programów może być zwykły .CAS. Odtwarzanie muzyki, która znajduje się na prawej ścieżce? Czemu nie, podłączenie urządzenia do Audio In nie stanowi problemu. Tylko pytanie, jak je przenieść na kartę SD. Bezpośrednio z Atari to się nie uda, kompresja .mp3 odbywałaby się na PC, ale.... jak to później zsynchronizować z lewą ścieżką?
Zastanawiałem się nad tym kiedyś, ale dobrego rozwiązania jeszcze nie mam. Może trzymać w pliku CAS jakieś dodatkowe bloki, informujące o tym ile sampli należy przeczytać, zanim skończy się następny rekord 'data'? Wtedy gdy podczas odtwarzania okaże się, że rekord się "skończył" zanim wszystkie sample zostały odczytane, można by po prostu wstawić dłuższą przerwę IRG. Alternatywnie, gdyby wcześniej skończyły się sample, można by zapewnić, że następny rekord będzie odczytany z prędkością powiedzmy 1.05x szybszą niż oryginalna; albo wstrzymać na chwilę odtwarzanie WAV-a.
Całość na pewno sprzętowo będzie dość podobna do SIO2SD. Krótki, czekam w takim razie na Twoje uwagi odnośnie nowego formatu - i oczywiście trzymam Cię za słowo, że zajmiesz się oprogramowaniem tegoż.... :)
Żeby nie było nieporozumień - jestem w stanie przygotować bibliotekę, które będzie odczytywać z formatu CAS/XCAS/Wav pojedyncze impulsy oraz zakodowywać owe impulsy do ww. formatów, ale to jak Ty ten mój kod wciśniesz na płytkę drukowaną to jest osobna sprawa, na tym się zupełnie nie znam.
OK, odezwe się jeszcze w niedzielę, bo teraz mam urwanie głowy.
Będzie OK. Wszystkie CASy będą działać - inaczej nie miałyby racji bytu.
Nie wiem, czy się przyda - ale autor (opensource'owego) emulatora Altirra (...)
Ta, wiem. Zamierzałem wykorzystać jego bandpass filtery u siebie. Moje rozwiązanie mimo wszystko ma zalety nad tym jego:
- nie jest windows-only
- jest osobną biblioteką (wspólny kod dla programu konwertującego i dla emulatora)
- umożliwia nie tylko odczyt, ale też zapis (zatem pozwala na konwersję między formatami)
- phaeron nie wziął na tapetę rozszerzania formatu CAS.
Coby nie gadać po próżnicy: Dely, gdybyście potrzebowali kogoś do oprogramowania obsługi XCAS, gdy specyfikacja już powstanie (na turbach się nie znam, więc co do specyfikacji się nie będę udzielał) to z przyjemnością chciałbym w tym brać udział. Już raz to zrobiłem ;) i uważam że wiem jak to powinno wyglądać.
Kuna mać! Od 2 lat siedzę w tym temacie. Zaplanowałem sobie że rozszerzę format CAS na obsługę wszystkich możliwych kaset zapisanych w normalu - także tych zabezpieczonych przed kopiowaniem (czyli bez turbo). Początkowo szło mi nieźle - zaimplementowałem bibliotekę, która potrafiła skonwertować do (rozszerzonego) formatu CAS wave'y z kaset zabezpieczonych przed kopiowaniem. Skonwertowałem do CAS Robbo, Misję, Freda, Lasermanię i Robbo Konstruktora - wsystkie te kasety mają niestandardowe rekordy których stary format CAS nie obsługiwał. Udało mi się moją bibliotekę podpiąć do Atari800, dodałem też do emulatora odgrywanie dźwięku z kasety! Wszystko było zajebiście.
Potem przyszła sesja egzaminacyjna.
Potem padł mi dysk :(
Udało mi się odtworzyć większość tego, co wcześniej miałem, ale zapał mi trochę opadł, czasu wolnego zrobiło się mniej i nie dokończyłem sprawy (chociaż plany mam nadal dalekosiężne). W każdym razie osiągnąłem stan następujący:
- jest biblioteka która potrafi konwertować formaty CAS (rozszerzony), WAV, HEX - z każdego formatu na każdy. Biblioteka w locie konwertuje plik wejściowy do formy sygnałów FSK, które można później zapisać do innego formatu, albo wykorzystać w emulatorze. Jeden haczyk: nie odtworzyłem jeszcze funkcji odczytu z WAV. Tej najważniejszej i najtrudniejszej :(
- jest program który tą bibliotekę wykorzystuje - taki nowy WAV2CAS, CAS2WAV - chociaż z powodu wymienionego wyżej nie potrafi jeszcze wczytywać WAVów
- jest modyfikacja do Atari800 wykorzystująca tę bibliotekę do wczytywania plików CAS. Nie wspiera jescze zapisu. Nie przywróciłem też jeszcze odgrywania dźwięku z taśmy.
- ostały mi się CASy owych pięciu skonwertowanych gier, więc mogę sobie usiąść prze emulatorem i je wczytać, łkając nad swoją niedolą :(
Jakoś od ponad roku nie mam czasu bardziej pociągnąć tematu, więc nawet spodziewałem się, że ktoś inny mnie w tym uprzedzi. W każdym razie, gdybyście byli zainteresowani, to mógłbym Wam podrzucić swój work-in-progress, może się przyda.
Odstępy w ogóle nie są potrzebne. Jeśli już, to tylko człowiekowi, żeby wiedział "na słuch", gdzie się kończy 1 plik a zaczyna drugi. Ale do tego celu lepiej sobie zanotować stan licznika magnetofonu. Więc wybierz sobie odstęp jaki Ci się podoba, albo w ogóle - programy i tak będą się wczytywać.
Po prostu chciałem się upewnić, że brałeś pod uwagę taką możliwość. Funkcja konwersji atarowskich plików jest zupełnie nie związana z obsługą obrazów dyskietek, więc tak naprawdę nie ma powodu żeby je sztucznie ze sobą łączyć. Poza tym moduły małe i o jasno określonej funkcjonalności są łatwiejsze w rozbudowie i bardziej odporne na powstawanie błędów.
Ja rozumiem że napisanie pluginu do Listera to jakiś tam nakład pracy (pewnie trzebaby dorobić GUI wyświetlające bitmapę zwracaną przez GRAFON). Ale właśnie mi przyszło do głowy, że funkcję konwersji np. GR8->BMP można też zrobić jako ... całkowicie osobny "packer plugin". Co o tym sądzisz?
Czy ja dobrze rozumiem, że Twój plugin umożliwia podgląd np. obrazka .GR8, ale tylko jeśli ten obrazek leży w ATRze? Jeśli tak, to ... trochę bez sensu. Lepiej by było podpiąć program "GRAFON.EXE" jako plugin do Listera (tj. wewnętrznej przeglądarki plików TC). Wtedy można by oglądać GR8, GR9, BASy itp. leżące w dowolnym katalogu.
A migać to będzie w/g o wiele mniej bo linie np. trybu 9 będą zawsze w tym samym miejscu a linie trybu 11 w swoim, bezwładność CRT pozwoli zachować o wiele mniejsze migotanie obrazu niż w przypadky wyświetlania w tym samym miejscu dwóch różnych trybów na przemian. Ale to tylko moje domysły trzeba sprawdzić w praktyce.
Obawiam się, że migotanie będzie znacznie większe. Zamiast wyświetlania dwóch obrazów o względnie równej luminancji proponujesz wyświetlanie na zmianę obrazu o luminancji dowolnej (gr.9) i obrazu o luminancji zerowej (gr.11). Założę się że to będzie wyglądać tragicznie.
Poza tym bezwładność CRT to mit. W normalnym obrazie TV nie widać migotania nie dlatego, że jest jakaś bezwładność, ale dlatego, że sąsiednie linie ekranu mało kontrastują ze sobą.
Nie mów, że nie sprawdziłeś na angielskiej Wikipedii...
Miło sobie powspominać, ja też tę grę bardzo lubiłem, mimo że wiele w niej nie osiagnąłem. Ładna grafika, jakaś taka kosmiczna atmosfera, muzyka nastrojowa mimo swej prostoty, a poza tym gra jest bardzo dopracowana jak na czas i miejsce, w jakim była wydana.
Kiedyś w Top Secret był taki tips: "Gdy bohater zacznie migać [chodzi o miganie tuż przed śmiercią], należy wcisnąć "Shift" (pauza) i po chwili "Fire" - 100 żyć." Nigdy nie udało mi się tego powtórzyć (miałem wersję bez nieśmiertelności), a jak widzę, cheat ten jest po dziś dzień popularny w necie. Udało się to kiedyś komuś z Was powtórzyć, czy to jest tylko jakaś ściema?
Też taki miałem, mój pierwszy joystick. Był nie do zdarcia. Konstrukcja nie wytrzymała dopiero gdy mój brat z wściekłości rzucił nim o ścianę - wtedy odpadł drążek i tak jak Nosty'emu został tylko kikut. Ale potem skręciliśmy drążek z podstawą za pomocą dwóch wielgachnych śrub i joy posłużył jeszcze parę lat. A graliśmy dość ostro - gdy wreszcie się rozleciał, w krótkim czasie uśmierciliśmy z 10 różnych joysticków (m.in. 2 CA-Commandery i 2 QS II Turbo).
Potem w 1996, z sentymentu kupiliśmy w składnicy harcerskiej na Ochocie jeszcze 2 VG-125-tki. Posłużyłyby pewnie jeszcze długo, ale niestety brat pożyczył oba koledze i słuch po nich zaginął :( Ech, wspomnienia...
Dobra, przepraszam za wprowadzenie w błąd. Zajrzałem do źródeł Atari800 - faktycznie Shift+F5 powoduje zimny start w sensie wysłania przerwania RESET do procesora, a nie tak jak wcześniej napisałem.
W każdym razie potestowałem w emu Atari800 w BASICu jak się sprawa ma. Ustawiłem wielkość pamięci na 128KB, wpisałem
POKE 54017,225:POKE 32700,1
POKE 54017,229:POKE 32700,2
POKE 54017,233:POKE 32700,3
POKE 54017,237:POKE 32700,4
i nacisnąłem Shift+F5. Wartości we wszystkich bankach zostały zachowane. Więc moja rada - sprawdź, czy Ci działa w czystym Atari800.
Shift+F5 to nie jest zimny start w sensie skoku pod procedurę zimnego startu $E477. Ta kombinacja symuluje wyłączenie i ponowne włączenie komputera - zimny start w innym znaczeniu.
O commoncontrols.h zmalazłem coś tu - nie wiem na ile to przydatne, nie znam się na programowaniu w Windows.
Co masz na myśli mówiąc "viewer"? O ile mi wiadomo, ADFView nie ma mechanizmu do podglądania plików z wewnątrz obrazu dyskietki.
Jak ktoś by się chciał pobawić w pisanie IFSa, to przyda mu się ta strona, szczególnie przykładowa implementacja systemu RomFS. Ale uwaga, pisanie drivera do jądra Windows jest naprawdę trudne.
Poza tym nadal pozostaje problem montowania plików ATR jako dyski. Wygląda mi na to, że nie da się tego zrealizować w Windows w "przezroczysty" sposób, czyli bez użycia dodatkowych narzędzi. (Co ciekawe, na ww. stronie jest narzędzie FileDisk właśnie do tego.)
http://www.viksoe.dk/code/adfview.htm
Źródła są na GPL, wystarczy "tylko" przerobić na ATRa.
Z tego co się orientuję, IFS nie jest dobrym rozwiązaniem do tego celu - IFS służy tylko do obsługi nowych systemów plików, więc i tak musielibyśmy w jakiś sposób "zamontować" plik ATR pod windowsową literkę dysku. Sprostujcie jeśli się mylę.
A to po prostu jest singel z 1979 roku.
Jeśli używasz Atari800Win(PLus), to jest prostsza metoda:
1. W Atari -> Settings... włączasz opcję "Enable P: patch for printer device";
2. Właczasz też opcję "Use alternative print command" i wpisujesz treść komendy "notepad %s". Zatwierdzasz OK;
3. W Basicu zapisujesz swój program na drukarkę komendą LIST "P:"
Żeby pojawiło się 48 kwadratów, trzeba uruchomić SELF-TEST z wyłączonym BASIC-iem - czyli włączasz komputer z wciśniętym OPTION.
Co do T2000 to przyczyny nie znam, ale nie ma się czym przejmować, dopóki bez katridża (patrz wyżej) wszystkie kwadraciki są zielone.
Jak masz szczęście, to SELF-TEST w Twoim Atari potrafi też testować rozszerzoną pamięć - na pewno zauważysz różnicę.
1. OPTION.
2. Chyba Getaway? Na Atarimanii mają skan instrukcji, może Ci pomoże.
Niestety mi sie nie udalo uzyc H: - Error 130.
"U mnie działa" - pod WinPlus 4.0 oraz pod atari800 2.0.3 udaje mi się wczytać do Action! (pobranego stąd) plik z urządzenia H6:.
Nosty, a sprawdzałeś przypadkiem czy Action działa z emulatorowym handlerem H:? Jeśli tak, to problem z głowy.
Ale serio, u mnie działa.
Tak, działają. Co prawda przy niektórych kombinacjach (nie alfanumerycznych) trzeba się trochę nabiedzić, ale nie udało mi się znaleźć ani jednej kombinacji Shift+Control, która działałaby na Atari a nie mogłaby być odtworzona w Atari800.
Przykład: chcemy uzyskać w emulatorze efekt naciśnięcia klawiszy Shift+Control+<. Oto co robimy:
1. dowiadujemy się z dokumentacji, że kombinacja klawiszy Shift+< (czyli czyszczenie ekranu) jest zmapowana pod klawiszem Home
2. Wciskamy Shift+Ctrl+Home
Inny przykład: naciśnięcie Shift+Control+=:
1. dowiadujemy się z dokumentacji, że kombinacja Control+= jest zmapowana jako strzałka w dół
2. Wciskamy Shift+Ctrl+strzałka w dół
;)
Przykłady w wątku do którego linkujesz (Shift+Control+Z, +, *) są chyba trochę chybione, bo o ile pamiętam na prawdziwym Atari też nie działają.
atari.area forum » Posty przez Krótki
Wygenerowano w 0.023 sekund, wykonano 39 zapytań