AspeQt for Android (beta).

[greblus]

Hi again.

 

With write delay set to 0ms in sio2bt settings it's getting a bit faster, but the communication is not stable. I thought that maybe reducing the distance between my tablet and bt dongle will improve stability but it does not change anything.

 

W.

 

[TheMontezuma]

A delay (10ms) is normally needed only when you use a patched XL/XE OS.

With the PBI SIO driver (Ultimate 1MB) in the HSIO+SIO2BT mode, 0ms should do well.

[flashjazzcat]

Mine's not especially stable with the delay set to 0 either, I must say, although it does flatter the benchmark. I wonder if environmental factors are to blame here too?

[TheMontezuma]

I wonder what we are doing in a different way:

 

 

The above results come from:

- Google (LG) Nexus 5 with SIO2BT app (2.71) and "Write Delay" set to 0ms

- Atari 65XE with Ultimate 1MB with UPBI BIOS 1.81, PBI Enabled, HSIO+SIO2BT

 

I get even better results with my old LG E-400 Android phone (Android 2.3).

[greblus]

No idea, on my Galaxy S5 mini the results are even worse. It's be cool to make it better, but the Android BT API doesn't have any magical functionality we could try...

Edited September 19, 2016 by greblus

[TheMontezuma]

Here are my results with the same setup, but with the "new" Android AspeQt app:

 

 

The AspeQt app works really well

 

Both tests (with SIO2BT app and with AspeQt app) were executed with 57600 Baud.

 

The results are very similar. AspeQt is a bit slower than the SIO2BT app (with 0ms delay) on my Android device.

 

There is a subtle difference in a way both apps handle files.

AspeQt copies the ATR files to the RAM, making file access as fast as possible, on the other hand writing to files has to be synchronized (either manually or automatically) with a physical file.

SIO2BT app access files directly, so the access time can differ depending on the flash memory.

A few weeks ago I built a test version of the SIO2BT app with a RAM file access, but the performance increase was negligible, so I gave up this approach.

 

What makes a difference is a delay (I called it "write delay") between ACK and COMPLETE bytes.

It is important for the patched XL/XE OSs. If these bytes would arrive at ATARI after each other without any pause in between, the ATARI would not process the COMPLETE byte and this would trigger a retry, making the communication less stable.

 

@Jon, @Wiktor

Is this what you observe?

 

As fas as I know, with the HIAS code in the Ultimate PBI Bios, the ACK and COMPLETE bytes can come together (this happens when the "write delay" setting of the SIO2BT app is set to 0ms).

 

I do not care that much about small performance differences between the apps.

I'm only concerned about stability issues if there are any (I do not observe them with my setup).

Edited September 20, 2016 by TheMontezuma

[flashjazzcat]

I'm not sure why behaviour of the patched OS would be different to that of the PBI BIOS concerning the proximity of ack and complete. It's the same code. Unless I missed some salient point (which is possible at the moment). What is the supposed difference?

[greblus]

Thanks for sharing the results! and great to know that the results are comparable - it means that JNI overhead is not that significant. I tried to do as much as possible in Java,

to limit the JNI calls. But I can't understand why your Nexus is so much faster than my S5 or Lenovo . Either Samsung/Lenovo did a very poor job with their bluetooth mods

applied to Google sources, or my bluetooth adapters are somehow incompatible with sio2bt dongle. I think it's time to get a Nexus.

 

I'll add 0ms delay option to AspeQt as well, but when I tried the communication was stopping with Error 143 (which is strange, as it's the checksum error).

 

W.

[TheMontezuma]

I'm not sure why behaviour of the patched OS would be different to that of the PBI BIOS concerning the proximity of ack and complete. It's the same code. Unless I missed some salient point (which is possible at the moment). What is the supposed difference?

 

Sorry, my mistake, I should be more precise.

With a patched OS I mean a standard XL/XE OS patched for Bluetooth (bigger TIMEOUT value) supporting 19200 only.

With the PBI SIO I mean the HIAS' SIO code adapted by you for U1MB and Bluetooth and supporting 57600, 38400 and 19200.

 

The standard XL/XE SIO code expects a pause between ACK and COMPLETE bytes (min. 250 μsec, according to the SIO spec).

Since Bluetooth data is buffered in the transceiver, much bigger delay has to be applied in the app (for example 10ms) to achieve the goal.

However the HIAS' SIO procedure does not have such limitation (as far as I know).

Edited September 20, 2016 by TheMontezuma

[TheMontezuma]

-

Edited September 20, 2016 by TheMontezuma

[flashjazzcat]

Sorry, my mistake, I should be more precise.

OK - I understand now! No apology required.

[greblus]

Hi guys.

 

SIO2BT is now officially included in my main Android branch

 

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

 

In this apk it's possible to change serial interfaces on the fly (SIO2BT through native Android BT stack and SIO2PC through usb-serial-for-android java library).

 

I've added ACK write delay as suggested by Marcin (default setting is still 10ms). It can be changed in the options window. Tests are not showing any instabilities in AspeQt when delay is set to 0ms and the results are getting a bit closer to Montezuma's test on his Nexus . Second screenshot is showing the results with my SIO2PC-USB right after switching the "driver".

 

Now I've to use it for a few days to see if all works well.

 

 

[+Larry]

S.O.T.

 

One of the advantages to the Android idea is certainly the small size of the phone/tablet. Here's one I used for a couple of years. Note that the "Mountain Dew" can is for size reference and also the caffeine is the power source for the P.C.

[TheMontezuma]

To be honest, I do not recommend Nexus 5 that much.

One big disadvantage of that smartphone is the way it handles (or rather the way it does not handle) the host USB port...

This means - I can't use the Android AspeQt with a cable connection

 

And one example picture, which shows that the number of cores and the CPU frequency sometimes does not matter:

 

 

This test was executed with the SIO2BT app on a very old single core LG E400 (Android 2.3) and the results are better than on Nexus...

 

[greblus]

 

This test was executed with the SIO2BT app on a very old single core LG E400 (Android 2.3) and the results are better than on Nexus...

 

 

I'm afraid that in case of SPP profile it's a matter of BT hardware incompatibility. That's the only logical explanation .

 

W.

[OmaOhneBH]

hey guys

 

I installed AspeQt on my Tablet running Android 4.1.1 JellyBean

 

after starting AspeQt the first time, mounting an ATR does work fine, game will be loaded, no problem

 

then, after that, AspeQt doesn't react properly anymore - hitting buttons, menu and stuff won't work at all, or some times won't work before trying it many times - very annoying

 

 

I don't know, what's the problem - does anyone have an idea?

 

 

 

 

 

[towmater]

Exciting and confusing. Should I remove my "Ape warp" OS chip and install an eprom with the sio delay mod to make this work?

[greblus]

Exciting and confusing. Should I remove my "Ape warp" OS chip and install an eprom with the sio delay mod to make this work?

 

You could try XBIOS4BT loaders from the original release of SIO2BT:

 

http://abbuc.de/~montezuma/SIO2BT.zip

 

And it'll work without hardware mods @19200.

 

But if you want 57600bps support, then U1MB + PBIBIOS is the way to go.

 

W.

[greblus]

hey guys

 

I installed AspeQt on my Tablet running Android 4.1.1 JellyBean

 

after starting AspeQt the first time, mounting an ATR does work fine, game will be loaded, no problem

then, after that, AspeQt doesn't react properly anymore - hitting buttons, menu and stuff won't work at all, or some times won't work before trying it many times - very annoying

I don't know, what's the problem - does anyone have an idea?

 

It's probably a shortcoming of current design of AspeQt - events are processed synchronously and if something stalls, in certain situations UI is also stalled - let's say that there are two main threads (it's a simplification) one is handling the Java side of AspeQt, the other one is responsible for the Qt part. Synchronous calls from Qt side expect that the functions on the Java side will return instantly. If it doesn't happen, the UI thread will not handle the screen and it won't react.

 

I'm thinking about a few possible solutions but currently my free time is too limited to do it. But sooner or later it'll improve

 

W.

[greblus]

Hi guys.

 

It's been a while but finally I've fixed a very old bug in FtdiSerialDriver.java which was preventing PCLINK from working at higher baudrates (via SIO2PC-USB). Surprisingly it's comparable or even slightly faster than RespeQt on my Linux laptop.

 

New version is already in Google Play Store and on Github:

 

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

 

W.

 

 

[Jeffrey Worley]

On 7/14/2015 at 7:29 PM, flashjazzcat said:

Looks great. I often wondered who needed fifteen disks online at the same time.

I use D7 a lot for THE one disk on my system that is always SIO.  I missed the D7 in this particular implementation.  Perhaps, since it is screen real-estate that's at issue, we could allow WHICH of the 15 available drive id's are emulated?  Have touching the disk # bring up a dialog to change what number it is.

[greblus]

Hi.

 

I'll add "custom drive numbers" to my TODO list. I'm afraid it will have to stay limited to 6 disks only, but I'll try to make it a bit more configurable

 

W.

 

 

[Jeffrey Worley]

I'm running aspeQt on my LG Tribute Dynasty phone with a genuine FTDI breakout board.  The board works beautifully at divisor 0 or greater with my PC running AtariSIO, but does not work at all in hardware mode on the Android device.  It DOES communicate in soft mode, but after a few sectors it naks, or stutters and naks, eventually naks within 15 sectors or so.  I get error 140 in Spartados (Framing error).  Is this something to do with my particular phone?  The mini usb to usb A I'm using works peachy with a 16 gig USB flash stick, so I have a working rig.  My FTDI uses CTS for handshaking.  I tried the default with a NON-FTDI chip breakout board.  This board works pretty well on my other rig, but errors if I try to copy really big files from double-density disks, but it uses RI for the handshaking, so I thought I'd try it.  The problem in it's case is the same as the genuine FTDI; hardware handshaking does not work at all, the Android Sees the SIO2PC device, but gets no data from it and the atari just farts when you try.  If I set soft mode, the Atari sees and communicates with the Android-hosted sio stack, but naks after a few sectors, rarely enough sectors come through to get a directory of an ataridos disk.  All the images I've tried so far are single density, or one 16mb double-density sdfs partition.  So this is a coms problem.  I only have, for Android, one other device to try and that is a FireHD8 tablet.  I'll try that next.

 

Any advice would be appreciated.

 

Best,

 

Jeff

[_The Doctor__]

if using RI, is the edge setting correct ? (it must be on for RI) remember also that RI is half the rate of the other control lines so it's response time is slower...