26

Montezuma napisał/a:

Możesz oczywiscie komendę GetTime zaimplementować na mikrokontrolerze, ale po co? Czas z mikrokontrolera nie będzie bardziej "wiarygodny" od czasu z ATARI.

Ja chciałbym podawać czas pobrany z internetu z jakiegoś NTP.
Wygląda na to że trzeba będzie dublować funkcjonalności w obu urządzeniach bo chcemy wykorzystywać podobne funkcje np. URLrequest, URLSubmission, GetTime etc. Może dla porządku niech te funkcję są realizowane za pomocą tych samych COMMAND ID ale z różnym SIO DDEVIC

27

Sikor napisał/a:

Polemizowałbym. Mimo synchronizacji czasu włączonej w win 10 na dwu komputerach czas mi się znacznie rozjeżdża.

Sterowania elektrownią atomową na tym nie robimy ;)

dekanex napisał/a:

Ja chciałbym podawać czas pobrany z internetu z jakiegoś NTP.
Wygląda na to że trzeba będzie dublować funkcjonalności w obu urządzeniach bo chcemy wykorzystywać podobne funkcje np. URLrequest, URLSubmission, GetTime etc. Może dla porządku niech te funkcję są realizowane za pomocą tych samych COMMAND ID ale z różnym SIO DDEVIC

SIO cart to Twój projekt i możesz robić co chcesz, ale polecam Ci (tam gdzie się da i ma sens) trzymać sie istniejących rozwiązań.
Jak już pisałem APE TIME (wprowadzony w oprogramowaniu APE):
http://atariki.krap.pl/index.php/APE_Time
stał sie standardem de facto.

Nic nie stoi przecież na przeszkodzie, żeby SIO cart emulował kilka urządzeń SIO. Dla niezaimplementowanych komend urządzenia wysyłasz NACK i tyle.

Załóżmy, że XXL napisał grę, która ładowana jest jest ze stacji dyskietek, pobiera sobie czas i komunikuje się z serwerem HiScore.
Wszystko przez SIO, używając 3 wirtualnych urządzeń (dysk D1 do załadowania gry, SmartDevice i NetworkingDevice).
Oczywiście gra zadziała nawet jeśli nie ma (opcjonalnych) SmartDevice ani NetworkingDevice w systemie.
Po prostu wyświetli się po staremu DATA MATRIX. A jeśli są, to gra spróbuje przesłać Hi-Score automatycznie.

Fajnie by było, żeby tak się działo bez względu na to czy grasz używając SIO Cart-a, RespeQt, AspeQt, sio2bsd, czy SIO2BT, itd.

ATARI 65XE + SIO2BT
http://atari.pl/hsc/ad.php?i=22.3

28

SIO cart to inny projekt i nie ma (na razie) nic wspólnego z SIO2WIFI ;)
Nie chce niczego robić na siłę. Jak dobrze wiesz nie jestem atarowcem i nie będę tu niczego forsował (nie śmiał bym). Liczę właśnie na to, że tutaj od Was dowiemy się jak najlepiej to zrobić i po to między innymi jest ten wątek.
Nie widzę większego problemu aby emulować trzy urządzenia. Po ustaleniu z xxl-em pewnie tak zrobimy. Skoro APE Time jest standardem to chętnie skorzystam z tego co już zostało wymyślone :) Chce w jak największym stopniu trzymać się tego co już jest, natomiast do tego czego nie ma ustalić z Wami najlepsze podejście.

29 Ostatnio edytowany przez mono (2017-04-06 16:23:23)

Zasugerowałbym rozważenie jakie urządzenia mogłyby być używane naraz na magistrali SIO, żeby nie okazało się że na wysłane polecenie jedno odpowiada NAK, a drugie ACK, bo na magistrali będzie miszmasz? Polecenie nieobsługiwane nie powinno odsyłać żadnego statusu, wtedy jest szansa że inne urządzenie odpowie (choć to złamanie założeń protokołu). Celem zapobieżenia konfliktów niektóre urządzenia (disk drive) mają swoje numery - może powinno to pójść w tą stronę?

Edit: ort

hex, code and ror'n'rol
niewiedza buduje, wiedza rujnuje

30 Ostatnio edytowany przez xxl (2017-04-16 20:25:23)

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

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

31 Ostatnio edytowany przez grzybson (2017-04-16 22:24:53)

dane nagrane w FAT

Urządzenie będzie miało czytnik kart SD? Gdzie będą te pliki nagrane w FAT?

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

Skąd to ograniczenie? O ile mnie pamięć nie myli, moduły ESP-12E 4 MB flash, więc musi być jakiś dodatkowy bufor.

Co jest na breadboardzie na filmiku? Moduł ESP12, konwerter stanów logicznych, zasilanie - coś jeszcze?

No i ponawiam swoje poprzednie pytanie - w czym piszecie firmware dla ESP8266?
(jeżeli na jakieś pytanie nie chcesz odpowiedzieć, to proszę też napisz)

grzybson/SSG^NG

32

proszę

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

33

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.

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

34

Czyli ty nie piszesz firmware'u dla ESP8266 tylko dekanex, tak?

grzybson/SSG^NG

35

firmware pisze dekanex.

przekazalem mu Twoje pytanie, i odpowiedzial: "moge ale po co".

typowy komodziarz.

---
na AAge tez jest prowadzony projekt wifi karta...

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

36

po pięciogodzinnym maratonie programowania wreszcie jest pierwsze polaczenie.

Co już możemy:
1. Scan network = wyszukaj sieci
2. command status = status komendy - w trakcie relizacji, blad, done
3. get network info = lista sieci (+ parametry)
4. connect network = polacz z nr.sieci (przeslij haslo w buforze, nr. sieci w AUX)
6. Network status = pobierz informacje o sieci (jesli jestesmy polaczeni)

Oczywiscie rozkazy SIO sa tymczasowe.

https://www.youtube.com/watch?v=v4ZljIuYKCk

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

37

Jakie rodzaje szyfrowania sieci są obsługiwane? Pytam o konkretną listę.

Rozumiem, że cały stack TCP oraz obsługę 802.11 zrzucacie na ESP8266?

.: miejsce na twoją reklamę :.

38 Ostatnio edytowany przez xxl (2017-04-21 08:22:17)

0    Sieć otwarta
1    Sieć chroniona WEP
2    WPA_PSK
3    WPA2_PSK
4    WPA_WPA2_PSK

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

39

skrzyp napisał/a:

Rozumiem, że cały stack TCP oraz obsługę 802.11 zrzucacie na ESP8266?

Tak

40

Dzięki za informację.

.: miejsce na twoją reklamę :.

41

a soft oczywiście nie będzie działał na U1MB czy będzie wymagał mapRAMu?

Atari Falcon 030 14MB+SD16GB; Atari TT 030 4MB ST-RAM, 64 MB TT-RAM; Atari 1040 STFM; Atari 1040 STE 4MB+NetUsbee+UltraSatan; Commodore 64+1541-II+XE1541; Atari 65 XE+CA-2001+Ultimate 1MB+Side2;  P166MMX+GUS.

42

Pójdzie pod dowolnym DOS-em bez xBIOS-a?

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

Terry Pratchett - Równoumagicznienie

43

O ja prdl... Zagrac po sieci w Hammurabiego to jest to na co czekam :) Ale bez odpowiedniego patcha to i tak sie nie da :/

44

skrzyp napisał/a:

Jakie rodzaje szyfrowania sieci są obsługiwane? Pytam o konkretną listę.

Rozumiem, że cały stack TCP oraz obsługę 802.11 zrzucacie na ESP8266?

O ile jakiś tam protetyczny stos tcp jestem sobie w stanie wyobrazic na 6502/816 o tyle juz szyfrowania i 802.11 nie baudzo.

"Was powinny uzbrojone służby wyciągać z domów do punktów szczepień, a potem zamykać do pi* za rozpowszechnianie zagrożenia epidemicznego" - Epi 2021
"Powinno się pałować tylko tych co tego nie rozumieją. No i nie szmatki i nie chirurgiczne tylko min FFP3, to by miało jakiś sens. U mnie we firmie, to jak przychodzi bezmaskowiec, to stoi w deszczu przed firmą" - Pin 2021

45

No właśnie stąd pytanie, bo coś mi tu nie pasowało

.: miejsce na twoją reklamę :.

46

mazi napisał/a:

O ja prdl... Zagrac po sieci w Hammurabiego to jest to na co czekam :) Ale bez odpowiedniego patcha to i tak sie nie da :/

hehe, swietny pomysl :-)

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

47

mazi napisał/a:

Zagrac po sieci w Hammurabiego

.. będziesz jednym z dwóch na świecie, którym ten pacz się uruchomi :D

Kontakt: pin@usdk.pl

48

Jako, że WiFi Prime jest wierne ostatnim wytycznym dzialu rozwoju firmy Atari:

"a new era of SIO "Plug n Play" devices to automatically load their device drivers and even on-board applications"

projektowana aplikacja-komunikator bedzie na zadanie sciagana i uruchamiana wprost z serwera, polaczenie z aplikacji uruchomionej w inny sposob nie bedzie akceptowane przez serwer komunikatora.

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

49

.. będziesz przez ten komunikator rozmawiał sam ze sobą? Zrobiłbyś raz coś normalnie.. :)

Kontakt: pin@usdk.pl

50

! dobry pomysl ! do serwera trzeba bedzie dodac jakiegos prostego BOTa :D

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