Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
BigPEmu 1.12 Richard Whitehouse wydał BigPEmu 1.12
FujiNET firmware v1.3.0 Nowa wersja oprogramowania do interfejsu sieciowego FujiNET. Tym razem z obsługą TCP!
hatari 2.5.0 Od dwóch dni dostępna jest najnowsza (2.5.0) wersja Hatari.
Grawitacja 2024 Czas na kolejną edycję 8 bitowego GameJamu.
Tenebra na Atari ST/STE Wersja gry na duże atari.
atari.area forum » Posty przez Marek Konopka
plik binarny nie ma tych ograniczen.
Jest jedno, dosyć abstrakcyjne ograniczenie. Nie załadujesz w ten sposób danych od adresu $FFFF w przypadku formatu AtariDOS. Próba takiej operacji zapewne zakończy się zgonem, jeśli nie wprowadzi się dodatkowych zabezpieczeń.
Alternatywa:
ldy #<file_name
ldx #>file_name
lda #EMode.CHUNK // ew. clc
jsr xBIOS_OPEN_FILE
ldy #<$ffffff
ldx #>$ffffff
lda #^$ffffff
jsr xBIOS_SET_LENGTH
ldy #<adres
ldx #>adres
jsr xBIOS_WRITE
jsr xBIOS_CLOSE_FILEvs
ldy #<file_name
ldx #>file_name
lda #EMode.STREAM // ew. sec
jsr xBIOS_OPEN_FILE
lda #value
jsr xBIOS_WRITE
jsr xBIOS_CLOSE_FILECzy planujesz, aby lokalizacja skąd/gdzie pobierane/zapisywane są dane, mogła być wyrażana przez liczbę większą od 16'stu bitów?
jednak PUT I GET musi zostac (musze miec mozliwosc czytania zapisywania wiekszej ilosci danych niz pojemnosc pamieci)
Sekwencja komend SET_LENGTH (X,Y), SET_LENGTH (X) załatwiłaby sprawę.
mozesz uzyc CLOSE po WRITE/READ FILE ale nie bedzie zadnego efektu, Close wymagane jest po to, zeby zgromadzone dane w buforze zapisac na dysk - zapis jest buforowany. tak naprawde CLOSE jest wymagany tylko po PUT. po GET nie, ale jak chcesz mozesz uzywac.
Chodzi mi o to, aby jawnie wyspecyfikować w dokumentacji, że protokół korzystania z operacji READ/WRITE jest następujący: OPEN, READ/WRITE, CLOSE. Każdy inny sposób może spowodować niezdefiniowane zachowanie. Jako użytkownik biblioteki nie chciałbym pewnego dnia zostać zaskoczony faktem, że dotychczasowy protokół korzystania jest błędny z racji zmiany implementacji CLOSE. Specyfikując go jednoznacznie unikamy na przyszłość takich problemów.
Czy nie lepiej byłoby zamienić obecną parę komend WRITE_FILE/PUT_BYTE na jedną, bardziej ogólną WRITE_FILE, gdzie podawalibyśmy ilość bajtów do zapisu? Użytkownik biblioteki zna maksymalny rozmiar danych do przetransferowania, więc nie byłoby z tym problemów. Skracamy w ten sposób listę komend kosztem rozbudowania interfejsu nowej komendy. Dla mnie taki interfejs byłby bardziej intuicyjny. Zapis do pliku tym sposobem byłby także bardziej wydajny.
Ta sama uwaga dotyczy komendy READ_FILE.
EDIT:
Możnaby wprowadzić komendę SET_LENGTH (X,Y - długość pliku) dla operacji READ/WRITE. Byłaby to opcjonalna komenda wykonywana po otwarciu pliku. Jeśli nie zostanie wywołana - odczytywany/zapisywany jest cały plik. W przeciwnym przypadku operujemy na ilości danych przekazanych w komendzie SET_LENGTH. Od strony implementacyjnej nie jest to problemem, wystarczy jedna flaga oraz słowo opisujące długość. Pętla realizująca odczyt bajtów, którą powyżej umieściłeś, stałaby się szczegółem implementacyjnym. Tym sposobem odczyt/zapis określonej ilości bajtów byłby prostszy. Oczywiście wydłuża się w ten sposób implementacja biblioteki, ale być może zostało ci jeszcze trochę bajtów.
Komenda xBIOS_WRITE_FILE nie przyjmuje parametru określającego długości pliku do zapisu. Ta informacja musi gdzieś istnieć, aby komenda funkcjonowała prawidłowo. Skąd, kiedy i w jaki sposób jest ona pobierana?
dla PUT i GET jesli nie zapisujemy calego pliku potrzeba konczyc operacje CLOSE
Bardziej intuicyjne byłoby założenie, że CLOSE jest wymagany za każdym razem, gdy korzystamy z PUT/GET. Ma to również sens w każdym przypadku korzystania z komend xBIOS_LOAD_FILE, xBIOS_WRITE_FILE, nawet gdy implementacja CLOSE dla tych przypadków jest pusta. Taki sposób korzystania z biblioteki jest łatwiej sobie utrwalić. CLOSE jest komplementarne dla OPEN. Komenda xBIOS_RUN_FILE jest tutaj wyjątkiem, gdyż automatycznie otwiera i zamyka plik, a komenda LOAD_DIR nie operuje na pliku.
Co następne? Koszulki i inne gadżety, na których jest ich logo, albo nazwa? Wysyłanie listów do ludzi, którzy mają w nazwie strony Atari?
Mówisz i masz.
Zapomniałeś o iny. Musi to nastąpić w ściśle określonym przypadku (przekroczenie bajtu) i w związku z tym trzeba dodać skok, co pogorszy czas wykonywania tego wariantu.
M0 ora $ffff,y
M1 sta $ffff,y
inc M0+2
inc M1+2
16 cykli do przodu / blok 8 pix
7 cykli do tyłu raz na blok 8 pix
9 cykli do przodu w pełnym rozrachunku
Umieszczenie na zpg poprawi odrobinę wydajność.
EDIT:
Statystycznie lepszym wariantem jest dokonywanie skoku gdy C = 1, co będzie miało miejsce najwyżej jeden raz na 8 pix. Zyskujemy w ten sposób 1 cykl przy zwiększeniu współrzędnej X.
lsr @
bcs skok
rti
skok ror *
iny
rti
DLIexample sta dl_a sta dl_a ;powtórzone bo potrzebowałem przesunąć o 3 cykle :) lda #$00 sta $d012 lda #$00 sta $d013 lda #$00 sta $d014 lda #$00 sta $d409 lda #$00 sta $d019 lda #$00 sta $d015 lda #<NextDLI sta $FFFA lda #>NextDLI sta $FFFB lda dl_a rti
Dzięki odpowiedniemu rozmieszczeniu kolejnych procedur obsługi DLI w pamięci można pozbyć się zmiany jednego z bajtów składowych wektora przerwań ($FFFA).
Tej jednej pustej linii można się pozbyć modyfikując DL, aby wyświetlała zawartość pamięci dla niej spod innego, nie przekraczającego 4 KB bloku. Można ją kopiować na VBL spod źródłowej lokacji do tej podmienionej. Koszt marginalny. Jeśli to byłoby problemem, to można wstrzyknąć kawałek kodu do logiki gry, który zrealizuje to samo.
Zajęłaby 78 000 bajtów dla całego ekranu.
Weronika by to udźwignęła.
Termin wstępnie akceptowalny dla mnie. Również proponuję nie targać ze sobą maszyn.
Boostowe są bardzo dobre (zresztą boost to niezbędnik każdego C++sowca :))..
Każda implementacja "cwanego" wskaźnika bazująca na liczniku odwołań zawiedzie przy odniesieniach wzajemnych dwóch obiektów (wycieki pamięci). Jeśli nie zna się tego ograniczenia, można nieźle się wkopać. To b. prawdopodobne, gdyż dokumentacja do klasy boost::smart_ptr nie wspomina o tym ani mru mru. Książka "Beyond the C++ Standard Library - An Introduction to Boost" również pozostawia nas w tym błogostanie.
W imieniu całej sceny BDSM - wielkie dzięki. Na przyszły rok trzeba koniecznie pomyśleć o poszerzeniu idei o jakąś inicjatywę w stylu live performance. Mamy już kilka pomysłów na ciekawe "sceny". W imieniu swoim (Liebling Pejcz) oraz pozostałych członków ATARIBDSM (Kleine Klaus, Ulrich von Chain) chciałbym podziękować za organizację imprezy i prosić o więcej.
Chciałbym także przypomieć, że nadal trwa nabór na jedno wolne stanowisko "Młodszego Niewolnika" w naszej grupie. Poszukujemy szczególnie uzdolnionych "wokalnie" osób.
"Nie lękajcie się bólu"
Marek, sorki za off ale nie moge sie powstrzymac:
Podaj prosze przyklad jakiejkolwiek gry na jakakolwiek platforme, korzystajacej z SQL ;)
Nie odpowiem tobie na to pytanie. Jestem pośrednikiem, którego poproszono o pomoc. Mnie te wymagania również wydały się nietypowe. Zastosowania SQL'a są na tyle uniwersalne, że pewnie i w jakichś specyficznych projektach gier można dla niego znaleźć miejsce, w szczególności grach on-line. Możnaby przykładowo stworzyć bazę ruchów obiektów dla jakiejś nieskomplikowanej gry, która nie wymaga dużej mocy procesora.
Jeśli ktoś z czytelników jest zainteresowany ofertą pracy dla doświadczonego programisty gier, ze znajomością Linux'a oraz SQL, proszę o kontakt prywatny.
Wideo pokazujące efekt pracujący na gołej atarce: http://www.youtube.com/watch?v=CzVT5wFhyVo .
Czyli cartridge do cartridge'a. :>
EDIT: Wciąż pozostaje problem dostępu do pamięci xROM przy wysokiej częstotliwości.
Dlaczego uważasz pomysł rozpowszechniania gier w formie kart SD jako bardzo zły?
Skąd ten dekompresor miałby przerzucać dane? Z tej samej kości o rozmiarze 16 KB?
Obiecany materiał wideo: http://www.youtube.com/watch?v=mQZhviM0Ewk. Przepraszam za kiepską jakość obrazu.
Weronika nie była projektowana jako konsola do gier, a jako koprocesor ogólnego zastosowania. Z tego co napisałeś wynika, że chciałbyś, aby Weronika po wsadzeniu pozwalała na przelotowość i odtwarzanie starego oprogramowania z CAR oraz nowego. Gry tworzone na taką platformę powinny odznaczać się lepszą oprawą graficzną, a to oznacza wsady o większym rozmiarze niż 16 KB (~1MB), a to jest już problem na obecnym etapie rozwoju. Lepszym rozwiązaniem w takiej sytuacji byłoby wykorzystanie SIO2SD oraz rozpowszechnianie gier w formie kart SD. Rozwiązanie z pamięciami xROM jest problematyczne, gdyż są to układy stosunkowo wolne.
Nowe zdjęcia prezentujące skalę.
Wpakowanie trójstanowych, dwukierunkowych buforów szyny danych do jednego układu CPLD/FPGA Altery, z tego co przeczytałem na stronie producenta, nie jest możliwe. Może się okazać, że te cztery scalaki będą musiały pozostać w formie fizycznej.
atari.area forum » Posty przez Marek Konopka
[ Wygenerowano w 0.077 sekund, wykonano 10 zapytań ]