26

Nie myślałeś o zastosowaniu Wemos D1 Mini? ESP-12E (ESP8266 tylko więcej IO), zasilanie 5V z microusb więc już masz zamiast 2 płytek 1 + konwerter stanów logicznych.

27

Pawel, przemyślałem sprawę i ten mały moduł ESP-01 to kiepski pomysł. Niby ma dwie linie GPIO wyprowadzone, ale są kłoptliwe w użyciu jako wejścia. ich stan jest sprawdzany przez bootloader urządzenia. Bardziej myślę o płytce od NodeMCu - więcj wyprowadzonych gpio, stabilizator 3v3 oraz USB-TTL na płytce. Tylko dokupić konwerter stanów logicznych.
http://propix.com.pl/pl/p/NodeMCU-v3-ES … CH340-/837

Sikor, dzięki za info, spróbuję porozumieć się z gościem. Temat jest świeży na AAge.

xxl, chcę też zabezpieczyć się na wypadek wysyłki na SIO danych podobnych do komend AT, ale nie skierowanych do modułu wiFI, tylko np. do stacji dyskietek czy drukarki ;)
Na początek tak jak Zenon opisywał jechałbym bezpośrednio po rejestrach POKEY'a z pominięciem OS. Później możnaby rozważyć np. firmware zgodny ze standardem urządzenia sieciowego SIO zaproponowanym przez Montezumę przy SIO2BT.

Czyli widzę pomysł jakiś sens ma, można próbować.

grzybson/SSG^NG

28

@grzybson mówimy o tym samym? Mnie chodzi o tę płytkę: https://www.wemos.cc/product/d1-mini.html
Mam i NodeMCu i Wemos i wolę Wemos bo mniejszy.

29

@Grzybson: command jest w stanie niskim podczas wysylania komendy ustawiony w pozostalych przypadkach - to nie wystarczy odwrocic command dla nowego urzadzenia i "sprawa zalatwiona", nie bedzie szansy na kolizje? chyba?

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

30 Ostatnio edytowany przez Montezuma (2017-02-24 14:44:57)

grzybson napisał/a:

xxl, chcę też zabezpieczyć się na wypadek wysyłki na SIO danych podobnych do komend AT, ale nie skierowanych do modułu wiFI, tylko np. do stacji dyskietek czy drukarki ;)
Na początek tak jak Zenon opisywał jechałbym bezpośrednio po rejestrach POKEY'a z pominięciem OS. Później możnaby rozważyć np. firmware zgodny ze standardem urządzenia sieciowego SIO zaproponowanym przez Montezumę przy SIO2BT.

Hej Grzybson,
poczytaj sobie o ATARI 850:
http://atarionline.pl/biblioteka/materi … qfpkblqpp6
W czasach kiedy nie było jeszcze internetu, Atarowcy w USA używali modemów ze złączem RS232 podpiętych do ATARI 850, żeby łączyć się z BBS-ami, a odbierane dane wyświetlane były przez software-owe emulacje terminali, np. Bobterm.
Odpowiadalo to mniej wiecej dzisiejszym stronom internetowym.

Dzisiaj Ci sami (30 lat starsi) Atarowcy powymieniali modemy na nowe np. Lantronix UDS10:
https://www.lantronix.com/wp-content/up … 100_UG.pdf
i łączą się za pomocą usługi Telnet z BBS-ami.

Wracając do Twoich pytań.
Atari 850 to urzadzenie SIO i jak wszystkie urządzenia SIO nasłuchuje stanu linii COMMAND, ignorując dane adresowane do innych urządzeń. Nie ma więc problemu jeśli dane zapisywane na dyskietkę będą przypadkowo zawierać komendy AT.
Magia polega tutaj na tym, że w czasie połączenia z modemem (i z BBS-ami) protokół SIO jest chwilowo nieaktywny.
850 można bowiem komendą SIO przestawić w tryb pracy nazwany przez ATARI "Concurrent Mode I/O".
W tym trybie 850 przerzuca tylko dane (raw data), a ATARI odbiera i wysyła dane używając sterownika urządzenia R: (wszystko dzieje się z pominięciem SIO). Innym urządzeniom to nie przeszkadza, bo cały czas czekają na wysoki stan linii COMMAND.
ATARI 850 opuszcza tryb "Concurrent I/O" po ustawieniu linii COMMAND przez komputer ATARI.

Oprogramowanie APE emuluje taki zestaw (ATARI 850 + modem). To samo możnaby uzyskać z ESP8266.
Jednak moim zdaniem bez dedykowanego firmware-u dla ESP8266 albo dodatkowego microcontoller-a nie da się użyć ESP8266 nie powodując kolizji z innymi urządzeniami SIO.
Ważne, żeby wiedzieć i rozumieć czego się chce. Nie wystarczy tylko powiedzieć, że chce się WI-FI ;-)

Moje podejście w "SIO2BT Networking" jest inne.
Cały czas aktywny jest protokół SIO i wysyłane/odbierane dane zawsze pakowane są w ramki SIO.
Jak znajdę trochę czasu, to dodam tą funkcjonalność do RespeQt i do sio2bsd.

Warto też poczytać sobie o modelu warstwowej struktury protokołów sieciowych:
https://pl.wikipedia.org/wiki/Model_TCP/IP

Warstwa transportowa TCP/IP dostępna jest dla programistów za pomocą mechanizmu gniazd (sockets).
Na tym właśnie poziomie "SIO2BT Networking" daje programistom ATARI dostęp do serwerów.

Usługi i protokoły takie jak: telnet, http, ftp, irc są w warstwie aplikacji.
Modem Lantronix i APE mają zaimplementowanego klienta usługi telnet, tak więc tutaj "cięcie" jest w innym miejscu.
Jeszcze inaczej jest z CONTIKI, które implementuje cały stos TCP/IP, a Dragon Cart udostępnia jedynie warstwę fizyczną ethernet.

SIO2BT:

ATARI (SIO)
--------------
TCP/IP sockets / Android device

Lantronix:

ATARI (R: handler)
--------------
Telnet / Lantronix device

Dragon Cart:

ATARI (CONTIKI)
--------------
ETHERNET / Dragon Cart

Przykładowo przeglądarkę stron WWW dla ATARI można by zrobić na 2 sposoby:
1) zaimplementować protokół http na ATARI (podobnie jak jest to już zrobione w CONTIKI)
2) zaimplementować protokół http w zewnętrznym urządzeniu i zdefiniować uproszczony protokół pomiędzy tym urządzeniem a ATARI. Takie urządzenie konwertowałoby strony WWW na wersje przyjazne dla ATARI.
3) Ewentualnie jak w punkcie 1) ale z użyciem serwera proxy, konwertującego strony WWW na wersje przyjazne dla ATARI

Można jeszcze wspomnieć o zastosowaniu "SIO over WI-FI", gdzie ESP8266 emulowałoby stacje dyskietek pozwalając na ładowanie gier z sieci.

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

31

I co tam w temacie bom ciekaw :P

32

jest hotove wifi?

ATARI 800XE with u1mb, stereo, covox, ramdisk hell led, ultra video 1.0 XE.
SIO2SD, SIDE3, sio2usb, sio splitter, dragon cart, lantronix mss-100, fujinet (lotharek), rverter, A8PicoCart, BT-100, XC12 (T2000), XC12 (SUPER TURBO, TURBO D), both with internal speakers
my youtube channel