Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
SV 2024 WE - program imprezy Już za tydzień odbędzie się zimowa edycja Silly Venture
Nowa obudowa dla 800XL - zostało 36 dni Niewiele ponad miesiąc do końca kampanii.
Zmarł twórca języka BASIC Zmarł Thomas E. Kurtz twórca języka BASIC
Zmiana serwera atari.area Serwis przeszedł właśnie ważną aktualizację infrastruktury
4th Atari ASCII Compo - wyniki Dostępne są już wyniki tegorocznego ATASCII Compo.
atari.area forum » Fabryka - 8bit » Bluetooth czyli SIO2BT
Strony Poprzednia 1 … 6 7 8 9 10 Następna
Zaloguj się lub zarejestruj by napisać odpowiedź
BTCFG SPEED 3konfiguruje moduł na 57600 (HSIO $08)
BTCFG SPEED 1konfiguruje moduł na 19200 (HSIO $28)
To robisz tylko raz i jeśli jesteś zadowolony, to już nie zmieniasz.
Natomiast Sparta Dos trzeba skonfigurować dla SIO2BT po każdym starcie kompa:
SIOSET WAITACK 16
SIOSET 1 US 8
Działa.
Nie jest to może demon prędkości, ale przyznam - bardzo fajne jest to urządzenie :)
Dzięki Montezuma!
Natomiast Sparta Dos trzeba skonfigurować dla SIO2BT po każdym starcie kompa:
SIOSET WAITACK 16 SIOSET 1 US 8
Ja sobie to wklepałem do configa i mam spokój ;)
Działa.
Nie jest to może demon prędkości, ale przyznam - bardzo fajne jest to urządzenie :)
Dzięki Montezuma!
Fajnie.
Możesz jeszcze troszkę przyśpieszyć, jeśli w ustawieniach appki zmienisz "opóźnienie zapisu" na 0ms.
Jest ono tylko potrzebne dla standardowych procedur SIO, bo precedury SIO Sparta Dos X nie mają problemu jeśli bajty ACK i COMPLETE przychodzą jeden po drugim (bez żadnej pauzy).
Z okazji czwartych urodzin appki - oto jej kod żródłowy:
https://github.com/TheMontezuma/SIO2BT
Na Google Play wrzuciłem update do wersji 3.00.
Poza małymi usprawnieniami, usunąłem z appki bazę danych z adresami modułow BT.
Tym samym appka pozwala teraz na połączenie z dowolnymi modułami BT SPP (np. HC-06), których nazwy zaczynają się od "SIO2BT" lub "ATARI".
Ta wersja będzie prawdopodobnie ostatnią dostępną na Google Play, ponieważ Google zapowiedział od listopada zamrożenie appek targetujących starsze wersje smartphonow. Appki będą dalej dostępne, ale deweloperzy nie będą mogli ich aktualizować.
Oczywiście zostanie możliwość instalacji za pomocą plików apk:
https://github.com/TheMontezuma/SIO2BT/ … Sio2Bt.apk
Bardzo dziękuję Wam za wsparcie mojego projektu (czyli za zakupy).
Polecam też AspeQt dla Androida: https://play.google.com/store/apps/deta … ple.AspeQt
i RespeQt dla WIN/LINUX/OSX: https://github.com/jzatarski/RespeQt
@Montezuma: a wiesz, że możesz targetować Pie i mieć Lollipoop (jak nie starsze) jako minimalną wspieraną?
Dzięki za info. Niby tak, ale problem jest taki, że zmiany w API to nie tylko nowa, dodana funkcjonalność, ale też zmiana zachowania isniejącego API.
Deklarując, że targetuję Pie, musiałbym kod i design UI dopasować do tej wersji API, a tym samym, na starszych telefonach appka mogłaby nie działałać jak należy.
Odwrotnie jest OK. Deklaruję jako TARGET Android 2.1 i wszystkie telefony w górę to respektują.
Testowałem na LG z Androidem 2.3 i na Pixelu z Androidem 9 (Pie) i wszystko działa jak należy.
Pie pokazuje podczas instalacji ostrzeżenie, że appka jest przeznaczona dla starszej wersji Androida, ale poza tym nie ma problemów.
Jeśli znalazłbym czas to raczej napisałbym nową appkę, targetującą Pie, która byłaby dostępna równolegle do starej "zamrożonej" appki.
A ja mam pytanie. Nie wiesz może dlaczego aplikacja nie tworzy nowej czystej dyskietki na Androidzie 8.0 na Galaxy S7? Wywala komunikat: "Nie udało się utworzyć nowej dyskietki". W systemie teoretycznie ma uprawnienia do zapisu plików na karcie pamięci.
Sprawdzilem przed chwilą na Pixelu z Androidem 9.0 i działa.
Domyślnie appka proponuje utworzenie pliku nowej dyskietki w ostatnio używanym katalogu (czyli tym, z którego wybieraliśmy ostatnio pliki).
Spróbuj czy uda Ci się utworzyć nową dyskietkę w pamięci wewnętrznej telefonu.
Albo inny test - wybierz jakiś plik ATR z karty pamięci, a następnie naciśnij dłużej jego nazwę (long touch).
Powinien pojawić się popup z możliwością zmiany trybu otwarcia pliku (R/RW). Wybierz RW.
Jeśli pojawi się błąd, to znaczy, że z jakiegoś powodu appka ma tylko READ ONLY dostęp do systemu plików na karcie pamięci :(
Poszukałem na szybko w necie i znalazłem coś takiego:
https://www.androidauthority.com/commun … nly.56873/
Upewnij się, czy karta pamięci jest sprawna...
Takiej się nie udało /storage/6A2B-4927/Atari/disk_20181017_133155.atr
Ale jak wybrałem inny /storage/emulated/0/bluetooth/disk_20181017_133602.atr
to poszło.
8.1.
Sprawdziłem i w wewnętrznej pamięci tworzy plik. Na karcie pamięci już niestety nie. Nie da się też odbezpieczyć dyskietki do zapisu. Karta pamięci oczywiście sprawna.
Dodam tylko, że inne aplikacje nie mają problemów z zapisem na karcie SD. Mam wrażenie, że czytałem kiedyś o tym problemie. Używam też innych aplikacji od niezależnych producentów i zdaje się, że też każda z tych aplikacji na moje wyraźne życzenie zmieniała uprawnienia do zapisu na karcie SD. W Androidzie 8.0 karta SD jest chyba domyślnie zablokowana do zapisu dla aplikacji.
Dzięki za feedback.
Znalazłem w sieci jeszcze to:
https://source.android.com/devices/storage/traditional
The WRITE_EXTERNAL_STORAGE permission must only grant write access to the primary external storage on a device. Apps must not be allowed to write to secondary external storage devices, except in their package-specific directories as allowed by synthesized permissions. Restricting writes in this way ensures the system can clean up files when applications are uninstalled.
Z drugiej strony inne aplikacje (jak choćby kamera, czy Total Commaner) potrafią zapisywać dane na karcie pamięci.
Sprawdziłem u siebie i Total Commander ma takie same "permissions" jak SIO2BT (WRITE_EXTERNAL_STORAGE ).
Spróbuję znaleźć rozwiązanie i wrzucić poprawkę przed 1 listopada...
No więc nic z tego nie będzie. Targetując Androida 2.1 (https://en.wikipedia.org/wiki/Android_Eclair), nie mogę korzystać z nowszego API, pozwalającego na dynamiczne udzielanie zezwoleń przez użytkownika.
Fakt, że appka deklaruje chęć zapisu do pamięci flash (WRITE_EXTERNAL_STORAGE) nie robi wrażenia na urządzeniach od wersji Android 4.4 (https://en.wikipedia.org/wiki/Android_KitKat), które pozwalają takiej appce tylko na odczyt plików z kart pamięci...
Więcej informacji tutaj:
https://possiblemobile.com/2014/03/andr … l-storage/
https://www.androidpolice.com/2014/02/1 … ting-them/
Widzę dwa rozwiązania problemu:
- można zaakceptować problem i używać pamięci wewnętrznej telefonu (zamiast karty SD)
- zrootowane telefony można zmusić do współpracy: https://www.thedroidway.com/fix-externa … -lollipop/
Sorry, że nie mam lepszych wiadomości...
No cóż. Szkoda. Nie zaśmiecam sobie pamięci wewnętrznej innymi plikami niż aplikacje. Pozostanie korzystanie z jakiegoś starego smartfona z szuflady.
Dzień dobry, pytanie mam.
Dlaczego oprogramowanie na androida nie jest w stanie podmontować pod BT pliku o rozmiarze 14.9MB??????
Nie pamiętam szczegółów, ale na szybko sprawdziłem,
że ma to chyba związek z ograniczeniami formatów systemów plików (DOS, MyDOS):
http://atariki.krap.pl/index.php/Format … lik%C3%B3w
W kodzie appki sprawdzany jest warunek:
if(mSectorCount > (0xFFFF-0x171))
{
// brak obsługi
gdzie liczba sektorów (mSectorCount) wyliczana jest na podstawie wielkości pliku, a więc duże pliki rzeczywiście nie są obsługiwane.
wydaje mi sie, ze plik w mydos moze siegnac sektor o numerze $ffff
wydaje mi sie, ze plik w mydos moze siegnac sektor o numerze $ffff
http://atariki.krap.pl/index.php/Format_MyDOS
Tak i według atariki format MyDOS pozwala na pliki wielkości do 15,81 MB.
W appce SIO2BT, dla każdego montowanego pliku (z wyjątkiem ATR, ktory sam w sobie jest obrazem dyskietki) emulowana jest dyskietka.
Żeby uprościć sobie życie, początek takiego pliku znajduje się na tej wirtualnej dyskietce w sektorze 0x171 = 369 (zaraz za sektorem z VTOC), a ostatnim sektorem, w którym mogą znajdować się dane pliku jest sektor 0xFFFF.
Czyli plik jest obsługiwany, jeśli daje się go zmapować do maksymalnie 0xFFFF - 0x171 = 0xFE8E (65166) sektorów.
Niestety emulowana dyskietka jest formatu SD, czyli sektor ma wielkość 128 bajtów (125 bajtów danych na sektor).
Daje to ograniczenie na długość pliku: 8 145 750 bajtów.
Wieczorem sprawdzę, czy dałoby się zmienić format emulowanej dyskietki na DD, co pozwoliło montować pliki 15,7MB.
po to zeby dosem mozna bylo czytac katalog montujac tylko plik?
dobrze napisany DOS nie przeczyta juz sektora $16A przeszukujac katalog jesli na "dyskietce" znajduje sie tylko jeden wpis.
wiem... czepianie sie :-)
W załączeniu plik instalacyjny appki SIO2BT, który emuluje dyskietke DD dla dużych plików.
Na próbę podmontowałem jakiś plik mp3 (11,5 MiB), ale nie mam cierpliwości, żeby skopiować go do pustego 16MiB ATR-a z prędkością 57600.
A sektorowo ?
Sektorowo bez zmian, pliki mogą zajmować maksymalnie: 65166 sektorów.
Dotychczas emulowana była dyskietka SD, a więc 65155x125=8145750 bajtów (7,77MiB)
Teraz DD, a więc 65155x253=16484215 bajtów (~15,72MiB)
Wielkość plików ATR ograniczona jest zgodnie z definicją formatu (16MiB), a plików wykonywalnych 7,77MiB.
Wczoraj zapuściłem kopiowanie podpiętego pliku MP3 (11,6MiB) do zamontowanego pustego ATR-a.
Po paru godzinach, wyekstraktowałem (na PC) z ATR-a plik mp3 i porównałem binarnie z orginałem. Wszystko OK, więc zmiany wrzuciłem do Github-a:
https://github.com/TheMontezuma/SIO2BT
Właściwie to gdzie można to kupić?
Strony Poprzednia 1 … 6 7 8 9 10 Następna
Zaloguj się lub zarejestruj by napisać odpowiedź
atari.area forum » Fabryka - 8bit » Bluetooth czyli SIO2BT
Wygenerowano w 0.037 sekund, wykonano 54 zapytań