RespeQt r2 released

[phaeron]

I see this in your hardware manual, in Atariki is written, that $23 is for format with DSDD, but probably without high speed skew - it is not clearly written, and that's probably one of reasons why $A1 was not included in SIO2SD. $23 is described as format with high speed skew for Indus GT with Synchromesh enabled.

Is $A1 suitable for all densities or for DSDD only?

 

$A1 will work for any density but only changes interleave for DD formats. SD/ED formats jump around the interleave check and ignore bit 7. After the format completes, the high speed flag (F0) is always cleared, so the result is always sent in low speed. I don't know if any other drives support this behavior but have only heard of it for the XF551.

 

I don't know why Atariki lists $23 as an XF551 command. It isn't in the command table in the XF551 firmware that I disassembled, and this writeup by Jiri Bernasek does not list it either:

http://www.ataripreservation.org/websites/freddy.offenga/megazine/ISSUE5-XF551.html

 

The XF551 doesn't need such a command anyway since it supports the PERCOM block commands.

 

I agree with HiassofT that it would be better not to call the XF551 mode Synchromesh since that term originated with the Indus GT. Synchromesh implies that you can use the normal Indus GT Synchromesh drivers to communicate at high speed, and that definitely won't work with an XF551 or an emulator that doesn't support the initialization commands.

[drac030]

Indus GT and XF-551 use the same turbo protocol, just the speed is different. To my knowledge, there are two instances of Synchromesh for the Indus GT, one slower (38,4 kbit/s), one faster (67 kbits/s). There is also Supersynchromesh for 64k Indus drives, which uses the faster transfers and some kind of sector buffering. Also, there is the CA-2001 drive, which has own instance of the Synchromesh program working at the 38,4 kbits/s. All of this, as said above, use the same protocol, i.e. the command byte is ORed with #$80, sent at 19200, the ACK comes at 19200, then the data blocks (and their ACKs) are transferred at the higher baudrate.

 

Indus GT/LDW 2000 Super: 38,4 kbps or 67 kbps, Synchromesh program necessary

CA-2001: 38,4 kbps, Synchromesh program necessary

XF-551: 38,4 kbps, Synchromesh program not necessary

 

Therefore it was convenient to group all this under the same category, and it was (arbitrarily) called "Synchromesh protocol" just for consistency.

Edited February 7, 2016 by drac030

[Kyle22]

Just remember that the Synchromesh program only sends the proper Z80 code to the drive to program it for high speed operation. INDUS.SYS in SDX is an example of this. It does not change anything on the Atari, or use any RAM. Once the drive is programmed, you can shut off or re-boot the Atari, and there is no need for the Synchromesh program again, as long as the drive remains powered on.

[phaeron]

The protocols look the same, but after spending some time getting the original Indus GT Synchromesh software working in emulation, I'm convinced that they're subtly different and incompatible.

 

The first issue is the $A1 format command. The OSS Disk Initializer, Atari Indus version 2.35 issues this command to Synchromesh-enabled drives expecting the drive to return the sector list at high speed. DOS XE, on the other hand, expects $A1 to return the list at low speed when formatting in XF551 mode. The two DOSes fail to format if the behavior is swapped. SpartaDOS X appears to work in both cases simply by trying the command both ways.

 

The second issue is Synchromesh sector writes. For some reason, the Indus-modified DOS attempts to use synchronous clocking mode to receive the ACK+Complete when writing sectors to a Synchromesh-enabled drive, instead of the asynchronous mode that is usually used. The ROM disassembly floating around on AtariAge reveals that the Synchromesh firmware synchronizes to the clock being output from the Atari when sending bytes at high speed, which allows this to work. The schematics for the XF551 don't even show the clock lines being hooked up to the MCU, so it couldn't support this. Given that this is in emulation I couldn't confidently say that synchronous mode would fail for receiving from the XF551, but we've seen reports of that not working reliably even at standard 19,200 baud speed, much less 38,400.

 

The software on the SuperSynchromesh disk does use asynchronous mode for all reads, but it is of course incompatible with the XF551 purely by baud rate.

 

[dmsc]

Hi!,

 

But getting the timing right on XF551-speed write commands is most certainly where you get the error. Look at this trace (ACK+data part of the write sector 1 command):

dosxe-write-sector.png

The Atari starts transmitting the (38400bps) sector data approx 300µs after the ACK (19200bps). So you have a really small window where you need to switch from 19200bps to 38400bps.

 

Honestly I have no idea how you could get this timing right with a USB-serial adapter...

I agree with you, this would be very difficult to implement in a standard USB-serial adapter. This is a shame, because the good thing about the XF551 high speed mode is that it can be implemented in only 59 bytes, see http://www.ataripreservation.org/websites/freddy.offenga/megazine/ISSUE6-PALXFSIO.html

 

Perhaps it is worth designing a small USB microcontroller device with a simple protocol to convert atari SIO to USB directly, capable of handling all of the timing details. something based on a PIC16F1454 (that needs almost no external components, with crystal-less USB support), or perhaps a tiny AVR using V-USB https://www.obdev.at/products/vusb/index.html

[Joey Z]

Hi!,

 

 

I agree with you, this would be very difficult to implement in a standard USB-serial adapter. This is a shame, because the good thing about the XF551 high speed mode is that it can be implemented in only 59 bytes, see http://www.ataripreservation.org/websites/freddy.offenga/megazine/ISSUE6-PALXFSIO.html

 

Perhaps it is worth designing a small USB microcontroller device with a simple protocol to convert atari SIO to USB directly, capable of handling all of the timing details. something based on a PIC16F1454 (that needs almost no external components, with crystal-less USB support), or perhaps a tiny AVR using V-USB https://www.obdev.at/products/vusb/index.html

That would be the ideal way to go, but I'm more concerned with supporting the stuff everybody already has right now, which is USB serial modules.

 

But yes, that is a reasonable idea, and it's one that I've thought about even.

[morelenmir]

That would be the ideal way to go, but I'm more concerned with supporting the stuff everybody already has right now, which is USB serial modules.

 

But yes, that is a reasonable idea, and it's one that I've thought about even.

 

It would be a really fun project to have a bash at breadboarding out - I think even I might be able to get it working properly!!! Of course the device itself would be useless without support from RespeQT.

[atarixle]

How to build RespeQt staticly on Debian Wheezy

==============================================

I Downloaded qt-everywhere-opensource-src-5.5.1 from here http://www.qt.io/download-open-source/

Built QT5 staticly

as described here http://doc.qt.io/qt-5/linux-deployment.html

and here https://forum.qt.io/topic/57888/solved-qt5-5-static-build-failed-qqmldebugserverthread-run-error-undefined-reference-to-qtcpserverconnection-qtcpserverconnection/4...:

go to the qt-everywhere-opensource-src-5.5.1 directory, create the build-directory (e.g. build), then type

./configure -static -prefix /home/atarixle/Projekte/QT5static/build -release -qt-xcb -nomake examples -nomake tests -skip webkit -skip multimedia -D QT_QML_NO_DEBUGGER

make install

Build RespeQt:

go to the RespeQt R2 directory, then build RespeQt:

use the newly built version of qmake:

/home/atarixle/Projekte/QT5static/build/bin/qmake PREFIX=/home/atarixle/Projekte/QT5static/build

make

there you go ... there should appear the version of RespeQt working on Debian Wheezy without trouble ...

And this is the result of this work: http://atarixle.ddns.net/download/respeqt/RespeQt_R2_QT5static_debian7_x86.tar.gz

Edited February 14, 2016 by atarixle

[atarixle]

it rather should be

./configure -static -prefix /home/atarixle/Projekte/QT5static/build -release -qt-xcb -nomake examples -nomake tests -skip webkit -skip multimedia -D QT_QML_NO_DEBUGGER

make

make install

[atarixle]

Another build:

 

http://atarixle.ddns.net/download/respeqt/RespeQt_R2_QT5static_Ubuntu1404LTS_x86_64.tar.gz

 

for use with Debian x64 / Ubuntu 12.04 LTS / ... not tested yet, because I have non of the targeted operating systems installed.

[atarixle]

giving up ... this was my last Linux build of RespeQT ...

 

RestpeQt always builds against another version of libicu*, so I would have to make builds for each Linux OS piece for piece

 

This effects the dynamic, aswell as the static build of RespeQt.

 

Whatever I do, whatever I try, I cannot make it link against the libicu*.so files ... it ALWAYS links to libicu*.so.48 (debian 7), libicu*.so.52 (Ubuntu 14.04), libicu*.so.55 (debian 8 ), which makes RespeQt unusable on any other Linux system.

 

... I can't solve this problem, so I give up

Edited February 15, 2016 by atarixle

[atarixle]

one more build: http://atarixle.ddns.net/download/respeqt/RespeQt_R2_QT5static_Ubuntu1204LTS_x86_64.tar.gz...built in 12.04 - works in 12.04

[TheMontezuma]

and the Windows build

(more info)

Edited February 24, 2016 by TheMontezuma

[morelenmir]

One problem I am experiencing with RespeQT; if I start the programme while the SIO2PC-USB connector is plugged in, ensure that emulation has begun, mount a disk image and then start the A8 I find that the Atari cannot see the attached device. It makes no difference if I restart RespeQT or remount the *.ATR. The only way around this is to unplug the USB from the SIO2PC-USB and then plug it back in - all while ensuring RespeQT is still running. Then when I mount an image I find the A8 will read it properly.

 

This can get rather tedious as my 130XE sits directly next to my PC and I keep the SIO2PC-USB plugged in at all times. To cycle the USB connection I have to start groping around in the dark behind my desk and it usually takes a few goes to get everything plugged in properly.

 

A totally different question. Is there any possibility that VAPI images will be supported by RespeQT in the future?

[+DrVenkman]

One problem I am experiencing with RespeQT; if I start the programme while the SIO2PC-USB connector is plugged in, ensure that emulation has begun, mount a disk image and then start the A8 I find that the Atari cannot see the attached device. It makes no difference if I restart RespeQT or remount the *.ATR. The only way around this is to unplug the USB from the SIO2PC-USB and then plug it back in - all while ensuring RespeQT is still running. Then when I mount an image I find the A8 will read it properly.

 

 

What OS and what type of SIO2PC-USB device are you using? I have never had this problem with any version of RespeQt (or AspeQt) on my Mac or now my RPi2.

[morelenmir]

 

What OS and what type of SIO2PC-USB device are you using? I have never had this problem with any version of RespeQt (or AspeQt) on my Mac or now my RPi2.

 

I use Windows 7 with the standard FTDI drivers installed. The SIO2PC is one I made from a SparkFun FT232RL breakout board, tying the RX, TX and GND pads to the appropriate pins of an SIO plug and connecting RI for handshaking. This is identical to the one I used:

 

https://www.sparkfun.com/products/12731

[+DrVenkman]

Well I can't help you with the Windows issues unfortunately. Perhaps someone else can chime in and see if they can replicate the problem to help with troubleshooting.

 

 

Sent from my iPhone using Tapatalk

[Joey Z]

One problem I am experiencing with RespeQT; if I start the programme while the SIO2PC-USB connector is plugged in, ensure that emulation has begun, mount a disk image and then start the A8 I find that the Atari cannot see the attached device. It makes no difference if I restart RespeQT or remount the *.ATR. The only way around this is to unplug the USB from the SIO2PC-USB and then plug it back in - all while ensuring RespeQT is still running. Then when I mount an image I find the A8 will read it properly.

 

This can get rather tedious as my 130XE sits directly next to my PC and I keep the SIO2PC-USB plugged in at all times. To cycle the USB connection I have to start groping around in the dark behind my desk and it usually takes a few goes to get everything plugged in properly.

Next time it happens, get putty, and set it up for a serial terminal on the SIO2PC-USB at 19200 baud. Restart the atari, and see if you see anything come over the serial connection. It could be a windows driver issue, and if putty also has a similar issue, I'd bet it is. I'm assuming, of course, that you're not seeing any disk requests that fail in RespeQt

 

A totally different question. Is there any possibility that VAPI images will be supported by RespeQT in the future?

Haven't looked at it, but it's on the todo list.

[morelenmir]

 

Next time it happens, get putty, and set it up for a serial terminal on the SIO2PC-USB at 19200 baud. Restart the atari, and see if you see anything come over the serial connection. It could be a windows driver issue, and if putty also has a similar issue, I'd bet it is. I'm assuming, of course, that you're not seeing any disk requests that fail in RespeQt

 

 

Haven't looked at it, but it's on the todo list.

 

Okay - tested this again today.

 

Initially:

 

The 130XE is on.

The SIO2PC-USB is connected to the PC through USB and the 130XE via daisy chain through a Happy 1050 which is set as D1:.

I start RespeQT, it reports: "Emulation started through standard serial port backend on 'COM4' with RI handshaking".

I power cycle the 130XE and SDX boots from SIDE2.

I mount an image in RespeQT as D1.

I change to D1 in SDX and then type 'DIR'.

Short handshake buzz and then '138 Device does not respond' is displayed.

 

Okay - so at this point RespeQT is in the failure state I mentioned before.

 

Testing:

 

I turn the 130XE off.

I close RespeQT

I open PuTTY and specify a connection on 'Serial' as COM4 at 19200baud.

PuTTY connects to the SIO2PC-USB (presumably) and displays a black screen.

I turn the 130XE on and the SIDE2 boots to SDX.

The PuTTY screen remains totally blank with no text.

 

I guess this denotes a driver problem? It may be relevant that when I click the 'Start Emulation' button it takes an appreciable length of time before RespeQT announces 'Emulation started...'.

[+DrVenkman]

 

Okay - tested this again today.

 

Initially:

 

The 130XE is on.

The SIO2PC-USB is connected to the PC through USB and the 130XE via daisy chain through a Happy 1050 which is set as D1:.

I start RespeQT, it reports: "Emulation started through standard serial port backend on 'COM4' with RI handshaking".

I power cycle the 130XE and SDX boots from SIDE2.

I mount an image in RespeQT as D1.

I change to D1 in SDX and then type 'DIR'.

Short handshake buzz and then '138 Device does not respond' is displayed.

 

Okay - so at this point RespeQT is in the failure state I mentioned before.

 

 

If that's not a typo above, well ... it may not be the complete source of your problem but hat Happy 1050 is going to try to respond and so, too, will RespeQt. It's going to cause some kind of serial bus contention I would think.

 

Pull that 1050 out of the chain and test again. It might well be that your SIO2USB device doesn't "play well" with real floppy drives on the same SIO chain.

Edited March 6, 2016 by DrVenkman

[morelenmir]

 

 

If that's not a typo above, well ... it may not be the complete source of your problem but hat Happy 1050 is going to try to respond and so, too, will RespeQt. It's going to cause some kind of serial bus contention I would think.

 

Pull that 1050 out of the chain and test again. It might well be that your SIO2USB device doesn't "play well" with real floppy drives on the same SIO chain.

 

Very good point! I will give it a shot. I do not switch the happy on very often, will it conflict even when off?

 

Okay - tested with the SIO2PC-USB connected directly to the 130XE. Identical behaviour as before in regards RespeQT and PuTTY.

[+DrVenkman]

 

Okay - tested with the SIO2PC-USB connected directly to the 130XE. Identical behaviour as before in regards RespeQT and PuTTY.

 

 

Just out of curiosity and to get a few more data points, try mounting a few different random .ATRs, and try a couple different slots in RespeQt. It might help if we can determine if it's some combo if .ATR type/size/format, RespeQt behavior, Windows driver behavior, etc.

[morelenmir]

 

 

Just out of curiosity and to get a few more data points, try mounting a few different random .ATRs, and try a couple different slots in RespeQt. It might help if we can determine if it's some combo if .ATR type/size/format, RespeQt behavior, Windows driver behavior, etc.

 

Will do!

[Joey Z]

 

Okay - tested this again today.

 

Initially:

 

The 130XE is on.

The SIO2PC-USB is connected to the PC through USB and the 130XE via daisy chain through a Happy 1050 which is set as D1:.

I start RespeQT, it reports: "Emulation started through standard serial port backend on 'COM4' with RI handshaking".

I power cycle the 130XE and SDX boots from SIDE2.

I mount an image in RespeQT as D1.

I change to D1 in SDX and then type 'DIR'.

Short handshake buzz and then '138 Device does not respond' is displayed.

 

Okay - so at this point RespeQT is in the failure state I mentioned before.

 

Testing:

 

I turn the 130XE off.

I close RespeQT

I open PuTTY and specify a connection on 'Serial' as COM4 at 19200baud.

PuTTY connects to the SIO2PC-USB (presumably) and displays a black screen.

I turn the 130XE on and the SIDE2 boots to SDX.

The PuTTY screen remains totally blank with no text.

 

I guess this denotes a driver problem? It may be relevant that when I click the 'Start Emulation' button it takes an appreciable length of time before RespeQT announces 'Emulation started...'.

Yes, lack of anything in Putty sounds like a driver issue. If RespeQt doesn't see the commands, it can't do anything. If it were working, you would see some data appear in Putty probably.

 

What SIO2PC-USB do you have? I think the Atari8Warez ones require DTR to be high to work, or something. Putty might not do that, so go ahead and try Putty again once you have things in a working state. You should now see some stuff that looks a bit like garbage appearing in the Putty window when you cold start the Atari.

 

EDIT: no, I think I was thinking of Atarimax SIO2PC serial versions with the DTR thing, but go ahead and try putty again when it's working anyway.

Edited March 6, 2016 by Joey Z

[morelenmir]

Yes, lack of anything in Putty sounds like a driver issue. If RespeQt doesn't see the commands, it can't do anything. If it were working, you would see some data appear in Putty probably.

 

What SIO2PC-USB do you have? I think the Atari8Warez ones require DTR to be high to work, or something. Putty might not do that, so go ahead and try Putty again once you have things in a working state. You should now see some stuff that looks a bit like garbage appearing in the Putty window when you cold start the Atari.

 

EDIT: no, I think I was thinking of Atarimax SIO2PC serial versions with the DTR thing, but go ahead and try putty again when it's working anyway.

 

Yep - as you predicted Joey Z if I go through the unplug/replug business with the USB cable and get it working I do indeed see a string of characters appear in the PuTTY console. So... It looks like for some reason - maybe its some kind of time-out deal - the PC looses proper connection to the SIO2PC-USB and while still recognizing it as a device needs to re-identify it in Device Manager again before it can properly communicate with it.

 

I wonder if it is because of the DIY nature of my unit? It would be interesting to see if it happens with a more commercial device like the one Lotharek sells.