Z covoxem jest rożnie.. w zależności od implementacji.. PokeyMax covoxa ma pod D280, a rozszerzenia lotharka p-covox pod adresami D500, D600 lub D700.. z tym, że d500 kłóci się ze spartą, d600 z VBXE.. i rozsądnym jest d700.. niestety jest w tym bałagan. Tak więc powinna być możliwość wyboru adresu np. w pliku ini lub w samej grze.
Nie wiem, czy autodetekcja dla rożnych opcji jest możliwa.
Nie wiem, do kogo te ataki są systematycznie kierowane, ale ja to po prostu lubię, nic nie wiem i robię to głównie dla siebie. Spróbuję również dokonać początkowego wyboru adresu.
W1k - nie ma co się przejmować, przypadłość wieku starczego, człek dziecinnieje. Zamiast sobie jakiej kwatery szukać na miejscu wiecznego odpoczynku to dogryzają wzajemnie i za włosy ciągają. :-DD
świetna robota :) ale mogłem zobaczyć "tylko" filmik (kopara opada!) bo na wczytywaniu levela już się wiesza i widać tylko loading. Bez rapidusa mogą być takie problemy? mój sprzęt: 800xe, u1mb, vbxe, atr wczytuję przez fujinet
ja tak czy inaczej doceniam i to najzupełniej bez sarkazmu. Sam stawiam teraz pierwsze kroki w tandemie vbxe + madpascal, powoli się witam z blitterem, i to bez wsparcia AI. Idzie bardzo ciężko, więc gdy widzę taką robotę to czapka z głowy. Jest w tym jakaś część racji że rapidus to nisza (jak rozumiem @dracon o to właśnie ci chodzi) ale... w nosie to mam :) robota fantastyczna, nawet jeśli to nisza w niszy.
Czy ktoś ostatnią wersję skutecznie załadował po SIO? 3x, żeby nie było katorgi, rzecz jasna... Pytam, bo pod Altirrą się wiesza po wyborze ustawień dźwięku na ekranie "Loading", a na prawdziwym nie mam chwilowo jak sprawdzić.
Szczerze - vibecoding czy nie, tak wygląda doświadczenie z pisania programów na Atari. Po każdej mojej ukończonej grze było to samo: "no szkoda, że nie działa z (tu dowolne rozszerzenie lub soft o którym nawet nie słyszałem)". Ja zrezygnowałem z próby "zadowolenia wszystkich" po ->link<- , bo nawet wyłączenie Basica przez PORTB może obrazić jakiegoś "roszczeniowca rozszerzeniowca" ;-)
@ilmenit Po prostu coś co działało i się ładowało bez problemu w poprzednich wersjach, od wersji ze wsparciem dla Covoxa przestało. Czy to w Altirze po SIO, czy po SIO2SD, a chyba powinno, skoro to ATR? Nie bardzo rozumiem Twój komentarz w tej konkretnej sytuacji, gdzieś wkradł się jakiś problem i tyle.
@w1k W Altirze mam ustawionego Rapidusa (w trybie Rapidus), VBXE, U1MB (1088KB) i SIOV patch only zaznaczone. Zresztą próbowałem już różnych ustawień SIO, ale chyba nie w tym rzecz, skoro inni potwierdzili problemy na prawdziwym sprzęcie. Ja na rozszerzonym 130XE z SIO2SD będę mógł sprawdzić dopiero w poniedziałek.
@Jacques, to ogólny komentarz odnośnie pisania softu na Atari. Przez liczbę rozszerzeń i roszczeniowość ich użytkowników czasami odechciewa się pisać soft. A czy powinno coś działać po SIO2SD? ATR to tylko format. Czy powinno działać to zależy głównie jak dobrze twórcy rozszerzenia trzymali się standardów OS Atari.
SIO2SD to jeden z najbardziej sprawdzonych, zgodnych i uniwersalnych ładowaczy po SIO. Jak coś nie działa, to raczej jest to problem softu. Ale tu nawet ten przypadek nie ma miejsca (jakaś domniemana wina SIO2SD), tylko jest ogólny problem z ładowaniem ATR-a po SIO.
@w1k More feedback, with above described config, I tried again, but switching Rapidus to Classic (non-turbo) mode, instead of earlier Rapidus-mode.
And result is (1.77 MHz):
1) loading with black screen 2) audio selection screen (accepted with START) 3) intro playing 4) loading with "loading screen..." 5) freeze after few seconds of loading
So quite oddly, in Rapidus mode (20 MHz) point 3) is automatically skipped (no intro played at all) and it immediately hits 4) and trouble in 5). Yet, of course, using Rapidus mode with this game is a standard way to go. There was no problem either with Classic or Rapidus mode with your earlier versions (pre audio menu). Hope it helps, a bit :-)
Moja filozofia życiowa (implementowana w moich demach poprzez użycie PRINT pod adresem $c642) jest taka, że jak ktoś rozszerza swoje XE, to sam sobie jest winien.
Dlatego dla mnie nie istnieją rozszerzenia (nie mają uzasadnienia) poza: rozszerzeniem pamięci, pokey stereo, oraz ew. covoxa, ale tu liczę się z problemami.
Używam gołej 65XE, z doczepianymi urządzeniami z tyłu. Bozia dała 6502 - używam 6502. Wtedy można sobie poszaleć i pocyklować, co jest bardzo retro. Rozdzielenie prędkości procesora od generowania obrazu daje poczucie peceta.
Tym bardziej, że pisanie oprogramowania na sprzęt/software, którego się nie ma, to syzyfowa praca. Programista nie ma możliwości sam przedebugować, i jedynie co to pozostaje to czytanie mało przyjaznej dokumentacji (jak ->link<- ) i zgadywanie dlaczego nie działa, albo robienie z ludzi żywych proxy, którzy jedynie co zwykle mogą napisać to "nie działa!".
to moja wina, szybko wykonałem poprzednią poprawkę, wyświetliło się tylko menu, więc wyłączyłem atari i nie próbowałem już ładować przez sio2sd. częściowy moduł ładujący korzystał z własnej, szybkiej procedury SIO, która działała tylko na urządzeniach odpowiadających na polecenie $3F (SIO2SD tak robi, SIDE3/Altirra nie) oraz pętli oczekiwania „LOADING...” bez limitu czasu.
Za to na Antonii popyla aż miło. Normalnie płynność 100%. Ale... jest trudno, logika gry nie wybacza zawahań (chociażby na samym początku, jak się od razu nie da do góry to potwór w basenie nas łapie. Ten goniący nas - to samo, trzeba baaaardzo szybko uciekać i to natychmiast gdy to możliwe bo inaczej nas złapie. Dalej nie grałem (złapał mnie 4 razy).
@w1k 2 rzeczy, jeśli mogę prosić: 1. wyłączenie dźwięku sio podczas ładowania tego długiego atr'a 2. w tym samym bloku sprawdzenie czy vbxe ma rdzeń FX, bo tak, to się czeka i czeka żeby zobaczyć: VBXE NOT DETECTED!
OK, obie rzeczy poprawione. Ale naprawdę nie polecam uruchamiania gry przez sio2sd, polecam urządzenie PBI. Teraz mogę skupić się na konwersji wersji bez VBXE :)
Z tego co zauważyłem to assety się doczytują, z XEX-em tego nie zrobisz. Znaczy - zrobisz ale raz. A jak przegrasz i trzeba wczytać poprzedni fragment?
Działa, sprawdzone (na razie) pod Altirrą. I warto dodać, że to nie był problem z SIO2SD, tylko ogólnie z ładowaniem po SIO. Co ciekawe, w trybie "Rapidus" przy emulowanym Rapidusie (w Devices) nadal się wiesza na screenie z napisem "Loading..." (po intrze), ale jak doda się CPU 65816 bezpośrednio w głównych ustawieniach Altirry (a nie przez urządzenie Rapidus), to przy 21MHz działa bez zarzutu. Ale to już najwyraźniej kwestia emulacji Rapidusa, skoro na prawdziwym się już też ładuje, jak rozumiem.
@w1k nie idzie jakoś tego zoptymalizować dla sprzętów bez rapidusa? już w tym momencie z wielkim oporem ale jako - tako da się zagrać. Jest trochę nieresponsywnie, brakuje nieco płynności na starcie i gdy jest więcej obiektów.. ale skoro udało się dotrzeć do tego momentu, to może pchniesz to dalej? :)
ok, ale systemy plików i DOSy powstały właśnie w celu możliwości wczytania programu, a potem danych (czy części programu) w dowolnej kolejności. Skąd pomysł, że lepiej "jeden .xex zamiast .atr"? W czym to by miało by być lepsze?
Ale fakt faktem, skoro jak w1k napisał, że (co logiczne) ze względu na objętość i ilość danych PBI jest sugerowanym sposobem ładowania, to prosi się o xex, bo z atr-ami tą drogą różnie bywa ;-) Ale czy się da, nie da i czy byłoby to do zaadaptowania w tym konkretnym przypadku to nie wiem.
