TheMontezuma Posted January 30, 2016 Share Posted January 30, 2016 exactly 1 Quote Link to comment Share on other sites More sharing options...
TheMontezuma Posted January 31, 2016 Share Posted January 31, 2016 XF551 $A1 (format with high speed skew) isn't a high speed command. It's a special case that still uses 19200 baud. If accurate sector timing isn't being tracked in the image, this can just be mapped to $21. XF551 always uses 19200 baud for command frames. Only data frames are transferred at 38400 (if negotiated). To find out if a floppy supports "Synchromesh", Atari DOS (for example DOS XE) sets the 7-th bit of the SIO commands (for example $21 -> $A1). If a floppy answers with NACK, it does not support 38400. https://translate.googleusercontent.com/translate_c?act=url&depth=1&hl=de&ie=UTF8&prev=_t&rurl=translate.google.de&sl=pl&tl=en&u=http://atariki.krap.pl/index.php/Synchromesh&usg=ALkJrhin_7Lhd3AbX2WWvp-ziBgg4P1ggA Quote Link to comment Share on other sites More sharing options...
morelenmir Posted January 31, 2016 Share Posted January 31, 2016 XF551 always uses 19200 baud for command frames. Only data frames are transferred at 38400 (if negotiated). To find out if a floppy supports "Synchromesh", Atari DOS (for example DOS XE) sets the 7-th bit of the SIO commands (for example $21 -> $A1). If a floppy answers with NACK, it does not support 38400. https://translate.googleusercontent.com/translate_c?act=url&depth=1&hl=de&ie=UTF8&prev=_t&rurl=translate.google.de&sl=pl&tl=en&u=http://atariki.krap.pl/index.php/Synchromesh&usg=ALkJrhin_7Lhd3AbX2WWvp-ziBgg4P1ggA That negotiation must be what is tripping up DOS XE in practice then, because on the message screen in RespeQT I always see three groups of 'NAK' responses when I try to format a 'XF551' style disk. Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted January 31, 2016 Share Posted January 31, 2016 I thought it was because the $A1 command wasn't recognised? Quote Link to comment Share on other sites More sharing options...
morelenmir Posted January 31, 2016 Share Posted January 31, 2016 I thought it was because the $A1 command wasn't recognised? Could the NAK's be generated by not recognizing the $A1 command? [Disk 2] Get PERCOM block (QD Diskette (360k))." [x3] [Disk 2] command: $a1, aux: $0005 NAKed." [x4] Serial port speed set to 57600." Serial port speed set to 19200." [Disk 2] command: $a1, aux: $0005 NAKed." [x3] Serial port speed set to 57600." Serial port speed set to 19200." [Disk 2] command: $a1, aux: $0005 NAKed." [x3] Serial port speed set to 57600." Serial port speed set to 19200." [Disk 2] command: $a1, aux: $0005 NAKed." [x3] Looking at that little lot I guess so! The $A1 is sent out by DOS XE from the atari, received by RespeQT but not recognized and it returns a NAK. Quote Link to comment Share on other sites More sharing options...
TheMontezuma Posted January 31, 2016 Share Posted January 31, 2016 (edited) As mentioned above, $A1 is a format command ($21) with the 7-th bit beeing set. Because you tell DOS XE explitely that you use XF551, DOS XE knows, that the drive should understand "Synchromesh" and sends modified SIO commands. Other drives (and RespeQt) answer these modified SIO commands with NACK, so DOS XE reports an error. XF551 acknowledges such commands (with 19200) and than switches to 38400 and proceeds with data transfer at this rate. At the end it switches back to 19200 (to process the following command frames). Edited January 31, 2016 by TheMontezuma Quote Link to comment Share on other sites More sharing options...
TheMontezuma Posted February 1, 2016 Share Posted February 1, 2016 I just read about "Synchromesh" something different here: http://atariage.com/forums/topic/223248-sio-command-list-of-atari-floppy-extensions/?do=findComment&comment=2952797 It looks like that the Hi-Speed (38400) is used only for data transfer. Acknowledge / Complete / Error bytes and command frames are sent on low speed. 1 Quote Link to comment Share on other sites More sharing options...
TheMontezuma Posted February 1, 2016 Share Posted February 1, 2016 (edited) I tried to implement locally a simulation of the "Synchromesh", but I failed. The Logic Analyzer was showing a corrupted ACK byte after a command frame with the 7-th bit set to ON in the command byte (RespeQt sends out the ACK byte at 19200 and then switches to 38400 before proceeding with the command execution). Perhaps re-configuring the serial port in the setSpeed() influences data in the output buffer. I don't know. Maybe HIAS has a hint? Edited February 1, 2016 by TheMontezuma 1 Quote Link to comment Share on other sites More sharing options...
HiassofT Posted February 2, 2016 Share Posted February 2, 2016 I tried to implement locally a simulation of the "Synchromesh", but I failed. The Logic Analyzer was showing a corrupted ACK byte after a command frame with the 7-th bit set to ON in the command byte (RespeQt sends out the ACK byte at 19200 and then switches to 38400 before proceeding with the command execution). Perhaps re-configuring the serial port in the setSpeed() influences data in the output buffer. I don't know. Maybe HIAS has a hint? Try doing a tcdrain() followed by a 500µs-1ms delay after sending the ACK and before switching speed. Don't do a tcflush(), that might discard the ACK. tcdrain seems to be working strangely with USB devices, read more about it here and in the few postings after that. so long, Hias 2 Quote Link to comment Share on other sites More sharing options...
morelenmir Posted February 2, 2016 Share Posted February 2, 2016 I tried to implement locally a simulation of the "Synchromesh", but I failed. The Logic Analyzer was showing a corrupted ACK byte after a command frame with the 7-th bit set to ON in the command byte (RespeQt sends out the ACK byte at 19200 and then switches to 38400 before proceeding with the command execution). Perhaps re-configuring the serial port in the setSpeed() influences data in the output buffer. I don't know. Maybe HIAS has a hint? and Try doing a tcdrain() followed by a 500µs-1ms delay after sending the ACK and before switching speed. Don't do a tcflush(), that might discard the ACK. tcdrain seems to be working strangely with USB devices, read more about it here and in the few postings after that. so long, Hias Even though I am not currently at a place mentally where I can fully understand what you are describing here I am really enjoying the discussion. I am currently trying to re-learn embedded electronics and I think these kinds of experiments in software overlap heavily with that. Quote Link to comment Share on other sites More sharing options...
TheMontezuma Posted February 3, 2016 Share Posted February 3, 2016 I am also enjoying discussions here at the Atari Age. The most of us learn this way. Anyway I tried (under Linux) tcdrain() and sleep before the baud rate switch. I also replaced TCSANOW in: tcsetattr(mHandle, TCSANOW, &tios) with TCSADRAIN and with TCSAFLUSH to prevent changing speed while sending data, but DOS XE still reports problems. I remember the comments from the SIO2SD author (http://www.atari.org.pl/forum/viewtopic.php?pid=144470#p144470) about the TURBO systems emulation. He mentioned that there is no or very little technical information available and this was a try and error approach to achieve the goal... Quote Link to comment Share on other sites More sharing options...
HiassofT Posted February 3, 2016 Share Posted February 3, 2016 I did a quick test with Dos XE and AtariSIO in XF551 mode. When initializing a disk the command trace looks like this: command frame [ 32 4e 05 00 ] OK command frame [ 32 4f 05 00 ] OK command frame [ 32 4e 05 00 ] OK command frame [ 32 a1 05 00 ] OK command frame [ 32 d0 01 00 ] OK command frame [ 32 d0 02 00 ] OK command frame [ 32 d0 03 00 ] OK command frame [ 32 d0 04 00 ] OK command frame [ 32 d0 05 00 ] OKSo it does percom get/put/get, format in XF551 skew (all in standard speed) and then writes out sectors 1-5 in XF551 speed. Getting the timing right on XF551-speed read commands (i.e. transfer from SIO emulator to Atari) is no problem: send the ACK, wait as long as you want, switch speed, again wait if you want, then send the complete. 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): 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... so long, Hias 5 Quote Link to comment Share on other sites More sharing options...
morelenmir Posted February 3, 2016 Share Posted February 3, 2016 I did a quick test with Dos XE and AtariSIO in XF551 mode. When initializing a disk the command trace looks like this: command frame [ 32 4e 05 00 ] OK command frame [ 32 4f 05 00 ] OK command frame [ 32 4e 05 00 ] OK command frame [ 32 a1 05 00 ] OK command frame [ 32 d0 01 00 ] OK command frame [ 32 d0 02 00 ] OK command frame [ 32 d0 03 00 ] OK command frame [ 32 d0 04 00 ] OK command frame [ 32 d0 05 00 ] OKSo it does percom get/put/get, format in XF551 skew (all in standard speed) and then writes out sectors 1-5 in XF551 speed. Getting the timing right on XF551-speed read commands (i.e. transfer from SIO emulator to Atari) is no problem: send the ACK, wait as long as you want, switch speed, again wait if you want, then send the complete. 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... so long, Hias Maybe this is one of those situations where it is impossible to emulate an old school behavior in modern electronics. Is it possible this is why the SIO2SD chaps didn't add XF551 support? Going from what Hias says, is the problem that USB - or perhaps the FT232RL - does not transmit those signals quickly enough for RespeQT to respond in time? Quote Link to comment Share on other sites More sharing options...
lemiel Posted February 3, 2016 Share Posted February 3, 2016 (edited) Maybe this is one of those situations where it is impossible to emulate an old school behavior in modern electronics. Is it possible this is why the SIO2SD chaps didn't add XF551 support? Going from what Hias says, is the problem that USB - or perhaps the FT232RL - does not transmit those signals quickly enough for RespeQT to respond in time? Probably because DOS XE in Poland is not popular (and memory eater). But Synchromesh at 38400bps in firmware 3.1 is supported. But maybe not this high speed skew format command - I am not sure and my SIO2SD is broken. I will ask Steven Tucker if his SIO2PC USB could support this in APE with virtual com port driver. And also Simius if his SIO2FIFO could help in this. Edited February 3, 2016 by lemiel 1 Quote Link to comment Share on other sites More sharing options...
HiassofT Posted February 3, 2016 Share Posted February 3, 2016 Maybe this is one of those situations where it is impossible to emulate an old school behavior in modern electronics.I wouldn't say impossible, just very tricky. And you might need to think outside the box to get the job done. For example you might offload the timing-critical stuff to a separate µC, like APE/Atarimax does. Or find out if some USB-serial chip maybe supports asymmetric receive/transmit rates (then you could setup the receive rate before sending the ACK). Or maybe some USB-serial chips have a command that support exactly this, switch rate after transfer has finished. But exploiting such neat features comes at a cost: you limit the application to a few specific chips (or even a single one) and you might need to implement the whole low-level communication stuff yourself. BTDT: in AtariSIO I've implemented a Linux kernel driver to talk directly do a 16550/16C950 serial chip and handle all the timing critical stuff. XF551-mode and Ultraspeed are no problem, but of course this doesn't work at all with USB-serial adapters. Not a huge deal for desktop PCs, you can still buy PCI/PCIe 16C950 cards, but try finding a new notebook with an Expresscard slot... Is it possible this is why the SIO2SD chaps didn't add XF551 support?Implementing XF551 support in SIO2SD wouldn't be a big deal, quite certainly nobody thought it'd be useful. Why implement 38k XF551 speed when you already have 56k-125k Ultraspeed? Going from what Hias says, is the problem that USB - or perhaps the FT232RL - does not transmit those signals quickly enough for RespeQT to respond in time?It's not only about USB (which might be a showstopper in itself), it's also about latency in general. Getting down to ~100µs (somewhat guaranteed) latency is the realm of realtime OSes - your standard Windows/Mac/Linux desktop OS won't do the job. If you've setup your system correctly and if all drivers and applications are playing nicely using a Linux kernel with the RT preempt patches might be a solution - but this is also a rather niche area, certainly not mainstream. And it also won't help you with the (possible) huge latency of USB transactions. so long, Hias 2 Quote Link to comment Share on other sites More sharing options...
morelenmir Posted February 3, 2016 Share Posted February 3, 2016 I wouldn't say impossible, just very tricky. And you might need to think outside the box to get the job done. For example you might offload the timing-critical stuff to a separate µC, like APE/Atarimax does. Or find out if some USB-serial chip maybe supports asymmetric receive/transmit rates (then you could setup the receive rate before sending the ACK). Or maybe some USB-serial chips have a command that support exactly this, switch rate after transfer has finished. But exploiting such neat features comes at a cost: you limit the application to a few specific chips (or even a single one) and you might need to implement the whole low-level communication stuff yourself. BTDT: in AtariSIO I've implemented a Linux kernel driver to talk directly do a 16550/16C950 serial chip and handle all the timing critical stuff. XF551-mode and Ultraspeed are no problem, but of course this doesn't work at all with USB-serial adapters. Not a huge deal for desktop PCs, you can still buy PCI/PCIe 16C950 cards, but try finding a new notebook with an Expresscard slot... Implementing XF551 support in SIO2SD wouldn't be a big deal, quite certainly nobody thought it'd be useful. Why implement 38k XF551 speed when you already have 56k-125k Ultraspeed? It's not only about USB (which might be a showstopper in itself), it's also about latency in general. Getting down to ~100µs (somewhat guaranteed) latency is the realm of realtime OSes - your standard Windows/Mac/Linux desktop OS won't do the job. If you've setup your system correctly and if all drivers and applications are playing nicely using a Linux kernel with the RT preempt patches might be a solution - but this is also a rather niche area, certainly not mainstream. And it also won't help you with the (possible) huge latency of USB transactions. so long, Hias Absolutely *solid* info there Hias!!! Many, many thanks - two upvotes if that were possible!! Given this situation I'm starting to think that maybe DOS 4 would be a better platform for my retro system now - typing in listings and the like. I would hate for you guys who are working on RespeQT to spend huge amounts of time chasing this functionality that could be better spent on other, cooler features. DOS 4 is still authentically 80's and will do DS-DD on both SIO2SD and RespeQT while also offering the SS-DD for my Happy 1050. I still think that DOSXE is the best of the Atari releases, but is probably only appropriate used in conjunction with real hardware when/if I ever get hold of a real XF551. Sadly I do not think anyone would do a swap for three 1050's in exchange!!! Probably because DOS XE in Poland is not popular (and memory eater). But Synchromesh at 38400bps in firmware 3.1 is supported. But maybe not this high speed skew format command - I am not sure and my SIO2SD is broken. I will ask Steven Tucker if his SIO2PC USB could support this in APE with virtual com port driver. And also Simius if his SIO2FIFO could help in this. I would say you have hit the nail on the head there lemiel; actual data transfer might work with Synchromesh on the SIO2SD, but the $A1 format command - and therefore getting DOS XE to recognize the emulated drive as Synchromesh capable - does not. Quote Link to comment Share on other sites More sharing options...
atarixle Posted February 5, 2016 Share Posted February 5, 2016 (edited) some Linux builds: http://atarixle.ddns.net/download/respeqt/RespeQt_R2_debian_8.2_x86.tar.xz and http://atarixle.ddns.net/download/respeqt/RespeQt_R2_debian_8.2_x86_64.tar.xz read some lines: http://atarixle.ddns.net/download/#respeqt Edited February 5, 2016 by atarixle 1 Quote Link to comment Share on other sites More sharing options...
lemiel Posted February 6, 2016 Share Posted February 6, 2016 (edited) I had again badly understand that Atarimax SIO2PC USB is available via VCP, but it is not. But WinAPE is supporting $A1 command and Synchromesh. Edited February 6, 2016 by lemiel Quote Link to comment Share on other sites More sharing options...
lemiel Posted February 7, 2016 Share Posted February 7, 2016 XF551 $A1 (format with high speed skew) isn't a high speed command. It's a special case that still uses 19200 baud. If accurate sector timing isn't being tracked in the image, this can just be mapped to $21. 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? Quote Link to comment Share on other sites More sharing options...
HiassofT Posted February 7, 2016 Share Posted February 7, 2016 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? Since you mention Indus GT, Synchromesh and command $23 I think the problem here is with terminology. We are talking about 3 different things: - XF551 mode - Indus GT Synchromesh mode - 7-bit Turbo mode in SIO2SD I don't have an Indus GT and there doesn't seem to be any source code out for the newer 3.x SIO2SD firmware so I can't verify where they differ and/or where they are identical. I'm used to the terminology of "XF551 mode" = highspeed mode of the XF551, data-transfer at 38k4 and "Synchromesh" = highspeed mode of the Indus GT, usually at ~67k (not sure if that's actually "Super Synchromesh" or just "Synchromesh"). I think it's best to not call the XF551 mode "Synchromesh" (as Google translate of Atariki seems to indicate) but to keep them separate. The SIO2SD page says 7-bit turbo mode is "very similar to XF551 turbo mode". Similar doesn't mean identical to me So maybe SIO2SD supports the $A1 command but uses highspeed transfer instead of standard transfer as the XF551 does? so long, Hias Quote Link to comment Share on other sites More sharing options...
lemiel Posted February 7, 2016 Share Posted February 7, 2016 Synchromesh is 38k4 - protocol should be compatible with XF-551 high speed mode, SuperSynchromesh is 68k. Cannot say anything about SIO2SD 7-bit mode. And I think, do not know why, that nobody cares about precision in knowledge. But for SDrive we have sources, which we do not have for SIO2SD, so we can make them to support all turbo modes. Of course, there should be someone interested in it with spare time and enough knowledge. Quote Link to comment Share on other sites More sharing options...
HiassofT Posted February 7, 2016 Share Posted February 7, 2016 And I think, do not know why, that nobody cares about precision in knowledge.Better ask the authors of the Atariki page for details, I can't quite figure out what the google-translated text should actually mean... so long, Hias Quote Link to comment Share on other sites More sharing options...
lemiel Posted February 7, 2016 Share Posted February 7, 2016 (edited) And please do not take it as an offensive personal threat (I am not very good in English). You did much in this topic with your AtariSIO. I am trying to catch as much knowledge as possible and wrote it to be better known. Edited February 7, 2016 by lemiel Quote Link to comment Share on other sites More sharing options...
HiassofT Posted February 7, 2016 Share Posted February 7, 2016 And please do not take it as an offensive personal threat (I am not very good in English). You did much in this topic with your AtariSIO. I am trying to catch as much knowledge as possible and wrote it to be better known.No problem at all, I'm just curious as well. It's the first time I heard/read that someone called the XF551 mode Synchromesh and I'm wondering where that's coming from. Therefore my suggestion to ask the authors of the page - I'm not even sure if they say that the XF551 uses synchromesh mode or if they write something else on that wiki page. I can neither understand polish language nor the google translated stuff so long, Hias Quote Link to comment Share on other sites More sharing options...
TheMontezuma Posted February 7, 2016 Share Posted February 7, 2016 This is what the Atariki says. The authors call XF551 38400 baud mode "synchromesh". Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.