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.
