Nie wierzycie ? Ja również ! Po raz siódmy zdecydowałem się na organizację eventu, który miał być tylko pojedynczym epizodem w mojej scenowej aktywności w roku 2000. Ten rok jest dla mnie bardzo trudny pod wieloma względami, jednak podejmuję rękawicę - mam świadomość jak wiele udało nam się wspólnie osiągnąć. Zintegrowanie międzynarodowej społeczności od Atari 2600 po Jaguara wydawało mi się kiedyś rzeczą raczej mało prawdopodobną - od 2010 roku stało się jednak faktem ! Jesteśmy jedną wielką Rodziną.
You want it?! YOU GET IT! :)
Mam nadzieję, że ponownie podołam temu wyzwaniu. Dziękuję wszystkim za dotychczasowe wsparcie (jest Was zbyt wielu, abym mógł wszystkich wymienić!) i proszę o jeszcze.
Już wkrótce pojawi się więcej informacji o SV2k14, a także pierwsze niespodzianki.
SV2k14 odbędzie się w dniach od 5-go do 7-go Grudnia (piątek-niedziela) i dedykowane jest 25-leciu komputera Atari STe. Logo tegorocznej edycji Silly Venture wygląda tak:
Autor:mOOnie / Mystic Bytes
Pamiętajcie - ATARI będzie żyło tak długo, jak długo nie opuści naszych serc.
Silly Venture 2k14 - the loudeST voice of the Atari scene !
You don't believe it ? Me neither ! It's the 7th time that I've decided to organise the event, which was supposed to be only a single episode in my scene activities back in year 2000. This year is very hard for me due to many things, however I again pick up the gauntlet. I am conscious of how many things we have achieved together. Integration of the international Atari community from Atari 2600 to the Jaguar seemed to be a rather impossible thing - but from year 2010 it became a fact ! We are one big Family.
You want it?! YOU GET IT! :)
I hope to manage to do it right again. Thanks to everyone for their previous support (there's too many of you to mention!) and I ask for more.
Further information about SV2k14, amongst will be some surprises, will pop up soon.
SV2k14 will take place on the 5th - 7th of December (Friday - Sunday) and is dedicated to 25 years of the Atari STe computer. The logo of this year's Silly Venture looks like this:
Author: mOOnie / Mystic Bytes
Remember - ATARI will live as long as it doesn't leave our hearts.
-Pin nie te czasy, gdzie człowiek jechał do Ornety i zastanawiał się czy zabrać monitor czy śpiwór/karin matę. Wybór był prosty śpiwora nie podłączę do Atari.
Takie czasy.. kiedyś wsiadałem na 30 letniego Junaka i jechałem na drugi koniec Polski, a teraz mając 70 konną Vke, zastanawiam się czy wyjazd 200km to nie za daleko, kapcianieje człowiek i tyle.
Kochaaany... Pan masz drobnomieszczańskie nawyki... Pan chciałbyś mieć tak, zimne wode osobno, ciepłe osobno, kraniki, dywaniki, kafelki, duperelki, szczelne rurki... Chamstwo! I drobnomnieszczaństwo z Pana wylazło :)
@marekp: ok, w sumie można listę otworzyć o wiele wcześniej :) będziesz na pozycji no. 1 :)
I teraz mała ciekawostka: na SV2k12 z przyczyn "obiektywnych" nie została zaprezentowana praca na STe. Autor poczekał do SV2k13 robiąc małe poprawki - to samo :) Teraz dostałem wiadomość, że chce ją zaprezentować na... SV2k14 :D Miło.
@wieczór: tak :) ciągle poprawiana bo nie pokazana :D myślałem że autor się wkurzy i naturalnie wystawi ją na innym party - on chce jednak czekać do SV2k14, eh :)
No to skoro mamy pierwsze demko w marcu to ciekawa impreza się szykuje;) Może tym razem niech trwa tydzień, aby kompoty można było przynajmniej zaprezentować w całości ;)
Choć jak sobie przypomnę minę Rega jak powiedział że naliczył się ~115 prac na compo to ;):)
A ja pozwoliłem sobie rozesłać wici po znajomych grafikach/architektach, którzy za dziecka bawili się atarynką. Mam nadzieję, że nie przestraszą sią narzędzi i będzie co w grudniu oglądać:)
Mi do pikslowania bardzo podszedł Fireworks. Fakt, że nie ma dedykowanej rozdzielczości z pikselem 2:1 ale paletę można sobie wczytać, a biorąc pod uwagę narzędzia itp. to jest całkiem wygodne.
Ale rozdzielczość ekranu nie ma nic do rzeczy :) Niezależnie od rozdzielczości ekranu chodzi o rozdzielczość edytowanej bitmapy. Zmiana rozdziałki ekranu spowoduje może że będzie to wyglądać inaczej ale wszystko wtedy będzie wyglądać inaczej.
Ja radzę sobie w ten sposób, że włączam grida 2:1 i piksluję z dokładnością co do grida - czyli 2 sąsiednie piksele, parzysty i nieparzysty zamalowuję parami. Tak przygotowana bitmapa daje pojęcie jak to będzie wyglądać. Oczywiście ma dwa razy więcej pikseli w poziomie - na koniec trzeba zrobić resize obrazka wybierając metodę nearest neighbour - czyli żadnego resamplingu, wytnij co drugi piksel. Obrazek wtedy schudnie w poziomie i można go wyeksportować. Po wczytaniu na atari czy do G2F proporcje wrócą.
G2F jest dobry do konwersji, ew. małych poprawek plus żonglowanie typowo atarowskimi mechanizmami typu DLI itp czyli kolorowanie. Rysować w nim - na szczęście - nie trzeba :)
Kochani, prezentuję Wam PROPOZYCJE do regulaminu na platformę Atari XL/XE nadesłane przez JAC!'a (Peter Dell). Bardzo liczę na rzeczową dyskusję.
Poniżej znajdują się 2 wersje - jedna przetłumaczona przez Wieczora z grupy LAMERS (dziękuję!!!) i jedna oryginalna nadesłana przez JAC!'a.
Ogólne zasady dla Atari 8-bit
Następujące zasady stosowane są do wszystkich plików wykonywalnych dla Atari 8-bit compo. Pierwszym powodem jest zapewnienie, że prace będą wyświetlane bez problemów czy przerw w czasie party. Powód drugi to zapewnienie możliwości upakowania prac w kompilacji wraz z loaderem aby promować party i zaprezentować wyniki. Jeśli potrzebna jest pomoc w zrozumieniu lub przestrzeganiu tych zasad, albo przetestowanie czy praca spełnia wymogi, skontaktuj się na adres [email]jac@wudsn.com[/email] lub na Atariage.
1) Pliki wykonywalne muszą ładować się pod DOS od adresu $2000 lub powyżej. Powód: W czasie party, prace są uruchamiane spod DOSa i łatwiej jest je umieścić w kompilacji.
2) Jeśli program wykorzystują przestrzeń $A000-$BFFF, powinny wyłączać BASIC w trakcie ładowania. Powód: Nie zmuszamy użytkownika do pamiętania czy ma nacisnąć OPTION czy nie. Przykładowy kod: LOADER LDA #$ff:STA $d301:LDA #$01:STA $3f8:RTS: INI LOADER
3) Programy nie mogą zmieniać adresów ZP: $08-$0d Powód: Adresy są używane przez procedure RESET. W przypadku ich zmiany, komputer zawiesi się po RESET. Starsza wersja G2F ma ten błąd. Prawdziwy komputer nie ma "SHIFT-F5" jak emulator.
4) Programy nie powinny nadpisywać głównego obszaru DOS lub menu ($400-$47f, $0700-$1fff) Powód: Obszary te używane są przez dopalacze, menu i DOS. Po nadpisaniu sprzęt wymaga rebootu.
5) Program nie powinien wywoływać lub ustawiać COLDST ($244) domyślnie. Powód: Wymuszenie zimnego startu marnuje czas użytkownika.
6) Jeśli reguła 5 nie może być zachowana, np. program wymaga obszaru menu lub DOS ($400-$47f, $0700-$1fff), powinien ustawić COLDST ($244) na $ff. Powód: Po nadpisaniu tych obszarów bez ustawienia COLDST, maszyna zawiesi się podczas RESET. Prawdziwy komputer nie ma "SHIFT-F5" jak emulator.
7) Program powinien wykrywać rozszerzenie RAM komputera.. Powód: Komputery mają różne rozszerzenia. Jeśli wspierasz jeden rodzaj, wielu ludzi może nie być w stanie uruchomić Twojej pracy.
The following rules apply to all executable entries for the Atari 8-bit compo. The first purpose of these rules is to ensure they can be shown without problems and interruptions at the party. The second purpose it to allow packing all the entries into a compilation with a loader menu to promote the party and its results. If you need support in keeping or understanding any of the rules or a tester, feel free to contact me at [email]jac@wudsn.com[/email] or at Atariage.
1) The executable must load from DOS to $2000 or above. Reason: At the party, entries are loaded from DOS and they shall be released as single disk compilation.
2) In case the executable loads to $A000-$BFFF, it must switch off BASIC while loading. Reason: Don't force the user to remember when to press OPTION and when not. Example code: LOADER LDA #$ff:STA $d301:LDA #$01:STA $3f8:RTS: INI LOADER
3) The executable must not change ZP addresses $08-$0d Reason: These addresses are used by RESET routine. If you change them, the machine will hang on RESET. Note that older G2F version have this bug. And real machines do not have "SHIFT-F5" like your emulator has.
4) The executable should not overwrite menu or DOS area ($400-$47f, $0700-$1fff) Reason: These areas are used by speeders, the menu and DOS. If your overwrite them you force the user to boot again.
5) The executable should not set or change COLDST ($244) by default Reason: If you force a cold start, this will waste the user's time.
6) If you cannot keep rule 5, i.e. the executable requires the menu or DOS area ($400-$47f, $0700-$1fff), it must set COLDST ($244) to $ff. Reason: When overwriting these areas without setting COLDST, the machine will hang on RESET. And real machines do not have "SHIFT-F5" like your emulator has.
7) The executable should auto-detect the actual extended RAM of the machine. Reason: Different machines use different upgrades. If you support just a single extension, many people will not be able to run your entry.
Miał być długi wpis - z odnoszeniem się do każdego punktu, ale wyszło, że będzie krótko. Kiedyś w ciężkich dyskusjach, wyszło nam (jako całemu środowisku), że im prostszy/krótszy regulamin tym lepiej. Co do samych punktów - w moim odczuciu w większości przeszkadzają. Zwłaszcza te, które rezerwują pewne obszary pamięci. Mamy permanentną walkę xxl vs pin o nielegale, które pozwalają urwać kilka cykli i bajtów, a tu pada propozycja by nieużywać ponad 6k ramu, czy stronę 2 na pół przeciąć...
@bob_er: to jest bardziej chyba zalecenie - o ile się da (tzn. wystarcza reszta pamięci) - wtedy używamy innych obszarów. Ale punkt 6 już zostawia furtkę - ok, nie da się, wtedy dopilnujmy żeby komp się poprawnie zrebootował (i tak będzie pewnie częściej).
Wydaje mi się, że trudno będzie organizatorom zweryfikować, czy dana praca jest zgodna z tak napisanym regulaminem. Zwłaszcza na szybko, na 5 min. przed kompotem.
Jeśli się okaże, że dana praca np. zmienia zawartość $08, ale nie daj boże wygrała? Dyskwalifikować, czy jak?
Gdybym ja miał coś wystawiać w myśl zasad takiego regulaminu to do samego końca nie wiedziałbym czy moja praca przejdzie :) A jak ktoś mniej obeznany z Atari zechciałby wystartować (np. taki "ja" dwa lata temu), to już całkiem byłby bezradny.
Grey raczej zawsze stawiał (i słusznie) na ilość prac w compo, dlatego też śmierdzi mi tu jakąś prowokacją :)
Myślę, że to raczej próba usprawnienia, a nie narzucania ograniczeń :) Ja coś tak czułem, że będzie opór (zauważam, że ja to tylko tłumaczyłem, i tak mi błąd wytknięto :) )
No ale jest to propozycja. Do dyskusji, ZMIANY, omówienia, własnej propozycji a nie po prostu tak czy nie. Ja się ze wszystkimi punktami nie zgadzam, 7 jest chyba niepotrzebny a 1 zbyt restrykcyjny.
Natomiast z aktualnego regulaminu, z którym nie wiem dlaczego nikt nie dyskutuje, wyrzuciłbym konieczność dodawania bank selectora - którego nikt chyba nigdy jeszcze nie użył (bo i już nie ma po co)
Bank selector jest wymagany w produkcjach dla >128k ramu. Sam muzykę do takiej pisałeś :P. Na 128k nie ma sensu, bo mamy standard - zwie się 130XE. Co do punktów, to pokolei: 1. Tego akurat pilnuję. 2. Piszę, by user sam sobie BASICa wyłączył, ale faktycznie, mógłbym sam wyłączać. 3. Tu może być różnie - nie wiem, czy będę miał pole manewru by ominąć te kilka adresów. 4. Nie ma mowy. 62k to za mało, by jeszcze ponad 6k odpuścić. 5, 6. To strasznie niewygodne będzie. Żadnej pełnej tablicy/kodu nie dasz na taki obszar. 7. Bank selector - napisałem wyżej...
ad 3. nie jestem koderem i nie mam pojęcia czy .xex wygenerowany przez wersję G2F, którą posiadam spełnia ten punkt (a może narusza jeszcze któryś z pozostałych?)
Poruszę sprawę prezentacji prac w gfx compo. Czy jest jakaś możliwość, żeby skonfigurować projektor pod paletę zbliżoną do atarowskiej, względnie uzgodnić, która z dostępnych dla G2F/emulatora da przy prezentacji najmniej przekłamany obraz? Rozumiem, że nie ma czegoś takiego jak paleta wzorcowa, ale chyba warto rozwiązać problem z zupełnie innym wyglądem obrazka wyjściowego z tym co ogląda się potem na party. Jak wiele traci się z niuansów kolorystycznych i detali mogliby powiedzieć chyba wszyscy graficy.
ad3 to nie jest błąd G2F, tylko zamierzony efekt, dotyczy szczególnego przypadku wykorzystania w programie rastra rozkazów 3 cyklowych (czyli strony zerowej), jeśli w każdej linii obrazu użyć innej wartości wówczas potrzebnych będzie 240 bajtów strony zerowej, przy optymistycznym podejściu
mało jednak osób używa rastra i pewnie mniej rozumie o czym tutaj piszę ;)
JAC is making the SV collection on one big ATR image since two years now - and me, I am making the ATR images for Abbuc Software Contest and Pro(c) Atari Magazine. Thus, we both have some experiences in this regard, which programs work under DOS or Gamedos, which programs are easy to handle and which programs are rather difficult or awkward to load (or sometimes require a patch or a fix)... ;-)
From my point of view, I see it like this: Abbuc has 400 members and most of them still use the real A8 ! If a program is completely Reset-proof, one has to switch off the Atari computer and then back on again, this is a) awkward and b) risky for a thirty years old computer ! So here are my subjective comments to the proposals (suggestions) above:
1) Errm, I would say the program should be loadable / start from DOS, it need not return to DOS after its executed; one could use e.g. Superpacker, Exomizer, Deflater, Code3-Cruncher etc. to load a packed file from DOS and when depacking, the DOS area could get overwritten, no problem...
2) Its nice, when a program that does not load with Basic enabled, switches off Basic automatically. On the other hand, we have Gameloaders / GameDOS versions on the A8 that do this automatically for ML files (e.g. MyPicoDOS). And being an idiot, I almost always add a Basic-off switch to the ML-files manually (with Superpacker), thats no big thing for me. (But sometimes idiotic, since the programmer may already did do this and I am to blind to see!)
3) Thats a must-have for me ! I still use my real A8 regularly and I hate programs (demos and games) that are absolutely reset-proof. Therefore, a) I often pack such programs with Code3-Cruncher (sometimes they are not reset-proof then anymore) or b) I add a Reset=coldstart ($244) routine manually. But there are programs where all these things fail and the program stays reset-proof, thats really bad, if not to say evil nowadays ! The programs by sack/cosine are such evil examples. Maybe I can bring Sack to court one day, in case my A8 dies, because of one of his reset-proof programs (and me having to switch off and on again, to load another program)... ;-)
4) Hmm, after depacking it should be allowed to overwrite DOS and/or Menu, shouldn`t it ? Set Reset=coldstart then and with a simple press on Reset one can return to (reboot) the menu.
5) Why not ? Reboot wastes time ? Playing Atari wastes more time! Or the "please wait 2 minutes for initializing" in some Basic programs. I guess, JAC always wants to return to his menu when Reset is pressed (without the need of re-booting). For me, its no problem if a program does an automatic coldstart after some time -or- if pressing Reset forces a coldstart. Booting a loader menu does not take that long (except from 600 baud tape maybe)... ;-)
6) Yeah, I love programs, where Reset forces a coldstart.
7) Errm, in the past we had 128k+ demos that worked only with a certain RAM upgrade - not good if you had a different upgrade. Later we had demos that came with a config. menu, thats better - but still annoying if you *always* have to set the config. before you can load the demo. I know that I have one or more demo (from Poland, don`t know the name right now) in my collection that loads automatically but also allows one to set the RAM config. The demo has a separate config-file, if this config file is not there (deleted) the config-program loads and one can setup the RAM upgrade then and create/save a new config-file. If the config file is there, the demo loads automatically and uses the settings from the config file. So, you have to set your config. only once and afterwards the demo will always load automatically on your real Atari machine (and in case you change your computer config., just delete the config. file and create a new one).
But I am unsure if such a config-file and config-program will work only under DOS or also from a game-menu, gamedos, bootloader, etc. And err, such a scheme might be handy for a real A8 (where you do not change your hardware configuration that often), but not so good maybe for emulator users where a hardware config-change is just a keyclick or mouse-click away...
Strasznie emocjonalnie do tego podchodzicie. To były tylko propozycje do przedyskutowania. To raz. Dwa - nie jako całość i zamknięta lista a jako poszczególne punkty. I argumenty za i przeciw padły, w moim mniemaniu sensowne. Jakiekolwiek wypowiedzi typu: "nie bo nie i już", sensu nie mają. Sens mają: "nie, ponieważ:" i takich jest sporo. Co do bank selectora: i tak nie widzę sensu - wiem po co został zrobiony - skoro na koniec muszę wyłączyć komputer żeby go zrebootować. Co do punktu 7 - obecnie najczęstsze standardy to rambo i compy. A te chyba obsługuje się tak samo (z tego co wiem - mogę się mylić) - istnieją jeszcze takie jak Axlon gdzie chyba banki przełącza się innym rejestrem i o to chodzi. Brak zrozumienia zagadnienia pewnie wynika z faktu, że u nas jest to raczej egzotyka :)
Dostałem od JACa email, który śledzi dyskusję i poprosił mnie o zamieszczenie poniższej wiadomości celem pewnych wyjaśnień oraz przetłumaczenie (z góry przepraszam za ew. błędy). Chyba teraz stanie się jasne o co mu chodziło - istotny jest tylko efekt końcowy jaki chciał osiągnąć - a o tym, czy zaproponowane metody są ok czy nie, właśnie dyskutujemy.
We've had quite a percentage of entries that were simply not loading hanging on the real machine, so you had to power it off. My intention is to have everything running smoothly at the party on the pack and on everybody's real machine with a real DOS with with real loading times (where a cold start matters). My intention is not (!) to deny anybody's entry for the party, but to increase the fun and success of the releases. And to offer support to guarantee the author can achieve that. I've converted dozens of ATRs to EXE, ATRs to directories and sounds to executables in the past 2 years. I know how to do this and I'd love to help people.
Note: Rule 6 is there for every "big" demo and everything that uses XBIOS for example. Using XBIOS is of course pefectly fine, but people should keep in mind that their entry is not the only entry. So if the demo only requires 48k, why kill DOS and force the user to reboot
So what you write in your post 157 is perfectly right (translator's notice: that regards my post at Atari Area, in fact it's post 156 ->link<-
"It must be loadable from regular DOS and RESET must not hang the machine" - that's it. Everyhting else I've written is just how you can achieve that in a way that's good for the consumer.
Best regards, Peter.
Mieliśmy całkiem sporo prac, które po prostu się nie wczytywały, zawieszając prawdziwy sprzęt, więc trzeba było go wyłączać. Moją intencją jest aby wszystko uruchamiało się bez problemów na party i w kompilacji oraz na prawdziwym sprzęcie, z prawdziwym DOSem przy rzeczywistych czasach ładowania (gdy zimny start ma znaczenie). Moją intencją nie jest (!) odrzucanie czyichkolwiek prac na party, ale ich większy sukces i radość z ich oglądania. Oraz zaoferowanie wsparcia aby zagwarantować, że autor może to osiągnąć. W ciągu ostatnich 2 lat przekonwertowałem tuziny ATRów do EXE, ATRów i dźwięków to plików wykonywalnych. Wiem jak to robić i z chęcią wszystkim pomogę.
Uwaga: Zasada 6 jest swtworzona dla każdego "dużego" dema i wszystkiego co używa np. XBIOS. Używanie XBIOS jest oczywiście jak najbardziej w porządku, ale ludzie powinni pamiętać, że ich praca nie jest jedyna. Więc jeśli demo wymaga jedynie 48k, po co zabijać DOS i zmuszać użytkownika do rebootu.
Więc to co napisałeś w poście 157 to prawda (przyp. tłumacza to do mnie odnośnie postu na AArea, de facto to post 156 ->link<- )
"Powinno ładować się z DOS i RESET nie powinien zawieszać maszyny" - o to tylko chodzi. Wszystko inne co napisałem to jedynie wskazówki jak to osiągnąć w sposób wygodny dla użytkownika.
Albo jest "must", albo nie ma "must". Albo musi , albo powinien. Dla mnie powinien oznacza wpisanie w plik txt dla odpalającego pracę stosownej notki, żeby wiedział i był gotowy. Musi oznacza, że praca wylatuje bo nie spełnia regulaminu.
Nie ma tutaj emocjonalnego podejścia - stwierdzam fakt, że najprawdopodobniej nie jestem w stanie spełnić takiego regulaminu już teraz (być może ze względu na brak moich umiejętności). Jeżeli to jest "nie bo nie" nic na to nie poradzę.
Zresztą nie rozumiem np. tłumaczenia punktu 2 - w oryginale must, w tłumaczeniu powinien. dla 256b (która jadą po pamięci) to ograniczenie w skrajnym przypadku odrzuca pracę albo ze względu na przekroczony rozmiar, albo ze względu na nie spełnienie punktu regulaminu.
Ok, inaczej, ani JAC ani ja nie jesteśmy native speakerami i możemy popełniać błędy :) Skoro się skupiamy na kwestiach verbalnych, w takim razie usuńmy wszelkie must :)
Chodzi o co innego: regulaminy nie powstają po to aby utrudnić życie uczestnikom czy narzucić im jakieś formalne ramy a po to aby usprawnić praktykę. Czy robią to w sposób skuteczny i sensowny to już jest inna sprawa - to zależy od ich zawartości. Nie jesteśmy sformalizowaną organizacją i nikt nie odrzuci niczyjej pracy tylko dlatego, że się wiesza po resecie.
"Must" ja rozumiem w ten sposób, że program musi spełniać taki warunek aby nie sprawiać problemów a nie aby nie wylecieć z konkursu. Tego i tak do samego compo przecież nikt nie zweryfikuje a odrzucanie czegokolwiek PO compo ma tyle sensu co musztarda po obiedzie.
Email od JACa myślę wyjaśnia to dostatecznie: ostatecznym celem jest to co napisał - załadowanie spod DOSa i nie wieszanie po resecie, a jeśli ktoś uważa, że trzeba to osiągnąć w inny sposób lub nie da się osiągnąć, to podyskutujmy.
OCZYWIŚCIE są programy które NIE MOGĄ spełnić tych założeń - nie załadują się spod DOSa bo już na etapie ładowania wykorzystują jego przestrzeń. No i ok - nie tworzymy oprogramowania rynkowego aby to odrzucać czy odsyłać do poprawki.
Cyt.: "Note: Rule 6 is there for every "big" demo and everything that uses XBIOS for example. Using XBIOS is of course pefectly fine, but people should keep in mind that their entry is not the only entry. So if the demo only requires 48k, why kill DOS and force the user to reboot".
JEŻELI program używa mniejszej ilości pamięci to MOŻNA z powodzeniem wypełnić te punkty i nic się nie zawiesi. Ale JEŻELI pogram używa CAŁEJ pamięci to powinien przynajmniej dać się na zimno zresetować, a to chyba nie jest wielki problem?
Jeżeli dobrze zrozumiałem jest to jedynie zbiór zaleceń. Nic nie mam do Twojego tłumaczenia - jak widzę must to dla mnie to jest 0/1.
Jednak przedstawienie tego w takiej formie będzie prowadziło do nieporozumień i ja bym nie umieszczał takich rzeczy w regulaminie.
W skrajnym przypadku, bez złej woli autora, program może nie dać się zresetować w sposób jak opisano w punktach. To nie jest kwestia "wielkich problemów" - to jest kwestia potrzeb kodera. I co wtedy? Z kim mam na ten temat dyskutować 10 minut przed deadlinem?
Zazwyczaj umieszcza się w regulaminie potrzebę opisania sposobu uruchomienia softu - jeżeli odbiega ono od std. I to proponuję zachować. Czy to nie wystarczy? Jak coś to autor ma problem. Fakt, że compo macher musi się napocić i to jest dla niego spora praca + kompo nie idzie idealnie płynnie, ale chyba lepiej jest mieć więcej prac, niż mniej. A z takimi pracami jest jak z pomyłkami sędziów - to jest piękno sceny/piłki ;))))
Jeżeli będę w stanie spełnić każdy punkt to ok. ja osobiście postaram się, ale już widze, że np. na 3 może nie być szans.
To są tylko propozycje do przedyskutowania, spokojnie. Sam nie potrafiłem się do nich odnieść, dlatego postanowiłem wrzucić je na forum ludzi, którzy mają o tym pojęcie :)
Tutaj nikt niczego nikomu nie narzuca. Żadna zmiana nie została dokonana.
Dlatego moze to potraktowac jako zestaw zaleceń, próśb i dobrych rad zamiast "must" dając as far as it's possible :) wiadomo ze wypadki sie zdarzaja chodzi o to aby zminimalizowac ich ilosc i ulatwic ludziom zycie. Zaloze sie ze w wiekszosci przypadkow problemem to nie bedzie aby chociazby zapewnic reset, pkt 3 ja rowniez widze jako trudny do realizacji o ile nie mowimy o intrach, tylko wczesniej nikt sobie tym nie zawracal glowy. I prosba aby zechcial (o ile to mozliwe :))
ABBUC General Hints Advise: It´s not sufficient if a program runs with an Emulator. Who has no ability to test his software on real hardware please note the following: The RAM under the OS-ROM and the BASIC is filled with random values after switching on a real Atari (mostly $FF and $00). Atari Emulators often have 0 here. Before changing the display list (DLISTL/H) or switching on or off the screen (DMACTL) a vertical blank should take place (wait for it). Otherwise on real Ataris, especially with enabled DLIs, interferences (flickering) or even crashes may occur. Sound should be initialized at the start and after each load operation with AUDCTL=0, SKCTL=3, otherwise it will sound false. Also the total volume of all four (4) channels should not exceed 32, otherwise sound on real Ataris is distorted. The program has to run on PAL-Ataris. There are following differences to NTSC: - The VBI runs at 1/50 second (instead of 1/60 second) - Color palette is different - At PAL the vertical blank is notably longer Programs in XEX-format have to run as ATR also, regarding topic 2.1c). That means, other than the Emulator direct start the XEX file has to be startable with XEX-loader in memory. Most loaders need $700-$BFF, zero page $43-$49 and all SIO memory locations. The Emulators Altirra and Atari800Win offer color palettes that are not correct. E.g. the doors in "Project M 2.0" do not have the colors red, green, blue as in Altirra but brown, white-blue, blue-violet. A game developed on an Emulator can show different colors on real Ataris. The SIO runs slower with a 1050 than with SIO2XXX-devices or Emulators. This might lead to timing problems, if the program has a self-written SIO-routine or runs interrupts while loading.
dodalbym do tego informacje jak wylaczyc BASIC. i jak wymusic zimny reset.
Nie powinien też oznacza zakaz w zasadzie, ale dopuszcza że coś może pójść nie tak - nie da się przewidzieć wszystkiego w 100% :) Propozycję pisał człowiek z kraju gdzie wszystko definiuje się bardziej kategorycznie :D
> Propozycję pisał człowiek z kraju gdzie wszystko definiuje się bardziej kategorycznie :D
Tym bardziej należałoby uważać z powiększaniem podczas tłumaczenia rozjazdu między dwiema wersjami. Dla Niemca "nie wolno" oznacza "bezwzględny zakaz". Dla Polaka "nie powinien" oznacza "fajnie by było, żeby tego nie robić, ale wiadomo jak jest" :)
To może po prostu obok certyfikatu 'PIN ready' dodamy 'JAC! ready' - i będzie na zasadzie deklaracji :). Kto spełni - to gdzieś tam umieści w produkcji, kto nie spełni - nie umieści.
