MapRAM, pomimo że ciekawy, to już w ogóle jest rzecz, która może być i na zawsze pozostanie tylko ciekawostką. Chyba, że spowodujesz, że wszystkie Atari na świecie nagle zyskają tą modyfikację.

Cyprian, pełna zgoda, też tak myślę o standardzie i wszystko co powyżej 64k to już jest rozszerzenie.

Natomiast w kwestii co jest najlepszym wariantem na dzień dzisiejszy, to ja bym powiedział, że jak już ktoś ma chęć rozszerzać pamięć, to najlepiej zrobić to od razu do 1MB, bo to jest na dziś taka ilość RAM-u, która zapewni, że pójdzie nam na pewno wszystko co powstało i powstaje na jakiekolwiek rozszerzone konfiguracje. Jak dziś robić rozszerzenie, to 1MB warto też ze względu na to, że obojętnie jak bardzo rozszerzamy pamięć, to roboty jest mniej-więcej tyle samo, a koszt samego RAM-u praktycznie pomijalny, bo też nie będzie różnicy za dużej w cenie czy kupujemy 64k czy kupujemy 1MB, bo te pamięci po prostu stanowią dziś taki sam złom, więc raczej liczy się jego waga i koszt przesyłki niż ilość pamięci w scalaku:-)

Standardem było dla mnie zawsze 64k, bo rzadko kto miał 130XE. A myślisz, że dlaczego nie było prawie nic na wersję 130XE? Może właśnie dokładnie z takiego samego powodu z jakiego teraz tutaj toczymy tą dyskusję. W latach świetności Atari też zapewne prowadzono takie dyskusje i doszli do wniosku, że bez sensu jest robić grę dla mniejszości, lepiej zrobić pod 64k, wtedy dotrze do wszystkich. W tamtych latach tego tak nie rozumiałem, ale dziś tak sobie myślę, że może raczej wersja z większą pamięcią nie miała być krokiem naprzód w sensie, że będą lepsze gry, ale bardziej krokiem równoległym otwarcia wersji komputera dla deweloperów i ludzi, którzy pracują przerzucając większe ilości danych itp. Czyli ułatwienia typu ramdyski itp.

979

(16 odpowiedzi, napisanych Emulacja - 8bit)

Łeeee, popsułeś zabawę...

No tak, ja też mam Maxflashe, SIC!e, a we wszystkich swoich Atarkach mam 1MB. Jednak z powodu chęci trafienia do jak najszerszej rzeszy odbiorców ze swoimi produkcjami (na razie z jedną) celuję w stock 64kB i zrobię wszystko, żeby się udało to odpalić na takim właśnie sprzęcie, a przy okazji da mi to największą satysfakcję z osiągniętego celu. Niemniej jednak jeśli się nie uda i miała by na tym ucierpieć jakość produkcji, to zrobię to tak, żeby z kartridża dało się odpalić na stock 64kB, a bez kartridża z pliku xex na rozszerzonej pamięci do 128kB. Akurat przy obecnej produkcji nie przewiduję, żeby było potrzeba jeszcze więcej RAM-u, ale gdyby było potrzeba, to wtedy zrobił bym to dokładnie tak samo, czyli z kartridża zawsze ma działać wszystko na stock 64kB, a z xexa na dowolnym rozszerzeniu pamięci wskazanym przez kodera (w sensie dowolności ilości RAM, ale pozostańmy chociaż przy zgodności rozszerzeń z portB jako utartego standardu).

981

(16 odpowiedzi, napisanych Emulacja - 8bit)

A co, miałeś tam skrycie U1MB? Hehe:-)

Jacques napisał/a:

Według mnie większość produkcji powinna celować w RAM o wielkości WYSTARCZAJĄCEJ do zrobienia danej produkcji BEZ UTRATY PLANOWANEJ JAKOŚCI (z powodu ograniczenia RAM).
Czyli niezbędne minimum: czasem wystarczy 64KB, czasem 320KB, itd.

Dokładnie tak samo myślimy tutaj:-)

Pin napisał/a:
Sikor napisał/a:

No, ale jak odłączysz pamięć to spokojnie wyprowadzisz 2 dodatkowe gniazda.

... nieeeee, nie wolno dotykać plomby z Pewexu :)

Pin, a U1MB, to zamontowałeś sobie przez szczelinę kartridża tak jak się buduje okręty w butelkach?:-)

Nie, dzielić nie będę. Robię tę grę już ponad rok czasu, zakładałem, że będę ją robił tak długo jak będzie trzeba, że nie będę szedł na skróty, nie będę robił kompromisów, wszystko dopnę na ideał taki jaki sobie z góry wydumałem. Założenie było podparte tym, że kiedyś marzyłem o zrobieniu "prawdziwej" gry na Atari i spełniam to marzenie, a ponieważ zajmie mi to masę czasu i prawdopodobnie będzie jedyną grą jaką zrobię, to nie spieszę się. W tak zwanym międzyczasie naszło mnie parcie na chwalenie się (próżność) i trochę zacząłem pokazywać różnym osobom i wrzucać zajawki na fora, no i teraz głupio mi jest, że ciągle termin się oddala, a już jest grupa ludzi, którzy na tę grę czekają, bo im się podoba. Dlatego staram się jednak cisnąć i przyspieszać prace. W tak zwanym międzyczasie wydarzyło się coś jeszcze istotnego, co też mocno zmienia koncepcję: mianowicie założenie, że to będzie jedyna gra w życiu zostało przekreślone, bo mam już dwa kolejne pomysły na gry i bardzo bym się nimi chciał już zająć. Nie chcę jednak tego robić, zanim skończę Dude Story, bo za chwilę wzorem innych będę miał milion zaczętych gier i żadnej dokończonej... Dlatego pojawiają się rozterki czy warto tyle godzin poświęcać na te wszystkie optymalizacje i ciśnięcie się za wszelką cenę w 64k.

Sikor, oczywiście można doczytywać, ale OS wyłączony, żeby mieć więcej RAM, wszystko powywalane, więc jak na koniec zabraknie 3,5kB, o będzie trzeba wszystko przebudować, żeby dodać procedury do doczytywania, a w dodatku będzie mega głupio wyglądało jeśli przejdziemy całą grę i na samym końcu kawałeczek będzie trzeba doczytać:-) No i nie będzie w pojedynczym xex, a chcę żeby było. Doczytywanie ma sens jak od początku założymy że ma być doczytywane.

Testerzy są jak na razie zachwyceni:-)
Jednak nie chodzi tu o wybór między dopracowaniem grafiki lub grywalności. Zakładam, że będzie dopracowana pod obydwoma względami, jak również pod trzecim, czyli muzyka, która jest tutaj również dla mnie mega ważna. Pytanie jest czy w sytuacji kryzysowej postawić na więcej RAM-u, czy na pogorszenie gry w jakichkolwiek aspektach.
U mnie się rzecz nie będzie rozbijać o to żeby pogarszać grywalność czy grafikę, bo cały silnik, grafika, muzyka itd będzie już dopracowane, ale nie wiem, czy zmieści się na koniec cały scenariusz i może się okazać, że ten wybór będzie taki, że gra się stanie zbyt krótka przy 64k, więc może lepiej wtedy wyjść ponad 64k żeby zmieścić cały zakładany scenariusz i np. nie uciąć 1/4 scenariusza skracając grę... Bardzo tego nie chcę robić, bo to się właśnie odbije na rozczarowaniu zbyt szybkim końcem gry. Taka sytuacja miała miejsce np. w grze Crownland, którą w Gramy na Gazie Borsuk przeszedł z zachwytami, a na koniec usiadł i nastała taka niezręczna cisza...

No jak to? 320kB to popularne rozszerzenie, ponieważ było robione już w dawnych czasach. Ta ilość RAM wynika z faktu, że na rynku podzespołów elektronicznych dostępne są kości 256k x1bit i 256k x4bit, a to powoduje, że łatwo jest rozszerzyć właśnie o taką ilość pamięć w Atari zarówno z pamięciami 1-bit jak i 4-bit poprzez nalutowanie "na barana" odpowiednich kości i dodanie odpowiedniej logiki do tego. Takie rozszerzenia są i były popularne dlatego, że można je robić nawet "na pająka" bez żadnych płytek.

Edit: rozszerzenie do 128k robi się tak jak jest zrobione w 130XE. Do 192k robi się tak, że lutuje się kolejne 64k "na barana". Do 256k robi się tak, że do 130XE lutuje się na oba 64k kolejne 64k.
512k to tak na prawdę 576k. DOdaje się osobno 512k pamięci, najlepiej jako SRAM (rozszerzenie Hias-a).
1024 to tak na prawdę 1088 - tu mamy np. SIMMexp, albo U1MB, albo satantronic.
Nie słyszałem o wyrzuceniu podstawowego 64k i zamiast tego 1024. Trochę nie wyobrażam sobie jak by to zrobić, było by trudno i nie było by kompatybilne za bardzo z rozszerzeniami typowymi na port B. Ale może się mylę i ktoś naprostuje.

Zagłosowałem na 64k.

Co prawda we wszystkich swoich Atarkach mam 1MB, bo sam sobie robię i lubię, ale jednak twierdzę jako zwykły użytkownik, że większość nowych gier powinno celować w stockowe 64k, chociażby z tego względu, żeby trafiło do jak największej liczby odbiorców, żeby ktoś kto wyciąga swoje Atari dzisiaj z przysłowiowego pawlacza po 30-stu latach, mógł sobie uruchomić na nim nowości i zachwycić się, że od poprzedniego uruchomienia w latach 90-tych do dziś wyszło tak dużo fajnych rzeczy, w które znowu można sobie pograć i poczuć się jak kiedyś.

Jako "scenowiec" w ogóle się nie wypowiadam, bo nim nie jestem. Chyba, że rozszerzymy tą kategorię o programistów-twórców, to mogę się wypowiedzieć, bo od ponad roku pracuję nad dużą grą. Początkowo zakładałem, że nie będę w ogóle się ograniczał pamięcią, bo przecież dziś to żaden problem ją rozszerzyć i większość ma jakieś tam rozszerzenie. Z czasem jednak znalazłem mega zajebistą zabawę i frajdę w optymalizacji, więc wycelowałem sobie w 128k jako maksimum. Idąc dalej obecnie tak bardzo optymalizuję, że zaczynam się powoli łudzić, że może uda mi się zmieścić w stockowe 64k. Powstają jednak dylematy: czy jak już dobiję do krawędzi i zacznie mi tego RAM-u brakować, to lepiej obciąć grę, czy lepiej podnieść ilość RAM? Najbardziej boję się tego, że dojdę do 64k i zabraknie mi np. 3,5kB. Wtedy kolejne pytanie, czy warto było wydłużyć deweloperkę gry o rok, a potem i tak zrobić grę na 128k i czy warto było tak wszystko upychać, a potem po przekroczeniu tej granicy i tak musi być 128k, z czego np. 50k jest puste...

W temacie kartridży, ja bym się tutaj w ogóle nie ograniczał i nie dyskutował nad tym ile tam jest pamięci. Jak mieliśmy dawniej gry czy programy na kartridżu, to nikt nie wiedział ile pamięci ma kartridż, po prostu gra była na kartridżu i tyle. Natomiast osobiście nie lubię jak gra jest tylko i wyłącznie na kartridżu, bo przez to w dzieciństwie nie miałem zielonego pojęcia o istnieniu pewnych gier, w które zagrać można dopiero współcześnie, bo powstały wersje na rozszerzony RAM (np. Commando). Z tego powodu nie mam absolutnie nic przeciwko temu, żeby robić gry na rozszerzoną pamięć, ale mi by się podobało, żeby zawsze zrobić absolutnie wszystko co jest w mocy kodera, żeby zmieścić się w stockowe 64k, a dopiero jak już na prawdę się nie da, to sięgać po rozszerzony RAM, przy czym tu już nie ma znaczenia jak bardzo rozszerzony, niech koder decyduje. Ale jednocześnie niech to będzie tak, że ilość rozszerzonego RAM-u powinna być proporcjonalna do szczękoopadu na widok jakości/możliwości/innowacyjności itd.itp.

Reasumując można by powiedzieć, że rozszerzony RAM widział bym jako powiększenie możliwości, a nie jako wykorzystanie z lenistwa, czy dla uproszczenia/ułatwienia realizacji celów, które dało by się równie dobrze zmieścić w mniejszym RAM-ie. Może też służyć ulepszeniom na zasadzie, że powstaje gra, która doczytuje się z dyskietki i działa normalnie na stock 64k, ale jak ktoś ma rozszerzony RAM, to ma alternatywnie xex-a, który w całości się wczytuje i nie wymaga później doczytywania. Taki model lubię najbardziej.

987

(16 odpowiedzi, napisanych Emulacja - 8bit)

xxl napisał/a:

drugi cart gdzie przelaczanie bankow odbywa sie w ten sposob: sta $D500,X (np. X=1) zamiast STA $D501 dziala... o co biega z Altirra ?

W Maxflash przełącza się banki robiąc zapis dowolnej wartości pod adres odpowiadający danemu bankowi. A więc np. $D500 to jest bank 0, $D501 to jest bank 1, $D502 to jest bank 2 itd.
Czyli żeby wybrać bank, to robisz po prostu sta $D500
Bank przełącza się gdy na szynie adresowej pojawi się odpowiedni adres, a jakie są wtedy dane na szynie danych nie ma żadnego znaczenia.

xxl napisał/a:

dziala poprawnie tylko na AtariWin+ poniewaz na Altirze ... nie dzala przelaczanie bankow - wszystko co potrafi to przelaczyc bank 0 i odlaczyc carta

Jeśli działa tylko przełączanie na bank zerowy i odłączanie carta, to by znaczyło, że być może komp się po prostu resetuje? Jeśli masz włączony OS, to musisz pamiętać, że w trakcie zmiany stanu kartridża z włączonego na wyłączony i odwrotnie musisz mieć wyłączone przerwania, bo OS w VBI sprawdza co ramkę czy nagle nie był wyjęty albo wsadzony kartridż i wtedy resetuje system.

988

(24 odpowiedzi, napisanych Software, Gry - 8bit)

Ja po prostu lubię prawdziwe Atari:-)

xBIOS też lubię:-)

989

(24 odpowiedzi, napisanych Software, Gry - 8bit)

Dla mnie gra, to gra. Patrząc z zewnątrz nie jestem w stanie zauważyć czy tam jest xBIOS czy go nie ma. Pod emulcem po prostu odpalam i gram, na prawdziwym Atari też po prostu odpalam i gram. Wszystko śmiga jak należy ;)

990

(24 odpowiedzi, napisanych Software, Gry - 8bit)

Wygląda fajnie. Nigdy nie grałem w tego typu gry, jakoś mnie nie zainteresowały, więc nie umiem, ale teraz spróbuję z tym się pobawić zatem:-)

991

(16 odpowiedzi, napisanych Emulacja - 8bit)

Pod Altirra działa bin, nie ważne jest rozszerzenie. Ja odpalam obrazy kartridży tak, że mam uruchomioną Altirrę i plik obrazu przeciągam na okienko Altirry. Wtedy pokazują się w okienku Altirry po prawej stronie urządzenia pod które możesz podmontować plik i tam na samym dole jest kartridż, więc tam należy ten plik przeciągnąć. Jak się upuści na tym plik, to jeśli nie jest to plik car, tylko goły obraz, to wyskoczy okienko z pytaniem jako co chcemy plik podpiąć i tram już wybieramy sobie odpowiedni typ kartridża.

Edit: aha, jak tak podpinamy obraz kartridża, to jeszcze trzeba dać reset w Altirra (F5) i wtedy nam Atari wstanie z tym kartridżem.

992

(17 odpowiedzi, napisanych Bałagan)

No tak, ale idziecie w jakieś ślepe zaułki. Sprzedaż perhydrolu nie jest ani zakazana, ani nawet problematyczna. Po prostu są przepisy regulujące zasady przechowywania, transportu, handlowania różnymi substancjami chemicznymi i tyle.

993

(17 odpowiedzi, napisanych Bałagan)

No tak, ale ja nie jestem urzędnikiem państwowym, więc chyba zgodzisz się, żebym mógł mieć to gdzieś? ;)

994

(17 odpowiedzi, napisanych Bałagan)

Dobra, ale cóż to kogo obchodzi czy ktoś kupił, czy ktoś sprzedał. Napisałem tylko czego dowiedziałem się od sprzedawcy prowadzącego hurtownię z chemikaliami, bo temat dotyczy przepisów. To, że ktoś na allegro sprzedaje nie przejmując się przepisem, to tym bardziej mi wisi, niech se każdy robi co chce, co mnie to obchodzi. Ja nie widzę też problemu w zakupie perhydrolu z NIPem czy bez, nie robi mi to najmniejszej różnicy.

995

(17 odpowiedzi, napisanych Bałagan)

Wiesz co, ja już nie pamiętam gdzie kupowałem, bo to było dość dawno, ale właśnie w jakiejś takiej hurtowni chemicznej internetowej. Po zakupie jak dołożyłem sobie perhydrol do zamówienia, to dostałem telefon i bardzo miły pan z obsługi poinformował mnie, że nie wolno im perhydrolu sprzedać osobie prywatnej, bo takie są przepisy. Akurat miałem firmę, więc podałem tylko dane i wysłali, nie było problemu. Zapytałem tylko czy to może być firma o dowolnej działalności, bo ja nie mam nic wspólnego z chemią, powiedział, że dowolna działalność może być, bo chodzi tylko o to, żeby było zarachowane dla kogo poszło. Więcej się nie wypytywałem, bo tak jak mówię, dla mnie nie był to żaden problem i różnicy mi nie robiło.

996

(9,967 odpowiedzi, napisanych Bałagan)

Fajne:-) 15 minut se generowałem przeróżne obostrzenia. Muszę komuś za to fakturę wystawić, bo w godzinach pracy generowałem:-)

997

(17 odpowiedzi, napisanych Bałagan)

Wiesz co, to już było od dawna, ale tam nie chodzi o to, żeby jakoś dokumentować szczególnie do czego się to używa, tylko chodziło o to, że te preparaty ze względu na to że są niebezpieczne, to muszą być ściśle zarachowane do kogo poszły, jakim transportem itd.
Jak kupowałem kiedyś perhydrol 35%, to też mi koleś powiedział, że musi po prostu wystawić fakturę na jakąś firmę, więc zwyczajnie kupiłem na swoją firmę i już. Wtedy dowiadywałem się i mógł to kupić każdy na obojętnie jaką firmę. Możesz być np. taksówkarzem i sobie kupić perhydrol, bo chcesz w samochodzie sobie wybielić gajgę od kierunkowskazu i nikt się nie ma prawa przyczepić.
Po prostu sprzedaż tych preparatów nie może być anonimowa i to tyle.

998

(128 odpowiedzi, napisanych Programowanie - 8 bit)

Tak, szybkość jest dla mnie istotna, bo w locie rozpakowuję plansze w grze podczas przechodzenia z planszy do planszy i nie może być za długo czarny ekran, bo się gracze zniechęcą, żeby nie powiedzieć wq...ą:-)

Takie rozpakowanie u mnie za pomocą apl, to jest 6k danych graficznych, plus dwa fonty po 1k, więc 8k musi się rozpakować w czasie do sekundy. U mnie to trwa za pomocą unapl standardową biblioteką z Mad Pascala jakieś 40-50 ramek.

Teraz doczytałem we wcześniejszych postach, że testowałeś dane podobnej wielkości i już po optymalizacjach uzyskałeś 488 ramek, czyli około 10x wolniej niż apl. W takim razie odpuszczę, może mi się ta kompresja przyda kiedyś do innych zastosowań, widać do innych celów jest shrinkler.

999

(128 odpowiedzi, napisanych Programowanie - 8 bit)

Spakowałem sobie testowo grafikę, muzykę, fonty, które jak dotychczas najlepiej mi się pakowały apl. Jestem pod wrażeniem, bo wszystko pakuje się o jakieś 10% bardziej, więc oszczędził bym bardzo dużo miejsca w grze, korzystając z tego shrinklera zamiast apultra.

Mam kilka pytań:

1. Jak wygląda szybkość rozpakowania na Atari z jednego miejsca pamięci w drugie w porównaniu do apl? Ta szybkośc jest już dla mnie dość krytyczna, unapl działa mi tak w sam raz, minimalnie wolniej jak będzie to jeszcze przełknę, ale jeśli by to miało się rozpakowywać np. dwa razy wolniej, to już dla mnie nie do przełknięcia.

Nie jestem za szybki w analizowaniu tego kodu assemblerowego, więc czy mógłbym prosić o wyjaśnienia:

2. Czy dało by się zrezygnować przynajmniej częściowo z użycia strony zerowej? Z tego co widzę potrzeba 20 bajtów, chyba tyle nie mam...

3. Czy depaker korzysta z jakiegoś bufora? Widzę na końcu kodu jakieś definicje, ale jak dużo miejsca potrzeba i gdzie się lokuje w pamięci? Ogólnie prosił bym o wyjaśnienie z jakich zasobów pamięci korzysta ten depaker.

1,000

(734 odpowiedzi, napisanych Kolekcjonowanie)

Cztery identyczne joysticki podłączone jednocześnie każdy do swojego kompa, to już trochę ekstrawagancja:-) Fajny stryszek, gratuluję:-)