koszt?
""Ja bardzo przepraszam, ale podejrzenia panów są całkowicie bezpodstawne. Ja niczym nie handluję. Ta pani przyszła do mnie w tym Pancake-u i w nim wychodzi.""
ABBUC Member #319. Preferowana forma kontaktu: email
Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
Zmarł twórca języka BASIC Zmarł Thomas E. Kurtz twórca języka BASIC
Zmiana serwera atari.area Serwis przeszedł właśnie ważną aktualizację infrastruktury
4th Atari ASCII Compo - wyniki Dostępne są już wyniki tegorocznego ATASCII Compo.
thing neo 1.60 Olivier Landemarre wydał nową wersję desktopu Thing.
VIII. Basque Tournament of Atari 2600 Kolejna relacja, wśród otrzymywanych od naszego przyjaciela Egoitza z Kraju Basków.
atari.area forum » Fabryka - 8bit » Gravity Worms
Strony Poprzednia 1 2 3 4 … 17 Następna
Zaloguj się lub zarejestruj by napisać odpowiedź
koszt?
Nie analizuję za mocno jak to zaprojektowaliście, ale widzę trzy TTL-e i EEPROM, czyli z grubsza standardowy kartridż. Z tego wynika, że zapis planujesz robić do tej samej kości, na której zapisana jest gra. Nie wiem jak to tam rozwiązaliście, pewnie można flashować fragment kości i w ten sposób robić zapis, ale moim zdaniem lepiej by było gdyby konstrukcja "zapisu" była oddzielona od części z wsadem samej gry, bo jak wszystko jest w jednej kości, to istnieje obawa, że przy dużej ilości zapisów robionych przez użytkownika, razy ilość użytkowników, to mocno zwiększa prawdopodobieństwo i częstotliwość wystąpienia wywalenia się takiej kości, co może zaowocować tym, że user zostanie nie tylko bez zapisanej gry, ale w ogóle bez gry. Chyba, że dostarczysz userowi również program do sflashowania w Atari tej kości w całości pierwotnym oryginalnym wsadem gry w wypadku uszkodzenia, to wtedy w razie czego nie będzie problemu.
prawdopodobnie chodzi Ci o koszt karta w sensie plytki i elementow - nie wiem.
ja kupuje tego karta z usluga poskladania + obudowa i zamkniecie w obudowie.
===
usluge zapewnia mi J.Husak (poprzednia jego produkcja to byla platform dla gry Ridiculous Reality)
a możesz powiedzieć ile to to będzie kosztowało BRUTTO? :-) znaczy z Twoim wkładem, bo o to pytałem..
Nie żebym się czepiał, ale to nie jest EPROM.
Nie żebym się czepiał nieczepiania, ale też myślę, że to nie jest EPROM:-)
I raczej nie EEPROM tylko Flash, a one mają ograniczoną ilość zapisów, poza tym kasowanie odbywa się blokami. Lepszy byłby zapis do jakiegoś eepromu (około 100tys zapisów) ale one najczęściej są jako pamięci z zapisem szeregowym, a nie równoległym.
Nie zapisów a kasowań, a to czyni istotną różnicę.
Kto powiedział że przed każdym zapisem trzeba kasować całą strone?
To jest pamięć nor flash, wiec zapisuje sie też tylko caly wiersz a nie sektor... Do tego wiersz można zapisywać wielokrotnie ;>
Ale to juz niech inżynierowie od xbiosa rozpracowuja sobie sami.
Ja tam widzę 39SF0?? czyli NOR Flash. EEPROMy równoległe jak najbardziej istnieją np. SST 29EE010. Do zapisu na pamięci Flash powinien być stosowany specjalny system plików (np. JFFS)... no ale wtedy to nie mogłoby działać jako cart. Tak czy inaczej wypada programowo zadbać o wear leveling.
Dobra, bo żeby się tu znowu nie zrobiło wymądrzanie i wyścigi kto jest większym autorytetem. Mi tu nie chodziło o to żeby dyskutować jaka to jest pamięć i ile ma cykli czego przewidzianych. Po prostu z doświadczenia wiem, że przy przeprogramowywaniu pamięci czasem się wywalają i trzeba je programować od nowa. Zawsze wszelkie fleszowania różnych biosów i innych tego typu rzeczy opatrzone są warningami, żeby w trakcie nie przerywać, żeby mieć pewne zasilanie itp. Częste powtarzanie operacji obarczonej ryzykiem zwiększa częstość wywalenia się tego, bo to po prostu nie jest przewidziane do notorycznego traktowania jako pamięć masowa. Ja bym po prostu nie ryzykował mielenia po takiej kości fragmentami, ale jeśli ma to działać jak np. SIC, a wsad kompletny będzie dla usera dostępny i będzie mógł w każdej chwili łatwo całość od nowa przeflashować, to czemu nie. Natomiast jak ma być gra zapisana w carcie na stałe, a zapis ma być tylko np. stanu gry, to bezpieczniej było by mieć osobną pamięć na grę, której nie ruszamy, a osobną małą jako miejsce na sejwy. Ale w sumie xxl nie napisał jak to ma technicznie w całości działać, więc może jest całościowo jakoś dobrze przemyślane, a my tu niepotrzebnie bijemy pianę bez sensu.
Jeden sektor (128 B) można bezpiecznie kasować i zapisywać, nic się nie wysypie, a jak się wysypie, to co najwyżej ten sektor z zapisem stanu gry. Flash to nie EEPROM i ma zintegrowany kontroler. Przy BIOSie to było inaczej, bo jak się wywalił przy zapisie to zostało ileś tam bloków nowego obrazu binarnego, a na końcu kilka bloków starego, no i to nie mogło działać.
Do zapisu na pamięci Flash powinien być stosowany specjalny system plików (np. JFFS)...
"Nie mieszajmy tu dwóch różnych systemów walutowych" (Miś, Bareja). JFFS to system plików, mocno związany z OS-em a nie fizyczny sposób zapisu... jak się zapisze ten sam obszar wiele razy to sie wy@#!li i już! Po kosteczce!. I nie ma znaczenia jaki FS będzie pod spodem.
Hallooo?
Ziemia?
Jak nie to zejdzcie na nią.
To jest Atari. Male. 8bit.
Przy cyklicznym kasowaniu i zapisywaniu tego samego sektora co 1 minute, teoretycznie zuzyje sie po 70 dniach grania non stop.
JFFS to system plików, mocno związany z OS-em a nie fizyczny sposób zapisu...
...posiadający jednak mechanizmy wear leveling dla NOR Flash, które można wykorzystać. Tu nie będzie przepisywana cała kość tylko jeden, może kilka sektorów. Jeśli padną to tylko one. Żywotność to ok 100 tys. cykli zapisu. Nie ma problemu, żeby część kości przeznaczyć na stały obraz, a na części zrobić system plików, lub jego namiastkę.
Najprostsze możliwe rozwiązanie to pół kości na obraz binarny, a pół do zapisu bloku stanu gry. Blok stanu gry ma jakiś znacznik początku. Za pierwszym razem jest zapisywany w pierwszym możliwym adresie, kiedy ma być nadpisany, jest kasowany, ale nowa zawartość jest zapisywana od pierwszego sektora za starym blokiem i tak do zapętlenia. Gdy chcemy wczytać blok stanu gry przeglądamy sekwencyjnie wszystkie sektory, aż trafimy na znacznik początku bloku stanu gry.
Można też użyć jednego sektora jako wskaźnika aktualnego bloku stanu gry. W tym celu można wykorzystać specyficzną cechę pamięci NOR Flash, otóż jeśli zapiszemy sektor bez jego wcześniejszego skasowania, to co pozostanie w pamięci po tej operacji będzie iloczynem logicznym tego co było i tego co zapisaliśmy, innymi słowy możemy "gasić" kolejne bity, nie "zużywając" cykli zapisu (a właściwe kasowania).
Willy tak, ale faktycznie koledzy mają rację, że gdyby programowo ogarniać zapisywanie w różne miejsca, to drastycznie wydłuża ilość cykli - tak jak mówisz 70 dni non stop, gdyby przemnożyć np. przez 10 stosując odpowiedni algorytm zapisu kolejno w różne miejsca, to już praktycznie można przyjąć, że nie dożyjemy zużycia tego. Ale w drugą stronę patrząc, jeśli gra cały czas by coś sobie sama w tle na bieżąco zapisywała ciągle w to samo miejsce z większą częstotliwością niż raz na minutę (np. co kilka sekund), to w kilka dni grania po kilka godzin dziennie kostka się zużyje.
Inna rzecz, że tak jak wcześniej napisałeś liczą się cykle kasowania, jeśli dane komórki nie ulegają zmianie, to i nie są kasowane, więc taka operacja "nie zwiększa licznika cykli".
Ogólnie wszystko zależy od tego do czego i w jaki konkretny sposób taki kartridż się użyje oraz jak się go oprogramuje. Ja zwróciłem uwagę na możliwość wywalenia się kości całkowicie przez jakieś nieprawidłowości podczas zapisu (np., niestabilne zasilanie itp.), koledzy zwrócili uwagę na ilość cykli. To tylko informacje, które warto po prostu uwzględnić w takim projekcie i później przy projektowaniu korzystającego z niego softu na Atari.
W innym wątku xxl wspomniał, że na ten kartridż będzie można zapisywać dane jak na zwykłej dyskietce (z uzyciem xbios), więc już możemy mieć tu do czynienia z bardziej masowym przewalaniem danych w te i wew te w zależności od tego co kto wymyśli, a to zmienia trochę postać rzeczy w stosunku do zapisu tylko jednego wybranego sektora bardzo rzadko i tylko dla sejwu gry.
Dodał bym jeszcze, że warto też przyjrzeć się różnym kościom i różnym producentom, bo o ile w normalnym kartridżu liczy się dla nas tylko pinout i rozmiar pamięci, a stosujemy jakąkolwiek bądź, o tyle tutaj już warto rozważyć konkretnych producentów, bo też te ilości cykli się potrafią różnić w datasheetach, a poza tym renomowane kości będą faktycznie te parametry miały, a inne niekoniecznie.
Sądziłem, że to było zamierzone, wymuszało to zjadanie owoców w określonej kolejności, po ich zjedzeniu traciło się punkty podparcia.
gra wygląda całkiem fajnie.
muzyczka też jest zacna
Robak porusza się skokowo (co znak?). Czy wynika to z jakichś technicznych ograniczeń? Jeśli nie to czy dało by się dodać płynną animację, z ruchem co piksel?
xxl gratuluję stworzenia nowej gierki.
Właśnie przeszedłem pierwszą planszę. Bardzo fajne.
Lubię takie gry, które wymagaja trochę myślenia.
Grafika i muzyka też mi się podoba.
Ok, mam działającą na Ultimate 1MB wersję. :D Wcześniej przeoczyłem dwa miejsca.
Bierzemy rozpakowaną wersję od Baktry o długości 46030 bajtów. Wczytujemy ją np. do HexEdit i w podanych poniżej lokacjach występujące tam bajty podmieniamy na $01:
- $0611 (był tam adres $D3FD)
- $0628 (poprzednio $D3F9)
- $361C (poprzednio $D3F5)
- $3624 (poprzednio $D3F1)
- $676F (poprzednio $D3ED)
- $6798 (poprzednio $D3E9).
Widać pewną regularność; adres zmniejsza się o 4 bajty przy każdym kolejnym wystąpieniu. :)
Prośba do użytkowników wiadomo czego o testy. :D
Widać pewną regularność; adres zmniejsza się o 4 bajty przy każdym kolejnym wystąpieniu. :)
Thanks! Heuristic anti-virus detection in next version of U1MB loader knows what to look for now. :D
Strony Poprzednia 1 2 3 4 … 17 Następna
Zaloguj się lub zarejestruj by napisać odpowiedź
atari.area forum » Fabryka - 8bit » Gravity Worms
Wygenerowano w 0.031 sekund, wykonano 54 zapytań