SIO2Bluetooth possible?

[Awch]

I'm not the sharpest stick in the pile but I'm wondering if it might be possible to use this module to create a battery powered SIO2Bluetooth adapter:

http://www.adafruit.com/products/1588

 

I think it would work like a serial SIO2PC module if I'm understanding this properly. A wireless connection to AspeQT would be awesome if this is possible!

 

Does anyone who actually knows this stuff (unlike me) think it could work?

 

Thanks for your help,

Greg

[Rybags]

Cool... I assume this hooks up at the client end though and not to the serial port of the PC ?

 

My thinking is that you just build it inside the Atari then run some Android software and use a phone as the drive emulation host.

If that could be done then you'd have the most versatile SIO2xx solution and could do so for under 50 bucks total.

[Kyle22]

I think it looks very promising. I'm not sure about the 100ms delay on the CMD line, though.

[Rybags]

Where's that mentioned? The required tolerances for standard SIO protocol are listed in the OS manual.

Lag is often the enemy with the wireless devices on PC regardless of capable transmission rate, so yes there could be potential for problems.

[Kyle22]

Here: http://learn.adafruit.com/introducing-bluefruit-ez-link/pinout

 

Section 2 DSR:

 

DSR - this is the "Data Signal Ready" hardware flow control pin that is transmitted from the Microcontroller, through the EZ-Link to the paired computer. If you want to send a signal outside of the UART back to the computer, this pin can do it. The computer can then read the terminal-status lines. This isn't a high-speed line, expect up to 100ms delay from when the pin toggles to when the signal is read on the computer. If not used, tie to ground.
On FTDI cables this is often labeled CTS, for a different signal line. Bluetooth does not have support for sending this signal back to the computer so we substituted DSR instead.

[Subby]

This would be kinda cool!

It would be excellent to replace my Dell laptop with a jailbroken iPhone1.

[eeun]

Cool indeed! You'd still need a host with bluetooth capability since most desktop PCs don't have it stock, but USB bluetooth adapters are dirt cheap on ebay.

 

Or...we need an equivalent to Ape/Aspeqt for android/ios devices that have BT built in.

[Awch]

I'll be ordering one with a battery and charging adapter once they're back in stock. Hopefully I'll get some time early in the year to assemble and test. I'll report back if I have any success.

[atari8warez]

I'm not the sharpest stick in the pile but I'm wondering if it might be possible to use this module to create a battery powered SIO2Bluetooth adapter:

http://www.adafruit.com/products/1588

 

I think it would work like a serial SIO2PC module if I'm understanding this properly. A wireless connection to AspeQT would be awesome if this is possible!

 

Does anyone who actually knows this stuff (unlike me) think it could work?

 

Thanks for your help,

Greg

 

These guys indeed seem to have addressed the main issues with the majority, if not all BT devices that I've seen so far. I actually built and tested a prototype SIO2PC device using the Texas Instruments BT module and read about others in the not so distant past and had issues with flow control and baud rates (I will spare you from the details of the problems as they are already mentioned in the BlueFruit introduction video at the Adafruit website)

 

This BlueFruit device apparently addresses those issues with a customized SPP stack, which is excellent and nullifies the need for an intermediary micro processor between the Atari and the BT module. The 100ms delay however can be a problem as others already mentioned. I am not sure if I am comparing apples to oranges here, but taking the FTDI chip based SIO2PC devices (like my own SIO2PC/10502PC Dual-USB) as an example, the maximum latency that can be set on the FTDI device when used between an Atari 8 bit and AspeQt is 16ms, anything over that is asking for trouble.

 

Now that latency relates to reading the bytes from the FIFO buffer and not to the transmission of the flow control signal, so I am not sure what kind of effect this 100ms delay in the DSR line will cause. The Atari OS manual has bus timings from the computer's perspective but no info about the peripherals (or did I miss it?)

 

One other issue with this (and all other BT devices for that matter) is that the blue tooth radio needs to be already powered, initialized and paired to the host before it can start any transmission, this means the device can not be just inserted into a powered down Atari's SIO port and expect to work as soon as the Atari is powered up (assuming the Atari will be the power source for the device). This can be however alleviated either by turning the Atari ON before inserting the device into the SIO port, then wait till the device initialized and paired with the host and then cold start the Atari without actually turning it OFF, or by the use of an external power source (or a battery). In any case it seems it's worthwhile trying and seeing what kind of performance, if any, we can get from it.

Edited December 26, 2013 by atari8warez

[Kyle22]

To be fair, please note that the official docs say UP TO 100ms delay. Maybe it would be less in certain situations? I think it's worth a try.

[Rybags]

DSR/DTR in the original sense was to let the host know that the peripheral was ready to receive data.

 

Maybe the 100 ms is for initial receipt of this signal? Whatever the case, I agree it's worth someone giving it a shot.

[Awch]

The module is back in stock. I ordered a pair of Bluetooth modules, lithium ion batteries and USB battery charging modules. It would be great to charge the battery off of sio when the atari is running, but it looks like sio doesn't put out enough power. I'll let you know if I make any progress.

[Kyle22]

DTR lets the peripheral (usually modem) know if the host (computer) is ready (Data Terminal Ready), and DSR lets the host know that the peripheral is ready (Data Set Ready).

 

I just don't know how SIO will respond to this delay on the command line.

[Rybags]

It'd be the peripheral or emulated peripheral that has problems with the delay.

 

There's a minimum requirement from when Command goes low until when the device should be ready to receive the command frame.

If serial data is transmitted to an idle device with Command still high, it just gets ignored.

[Kyle22]

If it NAK'd (139) first, it might be ok, or, it may cause some DOS's to flip the PoKey speed divisor, if it goes 138, it MIGHT re-try, or it may abort completely.

 

I will try to figure out the requirements, and hope we can be within (or at least close to) parameters.

 

-K

Edited January 8, 2014 by Kyle22

[Rybags]

There's command retries from the computer but if you have lag with command line switching on/off it could be the case that the data doesn't coincide with the command line being low.

 

Also, in the case where you have these command retries, the overall throughput of SIO could potentially suffer.

 

But it's wait and see I guess - not too much of an investment lost if it doesn't work.

[Kyle22]

Yes, I agree 100% with the above message.

 

If it works at all at 19200 Baud, it would be better than nothing. Hopefully, it could eventually support highspeed, ( but I doubt it).

 

Now, I think I am right, but I HOPE I'm wrong. I was gonna try the math, but.... I hate math, I am not good at it.

 

Is a 100ms (max) delay possible, or would it totally blow up SIO?

 

Hope this makes sense

[Rybags]

I'm fairly certain all command operations are @ 19.2 k, otherwise standard speed peripherals would get confused. It's just the data portion where the speed can vary.

 

Someone like hiass could verify that, he's one of the leading minds re high-speed SIO stuff.

 

My feeling is the actual speeds mightn't be the deal-breaker but lag with command could be.

[HiassofT]

Just a quick summary with the most important things:

 

A 100ms delay will kill you (well, not you, but reliable SIO transmission), T2 is specced at 16ms max (T2 is the time between the trailing edge of /COMMAND and the peripheral / SIO-emulator transmitting the ACK byte).

 

Another thing that can kill SIO is if the /COMMAND line and reception of characters are skewed (this can happen if you have the receive FIFO enabled but not configured properly - like it's the case for standard Linux 16550/16C950 ttySx devices).

 

Highspeed should not be a problem, in the UltraSpeed protocol all bytes (including the command frame) are transmitted at high speed (Warp Speed, XF551 and Turbo transmit the command frame in highspeed), but all delays are the same. Actually, Warp/XF551/Turbo might be more critical since you have to switch speed at the exact point in time.

 

I'd say just give it a try, if the 100ms is an absolute worst case value it could work quite fine. If RxD/TxD are delayed too, there's not much you can do, if just DSR is delayed you might be able to find a workaround (eg don't wait for the trailing edge of /COMMAND but do a delay of a few ms).

 

so long,

 

Hias

[TheMontezuma]

Just a quick summary with the most important things:

 

A 100ms delay will kill you (well, not you, but reliable SIO transmission), T2 is specced at 16ms max (T2 is the time between the trailing edge of /COMMAND and the peripheral / SIO-emulator transmitting the ACK byte).

 

Another thing that can kill SIO is if the /COMMAND line and reception of characters are skewed (this can happen if you have the receive FIFO enabled but not configured properly - like it's the case for standard Linux 16550/16C950 ttySx devices).

 

Highspeed should not be a problem, in the UltraSpeed protocol all bytes (including the command frame) are transmitted at high speed (Warp Speed, XF551 and Turbo transmit the command frame in highspeed), but all delays are the same. Actually, Warp/XF551/Turbo might be more critical since you have to switch speed at the exact point in time.

 

I'd say just give it a try, if the 100ms is an absolute worst case value it could work quite fine. If RxD/TxD are delayed too, there's not much you can do, if just DSR is delayed you might be able to find a workaround (eg don't wait for the trailing edge of /COMMAND but do a delay of a few ms).

 

so long,

 

Hias

 

I can confirm the information from Hias.

 

One year ago at NOMAM Party I have measured the delays with a logic analyser and they were far behind the acceptable values.

I tested a cheap no name BT module and a reliable transmission was not possible.

 

XXL has provided me a software patch (for Atari):

http://www.atari.org.pl/forum/viewtopic.php?pid=169041#p169041

 

And after booting the ATARI from SIO2SD (with mounted atr from XXL), the transmission over BT was successful.

The floppy emulation on the PC was possible with sio2bsd from drac030:

 

http://drac030.krap.pl/en-inne-pliki.php

 

It does not need flow control (which is not available in the BT module).

Edited January 9, 2014 by TheMontezuma

[atari8warez]

Sorry guys I can confirm that this device (Bluefruit EZ-Link) will not work as an SIO2PC. Details coming later...

[atari8warez]

And here are the results of my tests with Adafruit EZ-Link Bluetooth module. I'd say don't waste your time with it for SIO over air unless you want to re-engineer the whole concept of Bluetooth. My conclusion is Bluetooth is for simple, non-time critical serial communications, don't expect decent hardware flow control, if any at all... after all air is no "hardware"....

 

Edited January 10, 2014 by atari8warez

[Dripfree]

I had been wondering if something like this were possible for some time now. Although for now the bluetooth option seems to be a dead end has anyone ever considered a wired connection to phones or ipods? I use my ipod to play .wav files into my 810. It would be really sweet to have a Aspqt ipod app even if I did have too plug in a usb cable. I figure its just a matter of someone with programming knowledge to have proper inspiration and motivation to code the software. This is an idea thats far beyond my expertise, but If someone with proper knowledge was looking for a hobby project I think that app would be a very useful little tool for the Atari community. Just thought Id float that idea out there and see what people think.

[gozar]

I had been wondering if something like this were possible for some time now. Although for now the bluetooth option seems to be a dead end has anyone ever considered a wired connection to phones or ipods? I use my ipod to play .wav files into my 810. It would be really sweet to have a Aspqt ipod app even if I did have too plug in a usb cable. I figure its just a matter of someone with programming knowledge to have proper inspiration and motivation to code the software. This is an idea thats far beyond my expertise, but If someone with proper knowledge was looking for a hobby project I think that app would be a very useful little tool for the Atari community. Just thought Id float that idea out there and see what people think.

 

That's an interesting idea. At the very least, using an mp3 player would be a very cheap way to add read-only storage. You'd be limited to what you could do with it though. I use my iPod with my CuttleCart on my 2600.

[Kyle22]

How could you play .wav files into your 810 disk drive? There are adapters that allow non-Atari cassette drives to be used. I can see you playing a wav file through that and doing LOAD"C:, or booting with START.