Hehhe dzieki wieczor, ale akurat kiepsko trafiles, bo slomiany zapał to moja najgorsza zmora ;) Dwa inne prawie skonczone dobre projekty czekaja juz u mnie w kolejce na niewiadomo kiedy...

Tak bywa, zawsze czasu brakuje.

Dokładnie tak, każdy będzie mógł sobie dopisać co mu potrzeba.

Tu się pozwolę nie zgodzić.
64 kB danych to na 8bit ogromna ilość danych.
To bez problemu powinno wystarczyć na level gry nawet z bardzo wypasioną grafiką.

Coś w tym jest, tylko że to tak może obrastać w różne rzeczy, a z czasem różnie bywa.

Chyba lepiej skończyć pierwszą wersję bez flaszowania.

A co do słomianego zapału, nie musisz mi tłumaczyć, każdy to ma w większym lub mniejszym stopniu :) Ważne jest umieć z tym walczyć i umieć się automotywować - a Ty chyba potrafisz ;)

To w sumie to nie jest najgorsza rada: wyobrazam sobie mozliwosc, ze kazdy kto chce developowac na Tomka gry i zmieniac firmware, musi kupic zestaw developerski Microchipa (jakies 140zl chyba), co umozliwiloby mu od razu tez poprawianie firmware. To faktycznie nie sa wielkie pieniadze.

Mozna wiec w ten sposob tworzyc i wydawac fajne gry.

Ale w PIC'u bedzie mozna przechowywac max. tylko jakies 64 - 96KB danych dla Atari. Wiec wieksze gry beda musialy ladowac do niego np dane kolejnych leveli itp. (na cartridgu bedzie pamiec EPROM do 512 lub 1024KB).
Wiec flashowanie jest konieczne.

No i docelowo chce zeby uzytkownik koncowy mial mozliwosc wykorzystwania raz zakupionego sprzetu do roznych gier. To tez wymusza zmiane firmware z poziomu Atari.

Lepiej wiec pomyslec zawczasu.

Zrobiłeś naprawdę wyjątkową fajną rzecz i szkoda żeby to padło.

Najlepiej byłoby skończyć projekt tak jak jest.

Temat flashowania z poziomu atari można na razie olać.

Ani ten PIC24 (ok 25 PLN) ani programator (do 100 na allegro)

do niego to nie są jakieś straszne pieniądze.

Najwyżej jak ktoś będzie potrzebował to zrobi sobie płytkę z podstawką pod PICa

i będzie ładował wyciągał i ładował flash na PC.

Ja nawet sie zastanawialem nad pamiecia SPI RAM do wykorzystania roboczego (bo wbudowanej mam bardzo malo: 8KB), ale niestety jest ona przez swoja szeregowosc duzo za wolna. Wyszlo mi ze nawet najszybsza na rynku bylaby prawie 20x wolniejsza od wbudowanego RAM'u.

Przemysle to jeszcze.

Muszę umożliwić w Tomku flashowanie pamieci programu z poziomu Atari. I to na dwa sposoby:
1. Zmiana calego firmware
2. Umieszczenie w pamieci flash programu obiektow binarnych (np. bitmap) do wykorzystania w grze.

Punkt 2 jest wzglednie latwy, gorzej z pkt 1.

Problem w tym, ze nietypowy interfejs Atar <--> PIC jakiego uzywam wymusza programową obsluge komunikacji. Mowiac inaczej: PIC musi odebrac od Atari rozkaz "zaprogramuj X bajtow od adresu Y", nastepnie odebrac X bajtow i wywolac sekwencje self-programowania.

I tu pojawia sie problem: co jesli bede chcial upgradowac procedurę programującą? :) Nie moze nadpisac sama siebie, bo sie w pewnym momencie zwiesi :P PIC nie ma niestety mozliwosci przepisania fragmentu kodu do RAM'u i wykonania go stamtad.

Przychodzi mi do glowy takie rozwiazanie: procedura startowa (wektor RESET) zawsze musi byc pod jednym niezmienym adresie w wydzielonym miejscu pamieci programu. Tam umieszcze procedure czekającą na inicjację komunikacji ze strony Atari. Jesli Atari wysle standardową sekwencję inicjującą to procedura skoczy do programu glownego i PIC bedzie czekal na rozkazy. Ale jesli Atari wysle sekwencję oznaczającą programowanie firmware to ta procedura wykona cala operacje odbioru danych i flashowania, a nastepnie skoczy do programu glownego (juz upgradowanego).

Natomiast w programie glownym bedzie obslugiwany rozkaz "flashuj procedure resetu", ktory pozwoli na upgrade powyzszej procedury.

Czy to ma sens? Czy nie mozna prosciej?
Nigdy czegos takiego nie musialem kodowac, wiec wole spytac praktykow zanim sie niepotrzebnie narobie.