26

Odp: Gravity Worms

koszt?

https://systemembedded.eu/
""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

27

Odp: Gravity Worms

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)

Ostatnio edytowany przez xxl (2020-01-08 17:19:23)

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

28

Odp: Gravity Worms

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.

29

Odp: Gravity Worms

xxl napisał/a:

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..

https://systemembedded.eu/
""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

30

Odp: Gravity Worms

Nie żebym się czepiał, ale to nie jest EPROM.

"tatusiu zobacz, narysowałam tobie takie same coś jak na twojej koszulce" 
https://github.com/willyvmm/mouSTer
jmp $e477

31

Odp: Gravity Worms

Nie żebym się czepiał nieczepiania, ale też myślę, że to nie jest EPROM:-)

32

Odp: Gravity Worms

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.

33

Odp: Gravity Worms

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.

"tatusiu zobacz, narysowałam tobie takie same coś jak na twojej koszulce" 
https://github.com/willyvmm/mouSTer
jmp $e477

34

Odp: Gravity Worms

pancio.net napisał/a:

a możesz powiedzieć ile to to będzie kosztowało BRUTTO?

nie wiem. po prostu. nawet nie bede strzelal... nie mam pudelkam, poligrafii itp.

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

35

Odp: Gravity Worms

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.

Ostatnio edytowany przez _tzok_ (2020-01-09 00:09:38)

Moja kolekcja: Atari 1040STe (4MB), Atari 1040STfm (4MB, BLiTTER, AT-ONCE+), Atari 800XE (SIMM EXP 1MB), Atari 800XL (RAMBO XL 256kB), Atari 600XL (64kB), Sinclair ZX SPECTRUM+ (48kB), TIMEX Computer 2048 (48kB), Commodore A600 (2MB+4MB, HDD CF 4GB), Commodore C64C.

36

Odp: Gravity Worms

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.

37

Odp: Gravity Worms

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ć.

Ostatnio edytowany przez _tzok_ (2020-01-09 00:29:36)

Moja kolekcja: Atari 1040STe (4MB), Atari 1040STfm (4MB, BLiTTER, AT-ONCE+), Atari 800XE (SIMM EXP 1MB), Atari 800XL (RAMBO XL 256kB), Atari 600XL (64kB), Sinclair ZX SPECTRUM+ (48kB), TIMEX Computer 2048 (48kB), Commodore A600 (2MB+4MB, HDD CF 4GB), Commodore C64C.

38

Odp: Gravity Worms

_tzok_ napisał/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.

https://systemembedded.eu/
""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

39

Odp: Gravity Worms

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.

"tatusiu zobacz, narysowałam tobie takie same coś jak na twojej koszulce" 
https://github.com/willyvmm/mouSTer
jmp $e477

40

Odp: Gravity Worms

pancio.net napisał/a:

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).

Ostatnio edytowany przez _tzok_ (2020-01-09 11:24:29)

Moja kolekcja: Atari 1040STe (4MB), Atari 1040STfm (4MB, BLiTTER, AT-ONCE+), Atari 800XE (SIMM EXP 1MB), Atari 800XL (RAMBO XL 256kB), Atari 600XL (64kB), Sinclair ZX SPECTRUM+ (48kB), TIMEX Computer 2048 (48kB), Commodore A600 (2MB+4MB, HDD CF 4GB), Commodore C64C.

41

Odp: Gravity Worms

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.

Ostatnio edytowany przez Mq (2020-01-09 11:40:24)

42

Odp: Gravity Worms

po zjedzeniu owoca pozostawala "dziura" w grafice... :/

zmiana: owoce traktowane sa jak inne obiekty - moga zaslaniac tlo, po usunieciu z planszy tlo jest odslaniane (klocek tla lub inny)

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

43

Odp: Gravity Worms

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.

Moja kolekcja: Atari 1040STe (4MB), Atari 1040STfm (4MB, BLiTTER, AT-ONCE+), Atari 800XE (SIMM EXP 1MB), Atari 800XL (RAMBO XL 256kB), Atari 600XL (64kB), Sinclair ZX SPECTRUM+ (48kB), TIMEX Computer 2048 (48kB), Commodore A600 (2MB+4MB, HDD CF 4GB), Commodore C64C.

44

Odp: Gravity Worms

nadal tak moze byc ale sa tez klocki tla, ktore nie wchodza w interakcje i o nich mowie.

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

45

Odp: Gravity Worms

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?

Ostatnio edytowany przez Cyprian (2020-01-11 19:46:42)

Lynx I / Mega ST 1 / 7800 / Portfolio / Lynx II / Jaguar / TT030 / Mega STe / 800 XL / 1040 STe / Falcon030 / 65 XE / 520 STm / SM124 / SC1435
DDD HDD / AT Speed C16 / TF536 / SDrive / PAK68/3 / Lynx Multi Card / LDW Super 2000 / XCA12 / SkunkBoard / CosmosEx / SatanDisk / UltraSatan / USB Floppy Drive Emulator / Eiffel / SIO2PC / Crazy Dots / PAM Net
http://260ste.atari.org

46

Odp: Gravity Worms

xxl gratuluję stworzenia nowej gierki.

47

Odp: Gravity Worms

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.

48

Odp: Gravity Worms

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

Powszechnie wiadomo, że kamień potrafi myśleć. Na tym fakcie opiera się cała elektronika.

Terry Pratchett - Równoumagicznienie

49

Odp: Gravity Worms

voy napisał/a:

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

50

Odp: Gravity Worms

heheh

ale sie musicie meczyc i wymyslac cuda zeby tylko nie naprawic bledu w u1mb :-)

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