zapytales - odpowiedzialem przykladem. nie istotne dla Ciebie ale istotne dla mnie jak widac :-) tedy... po co mam wymieniac :D

no ale skoro mówisz że na Atari działa...

Książka dotarła. Jakość wydania - premium.

Jestem gotowy na koleją pozycję. Proszę mnie dopisać.

Tak, moim zdaniem musi miec karte SD (chociaz w zespole w tym temacie jest rozbieznosc), programy sie pisza tak jakby byla.

ograniczneie wynika z wielkosci bufora i mapowania plikow skonczonej wielkosci na obrazie .atr - narazie jest 128b (bez problemu moze byc wieksza) ale ja sklaniam sie ku mniejszemu, jeszcze nie wiem jaka wielkosc bufora do wymiany informacji miedzy atari i "wifi" bedzie optymalna (wdaje mi sie ze juz 128 bedzie za duza)

Montezuma podrzucil pomysl jak taka komunikacja powinna wygladac w przypadku danych o nieznanej wielkosci... zobaczymy w testach.

Co do pytania o hardware (po prostu nie wiem) albo czego uzywa dekanex to nie chce odpowiadac.

niestety udostepnianie obrazow .atr z internetow przez WiFiCarta okazalo sie niewystarczajace. pojawila sie potrzeba uruchamiania plikow .xex/.com/.obx itp. i potrzeba ta zostala zaspokojona:

kolejny maly kroczek do przodu. WiFiCart wykonywalne pliki z sieci udostepnia jako obrazy w .atr, jesli chcemy np. uruchomic taki plik to Atari podczas bootowania sciagnie z urzadzenie bootloader xBootWiFi po czym zaladuje plik.
xBootWiFi jest oczywiscie xB team aproved:
- nie uzywa komorek na ZP
- w przypadku braku RUNAD plik zostanie uruchomiony od poczatku pierwszego ladowanego bloku
- mozliwosc bootowania z drive innego niz D1:
- pozwala ladowac od $800 (na specjalne zyczenie od $600, zmienna konfiguracyjna, podobnie jak BASIC ON/OFF, domyslnie OFF)
- udostepnia funkcje GET_BYTE - dzieki temu ladowany program moze np. dekompresowac dane wprost z udostepnianego obrazu pliku bez buforowania w pamieci (jesli funkcja sie przyjmie to w kolejnej wersji xBOOT - fileowego bootloadera dla *.atr/dyskietek tez zostanie zaimplementowana)

niestety sa tez ograniczenia :/
- ograniczenie wielkosci pojedynczego pliku to 8 388 096 bajtow ;D

ograniczenie spowodowane jest tym, ze chcemy udostepniac zasoby internetow oraz dane nagrane w FAT w taki sposob aby nawet uposledzone funkcjonalnie dosy mialy do nich dostep.

z chaosu powoli wylania sie swiatlo. teraz przyszedl czas na implementacje WYGODNYCH funkcji sieciowych (obecne dzialaja ale nie sa wygodne)

filmik:
https://www.youtube.com/watch?v=fJpNA8L9OJo

MM [dely]: fixed

MADS blednie kompiluje rozkaz DOP #

    14 4000 48                  .byte { DOP #$FF }
    15 4001 EA                  NOP
    16 4002 48 FF             DOP #$FF
    17 4004 48                  PHA

wczesniejsze wersje madsa w tym zakresie dzialaly prawidlowo.

Twoja nadinterpretacja robi sie smieszna

dziala na 1mb a nie dziala na 0,5? to musza byc czary.

o! jest mozliwosc ze w rejestrze Antica DMACTL niewykorzystane bity beda mogly przelaczac tryb pracy Antica:

na x2 color clock co pozwoli wyswietlac obraz 640x240 a w trybach gtia 160x240
na x4 color clock i mamy obraz 1280x240 albo tryby gtia 320x240

oczekuje, ze Twoj konfiturator oprocz bankow i rejestru sterujacego (zapis/odczyt) obejmie tez priorytety bo przeciez ktores z tych rozszerzen ma priorytet np. MEMACB - PORTB