Archiwa tagu: atari

Fujinet-pc na Raspberry Pi Zero W.

Wysłany by

Trafiłem ostatnio na wątek forum Atari Age, w którym Jan Krupa (apc) informował o postępach prac nad jego portem Fujinet na PC. Pierwsza myśl – jakby to działało na RPi Zero W?

Zamówiłem, szybko dotarło. Dopracowane jako produkt genialnie.

Instalacja Arch Linux na Arm6 to jakieś 10 minut na przygotowanie karty i konfigurację Wifi. Konfiguracja distcc zajmuje trochę dłużej, ale działa i bez tego – kompilacja na Raspberry to jakieś 15 minut. Źródła kompilują się bez żadnych warningów (zależności są minimalne: gcc, cmake, make i libbsd).

Update (sierpień 2022):

Niestety Archlinux Arm porzucił wparcie dla Arm6, więc przeinstalowałem Fujinet na Raspberry Pi OS z Debianem 11.4 Bullseye. Działa tak samo pięknie, a może nawet nieco lepiej.

Zwykle uruchamiam Fujinet w sesji screen przy starcie Raspberry Pi: screen -d -m ./run-fujinet, bo w razie konieczności zawsze można się przypiąć i odpiąć screenem po zalogowaniu przez ssh żeby zobaczyć co się dzieje. Interfejs webowy pozwala też na reset fujinet, ale szybciej i wygodniej zrobić to z Termux Widget na telefonie (skrypty uruchamiane są via ssh na Raspberry Pi):

#!/bin/bash
killall -9 fujinet
cd /home/greblus/fujinet/
screen -d -m ./run-fujinet

Skoro działa, to może jakiś niezbyt miarodajny test, np. RWTEST. Testy w SpartaDos X na Rpi, laptopie z Linuksem i w moim porcie AspeQt na Androidzie. Ten sam obraz atr z RWTEST.COM podmontowany jako D1. Fujinet na Rpi Zero działa fajnie z hsindex=0 i SIO2PC-USB, ale dobrze jest wyjście debuggowania w skrypcie run-fujinet przekierować do /dev/null, jest jednak nieznacznie szybciej, nawet przy odpiętym terminalu screen.

Fujinet na Rpi Zero W
Fujinet na laptopie
AspeQt na Androidzie

Jest ok. Zaskakujące, że na PC działa wolniej. Tłumaczę sobie to tym, że odczyty realizowane są z pamięci RAM bo obraz atr jest wczytywany do pamięci, a zapisy na Rpi i Androidzie realizowane są na pamięci Flash, tymczasem na moim starym laptopie kręci się stary dobry dysk talerzowy 5400rpm 🙂

Syncthing + AspeQt-1.0.62.

Wysłany by

Z najnowszej wersji AspeQt-1.0.62 (dostępna w Google Play i na Github) jestem wyjątkowo dumny pomimo, że nie ma w niej żadnych rewolucyjnych zmian:

  • Przebudowane z Qt-5.9.7 (min. API 16 = Android 4.1).
  • Poprawione błędy sterownika ftdi – działa z HSINDEX 0 = 115200bps.
  • Sprawdzanie dostępu do karty SD na Mashmallow i nowszych wersjach Androida

Jednak ta druga pozycja… to chyba najbardziej dołujący jak dotąd błąd z jakim przyszło mi się zmierzyć. Ale o co chodzi? Na nie-rootowanym Androidzie jedyna sensowna opcja obsługi portu szeregowego, a taki jest potrzebny do emulacji urządzeń SIO w 8-bitowym Atari, to tzw. usb-host mode i próba dogadania się z najpopularniejszym i najbardziej sensownym układem pozwalającym na taką komunikację, czyli FT232R firmy FTDI. Firma wypuściła w tym celu bibliotekę d2xx dla Androida, jednak nie jest ona zbyt szybka, a dodatkowo, licencja jest co najmniej problematyczna. Dawno temu odkryłem więc usb-serial-for-android. Dostęp do obiektów Javy w Qt5 i vice versa opisywałem już wcześniej – wystarczy wspomnieć, że bez JNI nie da rady tego ogarnąć, ale co zaskakujące, działa to bardzo szybko i wydajnie. Pod warunkiem, że działa ;). No i tu zaczyna się demotywująca część historii. Na niektórych urządzeniach AspeQt śmigał aż miło, ale użytkownicy zaczęli zgłaszać, że pomimo prawidłowej obsługi usb-host, na niektórych całkiem porządnych urządzeniach z Androidem nie działa. Niestety usb-serial-for-android od dwóch lat praktycznie rozwija tylko jedna osoba – Kai Morich w swoim forku – i to dzięki niemu udało się problem rozwiązać.

A teraz o moim ostatnim odkryciu: syncthing. AspeQt z HSINDEX 0 śmiga całkiem szybko, więc podmontowałem w nim na androidowym TVBoxie katalog, który przez syncthing jest synchronizowany po Wifi z laptopem i telefonem. Dzięki temu wszystko co ściągnę z internetów mogę od razu, bez skomplikowanych operacji, uruchomić na moim 8-bitowym super sprzęcie ;). Syncthing jest świetny, darmowy i bez reklam. W archowych repozytoriach są gotowe paczki dla Linuksa, a w Google Play apk dla Androida. Długo czegoś takiego szukałem:

SIO2BT + AspeQt.

Wysłany by

Update: wersja 1.0.39 z obsługą SIO2BT jest już w Google Play.

Kilka tygodni temu dotarły do mnie słuchy, że FJC planuje dodać obsługę większych prędkości (do 57600 bps) SIO2BT w PBI BIOS Ultimate 1MB, pomyślałem – ja się piszę – Marcin „The Montezuma” Sochacki przysłał mi pięknie zmontowanego dongla SIO2BT, a kilka dni później  AspeQt na Androidzie obsługiwał już SIO2BT.

Wersja w Google Play.
Ta sama wersja na Github.

Poza sparowaniem z Androidem wystarczy tylko w ustawieniach podać nazwę modułu, z którym AspeQt będzie się łączył. Standardowo wykorzystuje programową detekcję ramki komendy (SOFT), a prędkość ustawia się narzędziem BTCONFIG z poziomu Atari (jednorazowo). Z najnowszym firmware U1MB działa @57600bps. Jedyne wymaganie to wybranie w Opcjach interfejsu SIO2BT i ustawienie nazwy modułu BT, z którym Android będzie się łączył.

W planach mam utworzenie wspólnego javowego interfejsu dla SIO2BT, usb-serial-for-android i felhr/UsbSerial. Nie powinno mi to zająć dużo czasu…(zrobione).

Zadziała z każdym adapterem zbudowanym wg tego prostego schematu:

bluetooth_03

Moduł BT to koszt ok. 20zł (HC-06 na Allegro).

VBI i DLI w MadPascal-u.

Wysłany by

Kiedyś eksperymentowałem z Action!, dziś analogiczny przykład w MadPascal:

uses crt;

const
dl: array [0..32] of byte = (
112, 112, 112, 66, 0, 64, 2, 2, 2, 2, 2, 2, 2, 2, 2,
2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 130, 86, 72, 67, 65,
lo(word(@dl)), hi(word(@dl))
);

var
col0: byte absolute $2c4;
col1: byte absolute $2c5;
savmsc: word absolute $58;
nmien: byte absolute $d40e;
pc: ^byte; tmp: word;
hscrol: byte absolute $d404;
vcount: byte absolute $d40b;
colt: byte absolute $d017;
dlist: word absolute $230;
i,j,k,l,indx: byte;

procedure dli; interrupt;
begin
 asm { phr };
 inc(indx);
 for i:=0 to 7 do
  begin
   if indx>30 then indx:=0;
   colt:=vcount+indx;
  end;
 asm { plr };
end;

procedure scroll; interrupt;
begin
 j:=j+1;
 if j=16 then
  begin
   j:=0; dec(pc^,2); k:=k+1;
   if k=14 then
    begin
     k:=0; pc^:=tmp;
    end
  end;
  hscrol:=j;
 asm { jmp $E462 };
end;

begin
 i:=0; j:=0; k:=0; indx:=0;
 dlist:=word(@dl);

 SetIntVec(iVBL, @scroll);
 SetIntVec(iDLI, @dli);
 nmien:=$c0;

 pc := @dl;
 inc(pc, 28);

 tmp := pc^+6;
 col0 := 14; col1 := 14;
 savmsc := $4000;

 for l:=0 to 22 do
  writeln(' mp rulez! ');

 repeat until keypressed;
end.

mprulez

Niezaprzeczalną zaletą duetu mp+mads jest optymalizacja i wielkość pliku wynikowego:

$ mads -x -o:scroll.obx -i:/e/mp/base scroll.a65
SYSTEM: $205D..$205C
CRT: $205D..$2070
CODE: $2000..$226F
DATA: $2270..$2282
Writing listing file…
Writing object file…
3983 lines of source assembled in 5 pass
640 bytes written to the object file

 

AspeQt na Androidzie.

Wysłany by

Update: AspeQT na Androida jest dostępny w Google Play.

Jak niektórzy czytelnicy atarowych forów pewnie zauważyli, udało się. AspeQt działa na moich „Antkach” (4.2.2 Jelly Bean i 4.4.2 Kitkat).

Nie obyło się bez przygód. Z obsługą Kitkata miałem problem wynikający z dziwnego podejścia producentów lub ich nieświadomości: dostałem ostatnio od operatora jako nowy klient, bardzo fajny telefon: Kazam Tornado 348. Pod względem jakość/cena, polecam każdemu. Okazało się jednak, że tenże Kazam obsługuje OTG, czyli mogę sobie podłączyć np. pendrive, ale już USB Host na nim nie działa jak trzeba (pewnie jest nieskonfigurowany, a ja go rootować nie mam zamiaru). I cały czas, o ja głupi, myślałem, że to wina sterownika ftd2xx od FTDI, lub też zmian w KitKacie związanych z obsługą tzw. BroadcastReceiverów.

Jak widać powyżej na zupełnie budżetowym Kazam 345, wszystko śmiga aż miło (swoją drogą na prawdę fajny telefon, ale jakościowo Tornado vs Thunder dzieli ogromna przepaść). Support Kazam obiecał zająć się tematem. Może spodobało im się Atari…

Piszę to dlatego, że użytkownicy powinni się buntować. Dlaczego jeżeli sprzętowo coś jest dostępne, celowo pozbawiać użytkownika możliwości korzystania z tego? Bo co? Bo podłączy sobie przez USB klawiaturę/głośniki/kamerę dowolnego producenta? Paradoksalnie, tanie produkty, jak np. mój Lark FreeMe X2 nie mają z tym problemu. Ale już np. Samsung S5 mini, którego mam z pracy USB nie obsługuje wcale. To nic, że kosztuje krocie…

Przed AspeQT na Androidzie jeszcze daleka droga:

  • Muszę poprawić GUI, żeby dało się go obsłużyć wygodnie i na małym i na dużym ekranie.
  • Okno wyboru pliku i katalogu to w Qt5 na Androida jakaś masakra. Trzeba będzie poeksperymentować z dostępnymi natywnymi bibliotekami, które tą funkcjonalność oferują i obsłużyć to przez JNI.
  • Kontrola przepływu i prędkość transmisji, tego póki co się najbardziej obawiam. Póki co ustawiam FT_FLOW_NONE i prędkość na 19200. DSR nie chce działać, a po ustawieniu prędkości powyżej 19200 bez kontroli przepływu skutkuje odczytem bzdurnych danych.

Ale nic na siłę, wszystko w swoim czasie ;).

Dla zainteresowanych repo na github:

https://github.com/greblus/aspeqt

Apka poniżej (pod tym linkiem wrzucam najnowsze wersje bez uprzedzenia ale w katalogu android/apk/ zachowuje poprzednie, z datą kompilacji):

https://github.com/greblus/aspeqt/blob/android/android/apk/aspeqt.apk

QAndroidJniObject. To naprawdę działa!

Wysłany by

Jakby ktoś się zastanawiał, to walczę dalej z portem aspeqt na Androida, a dokładniej z obsługą czipu FTDI na Androidzie. Sterownik ftd2xx od FTDI to totalna porażka (segfault goni segfault) i z tego co widzę nie ma szans na obsługę FTDI za pomocą tego sterownika bezpośrednio z C++, bez roota i modyfikacji obrazu systemu.

Na szczęście jest jeszcze libftdi.

Ale i tutaj nie jest tak różowo. W pierwszej kolejności musiałem skompilować libusb na Antka, potem samo libftdi, a to wszystko, żeby się przekonać, że standardowe libusb nie potrafi otworzyć urządzenia bo nie ma do tego uprawnień. I choćby nie wiem jak kombinować z uprawnieniami w Manifest.xml, nic  to nie da.

Jest alternatywne podejście: najpierw z poziomu Javy należy otworzyć urządzenie i uzyskać uprawnienia do usb. Potem przekazać deskryptor pliku urządzenia do libusb. To ponoć działa na delikatnie zmodyfikowanej wersji libusb (mam już ją skompilowaną na Antka).

Mój plan był prosty: z poziomu QT wywołuje klasę Javovą, która otworzy urządzenie i poprosi o uprawnienia, a potem zwróci do QT deskryptor pliku. Plan planem, ale JNI w QAndroidJniObject nie chciało mi działać. Teraz już wiem dlaczego :). Przykład Bogdana Vetry zawierał rozwiązanie problemu w pierwszym komentarzu: plik źródłowy w Javie, umieszczamy w katalogach odpowiadających strukturze pakietu, ale w android/src. Jak pakiet utworzę w android to nie zadziała ;).

Czyli:
1. Tworzymy nowy projekt QT Android.
2. W pliku .pro dodajemy:

QT += core gui androidextras
ANDROID_PACKAGE_SOURCE_DIR = $$PWD/android/

W katalogu projektu dodajemy katalog android/src/net/greblus/MyJavaClass.java:

package net.greblus;

public class MyJavaClass {
     public static int fibonacci(int n)
    {
        if (n < 2)
            return n;
        return fibonacci(n-1) + fibonacci(n-2);
    }
}

i wywołujemy w C++ z QAndroidJniObject w ten sposób:

ret = QAndroidJniObject::callStaticMethod<jint>("net/greblus/MyJavaClass", "fibonacci", "(I)I", n);

Dwa wieczory spędziłem nad tym brakującym src, ale dzięki temu sporo się nauczyłem ;). QT5 to dla mnie w tym momencie toolkit nr 1.

libusb mam już skompilowane, teraz tylko mała modyfikacja libftdi i można próbować z otwieraniem urządzenia z Javy ;).