Rick Dangerous Teaser Trailer #3 by Xeen 2012-10-09 13:13:28
I pojawiły się kolejne przecieki o jednej z najbardziej
oczekiwanych konwersji gier na małe Atari: Rick
Dangerous.
Program w przypadku wykrycia rozszerzonego komputera będzie
wykorzystywał zasoby VBXE, a konkretnie mapę kolorów. Czekamy!
xeen 2012-10-09 13:29:57
bardzo przyjemna wiadomośc dla mało rozpieszczanych przez twórców posiadaczy VBXE :) grey / mystic bytes 2012-10-09 13:51:24
piękna gierka :) oby ujrzała światło dzienne w pełnej postaci :) josé pereira 2012-10-09 14:06:37
Look good but for VBXE. Does the game for original stock machines still beeing developed? tdc 2012-10-09 14:14:09
Of course this will be game for stock Atari too. Jacques 2012-10-09 15:18:32
Only question... When, when, when? :-) Wieczór 2012-10-09 18:08:04
@Jose: in video you can see footage from both versions... I would say rather than difference is cosmetic :) Just a little bit more colors on platforms, floors and ground pieces filling space between stones pin 2012-10-09 22:37:58
... no to czekamy na filmik dla VBXE, bo obecny jak sądzę dotyczy "stock" Atari. Oczywiście tym samym nie twierdzę, że to źle wygląda - wygląda oczywiście wybornie, no i bardzo grywalnie.
Czy autor mógłby zrobić detekcję VBXE w sensie tym, czy karta siedzi na $D6 / $D7 i detekcję rdzenia? Brak wspomnianej funkcjonalności jest niestety zmorą programów przeznaczonych dla karty.
Czy gra będzie dostępna w wersji plikowej? (bez xBios) xeen 2012-10-09 22:53:26
pin, filmik ma fragment podkolorowany specjalnie zaznaczony. ale się zaparłeś na tego xbiosa :) Ryszard Niebezpiecznoręki 2012-10-09 23:49:25
@Pin: Gra dokonuje autodetekcji lokalizacji rejestrów sprzętowych VBXE w przestrzeni adresowej komputera. Minimalne wymagania dotyczące wersji rdzenia to 1.20. Istnieje możliwość realizacji gry w wersji wielo-plikowej. Gra najprawdopodobniej będzie wykorzystywała bibliotekę xBios. pin 2012-10-10 12:32:35
.. to jeśli nie pójdzie bez xBios, to nie odpalisz tego na żadnym konkretnym IDE. Teoretycznie wiele nie trzeba, bo SDX w konfigu minimalnym memlo ma niewiele większe od xBios. Przy konfigu "golas" mam $0f43, xBios miał chyba coś w okolicy $0cXX... różnica więc stosunkowo jadalna ;)-
Co do VBXE, to przegapiłem trochę w takim razie owe podkolorowane elementy, może to przez super jakość YT ;)-. Zrób jeśli możesz jakąkolwiek detekcję rdzenia na zasadzie też takiej, że jeśli jest to starsza wersja niż 1.20 to gra wywala stosowny komunikat na tę okazję. Jak pisałem - większość softu na VBXE w chwili, gdy uruchamiamy program z niewłaściwym rdzeniem po prostu zawiesza się :) - no i jest później zgaduj - zgadula na czym to tak na prawdę działa ;)- xxl 2012-10-10 12:51:36
xbios zajmuje od $700 do $bff :-) ponizej $700 pamiec jest wolna w odroznieniu od DOS. roznic jest wiecej: xbios na standardowym nierozszerzonym atari daje wiecej pamieci podstawowej niz jakikolwiek dos na atari z dodatkowa pamiecia. xbios nie wymaga wlaczonego OS ROM podczas dzialania - pozwala ladowac bezposrednio w obszar powyzej $c000. rownie wazne: program napisany pod konkretnego dosa moze nie dzialac z innym dosem a napisany pod sparte i Twoje memlo na pewno nie bedzie dzialal na atari ktore nie ma rozszerzenia w postaci sprtyX oraz rozszerzenia pamieci :-) nie odpalisz z IDE? popros producenta urzadzenia o biblioteke :D pin 2012-10-10 13:03:35
... przypierdzielasz się jak mucha końska a tymczasem można to napisać tak, by działało pod xBios i pod Sparta DOS X :). Najprawdopodobniej problemu w tym nie będzie tym bardziej, że z czego słyszę gra będzie korzystała z wielu plików, więc to czy zostanie 3 strony pamięci więcej, czy nie to nie wiem czy to aż takie ważne. Co do pamięci pod ROM to nie widzę problemu by jej używać. 98% użytkowników SDX system trzyma w dodatkowej pamięci.
Dlatego nie mam nic do tego (bo niby dlaczego), by gra była rozpowszechniona w DOWOLNY sposób, np. wraz z xBios tyle tylko, by nie była to jedyna możliwość uruchomienia. Wówczas jak widzisz - niepotrzebna będzie Sparta a dla ludzi, którzy mają cokolwiek więcej - można będzie w szybki i komfortowy sposób ładować program.
Sądzę, że najlepszym wyjściem jest takie działanie, by jak najmniej użytkowników miało problemy z uruchomieniem gry i wielkich cudów tutaj nie sugeruje. xxl 2012-10-10 13:51:27
podejrzewam, ze Ryszard bedzie ladowal i zapisywal dane a w tym przypadku nie ma mozliwosci zeby do tego uzywal biblioteki dosa i xbiosa. to nie jest kwestia "3 stron"... podczas i/o najbardziej okrojony dos daje okolo 45kb ram (pewnie mniej) podczas gdy xbios zawsze 61 kb na standardowym atari...
> 98% użytkowników SDX system trzyma w dodatkowej pamięci.
no wlasnie - dodatkowej pamieci. nie kazdy ma dodatkowa pamiec. nie kazdy ma sparta dos x.
> Sądzę, że najlepszym wyjściem jest takie działanie, by jak najmniej użytkowników miało problemy z uruchomieniem gry i wielkich cudów tutaj nie sugeruje.
dokladnie tak. tegie glowy jakis czas temu doszly do takiego samego wniosku, dos stal sie im ciasny a nie bylo niczego podobnego to napisaly sobie chopy biblioteke I/O i zalaczali do swoich gier... zerknij na procki IO takich firm jak activision, lucasfilm :-) np. rescue on fractalus, eidolon albo road race. roznica jest taka, ze oni zadbali zeby format nie byl przenosny, xbios bazuje na filesystemie dosa ... wszystko co wykorzystuje xbiosa moze byc normalnie kopiowane dosem ;-)
mysle ze moglibysmy o tym dlugo rozmawiac. w.mnie nie istotne jest jak gra bedzie wydana - chociazby na karcie - wazne jest kiedy bedzie mozna w nia w koncu zagrac :-) xxl 2012-10-10 13:55:41
nie chce mi sie teraz sprawdzac ale chyba goscie z activision zerzneli kod z dosa i chyba nie wielkie tam sa zmiany... pin 2012-10-10 14:13:13
Widać XXL, że nie interesujesz się tematem. Z mojej analizy wynika, "ciasnota" pod twoim ulubionym Sparta DOS X wygląda tak, że możesz spokojnie uzyskać 58kB wolnej pamięci RAM nie rozwalając systemu. Nie wiem więc, skąd przyszło Ci do głowy 45kB ;)-
zresztą - róbcie sobie to jak chcecie, mnie to tam pipka, najwyżej część userów będzie sobie grało na emulatorze a nie na real atarce ;)-
było najpierw zrobić support do większości hardware'u (xB) a nie wypuszczać wybrakowanego bubla ;)- Tyle. Nara. mono 2012-10-10 14:21:22
@xxl: Kolekcja muzyczna "XL digital" była zrobiona tak, że zajmowała całą pamięć dostępną ($2000..$cfff + $d800..$ffbf + $100..$17f + $3c0..$6ff). Pracuje na dowolnym DOSie, który nie korzysta z pamięci pod ROMem. Używa CIO. Pisanie "pod Spartę" polega na olaniu CIO i wykorzystywaniu bezpośrednio mechanizmów SDX oraz jej rozszerzonego formatu pliku. To są jednak dwa różne pojęcia, a myślę że pin mówi o pisaniu "pod DOS" a nie "pod Spartę". xBIOS ma swoje zalety - wszystko zależy od tego, co wybierze programista :) xxl 2012-10-10 15:36:59
mono zgodze sie z Toba, ze mozna przepychac dane przez bufor po inicie kopiujac pod rom ale to nie jest bezposrednie ladowanie. nie zapominaj tez o stronie 0,2,3 ;-) co zrobic jak masz juz zapelniona pamiec, wolne miejsce pod romem i chcesz tam teraz cos zaladowac albo zapisac na dysk... klapa.
> możesz spokojnie uzyskać 58kB wolnej pamięci RAM nie rozwalając systemu.
i pewnie jeszcze use banked? ;-) nie mozesz bezposrednio zaladowac do tych 58, mozesz z bufora ktory musi byc wlasnie w tych 45 kb... a po tych wszystkich operacjach i tak bedzie dzialac tylko na jednej okreslonej konfiguracji o ktorej juz mowilem.
@Pin, zrozumiem, nie widze na horyzoncie innego niz sparta dos x rozwiazania dla Ciebie. uwazam, ze jest dobre ale ciesze sie bardzo ze mam wybor.
:) - jak na razie to widzę wymierne korzyści dla użytkownika SIO jeśli chodzi o użytkowanie obecnej wersji xBios. Dla przykładu rzuciłem okiem na Zybex :D
Czas ładowania:
SIO - xBios: 1 minuta 50 sekund.
PBI - ide+: 8 sekund
Nie mam więc nic przeciwko temu, by nowe gry i programy były ładowane z magnetofonu i tylko z niego, bo nie będzie potrzebny nawet xBios. A ile wówczas pamięci mamy ... ehhh ;)- miód malina! pin 2012-10-10 15:52:19
.. w przypadku xB brałem pod uwagę to, co jest. Czyli bez "przyspieszaczy" dla SIO i to, co mamy dostępne w obecnej wersji xB. xxl 2012-10-10 16:03:45
obecna wersja xbios dziala ze speedem w zakresie od 19k czyli standard to co sprawdzales do 115k - z ciekawosci sprawdze jak dlugo sie laduje zybex :-) ale to juz z chalpy pin 2012-10-10 16:10:23
widzisz ... i to jest właśnie bez sensu, że mając "jakąś" wersję na SIO nie wiem, dlaczego nie odpaliło mi to w trybie US mimo, że sprzęt se strony SIO umożliwia taką transmisję. AAA - zapomniałem, można sobie przecież podmieniać biblioteki i sprawdzać, kiedy zadziała :)- pin 2012-10-10 16:24:41
XXL - ładowanie sprawdzałem na wersji Zybex 50kB plik, std przeplot sektorów, SIo, 19200bps, jak coś. jury 2012-10-10 17:09:10
Ogólnie to nie zrozumiałem co napisaliście przez ostatnie 2 ekrany, ale przypomina mi to bezsensowne i bzdurne przepychanki w świecie amigi %-) xxl 2012-10-10 17:12:52
nie :-) wgraj obiblioteke ktora Ci odpowiada, urzadzenie umozliwia szybsze I/O? chcesz z tego korzystac? prosze bardzo. tylko ze w.mnie sam speed ladowania jest trzeciorzednej wagi, programista musi zadbac o to zeby cala gra lacznie z samym ladowaniem - czasem ladowania - miala rece i nogi. ten czas mozna przeznaczyc na... np. na obejrzenie obrazka :-) i co z tego ze jakas gre zaladujesz w 4 sekundy? nie zdazysz przeczytac co jest na ekranie ladowania... o i mam pomysla... bedziesz musial przeczytac ;-) dzis nie sprawdze siox1 ale zapamietam. xxl 2012-10-10 17:18:55
Pin co ty pierdzielisz, teraz sprawdzilem na emulcu standardowy speed to 48 sekund a nie minuta 50... xxl 2012-10-10 17:30:38
Pin cos sciemniasz:
SIO standard xbios: 48 sek SIO x6 xbios: 14 sek SIO x1 xbios nie moge sprawdzic bo emulec tego nie obsluguje a atarki nie moge dzis podlaczyc.
poza tym nie ma czegos takiego jak "jakas" wesja. jesli xbios nie znajdzie pliku xautorun wyswietla menu gdzie masz napisane dokladnie co to za wersja jakie zlacze/urzadzonko i speed, konfig pamieci do tego tez :p xxl 2012-10-10 17:31:18
przepraszam nie x6 nie x1 tylko hindex=6 i hindex=1 Ryszard Niebezpiecznoręki 2012-10-10 20:50:00
Gra będzie dostępna w wersji dyskowej (format DOS II) oraz cartrige'owej. Biblioteka xBIOS w zamierzeniu ma pomóc w transparentnym ładowaniu plików z klasycznego dysku, ramdysku oraz symulowanego ramdysku zlokalizowanego na kartridżu. Do tego ostatniego trzeba będzie stworzyć dedykowany sterownik. Myślimy o wykorzystaniu Coriny.
Przydomek "Niebezpieczny" nobilituje mnie do wykorzystania całych dostępnych zasobów komputera, zatem uruchomienie pod jakimkolwiek DOS'em nie wchodzi w rachubę. Potrzebuję rozpastwić się po całej pamięci komputera i przejąć nad nim całkowitą kontrolę, wliczając w to przerwania. Nie mam zamiaru zostawiać żadnych okruszków. Wycisnę z golasków ostatnie soki przy pomocy kolta.
Bez obawy, moi projektanci uwzględnią postulat dotyczący informowania użytkownika o niewystarczającej wersji jądra VBXE. zaxon1 2012-10-10 21:14:45
Well, jeszcze jest cos takiego jak SIDE u okolo 180 osob, moze warto to tez uwzglednic? Bolo 2012-10-10 21:50:53
Wyglada super pin 2012-10-10 22:01:02
@Zax - nic nie szkodzi, xBios nie wspiera SIDE, ale możesz zawsze odkurzyć CA2001 ;)-
@XXL - Testy przeprowadzone na STD Atari i XF551, oraz dyskietce 5.25". Sorry Winetu :)
@XXL - sprawa zmierza z złym kierunku - dlaczego. Otóż sytuacja jest taka: piszesz xBios pod SIO, ataridos FS, itd., zostaje 61kB wolnej pamięci. Wszystko działa, działa ze SIO2SD, SIO2_coś tam itd. Teraz piszesz inną bibliotekę, która zajmuje 2 strony pamięci więcej. I co - i cała koncepcja jest o kant dupy rozbić, bo okazuje się, że xBios nie zgodny jest z xBiosem i program napisany dla jednej biblioteki nie ma wystarczającej ilości pamięci w przypadku odpalenia innej, ;)- i to jest moim zdaniem fakt, który znacznie ograniczy rozwój projektu i zapewni użytkownikowi brak wsparcia w przypadku niektórych urządzeń "pamięci masowej". Przykład: Newdev + sparta FS. ;)- Na dodatek Zaxon pyta o SIDE :D
... i tu masz super rozwiązania, które nie posiadają supportu dla hardware'u: SIDE - 180sztuk i dokładnie tyle samo sprzedanych IDE+. 360 urządzeń w realnym hardłerze w śmietnik - czemu nie :) ... bo twierdzisz, że 5% z tego jest używane.
@Ryszard N. - to zamiast się chrzanić z liniową 64k i zyskiem na niej rzędu 2-3kB dzięki xBios jaki problem, by bezproblemowo użyć 1MB portb? ;)- Bez kompromisów i do bólu ;)- xxl 2012-10-10 22:27:51
> Testy przeprowadzone na STD Atari i XF551, oraz dyskietce 5.25".
musi byc niezle zajezdzona dyskietka :-) pewnie stacja czyta po 5 razy jeden sektor zanim dobrze przeczyta :-)
> Teraz piszesz inną bibliotekę, która zajmuje 2 strony pamięci więcej.
po co mam postepowac wbrew naturze? obawiam sie ze nie rozumiesz idei xbiosa.
> zyskiem na niej rzędu 2-3kB dzięki xBios
podczas i/o raczej 16kb
> jaki problem, by bezproblemowo użyć 1MB portb?
litosci. pin 2012-10-10 22:51:51
>musi byc niezle zajezdzona dyskietka :-) pewnie stacja czyta po 5 razy jeden sektor zanim dobrze przeczyta :-)
litości. Normalny przeplot, 19200 :)
>po co mam postepowac wbrew naturze? obawiam sie ze nie rozumiesz idei xbiosa.
Rozumiem. Rozumiem, że jeśli trzeba będzie zrobić coś więcej to jest to zero-rozwojowy projekt. Zrozumiałem :)
> podczas i/o raczej 16kb
hmmm - coś więcej?
>> jaki problem, by bezproblemowo użyć 1MB portb? litosci.
Litości ;) Jacques 2012-10-11 00:28:23
Sam mam 1MB, SIO2SD, SIDE, VBXE, także w teorii nie będę mieć problemu z uruchomieniem RD... Oczywiście świetnie byłoby jakby gra pozwalała się uruchomić spod partycji SDX na SIDE lub z poziomu SIDE Loadera, ale jeśli jest szansa by PEŁNOWARTOŚCIOWY Rick Dangerous działał ludziom na Atarkach z 64 KB RAM i stacją dyskietek (prawdziwą, SIO2IDE, SIO2SD, SIO2PC), to chyba to jest właściwa droga mimo wszystko. Dopóty, dopóki będzie wersja na FDD/SIO2COŚTAM, a gra będzie nosić oryginalną nazwę będzie git :-) A cartridge dla purystów, ja nie lubię tego przekładać ;-) Ot opinia w dyskusji. pin 2012-10-11 00:44:49
@Jacques - z poziomu SIDE loadera - nie jestem pewien. Będzie trzeba olać SIDE i odpalić z SIO2SD.
Co do reszty to pozostaje pytanie na które nie mogę udzielić odpowiedzi czyli - ile pamięci "głównej" będzie potrzebne w tym przypadku faktycznie. Teoretycznie nie powinienem tutaj niczego pisać, bo to nie moja sprawa, lecz staram się ustalić jaką przyczynę i logiczne uzasadnienie mają działania mające na celu za wszelką cenę zmniejszyć zgodność w stosunku do istniejącego hardware'u. Czasami wystarczy pomyśleć i nikt z niczym nie będzie miał kłopotów. I tyle ;)- xxl 2012-10-11 15:04:45
gra ma czytac i zapisywac na urzadzeniu zewnetrznym ... co Ci przyjdzie z tego, ze zaladujesz z SIDE loadera? Jacques 2012-10-11 16:17:37
SIDE Loader w sumie po nic, racja... Móc za to uruchomić spod SIDE w jakikolwiek sposób to byłoby coś ;-) Ale tak jak pisałem, jeśli jest szansa by gra chodziła na maszynach z 64 KB, to warto zapłacić cenę za format jedynie całodyskowy. xeen 2012-10-11 16:25:59
z tego co wiem jest więcej niż szansa, że to pójdzie na 64 KB, to paradygmat :) xxl 2012-10-11 16:45:40
@Jacques, xbios jest zaprzeczeniem formatu calodyskowego. uwazam, ze "calodyski" mimo ze banalnie proste do oprogramowania sa niewygodne. wygodne jest operowanie na plikach a nie sektorach i wlasnie tak robi xbios. pin 2012-10-11 19:37:33
tak właśnie ;)- anonim 2012-10-25 22:00:45
ktoś napisał o 180 urządzeniach side... hmmm sio2sd poszło kilka tysi.... twh/f2 2012-10-25 22:20:18