76

...Ta, a werwolf pali ogniem i meczem...

77 Ostatnio edytowany przez xxl (2012-10-30 08:42:34)

Pecus napisał/a:

A nie prościej było (bez wysiłku) zrobić jedną wersję w pliku, bez nielegali, z komunikacją przez CIO ???

najprosciej bylo tak jak jest teraz czyli:

- jedna wersja w pliku (nadal nie wierzysz ze moze byc jedna wersja gry :) - sprawdz SlightSIDPlayer z ta biblioteka)
- z nielegalami
- z komunikacja przez biblioteke

a poza tym.... powtarzasz sie ;-)

---
i maly figielek:

http://memy.pl/mem_348646_uzywam_nieleg … atari_xlxe

http://atari.pl/hsc/ad.php?i=1.

78

Skoro to plik, to przekopiuj go i odpal na normalnym Atari z klasyczna oryginalną stacją dysków np.... Atari 815.
To jest program całodyskowy udający, że jest plikiem a do tego mocno ograniczony.

Taka prawda.

Bla bla bla bla, bla bla bla. Bla bla bla - bla - bla. Blabla bleee.

79

Pecus napisał/a:

Taka prawda.

Bla bla bla bla, bla bla bla. Bla bla bla - bla - bla. Blabla bleee.


skopiuje na dyskietke w podwojnej gestosci i odpale pod biblioteka - czy taki test wystarczy?  :D

http://atari.pl/hsc/ad.php?i=1.

80

O to jest już biblioteka z obsługą DD ?? no no.... cuuuudo? Jak rozumiem u Kaza w katalogu gier będziemy mieli najdłuższą listę wersji jednej gry. Jeżeli to o to chodzi - nie mam pytań - "Kawa i WZ-tka jest u nas obowiązkowa, bijemy się o złotą patelnię"?? :)

Bla bla bla bla, bla bla bla. Bla bla bla - bla - bla. Blabla bleee.

81

Pecus napisał/a:

listę wersji jednej gry.


jest tylko JEDNA wersja gry

xxl napisał/a:

(nadal nie wierzysz ze moze byc jedna wersja gry

hehe

http://atari.pl/hsc/ad.php?i=1.

82 Ostatnio edytowany przez Pecus (2012-10-30 09:34:32)

Wiesz.... w Kazowym katalogu też jest wiele wersji ATRow z jedną wersją gry.
W przypadku tej gry pewne jest, że nie będzie XEXa :) - tak bardzo jest to gra plikowa :P , ale ATRów z różnymi wersjami biblioteki namnoży się sporo.
Może warto od razu zabrać się za opisywanie, który ATR z jakim sprzętem współpracuje, bo ktoś znowu ściagnie sobie plik, który zadziała tylko na emulatorze, albo nie pójdzie na atari 1050 bez przeróbki (bo będzie to wersja DD a do tego tylko pod US) :)

Bla bla bla bla, bla bla bla. Bla bla bla - bla - bla. Blabla bleee.

83

oczywiscie ze jest xex - tylko dla WYGODY bede kopiowal go do atr poniewaz oprocz samego xex beda na dyskietce znajdowaly sie tez inne pliki jak np. plik gracza, dane itp.

duzo latwiej i wygodniej jest userowi sciagnac jednego atr niz kilka plikow. jesli natomiast user bedzie chcial przekopiowac te pliki to nic nie stoi na przeszkodzie - niech sobie skopiuje na urzadzenie dla ktorego ma biblioteke :-)

Pecus napisał/a:

albo nie pójdzie na atari 1050 bez przeróbki (bo będzie to wersja DD a do tego tylko pod US)

co Ty opowiadasz.... jest jedna wersja gry, mozesz ja sobie skopiowac gdzie chcesz a uruchomic z urzadzenia dla ktorego masz biblioteke - mowie to juz 103 raz :-)

http://atari.pl/hsc/ad.php?i=1.

84 Ostatnio edytowany przez Pecus (2012-10-30 09:49:01)

"dla wygody" uuuuua :)
Po prostu bez tego skopiowania "dla wygody" i dołożenia przynajmniej jednego pliku zależnego od tego na co kopujesz i na czym chcesz uruchamiać, gra się z tego XEXa nie odpali. Nazywasz to wygodą???

Normalny użytkownik chce skopiować XEXa i odpalić grę ze swojego ulubionego DOSa czy loadera, albo skopiować ATRa i odpalić, dlatego będzie milion wersji tej gry, mimo że nie nazywasz ich wersjami.

Bla bla bla bla, bla bla bla. Bla bla bla - bla - bla. Blabla bleee.

85

odpalic gre z ulubionego dosa? :-) przeczytaj glosowanie: http://www.atari.org.pl/forum/viewtopic.php?id=9527

xbios jest tez loaderem - mozesz dopalic sobie z xbiosa

http://atari.pl/hsc/ad.php?i=1.

86

Pecus napisał/a:

Wiesz.... w Kazowym katalogu też jest wiele wersji ATRow z jedną wersją gry.

Wiesz, z tego co zrozumiałem xBios nie musi być dołączony do gry. Wystarczy Tobie jedna kopia xBiosa, dla urządzenia którego używasz. I pod jego kontrolą odpalasz gry z niego korzystające. Tak jak nie dołączasz Windows do każdej aplikacji pod Windows.  A Twoja lokalna kopia też ma zainstalowane sterowniki pod Twój sprzęt. Po prostu xBios to taki mini (nano?) system operacyjny, z konkretną funkcjonalnością, z którego program korzysta. I fakt, jest inna od DOSa. Ale coś za coś - chodzi o ilość zajmowanej pamięci. Dlatego właśnie dana wersja _xBiosa_ (a nie gry, gra jest jedna) obsługuje konkretne urządzenie.

Mazezam być może tego nie potrzebuje - to ma bardziej być demonstracja jak to działa.

The problem is not the problem; the problem is your attitude about the problem

87

10/10 :D

800 XE + CA 2001; Portfolio; 1040 STfm; Lynx II
Psion Organiser II XP, LZ64; Series 3a, 3c, 5mx; Siena; Workabout; HP 95LX, 200LX, 620LX; Amiga 1200; Amstrad NC100, NC200; Game Boy Color
http://palmtop.cosi.com.pl -- nie tylko o Atari Portfolio

88 Ostatnio edytowany przez Jacques (2012-10-30 11:26:55)

Mnie tylko zastanawia jedno, najpierw jest bum na rozszerzenia (RAM, dyski korzystające z transmisji równoległej, itp.), w przeciwieństwie do Commodorowców u nas większość miała gdzieś by dema czy gry chodziły koniecznie na 64 KB (ładowały się do EXT-RAM), a teraz tworzy się prąd odwrotny :D No dobrze, opcja zapisywania stanu gry / hi-score jest jakimś uzasadnieniem tego typu wynalazków jak xbios, ja choć mam współczesne ATARI z "dodatkami" do końca nie wiem co jest właściwą drogą... Bo z jednej strony fajnie, jak ktoś z seryjnym ATARI będzie mógł sobie odpalić grę, a z drugiej strony cała rzesza Atarowców u nas i w innych krajach ma rozszerzenia RAM, szybkie dyski, które "wyrzucimy do kosza" będąc zdanymi na doczytywanie poszczególnych leveli po SIO... I jak tu pogodzić to wszystko? ;)

89

mimo wszystko dobrze by bylo gdyby nowy soft dzialal i na golej dziewicy, ale pisanie tak, by dzialal na okreslonym wycinku dostepnego sprzetu, a specjalnie tak, by nie dzialal na tym wygodniejszym (tj. wszystko co podpinane jest nie-po-sio) - to po prostu pomylka.

rozumiem ze z czasem pojawia sie dodatkowe sterowniki/wersje xbios, obslugujace wiekszy wycinek sprzetu (wspomniane "niektore carty" - nadal nie wiem co autor mial na mysli, czy drc, czy side, czy sic, czy cokolwiek innego), ale i tak juz zapowiedziane jest ze niektore konfiguracje autora nie interesuja (np. cokolwiek z fs sparty).

inaczej piszac - dla mnie to wyglada na soft ktory _z definicji_ ma nie dzialac na czyms, na czym nie zyczy sobie tego autor, bo tego czegos nie lubi (sparta? dyski ide?).

The UNIX Guru`s view of Sex:
unzip; strip; touch; finger; mount; fsck; more; yes; umount; sleep

90 Ostatnio edytowany przez xxl (2012-10-30 12:06:14)

Jacques napisał/a:

będąc zdanymi na doczytywanie poszczególnych leveli po SIO

modul komunikacyjny biblioteki xbios jest niezalezny i nie musi byc zwiazany z SIO, sam zademonstruje biblioteke z modulem komunikacyjnym dla kartow. a wszystko to zeby wszystkim zylo sie lepiej :D


> inaczej piszac - dla mnie to wyglada na soft ktory _z definicji_ ma nie dzialac na czyms, na czym nie zyczy sobie tego autor, bo tego czegos nie lubi (sparta? dyski ide?).

nieprawda. programista nie ma ZADNEGO wplywu na to z jakiego urzadzenia IO korzysta user.

jedyne co autor gry moze to ZABLOKOWAC mozliwosc uzywania urzadzenia dodatkowego a caly ruch obslugiwac z urzadzenia podstawowego.

z radoscia zapraszam do watku o xbios.


MazezaaaaaaaM

http://atari.pl/hsc/ad.php?i=1.

91

xxl napisał/a:

nieprawda. programista nie ma ZADNEGO wplywu na to z jakiego urzadzenia IO korzysta user.

A user nie ma żadnego wpływu na to czy z jego (najbardziej standardowo podłączonego) urządzenia program napisany przez tego programistę sie uruchomi. No chyba, że user napisze sobie do swojego urządzenia bibliotekę.

Programista stara się jednak utrudnić życie zwykłym userom (nazywając to oczywiście "ułatwianiem życia"), i zamiast trzymać się rozwiązań, które działają od lat i na dowolnych zgodnych urządzeniach (nawet jeszcze nie zaprojektowanych), stosuje własną protezę, która jest zgodna sama z sobą i z tym co zechce się akurat programiście oprogramować.

Powtórzę się raz jeszcze, te 3 (słownie trzy) odwołania do xbiosa, które są w tym programie można było napisać jako 3 odwołania do CIO i nie byłoby tylu dyskusji, i nie byłoby tylu wersji i gra chodziłaby pod dowolnym DOSem (i nie prawdą jest że HSC, czy ładowanie poziomów to zasługa xbiosa mimo, iż niektórzy tak tutaj piszą).

Oczywiście XXXL odpowie zaraz, że i tak by nie ruszyła bo wyłącza sobie ROM (oczywiście bez sensu, i potrzeby) i ładuje się w obszar DOSa (też bez potrzeby) no i działa tylko dlatego że jest wspaniały, cudowny, funkcjonalny xbios, który omija te ograniczenia (niepotrzebnie dodane do programu).

Bla bla bla bla, bla bla bla. Bla bla bla - bla - bla. Blabla bleee.

92

xxl napisał/a:

z radoscia zapraszam do watku o xbios.


MazezaaaaaaaM

Nie ma tak dobrze - przeplotło się :) Ok, Panowie - jestem już prawie pewien, że zaszło tu nieporozumienie. Przez to, że xBios wyszedł w wersji "developerskiej" powstało przeświadczenie, że gry korzystające z niego chodzą na określonych urządzeniach. Nieprawda. One chodzą na xBiosie.

xBios jest tak naprawdę rodzajem mocno zminimalizowanego DOSa - w celu wykorzystania jak największej ilości pamięci. Minimalizacja polega na tym, że dana wersja xBiosa obsługuje konkretne urządzenia bezpośrednio odwołując się do nich w specyficzny dla nich sposób. Jednakże zawsze xBios udostępnia grze to samo API. xBios nie jest częścią gry a jedynie obecnie został do niej dołączony, aby oszczędzić użytkownikom poszukiwań.

I teraz: masz HDD - ładujesz xBiosa dla HDD. A następnie gry z niego korzystające. Masz FDD, ładujesz xBiosa dla FDD. xBios dla carta siłą rzeczy jest na karcie (bo może) więc nic nie ładujesz. Cały czas te same gry. Gra nie może sobie powiedzieć że chodzi tylko na jakimś tam urządzeniu - ona chodzi na xBiosie. Jeśli xBios obsługuje dane urządzenie, grze nic do tego. Nie widzę problemów, żeby powstał xBios dla FS-a Sparty - a gra chodząca pod xBiosem nie ma nawet zielonego pojęcia o tym, bo jej to nie obchodzi. xBios ją separuje od sprzętu.

Ideą xBiosa jest natomiast to, aby dana wersja nie chodziła ze wszystkim, bo musiała by mieć procedury obsługi wszystkiego, co zabija jego ideę - minimalną zajętość pamięci.

xxl: dobrze zrozumiałem?

The problem is not the problem; the problem is your attitude about the problem

93 Ostatnio edytowany przez Pecus (2012-10-30 13:01:47)

wieczor napisał/a:

....xBios jest tak naprawdę rodzajem mocno zminimalizowanego DOSa - w celu wykorzystania jak największej ilości pamięci....

....I teraz: masz HDD - ładujesz xBiosa dla HDD. A następnie gry z niego korzystające.

xxl: dobrze zrozumiałem?

I ja to rozumiem też i Ty dobrze zrozumiałeś, tyle że na razie jest jedna wersja biblioteki, chodząca tylko po standardowym SIO w gęstości SD/ED a reszat w planach, albo napisz se.
Pamiętaj też że jest to DOS niezgodny na poziomie API z innymi DOSami. A masz w tej chwili na atari conajmniej kilka standardowych systemów plików i wiele standardowych urządzeń podpinanych innymi niż SIO interfejsami.

Dlatego też i powtórzę to słowo za CHORE uważam pisanie gry/programu,, tak by wymagał on xbiosa, jeśli program ten nie potrzebuje żadnej jego funkcjonalności i spokojnie działałby pod dowolnym DOSem przez ustandaryzowane przez lata CIO.

xbios ma sens przy programach, które potrzebują tony wolnego RAMu, a i tak traktować je należy wtedy jak programy całodyskowe z namiastką dostępu do plików.

wieczor napisał/a:

xBios ją separuje od sprzętu

A co robi CIO ? Znane, ustandaryzowane i posiadające "wersje bibliotek" (zwane DOSami, lub loaderami) do wszystkiego co znamy i nie trzeba pisać kolejnych, tym bardziej że DOSy dodatkowo oddzielają jeszcze filesystem od sprzętu. Co więcej standardowo napisany program działający przez CIO zadziała także BEZ PRZERÓBEK z magnetofonem np. w TURBO 2000 czy nawet w normalnej transmisji, na RAMdysku itp.
Trzeba tylko dopasować implementacje do potrzeb. A w Mazezam jedyną potrzebą jaką XXXL uwzględnił jest to że ma udowodnić sens istnienia xbiosa.

Bla bla bla bla, bla bla bla. Bla bla bla - bla - bla. Blabla bleee.

94

Majzaaaaammmmmmmmmm

http://atari.pl/hsc/ad.php?i=1.

95

xxl napisał/a:

Majzaaaaammmmmmmmmm

Ni chu :)

Pecus napisał/a:

tyle że na razie jest jedna wersja biblioteki, chodząca tylko po standardowym SIO w gęstości SD/ED a reszat w planach, albo napisz se.

No to poczekajmy chwile czy się nie pojawią


Pecus napisał/a:

Pamiętaj też że jest to DOS niezgodny na poziomie API z innymi DOSami. A masz w tej chwili na atari conajmniej kilka standardowych systemów plików i wiele standardowych urządzeń podpinanych innymi niż SIO interfejsami.

Tylko że zgodność API nie ma tu żadnego znaczenia , bo to problem programisty piszącego grę pod xBios - ma w zasadzie odpalić jeden konkretny program i już. A on sobie będzie z niego korzystał.

Pecus napisał/a:

Dlatego też i powtórzę to słowo za CHORE uważam pisanie gry/programu,, tak by wymagał on xbiosa, jeśli program ten nie potrzebuje żadnej jego funkcjonalności i spokojnie działałby pod dowolnym DOSem przez ustandaryzowane przez lata CIO.

Ja też tak uważam - Mazezam traktuje jako demonstrację xBiosa raczej. Ale już tebe wspominał że to dobry pomysł w przypadku konstruktora do Panga.

Pecus napisał/a:

xbios ma sens przy programach, które potrzebują tony wolnego RAMu, a i tak traktować je należy wtedy jak programy całodyskowe z namiastką dostępu do plików.

Zgoda - tylko jeden mały problem - gry całodyskowe uzależnione są od struktury nośnika bo jadą po konkretnych sektorach. Dlatego np. w taki A.D. 20xx (i nie pamiętam numeru) sobie nie zagrasz na IDE+ bo gra jest dwustronna, strony dyskietki po zabootowaniu zmienić się nie da, a ponieważ nie ma tam plików, to nie wrzucisz też wszystkiego do jednego katalogu czy ATRa. Pod xBiosem nie byłoby problemu, gdyż z tego co rozumiem, to jest ten rodzaj gier "całodyskowych", które mają normalne pliki i możesz sobie przerzucić to na inny - pojemniejszy nośnik. O ile istnieje dla niego xBios.

A nie sądzę żeby długo trzeba było czekać.


Pecus napisał/a:

A co robi CIO ? Znane, ustandaryzowane i posiadające "wersje bibliotek" (zwane DOSami, lub loaderami) do wszystkiego co znamy i nie trzeba pisać kolejnych, tym bardziej że DOSy dodatkowo oddzielają jeszcze filesystem od sprzętu. Co więcej standardowo napisany program działający przez CIO zadziała także BEZ PRZERÓBEK z magnetofonem np. w TURBO 2000 czy nawet w normalnej transmisji, na RAMdysku itp.

Tak tylko to zajmuje pamięć. Podtytułem tematu otwierającego xBiosa - było - gry które lubią przestrzeń. Całej masy gier nie odpalisz z pod żadnego DOSa.

Pecus napisał/a:

Trzeba tylko dopasować implementacje do potrzeb. A w Mazezam jedyną potrzebą jaką XXXL uwzględnił jest to że ma udowodnić sens istnienia xbiosa.

Tu się zgadzam :D Mazezam nie ma absolutnej potrzeby używania xBiosa. Tym niemniej uważam że xBios ma sens (być może gdyby autorzy Ridiculous Reality - skorzystali z tego zamiast swojego ridiculous rozwiązania, dałoby się pod emulatorem normalnie zapisać i odtworzyć stan -  nie mówiąc o tym, że nie byłoby to potrzebne, bo można by wybrać dowolny level na przykład.

xxl napisał/a:

Majzaaaaammmmmmmmmm

Nic z tego. Sam żeś Waść to uczynił, to teraz się przyglądaj ;)

The problem is not the problem; the problem is your attitude about the problem

96

xxl napisał/a:

nieprawda. programista nie ma ZADNEGO wplywu na to z jakiego urzadzenia IO korzysta user.
jedyne co autor gry moze to ZABLOKOWAC mozliwosc uzywania urzadzenia dodatkowego a caly ruch obslugiwac z urzadzenia podstawowego.

autor, wybierajac xbios - decyduje o tym na czym to sie ma uruchamiac, bo poki co dostepne sa chyba 2 wersje xbios, sd i dd, prawda?
tak wiec wybierajac xbios - jak najbardziej ma wplyw na to z jakiego urzadzenia moze skorzystac user. przeczac jedynie siejesz FUD.

nie piszmy poki co o czyms co w przyszlosci moze bedzie, a moze nie bedzie (vide xbios na carty, obsluga spraty, cokolwiek).
ja wiem, a gdyby w przyszlosci stalo tu przedszkole - ale poki co go nie ma.

The UNIX Guru`s view of Sex:
unzip; strip; touch; finger; mount; fsck; more; yes; umount; sleep

97

jellonek napisał/a:

nie piszmy poki co o czyms co w przyszlosci moze bedzie, a moze nie bedzie (vide xbios na carty, obsluga spraty, cokolwiek).

Co do obsługi Sparty, to już widzę "mały problem", potrzebne są dwa bufory. W przypadku dysku o sektorach 256b to dodatkowa strona pamięci do zajęcia przez xbios i dobijamy do MEMLO SDX, a jak zechcemy dodać sektory 512b.... uuuuu to już mamy w xbiosie wyższe MEMLO niż SDX w trybie BANKED, a funkcjonalność pozostaje mizerna.

Bla bla bla bla, bla bla bla. Bla bla bla - bla - bla. Blabla bleee.

98 Ostatnio edytowany przez jellonek (2012-10-30 14:43:32)

wieczor napisał/a:

xBios nie jest częścią gry a jedynie obecnie został do niej dołączony, aby oszczędzić użytkownikom poszukiwań.

gra czy dowolny program jest zalezny od xbiosa tak jak moze byc zalezna od "ustalonego wspolnego subsetu dosa". roznica polega na tym, ze korzystajac z ustalonych dekady temu wywolan dosa - soft zadziala ci wszedzie, bo sa dosy dzialajace na roznych urzadzeniach.
xbios obsluguje wylacznie sio, wylacznie atari dos ii fs (jednak poki co autor nie uscislil o ktory subset chodzi, wiec nie wiadomo czy obsluguje katalogi czy nie), prawdopodobnie tylko sektory 128b/256b.

ps. jesli skompilujesz binarke na bsd (format elf), linkujac z libc bsd - ta sama binarka, mimo tego samego formatu pliku (tez elf) nie zadziala pod linuksem. linkujac binarke do okreslonego liba, przywiazujesz ja do srodowiska w ktorym ten lib dziala, wiec pierd...nie o przenosnosci/niezaleznosci od rozwiazania jest po prostu irytujace.

wieczor napisał/a:

I teraz: masz HDD - ładujesz xBiosa dla HDD.

tak? pokalinka!
poprosze o takiego ktory dziala na SIDE. nie musi byc sparta, nie musi byc obslugiwany 512b sektor, ani 128b.
odpowiedz w stylu "napisz.se" - nie jest odpowiedzia na moja prosbe.

wieczor napisał/a:

xBios dla carta siłą rzeczy jest na karcie (bo może) więc nic nie ładujesz.

ale tych wersji xbiosa nie ma i niektore po prawdopodobnie nie powstana. moze bedzie obsluga maxflash, moze sic, a co z reszta? napisz.se?

wieczor napisał/a:

Cały czas te same gry. Gra nie może sobie powiedzieć że chodzi tylko na jakimś tam urządzeniu - ona chodzi na xBiosie.

i w tym problem. dotychczasowe produkcje (wylaczajac calodyski) mozna okreslic mianem "dzialaja na atari".
tu raczej trzeba napisac ze "dzialaja na atari, do kotrego masz xbiosa".

wieczor napisał/a:

Jeśli xBios obsługuje dane urządzenie, grze nic do tego.

no wlasnie, xbios nie obsluguje urzadzenia/filesystemu - gra na nim nie dziala. grze na pewno nic do tego, ale autorowi gry? ma sam sobie zawezac liczbe obslugiwanego sprzetu? ma w ten sposob skreslac potecjalnych odbiorcow, bo kilka stron pamieci wiecej dostanie?

wieczor napisał/a:

Nie widzę problemów, żeby powstał xBios dla FS-a Sparty - a gra chodząca pod xBiosem nie ma nawet zielonego pojęcia o tym, bo jej to nie obchodzi. xBios ją separuje od sprzętu.

a ja widze - bo kto niby to by mial napisac? masz pewnosc ze zmiesci sie w tej samej ilosci kodu, w ktorej miesci sie xbios na ataridosii fs?
w przypadku fs to jeszcze nie jest tak problematyczne, jak w przypadku urzadzen pbi. jako wprawke polecam napisac odczyt/zapis sektora na SIDE, bo poki co nie widze na sieci zrodel pokazujacych jak to zrobic.

wieczor napisał/a:

Ideą xBiosa jest natomiast to, aby dana wersja nie chodziła ze wszystkim, bo musiała by mieć procedury obsługi wszystkiego, co zabija jego ideę - minimalną zajętość pamięci.

raczej by dzialala na altirrze i byc moze na sprzecie autora.

Pecus napisał/a:

a jak zechcemy dodać sektory 512b

a zechcemy? podejdz do tego realnie - kto by sie tego podjal i po co?

The UNIX Guru`s view of Sex:
unzip; strip; touch; finger; mount; fsck; more; yes; umount; sleep

99

ps. na pc tez poczatkowo powstawaly "calodyski", po czym ludzie sie obudzili ze niskopoziomowe przywiazanie do sprzetu choc na pierwszy rzut oka ma swoje plusy (sporo spraw potrafi uproscic), ale minusy przewazaja.

widac ktos poza granice tego pierwszego rzutu oka jeszcze nie wyjrzal...

The UNIX Guru`s view of Sex:
unzip; strip; touch; finger; mount; fsck; more; yes; umount; sleep

100 Ostatnio edytowany przez Pecus (2012-10-30 14:54:12)

Na Atari 8bit też ludzie się obudzili jakiś czas temu, było przerabianie wszystkiego na standardowe pliki, a nowe produkcje starają się działać przez CIO (nawet dema - Numen na przykład), bo to po prostu jest wygodniejsze. Ale chyba niektórzy znowu zasypiają ;)

Bla bla bla bla, bla bla bla. Bla bla bla - bla - bla. Blabla bleee.