Jump to content

Photo

SIO2BT


236 replies to this topic

#26 ryanmercer OFFLINE  

ryanmercer

    Moonsweeper

  • 420 posts
  • Location:Speedway, IN

Posted Wed Aug 20, 2014 4:45 AM

I don't see, that iOS devices don't want me.

 

If you try and get an app approved that allows the use of ROMS they are NOT going to approve it, if they accidentally do it will quickly be pulled from the store (if an app offends them enough they can actually reach out to devices and remove the app but so far that's been rare).



#27 JoSch OFFLINE  

JoSch

    Moonsweeper

  • 424 posts
  • Location:Germany

Posted Wed Aug 20, 2014 6:21 AM

 

If you try and get an app approved that allows the use of ROMS they are NOT going to approve it, if they accidentally do it will quickly be pulled from the store (if an app offends them enough they can actually reach out to devices and remove the app but so far that's been rare).

Which ROMs? Didn't know ROM could be loaded via SIO.



#28 ryanmercer OFFLINE  

ryanmercer

    Moonsweeper

  • 420 posts
  • Location:Speedway, IN

Posted Wed Aug 20, 2014 6:26 AM

Which ROMs? Didn't know ROM could be loaded via SIO.

 

 

Ok if you want to be like that...

 

If you have an app that lets you load potentially pirated intellecual property into the app or via the app, Apple will NOT approve it... be it a song, video, ROM, ATR, ISO, etc etc so on and so forth.



#29 JoSch OFFLINE  

JoSch

    Moonsweeper

  • 424 posts
  • Location:Germany

Posted Wed Aug 20, 2014 6:38 AM

Well, sure. They don't approve computer emulator, because essentially will use some copied software (apart from the discussion whether it's a copyright violation, if you copy the stuff you own)

But an disk emulator, where is the harm? I would argue, that standard use will be data disks, e.g. for Atari Writer, not copied software.

 

But the whole discussion is moot, because the necessary BT protocol doesn't seem to be supported at the moment.



#30 ryanmercer OFFLINE  

ryanmercer

    Moonsweeper

  • 420 posts
  • Location:Speedway, IN

Posted Wed Aug 20, 2014 6:50 AM

Oh they'd approve an emulator in a heartbeat. They will NOT approve an emulator that gives you a method of loading disk images to the phone if there is even the slightest hint that it could load stolen intellectual property.

 

It's also not moot, we are only a few weeks away from the next genereation of iPhone(s) announcement which we may find out it will be compatible with OP's current hardware choices.



#31 JoSch OFFLINE  

JoSch

    Moonsweeper

  • 424 posts
  • Location:Germany

Posted Wed Aug 20, 2014 7:42 AM

Oh they'd approve an emulator in a heartbeat. They will NOT approve an emulator that gives you a method of loading disk images to the phone if there is even the slightest hint that it could load stolen intellectual property.

 

It's also not moot, we are only a few weeks away from the next genereation of iPhone(s) announcement which we may find out it will be compatible with OP's current hardware choices.

It's not an platform emulator, so it's whole other game. Moreover, the ATARI software would NOT run ON the phone.

And yes, the discussion is still moot, because it's not hardware issue, it's an software issue.

If Apple hasn't announced SPP until now, it will not come with iOS 8.


Edited by JoSch, Wed Aug 20, 2014 7:43 AM.


#32 Jinks OFFLINE  

Jinks

    River Patroller

  • 3,773 posts
  • Location:Canada

Posted Sun Aug 24, 2014 9:53 AM

Interested. Please pm me when its done with payment info if you make them for sale. Thanks.

#33 DrVenkman ONLINE  

DrVenkman

    River Patroller

  • 2,333 posts
  • Back off, man! I'm a scientist.
  • Location:KMBT

Posted Mon Aug 25, 2014 7:50 AM

This is silly. Apple does (and has, many times) approved iOS apps that allow loading all manner of things into and through the phone - .PDF and reader apps for text document, video and audio file viewing and listening apps, stringed instrument tablature apps. All of these and others provide easy means to load files that may potentially be stolen IP - ripped videos and musics files, photocopied documents and sheet music, et cetera. They also have approved many old calculator emulator programs that allow loading of calculator ROM files into the emulators so they operate just like the originals but with enhancements like touch control and alternate screen layouts.  I use a great one called "m48+".

 

So this whole discussion is just FUD.

 

So long as the description and documentation don't go out of the way to point out ways you can use it to steal someone else's work, they would have no reason not to approve it. 



#34 ryanmercer OFFLINE  

ryanmercer

    Moonsweeper

  • 420 posts
  • Location:Speedway, IN

Posted Mon Aug 25, 2014 8:02 AM

I disagree, while the app wouldn't be an emulator for the iOS device itself, it would allow for emulation of files (commercial games and other software) on an Atari system via the device.

 

We've seen emulators sneak into the app store before and as soon as Apple catches on they get removed. Likely the app would need to be sideloaded or used via jailbroken devices by being added via cydia or similar means and as of now, there are ZERO known exploits for iOS 8 that would allow for jailbreaking (per the jailbreaking community). So, I wouldn't call it FUD I'd call it a reasonable assumption based on facts in evidence.



#35 DrVenkman ONLINE  

DrVenkman

    River Patroller

  • 2,333 posts
  • Back off, man! I'm a scientist.
  • Location:KMBT

Posted Mon Aug 25, 2014 8:41 AM

I disagree, while the app wouldn't be an emulator for the iOS device itself, it would allow for emulation of files (commercial games and other software) on an Atari system via the device.

 

 

You're painting with far too-broad a brush. "Emulation of files" doesn't even make sense as a term of art. .PDFs are "emulation of files" for text or images, just as AAC and MP3 files are for audio. That's not the basis for denial of an app. ANY app could be used to load pirated content (whether that be text, audio, video, still images, whatever). If the app has primarily non-infringing uses (and it should very well have) it should (and probably would) be approved. Otherwise every single Dropbox/Box/MS Live/Bitcasa/Google Drive/whatever-enabled app would be denied.

 

Again if the app isn't advertised and played up for its ability to facilitate IP theft, there's no reason that it should be denied. 



#36 JoSch OFFLINE  

JoSch

    Moonsweeper

  • 424 posts
  • Location:Germany

Posted Mon Aug 25, 2014 10:18 AM

 

You're painting with far too-broad a brush. "Emulation of files" doesn't even make sense as a term of art. .PDFs are "emulation of files" for text or images, just as AAC and MP3 files are for audio. That's not the basis for denial of an app. ANY app could be used to load pirated content (whether that be text, audio, video, still images, whatever). If the app has primarily non-infringing uses (and it should very well have) it should (and probably would) be approved. Otherwise every single Dropbox/Box/MS Live/Bitcasa/Google Drive/whatever-enabled app would be denied.

 

Again if the app isn't advertised and played up for its ability to facilitate IP theft, there's no reason that it should be denied. 

Also, the correct reason for rejection of emulator is not so much the execution of pirated software, but the execution of code. That would certainly not case here.



#37 TheMontezuma OFFLINE  

TheMontezuma

    Dragonstomper

  • Topic Starter
  • 539 posts
  • Location:Hildesheim, D / Kraków, PL

Posted Tue Sep 2, 2014 9:55 AM

Hi,

below you will find the description, that will be published in the next ABBUC Magazin.

The complete manual (18 pages), the software and the hardware will be available after ABBUC JHV event (25.10.2014).

 

SIO2BT project is a set of hardware and software solutions related to the wireless Bluetooth communication between the 8-bit Atari computers and Bluetooth (BT) enabled Serial Input Output (SIO) devices.

 

20140527311.jpg

 

Due to delay in the Bluetooth data transmission it was necessary to modify the original Atari OS. For that reason the timeout values (which could not be met) were increased.

A tool for patching Atari OS rom files for Atari 800 and for Atari XL/XE is provided as a part of the project.
Thanks to Stefan Dorndorf it is possible to patch QMEG 4.04 for Bluetooth as well.
Additionally there are disk images (*.atr) available for Atari XL/XE for those who want to use SIO2BT with original, not modified Atari computers.

Another difficulty was missing information about the SIO Command Line status. Hardware handshaking had to be replaced with a software solution for Command Frame detection.
Most of the Bluetooth transceivers available on the market are based on the CSR BC417143 chipset supporting SPP (Bluetooth Serial Port Profile). Two Bluetooth transceivers plugged between any two legacy serial devices would (in theory) be transparent and would appear as if they were connected via cable. In practice missing hardware handshaking and non-deterministic delays cause problems if the protocols rely on timing or on handshaking. And this is exactly the case with the SIO Protocol.

 

diagram.jpg

 

The BT transceivers provide RxD and TxD lines (TTL voltage level), which can be connected directly to the DATA OUT and DATA IN lines of the Atari SIO port.
Once configured for the SIO Communication (Baudrate = 19200, etc.), a Bluetooth transceiver can be paired with a PC. When a device is paired, the Bluetooth Software Stack on the PC creates a virtual serial port for it. Opening such ports establishes a Bluetooth connection between the PC and the transceiver. A PC can run the software emulating SIO devices.

I have adapted one of the most popular tools for emulating SIO devices – AspeQt 0.8.8 – for communication via Bluetooth. The tool is licensed under GNU General Public License version 2.0 (GPLv2) and my source code modifications are available freely to everyone.
The modifications include:
- a bug fix for Windows to support COM port numbers higher than 9
- a removal of a background image in the logger window, which consumes a lot of the CPU power (especially visible with weak machines like Raspberry Pi)
- software command frame detection (SOFTWARE handshaking)
- configurable delay for writing data to the Atari

The additional delay for writing is required for Bluetooth, because an Atari expects (according to the SIO specification) a minimum time delay between the “Acknowledge” Byte and the “Complete” Byte.
This timing is critical and unfortunately can not be guaranteed by Bluetooth. If we send two bytes waiting X milliseconds in between, the first byte can get stuck somewhere in the Bluetooth stack and the second byte will catch it up so they will arrive one after each other at the Atari. The Atari could skip the second byte and keep waiting for it. Luckily (after a certain timeout) the last Command Frame would be repeated and the communication would continue.

Using a Logic Analyzer and „trial and error“ approach I had to face the fact that there is no 100% guarantee for fast and error free communication. I can recommend a delay value of 10 milliseconds (default setting) for the most cases and bigger values for machines with slower Bluetooth stacks.

The SOFTWARE handshaking can also be used (even without any delay) with cheap USB2Serial cables (TTL) that do not support hardware handshaking.

There is one drawback of the SOFTWARE handshaking that should be understood by the users. The emulated SIO device is analyzing data coming from the Atari to detect an incoming Command Frame. We are on the safe side if our device is the only SIO device on the bus. However if the Atari writes data to a different physical SIO devices on the bus, the data (for example a disk sector) can include bytes that build a valid Command Frame. In such cases our device would incorrectly react upon it.

My recommendation is NOT TO USE other physical SIO devices when working with SOFTWARE handshaking, or to use them only to provide data to Atari.

As a part of the project I have provided a binary version of the AspeQt for Windows users and the source code for Linux users (tested successfully under Windows XP, Windows 7 and Ubuntu).

As long as the SIO devices are emulated on a PC, there is no real advantage of wireless communication.
However if SIO devices are emulated on a smartphone, we do not need a PC at all. Many people carry smartphones with them. Games can be downloaded from the internet and immediately loaded to the Atari from an emulated Disk Drive. One day we could even go one step further and introduce a new SIO Device – an intelligent network device with a TCP/IP stack...
I decided to support the Android platform (the iOS does not support Bluetooth SPP).
The SIO2BT App can be downloaded from the Google Play Store to any smartphone with Android 2.2 or higher.

 

2014_07_02_19_07_36.jpg


Edited by TheMontezuma, Tue Sep 2, 2014 10:01 AM.


#38 w1k OFFLINE  

w1k

    Stargunner

  • 1,650 posts
  • Location:martin, slovakia

Posted Tue Sep 2, 2014 12:58 PM

https://play.google....search?q=SIO2BT

 

no results



#39 TheMontezuma OFFLINE  

TheMontezuma

    Dragonstomper

  • Topic Starter
  • 539 posts
  • Location:Hildesheim, D / Kraków, PL

Posted Tue Sep 2, 2014 1:34 PM

 

Sure. The software will be available to everybody for download on 25.10.2014 (ABBUC JHV).

It is now available at google play only for the registered testers.



#40 atari8warez OFFLINE  

atari8warez

    River Patroller

  • 2,724 posts
  • Location:Canada

Posted Tue Sep 2, 2014 4:14 PM

 

There is one drawback of the SOFTWARE handshaking that should be understood by the users. The emulated SIO device is analyzing data coming from the Atari to detect an incoming Command Frame. We are on the safe side if our device is the only SIO device on the bus. However if the Atari writes data to a different physical SIO devices on the bus, the data (for example a disk sector) can include bytes that build a valid Command Frame. In such cases our device would incorrectly react upon it.

My recommendation is NOT TO USE other physical SIO devices when working with SOFTWARE handshaking, or to use them only to provide data to Atari.

 

 

I guess this is basically the same as the handshake: NONE setting in the current AspeQt version. Instead of checking for the handshake signal, it's looking for a command frame. The same caveat applies as far as multiple devices are concerned.


Edited by atari8warez, Tue Sep 2, 2014 4:15 PM.


#41 TheMontezuma OFFLINE  

TheMontezuma

    Dragonstomper

  • Topic Starter
  • 539 posts
  • Location:Hildesheim, D / Kraków, PL

Posted Tue Sep 2, 2014 10:48 PM

 

I guess this is basically the same as the handshake: NONE setting in the current AspeQt version. Instead of checking for the handshake signal, it's looking for a command frame. The same caveat applies as far as multiple devices are concerned.

 

Not really. I looked at your current code. You are just waiting (Windows code) for any received byte in the input buffer to start command frame processing.

This works only if this byte is the first byte of the command frame. If not - everything goes wrong...



#42 atari8warez OFFLINE  

atari8warez

    River Patroller

  • 2,724 posts
  • Location:Canada

Posted Tue Sep 2, 2014 11:33 PM

What else but the first byte of a command frame will start an I/O transaction on the SIO bus? and then once the transaction is started everything else follows a strict protocol until the transaction is completed. (i.e. Command Frame, Ack or NAK, Data Frame, OP Complete). If there is a BT transmission problem (i.e. missing byte or a wrong bit etc..) the command checksum will fail anyway and the command will be NAKed ending the current transaction. .

 

 I guess you haven't watched my demo video when I posted here at AA. If you watch through the end you will see that AspeQt is running without handshake (that same code you observed in the source). I've tested this many times over and haven't seen any problems happening, unless there is something that I am missing. As I mentioned before, the only reason I dropped this project was the limitation on the SIO speed (19,200bps). The BT module can be dynamically programmed to run at higher speeds but you would need a intermediary microprocessor and a firmware that will coordinate the baud rate between the Atari,  the BT module and AspeQt.

 

 


Edited by atari8warez, Tue Sep 2, 2014 11:59 PM.


#43 TheMontezuma OFFLINE  

TheMontezuma

    Dragonstomper

  • Topic Starter
  • 539 posts
  • Location:Hildesheim, D / Kraków, PL

Posted Wed Sep 3, 2014 4:25 AM

Hi atari8warez,

I watched your video on AA.

And I made first tries tries before you started working on that.

It was in April 2013. I used sio2bsd linux command line tool from drac030 and realized that the original OS timing does not allow for error free SIO communication via BT.

XXL has send me his xbios loader (with modified timings) and this combination worked fine.

In the meantime I was involved in other projects (Megacart 4MB) and didn't have time for Bluetooth.

One year later I decided to continue.

Regarding your solution - it was exactly my first try with AspeQt - I used the same approach, since it is pretty straightforward.

But - have you ever tried to press the "break" key while the system was loading data? You would realize that with this approach, the communication would never recover...

When powering on the ATARI, my Logic Analyzer was detecting a byte $FF on "DATA IN", before "GetStatus" command frame. This breaks that simple logic, too.

When ATARI gets stuck, because the COMPLETE byte arrives without any delay after ACK byte, the simple logic fails as well...

It is just a matter of robustness.

Until 25.10.2014 I can't explain technical details, but I will do it after ABBUC JHV.

Regards

Montezuma



#44 w1k OFFLINE  

w1k

    Stargunner

  • 1,650 posts
  • Location:martin, slovakia

Posted Wed Sep 3, 2014 7:21 AM

ah.. only for abbuc users? 5% of all atarians? only deutch? lol



#45 flashjazzcat OFFLINE  

flashjazzcat

    Quadrunner

  • 12,638 posts
  • Location:United Kingdom

Posted Wed Sep 3, 2014 7:25 AM

Well - somewhat better than an abandoned project which will reach 0% of Atarians. :)



#46 TheMontezuma OFFLINE  

TheMontezuma

    Dragonstomper

  • Topic Starter
  • 539 posts
  • Location:Hildesheim, D / Kraków, PL

Posted Wed Sep 3, 2014 8:32 AM

ah.. only for abbuc users? 5% of all atarians? only deutch? lol

 

Hi,

You didn't get it right.The project description and the manual is in english (well, I tried my best ;)).

That's the ABBUC members, that have a reason to complain - no german description is available.

The software is internationalized (polish, english, german).

According to the ABBUC Hardware Contest rules (until JHV event) - the projects must not be offered (for sale) and the technical details must not be published.

That's the reason that the SIO2BT App is only available for download to testers at the moment.

Technically speaking it is in a "testing phase" at google play, so that's why you can not find it.

On 25.10.2014 I will offcially publish the App, so you will be able to find it and to install it.

The hardware will be offered to the ABBUC members in the first step (a good reason to become an ABBUC member ;-)).

Best Regards

Montezuma



#47 atari8warez OFFLINE  

atari8warez

    River Patroller

  • 2,724 posts
  • Location:Canada

Posted Wed Sep 3, 2014 5:40 PM

 

It was in April 2013. I used sio2bsd linux command line tool from drac030 and realized that the original OS timing does not allow for error free SIO communication via BT.

 

 

Hi Montezuma
That's right the timing was a problem, I was using Hias's high-speed OS patch for my test and asked him how I can change the SIO timing, he suggested pokeing a certain value to a certain memory location (as seen in the video). That poke makes SIO work over BT at 19,000 bps. :)

 

 

But - have you ever tried to press the "break" key while the system was loading data? You would realize that with this approach, the communication would never recover...

 

 

Nope, I never used the break key, never thought of that to be honest  :D

 

 

Until 25.10.2014 I can't explain technical details, but I will do it after ABBUC JHV.

Regards

Montezuma

 

Great, will be very curious to see the tech details, wish you good luck on the contest by the way, it will be a great tool for people who need the mobility this project will  provide  :thumbsup:


Edited by atari8warez, Wed Sep 3, 2014 5:41 PM.


#48 TheMontezuma OFFLINE  

TheMontezuma

    Dragonstomper

  • Topic Starter
  • 539 posts
  • Location:Hildesheim, D / Kraków, PL

Posted Sun Oct 26, 2014 2:54 PM

Hi,

so now the official contest results are published:

http://www.abbuc.de/...ardware-ressort

Here are the docs and software:

https://drive.google...blpUTFBsRW1iRUE

And the Android App:

https://play.google....ontezuma.sio2bt

I have a few BT Transceiver to offer (without a SIO Plug) for 25$ + shipping costs.

Please send ma a PM if you are interested.

Regards

Montezuma



#49 Sowden OFFLINE  

Sowden

    Star Raider

  • 90 posts

Posted Mon Oct 27, 2014 1:38 PM

After reading the manual, let me see if I can get this strait.  I have to flash the current ROM on my Atari if I want the bluetooth to communacate properly?  My 800XL that I own has pre-installed switches in the back that switches between four different Atari ROMs.  I use Omnimon the most because it loads all of my games becasue I think my disks are specially formatted for it.  The other three ROMs load errors.  So are you saying that I can take one of those ROMs I'm not using, flash it to work with the SIO2BT, and still have my Omnimon to load my physical disks?  Or would it not be harmful to flash my Omnimon ROM itself?  Thanks.



#50 TheMontezuma OFFLINE  

TheMontezuma

    Dragonstomper

  • Topic Starter
  • 539 posts
  • Location:Hildesheim, D / Kraków, PL

Posted Mon Oct 27, 2014 1:55 PM

After reading the manual, let me see if I can get this strait.  I have to flash the current ROM on my Atari if I want the bluetooth to communacate properly?  My 800XL that I own has pre-installed switches in the back that switches between four different Atari ROMs.  I use Omnimon the most because it loads all of my games becasue I think my disks are specially formatted for it.  The other three ROMs load errors.  So are you saying that I can take one of those ROMs I'm not using, flash it to work with the SIO2BT, and still have my Omnimon to load my physical disks?  Or would it not be harmful to flash my Omnimon ROM itself?  Thanks.

 

Hi,

The SIO2BT Patcher tool can patch only the original ATARI ROM files (and QMEG 4.04) for Bluetooth usage (I have not provided support for Omnimon to make it compatible with Bluetooth).

But yes, if your OS Switch supports 3 more OS Versions, you could use one of the free slots for a BT-compatible OS.

I think that your OS switch uses the EEPROM memory (and not the FLASH memory), so you would need an EEPROM burner for it.

Regards

Marcin






0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users