Cracow Acid City.

Nie mogłem uwierzyć, że to brzmi tak dobrze na żywym Atari i pierwsze co zrobiłem wraz z poranną kawą, to test na prawdziwym sprzęcie.

 

Makary, pozamiatałeś chłopie! Nigdy nie słyszałem czegoś tak dobrego na 8-bitowym sprzęcie.

 

 

Reklamy

SIO2BT + AspeQt.

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.

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

 

Ładowanie plików CAS w AspeQt na Androidzie.

Udało się znaleźć przyczynę i pliki cas ładują się aż miło:

Dzięki temu zapisy do atr też powinny działać poprawnie. O dwa purge() za daleko i ftdi nie „zdanrzał” zapisać/odczytać danych z portu Atari.

Apk-a w zwyczajowej lokalizacji:

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

AspeQt na Androidzie.

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